Build Engine

ПрототипыПравить

20 июня 2000 года Кен Сильверман открыл исходные коды движка Build Engine.

Версия 2.0 (первый и единственный официальный релиз) EDuke от Мэтта Сетлера (порт для запуска Duke Nukem 3D под современными операционными системами) был отослан в 3D Realms (исходники Duke Nukem 3D и EDuke были по-прежнему в закрытом доступе).
Работая с бета-версией 2.1, Мэтт пытался встроить исходники Build в исходники Duke, но проект был закрыт, прежде чем появились отлаженные публичные версии. Несколько команд, занимавшихся тотальной конверсией игр на Build, решили работать прямо с исходниками Build Engine Кена, а не исходниками Duke. Позже, в результате работы появился редактор mapster.
Долгое время портирование движка Build на многозадачные операционные системы было затруднено из-за необходимости очень больших участков памяти компьютера, которых не было в многозадачных ОС. Проблема решалась подключением виртуальной памяти.

Исходные коды Duke Nukem 3D

1 апреля 2003 года 3D Realms опубликовали исходные коды движка Duke Nukem 3D, несмотря на то что на протяжении длительного времени утверждали, что этого никогда не случится. После этого очень скоро появились порты Icculus и JonoF. Стало возможно без проблем играть в Duke Nukem 3D на GNU/Linux, Windows NT и других платформах, и интерес к портам усилился.

Райан Горден (icculus) с посторонней помощью создал первый порт движка с использованием SDL. Изначально это был порт для Linux, после для Cygwin и ещё позднее для чистого Win32 (при сборке использовался компилятор Watcom C++, который использовался и для оригинальной DOS сборки (с точностью до того, что для Windows использовался Watcom C++, а Build написан на обычном C). Шли слухи о портировании EDuke на Windows, но ничего не произошло.

Второй порт на Windows и позднее, на Linux от Джонатана Фаулера (JonoF). В отличие от icculus порта, этот порт использует DirectDraw вместо SDL на Windows и работает значительно быстрее. Долгое время движок не поддерживал мультиплеер, потом появилась поддержка мультиплеера только для двух игроков.

Система Polymost (Полимост)

Автор движка взялся за задачу обновления Build Engine до полноценного трёхмерного движка. В примечаниях к релизу JFDuke3D Сильверман пишет:

Когда 3D Realms опубликовали исходные коды Duke Nukem 3D, я думал, кто-нибудь сделает OpenGL- или Direct3D-порт. Через несколько месяцев я понял, что никто не работает над использованием настоящего аппаратного ускорения в Build, люди просто говорят, что это невозможно. Позже я осознал, что единственный способ чего-либо добиться, — это сделать всё самому.

Система отрисовки полимост использует OpenGL для аппаратного 3D ускорения. Также введена технология хайтайл (hightile), позволяющая заменять стандартные игровые ресурсы более качественными в различных форматах.

Полимост был использован в JFBuild от Джонатана Флауера, JFDuke3D, JFSW, и других портов основанных на этой кодовой базе.

Публикация исходных кодов EDuke 2.0 позволила добавить к EDuke возможности порта JonoF и движка Build Engine 2.1, вскоре появился EDuke32, но на сегодняшний день в разработке находится только EDuke.

Исходник последней личной бета-версии EDuke 2.1 (которая никогда не была доведена до релиза) был также опубликован после исходных кодов EDuke 2.0. Также появился порт, основанный на Icculus, имеющий кодовое название wineduke, разработка которого на сегодняшний день не ведётся.

EDuke содержал элементы исходных кодов Nam и WW2 GI, что, возможно, упростило разработку. Также была попытка воссоздать Blood на движке DarkPlaces и назвать Transfusion, но на 2006 год этот порт находится ещё на стадии ранней разработки.

Исходные коды Shadow Warrior были опубликованы 1 апреля 2005 года, и JonoF опубликовал порт на игру 2 апреля 2005 года. Правда, он утверждает, что имел доступ к исходным кодам Shadow Warrior за неделю до их публикации.

СсылкиПравить

• Официальный сайт движка (англ.)
• Сайт порта Icculus (англ.)
• Сайт Джонатана Фаулера, посвящённый Build Engine (англ.)
• JonoF’s Duke Nukem 3D порт (JFDuke3D) (англ.)
• Категория на ODP (англ.)
• Страница с информацией о неопубликованной игре ‘Fate’ (англ.)
• Порт c ProAsm, основанный на JonoF’s JFSW (англ.)

Настраиваем ssh

SSH — удивительный и многофункциональный инструмент с широким набором возможностей. Реверсивные туннели — одна из многих, и именно она нас сегодня выручит. Реверсивный туннель позволяет удалённому компьютеру обращаться к своему локальному порту, а все обращения пробрасываются к локальному порту на той машине с которой производится ssh подключение. Подробнее об этой и многих других возможностях ssh можно почитать в документации или на хабре, например тут или тут.

Сначала на ноутбуке сгенерируем новые ключи для ssh клиента. Генерировать будем ключевую пару ed25519. Ed25519 — это современный и очень быстрый алгоритм аутентификации использующий очень эффективную эллиптическую кривую curve25519, созданную известным криптографом Даниелем Бернштейном. Она детально исследована экспертами по криптографии и имеет наибольшее доверие со стороны сообщества. Ed25519 использует очень короткие ключи, сохраняя необходимую криптостойкость, превосходит по производительности схемы аутентификации использующие стандартные эллиптические кривые рекомендованные NIST, и на добрый порядок производительнее схем с аутентификацией по RSA. Скорость установки соединения для нас будет очень важна, поэтому используем её:

ssh-keygen -o -t ed25519 -f ~/.ssh/id_ed25519_android_builds_server -C «key_for_android_build_server» -P «»

Теперь заранее подготовим алиас для будущего подключения в ssh конфиге. Алиас я назову android_builds_server. Открываем файл ~/.ssh/config, и дописываем в конец новую запись:

Теперь идём наш удалённый ПК и заходим в терминал от root. В моём случае это виртуальная машина на компьютере, у вас это может быть консоль в VPS. Самым первым делом, как и на любой машине, нам потребуется правильно сконфигурировать ssh сервер.

Я хочу создать отдельного пользователя на компьютере для выполнения моих android сборок, назову его builder. Именно им будет осуществляться вход в систему по ssh. Для этого на сервере сначала создадим этого пользователя, обязательно с домашней директорией, затем назначим ему пароль и добавим в группу sudo:

Конфигурация ssh будет играть большое значение в будущем. Нам потребуется максимальная скорость установки соединения и как можно более быстрая скорость передачи данных. Вот так выглядит мой конфиг.

Самое важное для нас здесь:

• Port 34567 — меняю порт на нестандартный чтобы боты не беспокоили и не засоряли логи;
• HostKey /etc/ssh/ssh_host_ed25519_key — удаляю использование всех ключей сервера кроме ed25519;
• Protocol 2 — чтобы исключить использование старых небезопасных версий ssh;
• «PermitRootLogin no», «PubkeyAuthentication yes», «PasswordAuthentication no», «PermitEmptyPasswords no», «ChallengeResponseAuthentication no» — оставляем аутентификацию только по публичным ключам и запрещаем всё остальное;
• GatewayPorts yes — важный параметр, имеющий по умолчанию значение «no». Позволяет использовать ssh туннели, которые нам потребуются;
• Compression yes — опционально. Я не делал точных замеров, но субъективно мне показалось, что использование этого параметра ускоряет передачу файлов через ssh
• Subsystem sftp /usr/lib/openssh/sftp-server — обязательно оставляем, т.к. нам потребуется передача файлов.

Сохраним конфиг и проверим что всё сделано без ошибок:

Если всё в порядке, то перезапускаем ssh:

systemctl restart sshd

Также я устанавливаю и включаю NTP, чтобы в будущем не было проблем при TLS соединениях связанных с рассинхронизацией времени:

timedatectl set-timezone Europe/Moscowapt install ntpsystemctl enable ntp

Отлично. Теперь с ноутбука можно будет подключаться к удалённому ПК по алиасу, вот так:

Разберёмся с запуском ssh туннеля.

Обратите внимание! ssh туннель и nginx-прокси нужны вам только в случае если в вашем проекте используется ресурс во внутренней сети компании. В моём случае это maven репозиторий. Если в вашем проекте такой проблемы нет, то смело пропускайте команды по настройке ssh туннелей, а с ними и всю последующую секцию по настройке nginx, и сразу переходите к разделу «Настраиваем android build-tools».

Запуск ssh туннеля делается одной несложной командой, она выполняется с ноутбука:

ssh -f -N android_builds_server -R 33333:localhost:33333

• -R — этот флаг указывает на необходимость пробросить порт с удалённой машины на локальную. Вариацией передаваемых параметров у него несколько но нас интересует только такой ПОРТ_НА_УДАЛЁННОЙ_МАШИНЕ:ХОСТ_НА_КОТОРЫЙ_ПРОБРАСЫВАЕТСЯ_ТУННЕЛЬ:ПОРТ_НА_ХОСТЕ. В нашем случае номера портов будут совпадать на локальной и удалённой машине, а хостом будет сам ноутбук
• -f — флаг указывающий на необходимость сразу перейти в бэкграунд а не открывать собственно шелл
• -N — этот флаг указывает не выполнять никаких команд на удалённом хосте. В man-е по ssh он как раз описан как флаг используемый при операции проброса портов

К сожалению, туннели ssh имеют неприятное свойство терять соединение и повисать в таком состоянии в системе. Если порт уже занят процессом, то новый ssh туннель открыться не сможет, поэтому перед их запуском всегда желательно проверять и, при необходимости, закрывать текущие открытые туннели. Как назло, никакой удобной команды для этого не существует, только выцеплять их в списке запущенных процессов и посылать им kill. Я делаю это вот так:

Запомним это. На этом настройка ssh на обеих сторонах закончена. Теперь настроим часть касающуюся nginx.

Выбор инструментов

Проблема с токеном, в некотором смысле — самое простое неизвестное в уравнении, потому что вариантов действия здесь не много. Токен обязательно должен быть при мне. Подключение может единовременно существовать только одно, поэтому и решение здесь может быть только одно.

Придётся поднимать подключение к VPN на рабочем ноутбуке, а доступ к ресурсам компании обеспечивать домашнему ПК транзитом через ноутбук. Как именно это сделать — есть несколько вариантов, но главное — обеспечить достаточную транспортную безопасность. Т.е. туннель между компьютером и ноутбуком обязан быть зашифрованным, а тут я бы хотел полагаться только на открытые, проверенные и надёжные инструменты.

В конечном счёте, для сборки, по существу, нужно только два ресурса компании — git и maven. А поскольку они оба сетевые, то это значительно упрощает дело. Собственно, тут для решения проблем, на сцену выходят nginx c его возможностью проксирования трафика, и ssh с его возможностью создания реверсивных туннелей (reverse port forwarding).

На удалённом компьютере я поднял отдельную виртуальную машину с Ubuntu server 20.04.5. В целом, я буду расписывать все шаги так, будто бы мы настраиваем абсолютно новую систему. В вашем случае это может быть свежая арендованная VPS например.

По операционной системе на локальном компьютере — пока что здесь будет только инструкция для MacOS. Для Linux она будет отличаться только обращением к пакетному менеджеру используемом в вашем дистрибутиве и командами по запуску и остановке сервисов. Для Windows же в плане настройки локальной машины всё также будет похоже и логика команд будет такой же, но, конечно, установить и работать с ПО придётся способами специфическими именно для этой операционной системы.

Поскольку мой ноутбук на MacOS, я использую brew для того чтобы устанавливать ПО. На ноутбуке нам понадобятся некоторые инструменты. Скачаем их с помощью brew:

brew install coreutils curl nginx rsync

Собственники и руководствоПравить

• Ван Чуаньфу (Wang Chuan-fu, род. 8 апреля 1966 года) — основатель, председатель совета директоров и президент компании. Ему принадлежит 17,64 % акций BYD Company.
• Люй Синъян (Lv Xiang-yang, род. в 1962 году) — сооснователь, вице-председатель компании. До создания компании в 1995 году работал в отделении Народного банка Китая в Чаоху. Ему принадлежит 13,55 % акций BYD Company.

Настраиваем mirakle

Пришло время вернуться непосредственно к самому коду проекта.

Для начала проговорим очевидное. Что такое сборка? Это когда мы берём файлы с исходным кодом, компилируем их предусмотренным образом, и получаем на выходе результат. Довольно просто и логично.

Изначально я планировал сначала либо настроить на удалённом компьютере проброс порта для git, таким же способом, каким пробросил его для доступа к maven репозиторию, и пользоваться им вызывая команды оттуда, либо же копировать исходный код на удалённую машину через rsync или scp, чтобы просто получить доказательство реализуемости такого подхода — редактировать код на локальной машине, а собирать код на удалённой. Мне стало интересно, а не реализовал ли кто-то уже подобную схему в виде готового инструмента делающего именно это, и, когда я поискал нечто похожее на github, то с удивлением обнаружил, что, во-первых, такое решение действительно уже существует, а, во-вторых, оно почему-то не очень популярно, не особо находится в поиске в интернете, и о нём почему-то не рассказывают публично.

Это gradle плагин mirakle.

Суть его работы примерно в следующем:

• Он использует rsync и ssh для безопасной передачи файлов проекта с локальной машины на удалённую.
• Передаёт через ssh на удалённую машину команду которая вызывает сборку проекта из переданных исходников проекта.
• По завершению процесса сборки копирует получившийся результат с удалённой машины на локальную, опять же через связку rsync ssh

Никакой магии, всё просто и гениально.

На самом деле плагин mirakle — это форк другого, намного более популярного проекта — mainframer. Mainframer — более универсальный инструмент и предназначен как раз для реализации вот такой вот схемы удалённой сборки. Им можно собирать например проекты бэкенд приложений Java, и не только. Вызывается mainframer вот так (в целом, по команде как раз можно предположить то как он работает):

mainframer ./gradlew build

mainframer — это standalone инструмент, в то время как mirakle предлагает интеграцию в виде gradle плагина, что очень удобно, однако если вызов mainframer-а прямой, не сложный, и для mainframer существует, в том числе, интеграция в виде плагина для Intellij Idea, позволяющего включать/выключать сборку на удалённой машине прямо из интерфейса IDE, то для mirakle придётся немного поколдовать руками и заготовить пару скриптов для включения и выключения режима удалённой сборки, но это не сложно и делается один раз.

На самом деле, всё что нам потребуется — иметь готовый настроенный ssh доступ на удалённую машину, подготовить на ней все необходимые инструменты для сборки андроид проектов (всё это уже готово), и грамотно прописать конфигурацию mirakle в части параметров для вызова rsync, и исключений, чтобы не передавать ничего лишнего через ssh туннель на удалённую машину и обратно.

Пожалуй, самая интересная часть в том, что mirakle делает всё это с помощью init скрипта gradle. Gradle позволяет описывать логику скриптов сборки не только для каждого отдельного проекта, но и для всей локальной машины целиком. Например применять при запуске gralde какие-то опции или добавлять логику глобально, для всех проектов сразу, не важно в каком именно месте он был вызван. При этом, там доступен весь тот же самый синтаксис, как и в случаях с обычными проектами. Например, можно применить gradle плагин, да, ко всем проектам сразу. Именно этой возможностью и пользуется mirakle.

Если представить очень грубо, то init скрипт требуется для того чтобы при получении команды сначала можно было предварительно и заблаговременно правильным образом вызвать rsync, а затем к команде с вызываемой таской gradle добавить префикс ssh ALIAS и таким вот образом вызвать её на удалённой машине вместо локальной.

Плагину mirakle необходимо проинициализироваться именно в init скрипте, а не на уровне проекта, чтобы всё было осуществимо, но это не проблема. Мы подготовим небольшой скрипт который будет использовать плагин только с текущим проектом и не оказывать влияния на остальные.

По умолчанию в системе нет ни одного init скрипта gradle, потому что в большинстве случаев все необходимые параметры сборки настраиваются на уровне проекта, а рядовому пользователю в них обычно нет никакой острой необходимости. Случаи использования чего-то подобного — достаточно редки. Лично, я с ними ни разу не сталкивался до этой ситуации.

Init скрипты располагаются в директории ~/.gradle. Перейдём в неё и создадим внутри директорию init.d. После этого внутри ~/.gradle/init.d/ создадим файл с init скриптом gradle. Назовем его mirakle.gradle. В моём случае конфигурация выглядит вот так:

Как видим, самым первым делом, перед инициализацией проекта подключается плагин mirakle, который подтягивается из репозитория mavenCentral.

Далее идёт блок rootProject в котором уже располагается блок mirakle. В нём указываются все необходимые настройки.

На этом с конфигурацией mirakle всё. Можно запускать сборку проекта, и, если вы всё сделали правильно, то файлы проекта отправятся на удалённую машину, там будет вызвана сборка, и: когда она закончится, результирующий apk будет передан на локальную машину и с неё отправлен на устройство. При этом можно использовать все стандартные вещи из UI Android Studio — отладку и т.д. Поскольку apk файл находится локально, то никаких пробросов adb на удалённый хост не потребуется. Смело нажимайте кнопку Run или Debug и увидите в логе вызываемых в процессе сборки gradle тасок новые :uploadToRemote, :executeOnRemote, :downloadFromRemote. Первая сборка займёт некоторое время, потому что удалённой машине необходимо будет выкачать дистрибутив gradle, и подготовить кэши, зато последующие будут проходить без задержек.

Если вы настраивали всё на удалённой машине руками по этой инструкции, а не с помощью приложенного скрипта из репозитория, то не забудьте зайти на удалённую машину, перейти в директорию с проектом, находящуюся в /home/builder/.mirakle/PROJECT_NAME руками создать файл local.properties. В этот файл нужно руками поместить строку содержащую путь к android sdk:

Коммерческие автомобилиПравить

Прописывать все эти параметры каждый раз, создавать или изменять init-скрипт gradle вручную — неудобно, поэтому я подготовил репозиторий со скриптами, которые позволяют быстро настроить и локальную машину, и удалённую машину, и одной командой включать сборку на удалённой машине и также одной командой возвращаться в режим обычной локальной сборки. Вот ссылка:

Советую сразу добавить строку в файл .gitignore, которая исключит эти файлы для добавления и случайной отправки в remote git репозиторий:

Все основные параметры сборки на удалённой машине необходимо править в  файле remote_android_config.properties.

Для включения и выключения режима сборки на удалённой машине требуется выполнять remote_android_build_on.sh и remote_android_build_off.sh соответсвенно.

Но прежде чем их выполнять необходимо подготовить удалённую машину.

Разберём два отдельных случая:

В первом случае порядок работы такой:

открываем файл remote_android_config.properties и изменяем значения в этих полях на те которые соответствуют вашим:

Заполняем значение параметра server.sdk.dependencies по аналогии со значением по умолчанию значениями для вашего проекта.

Если вам требуется прокинуть доступ в частный maven репозиторий, то установите nexus.proxy.required в true и настройте nginx и build.gradle из инструкции выше, в разделе про настройку nginx. Порт можно оставить 33333, если только вы не используете этот порт для каких-то своих задач.

Запустите remote_android_server_setup.sh для того чтобы убедиться что все необходимые зависимости установлены. Зависимости, которых не хватает на сервере будут установлены во время работы скрипта.

Всё готово. Теперь вы можете запускать remote_android_build_on.sh для включения удалённой сборки и remote_android_build_off.sh для возврата к сборке на локальной машине.

В этом случае порядок действий такой:

У вас должен быть IP адрес сервера. Открываем файл remote_android_config.properties и изменяем значения в этих полях на те которые соответствуют вашим:

Также как и в первом случае заполните значение параметра server.sdk.dependencies значением для вашего конкретного проекта. Блок с параметрами содержащий алиас, имя, пароль, порт и ключ заполнять в вашем случае не нужно. Эти значения будут установлены во время работы скриптов настраивающих окружение.

Сначала необходимо подготовить локальную часть ssh. Запускайте remote_android_local_prepare.sh. Этот скрипт сгенерирует новые ed25519 ключи и конфигурацию для ssh на локальной машине. В дальнейшем повторять это действие не потребуется.

Затем выполняйте remote_android_server_prepare.sh. Этот скрипт настроит ssh на удалённой машине. Обратите внимание что ssh попросит у вас дважды ввести пароль root — один раз чтобы отправить скрипт настройки ssh на удалённый ПК, второй раз — чтобы его выполнить. Это делается один раз для удалённого ПК. Далее доступ к машине будет осуществляться по алиасу, без ввода пароля, с использованием авторизации на публичных ключах.

После этого выполняйте remote_android_server_setup.sh. Этот скрипт установит все необходимые зависимости и полностью подготовит систему к сборке проектов. Его также достаточно выполнить один раз, однако, если в будущем вы будете добавлять в properties файл с конфигурацией новые версии android или build-tools, то этот скрипт будет необходимо вызвать заново, чтобы на удалённой машине установились новые зависимости.

Легковые автомобилиПравить

Для сборки android проекта на удалённой машине нам потребуется подготовить все необходимые инструменты.

Зайдём на удалённый ПК по ssh. Для начала нам потребуется JDK. Установим его через apt:

sudo apt install openjdk-11-jdk -y

Далее нам нужны сами инструменты для сборки — build-tools, platform-tools и т.д. Обычно они скачиваются через SDK manager в Android Studio, но в случае машины на которой нет графической оболочки, придётся поступить немного по другому. Нам потребуется набор CLI инструментов для работы с Android от Google. Найти их можно там же где располагаются ссылки на скачивание Android Studio. Вот по этому адресу:https://developer.android.com/studio/index.html

Прямо под ссылками на скачивание Android Studio есть блок «Command line tools only». Нас интересует версия под Linux. Выцепим её прямо из терминала чтобы не скачивать через браузер и не передавать с ноутбука отдельно.

Для начала создадим структуру папок под них.Нам необходимо чтобы конечный путь к исполняемому файлу sdkmanager был вот таким:

mkdir -p Android/Sdk/cmdline-tools/latest

Переходим в папку с SDK:

Загружаем страницу через curl и грепаем с неё ссылку на архив:

Полученную ссылку загружаем через wget, а затем распаковываем через unzip так чтобы содержимое оказалось в папке ~/Android/Sdk/cmdline-tools/latest

После этого откроем ~/.bashrc и пропишем назначение переменных окружения, а также пропишем все необходимые пути в PATH:

JAVA_HOME=»/usr/lib/jvm/java-11-openjdk-amd64″
ANDROID_HOME=»/home/builder/Android/Sdk»
ANDROID_SDK_ROOT=»/home/builder/Android/Sdk»
export JAVA_HOME
export ANDROID_HOME
export ANDROID_SDK_ROOT
PATH=»$JAVA_HOME/bin:$ANDROID_HOME:$ANDROID_HOME/cmdline-tools/latest/bin:$PATH»

Сохраняем ~/.bashrc, готово.

Теперь в переменной окружения PATH есть путь к скачанному sdkmanager, и мы можем установить всё что нужно для сборки. Но sdkmanager ничего не даст делать пока не принять лицензионные соглашения. Обычно это также как и управление зависимостями производится в диалоговом окне в Android Studio, но предусмотрен и CLI способ. Выполняем:

sdkmanager —sdk_root=/home/builder/Android/Sdk —licenses

Нас попросит подвердить то что мы ознакомлены с условиями лицензионного соглашения. Пишем «yes».

Затем скачиваем необходимые для сборки зависимости:

sdkmanager «platform-tools»sdkmanager «platforms;android-30″sdkmanager «build-tools;30.0.3»

Обратите внимание! Версии platforms и build-tools должны соответствовать версиям в проекте, который планируется собирать на этой удалённой машине. В моём случае эти значения такие, но в вашем случае могут отличаться.

Вот и всё, с этого момента мы можем клонировать на нашу удалённую машину проект из git репозитория и вызывать заветный ./gradlew assembleDebug, сборка будет работать.

На этом настройка удалённого ПК закончена.

• Лицензия на сайте icculus.org. Дата обращения: 16 июня 2008. Архивировано 14 мая 2008 года.
• Игры, похожие на Doom — Ликвидатор: 1 и 2. Дата обращения: 11 ноября 2012. Архивировано 24 июня 2016 года.

ИсторияПравить

На локальной машине настроим nginx в режиме прокси. Мы его уже установили ранее через brew. Находим в MacOS файл с конфигурацией nginx по пути /usr/local/etc/nginx. Необходимо добавить в него блок для создания прокси. Редактируем файл конфигурации следующим образом:

Мы будем использовать локальный порт 33333 для того чтобы принимать запросы и отправлять их в maven репозиторий во внутренней сети компании через VPN туннель.

Самое важное здесь это:

• listen 127.0.0.1:33333 — принимаем только локальные подключения и указываем номер порта;
• proxy_set_header Host privaterepo.nexus.company.com — поскольку репозиторий используеn TLS и может делить адрес с другим ресурсом, мы обязаны установить заголовок Host со значением доменного имени репозитория;
• блок location / и параметр proxy_pass — проксируем любые пришедшие на локальный сервер на настоящий мавен репозиторий.

Проверим что конфигурация создана без ошибок и nginx будет работать:

Обратите внимание, что в этот момент вы уже должны быть подключены к VPN сети компании, иначе nginx может не запуститься по причине недоступности хоста указанного в блоке конфигурации прокси сервера.

Теперь перезапускаем nginx:

brew services stop nginx brew services start nginx

Отлично. На этом настройка nginx закончена. Прокси сервер запущен.

Попробуем убедиться что запросы к maven смогут корректно выполниться.

В моём случае maven репозиторием был Nexus, располагающийся во внутренней сети, обратиться к нему можно только по HTTPS протоколу, и для соединения используется самоподписанный сертификат. Для подтверждения доступа используется basic-auth, который поддерживает curl.

Для начала попробуем взять curl и получить артефакт из maven репозитория напрямую, также как это делает во время сборки gradle:

Видим что запрос успешно выполнился и библиотека была выкачана. Теперь попробуем сделать тоже самое, но на этот раз обратимся не напрямую на maven репозиторий, а на наш свеженастроенный локальный nginx-прокси:

Работает! Файл также был успешно загружен. Теперь осталось только убедиться в том что файл сможет загрузиться через реверсивный туннель.

Запустим туннель, предварительно отправив команду на прибитие уже запущенных процессов:

Заходим на сервер:

Теперь с удалённого компьютера через ssh туннель мы должны иметь возможность обратиться к запущенному на MacOS nginx и поэтому запросы к maven репозиторию должны успешно выполниться. Номер порта на обоих машинах одинаковый, поэтому пробуем:

Файл успешно загружен. Замечательно. Самая сложная часть работы сделана.

Осталось только немного поправить скрипт сборки проекта. К сожалению, без этого никак, но зато поменять нужно всего несколько значений, а работать всё будет одинаково вне зависимости производим мы локальную сборку или сборку на удалённом компьютере. Главное откиньте эти изменения в отдельный changelist в git плагине в Android Studio чтобы случайно не запушить это дело в ремоут.

Нас интересует корневой скрипт сборки — это файл build.gradle в корне проекта. Там есть два блока — buildscript/repositories и allprojects/repositories в каждом из них перечислены используемые в проекте maven репозитории.

Возьмём блок с репозиторием который находится во внутренней сети компании. Сейчас он выглядит так:

Заменим настоящий адрес репозитория на адрес nginx-прокси, и обязательно добавим параметр сигнализирующий о том, чтобы игнорировать ошибки SSL соединения связанные с самоподписанным сертификатом, т.к. на удалённой машине установленных корневых сертификатов компании не будет!

Должно получиться вот так:

С такой конфигурацией все нужные артефакты смогут подтянуться при сборке как на локальной машине, так и на удалённой. Отлично! Это успех и доказательство того что схема абсолютно реальна. Теперь можно вернуться к шагам настройки удалённого компьютера, которые необходимо выполнить вне зависимости от того требуется нам проброс доступа к maven репозиторию во внутренней сети или нет — загрузить необходимые для выполнения сборки android проектов зависимости.

Дочерние компанииПравить

• BYD Lithium Batteries Co., Ltd. (КНР, 100 %, производство литий-ионных аккумуляторов)
• Shanghai BYD Co., Ltd. (КНР, 100 %, производство литий-ионных аккумуляторов и солнечных батарей)
• BYD Auto Co., Ltd. (КНР, 100 %, производство автомобилей)
• Huizhou BYD Battery Co., Ltd. (КНР, 100 %, производство литий-ионных аккумуляторов)
• BYD Auto Industry Co., Ltd. (КНР, 100 %, производство автомобилей и рельсового транспорта)
• BYD Electronic (International) Co., Ltd. (Гонконг, 66 %, инвестиционный холдинг)
  BYD Precision Manufacture Co., Ltd. (КНР, 66 %, производство комплектующих к мобильным телефонам и другой электронике)Huizhou BYD Electronic Co., Ltd. (КНР, 66 %, высокоточная сборка)Xi’an BYD Electronic Co., Ltd. (КНР, 66 %, производство комплектующих к мобильных телефонам)
• BYD Precision Manufacture Co., Ltd. (КНР, 66 %, производство комплектующих к мобильным телефонам и другой электронике)
• Huizhou BYD Electronic Co., Ltd. (КНР, 66 %, высокоточная сборка)
• Xi’an BYD Electronic Co., Ltd. (КНР, 66 %, производство комплектующих к мобильных телефонам)
• BYD Auto Sales Co., Ltd. (КНР, 100 %, продажа и гарантийный ремонт автомобилей)
• Changsha BYD Auto Co., Ltd. (КНР, 100 %, производство автомобмлей и комплектующих)
• BYD (Shangluo) Industrial Co., Ltd. (КНР, 100 %, производство солнечных батарей)

Технические характеристикиПравить

Сектора — основная составляющая геометрии уровня. С секторами можно работать в реальном времени. Их параметры (высоты, форма, углы наклона) не требуют пересчета при изменении. Это позволяет делать окружение в игре более интерактивным, например разрушаемым (как в Blood).

Разработчики использовали зарезервированные спрайты (секторэффекторы), которым присваивались специальные верхние (hi-tags) и нижние (lo-tags) теги (числа с определённым смыслом), которые позволяли делать мир более динамичным (например двери, взрывающиеся бочки и т. п.). Такие же теги могут быть заданы полу и потолку сектора для придания особых свойств. Например игрок, проходящий по полу со специальными тегами, проваливался вниз и выпадал из другого потолка со специальными тегами. На практике это применялось для создания водоёмов. Сектору могут быть присвоены теги, которые превращают его в дверь или лифт. Сектора могут перекрывать друг друга, чтобы один не был виден из-за другого (если в такой ситуации видно сразу два сектора, то с сильнейшими искажениями). Это позволяло создавать, например, вентиляционные шахты, находящиеся над помещениями (правда это значительно затрудняло дальнейшую работу с этой частью уровня, так как почти всё время разработчик проводит в двухмерном режиме). Также это позволяет создавать невозможные с точки зрения физики, миры (например система помещений в здании, которая больше самого здания). Все эти эффекты делали мир похожим на трёхмерный, пока не появился движок Quake.

Для сортировки плоскостей в Z-порядке Doom использовал BSP-дерево, строившееся каждый раз при сохранении WAD’а. В отличие от Doom, Build использовал механизм порталов.

Отрезки, разделяющие два сектора, объявляются «порталами». Движок сначала рисует сектор, в котором находится зритель, запоминая все порталы. После этого он рекурсивно запускает рендеринг секторов, которые видны сквозь порталы (не трогая того, что уже нарисовано).

В 2,5-мерном движке этот метод оказался лучше BSP-дерева по таким причинам:

• Сектора можно двигать и вращать. Пускай это движение очень ограниченно (движение возможно только в пределах одного сектора) — даже это прогресс по сравнению с Doom’ом. Что привело к очень «живому» миру — горизонтальные «лифты» (повсеместно во 2 части Duke Nukem 3D — Lunar Apocalypse), вагон метро (Duke Nukem 3D — уровень Rabid Transit), разрушаемые объекты (Blood) и т. д.
• Doom разбивает стены (linedefs) на сегменты (segs). Портальный движок никогда не делит стены на части — что приводит к более высокой скорости рендеринга на сложных сценах. К тому же, сложность невидимых частей уровня никоим образом не влияет на производительность рендерера. На машинах класса Pentium-100 можно свободно запускать Duke Nukem 3D в разрешении 640×480 — ни один порт Doom’а на такое не способен.
• Наконец, в портальном движке предварительные вычисления минимальны — а значит, пользователь может редактировать уровень в трёхмерном режиме.

Поздние версии движка позволяли заменять изображения в игре на трёхмерные объекты, сделанные из вокселей. Эта возможность появилась слишком поздно для того, чтобы использовать её в Duke Nukem 3D, но была использована в других играх. Blood использует воксели для оружия, патронов, улучшений, и различных украшений (таких как надгробия на уровне Cradle to Grave).

Несколько лет Кен работал над движком Voxlap, берущим за основу воксельную технологию.

Комната над комнатой

Некоторые игры на движке Build engine использовали трюк с объединением пола и потолка у двух секторов. Создание таких конструкций во время редактирования уровня было затруднено, поэтому часто сектора перемещались во время загрузки уровня (что упрощало расчёты, выполняемые движком для отрисовки). Технология комната-над-комнатой применялась в Shadow Warrior (смещение секторов во время загрузки карты) и Blood (без смещения). Сама технология не была заложена в движок, до неё додумались создатели уровней.