Кастомные порты под платформу

Подобно Собственные модули на C++ многоплатформенная архитектура в Godot спроектирована таким образом, чтобы создавать порты под платформу без изменения кода.

Примером пользовательского порта для платформы, распространяемого независимо от движка, является FRT, предназначенный для одноплатных компьютеров. Обратите внимание, что этот порт для платформы в настоящее время ориентирован на Godot 3.x; поэтому он не использует абстракцию DisplayServer, появившуюся в Godot 4.

Вот некоторые причины создания пользовательских портов платформы:

You want to port your game to consoles (see also the Godot website on console support), but wish to write the platform layer yourself. This is a long and arduous process, as it requires signing NDAs with console manufacturers, but it allows you to have full control over the console porting process.
Вы желаете перенести Godot на экзотическую платформу, которая в настоящее время не поддерживается.

Если у вас есть вопросы по созданию порта для пользовательской платформы, смело задавайте их на канале #platforms в Godot Contributors Chat.

Примечание

Godot — современный движок с современными требованиями. Даже если вы планируете запускать на целевой платформе только простые 2D-проекты, он всё равно требует такого объёма памяти, что его невозможно запустить на большинстве ретро-консолей. Для справки: в Godot 4 пустой проект без видимых элементов требует около 100 МБ оперативной памяти для запуска на Linux (50 МБ в режиме headless).

Если вы хотите запустить Godot на платформах с сильно ограниченными ресурсами памяти, более старые версии Godot предъявляют меньшие требования к памяти. Процесс портирования аналогичен, за исключением того, что DisplayServer не отделяется от синглтона OS.

Официальные платформы для портирования

Официальные порты платформы можно использовать в качестве справочного материала при создании собственного порта платформы:

Хотя код платформы обычно самодостаточен, из этого правила есть исключения. Например, общие для нескольких платформ аудиодрайверы и драйверы рендеринга находятся в папке drivers/ исходного кода Godot.

Создание собственного порта платформы

Создание собственного порта платформы — это масштабная задача, требующая предварительного знания SDK этой платформы. Объём необходимых работ варьируется в зависимости от необходимых функций:

Требуемые характеристики порта платформы

Как минимум, порт платформы должен содержать методы из синглтона OS, реализованные для сборки и использования в режиме headless. В папке платформы также должно находиться векторное изображение logo.svg (32×32). Этот логотип отображается в диалоговом окне «Экспорт» для каждого шаблона экспорта, ориентированного на данную платформу.

См. эту реализацию для платформы Linux/*BSD в качестве примера. См. также заголовочный файл OS singleton для справки.

Примечание

Если ваша целевая платформа — UNIX-подобная, рассмотрите возможность наследования от класса OS_Unix, чтобы большая часть работы выполнялась автоматически.

Если платформа не является UNIX-подобной, вы можете использовать Windows-порт в качестве ссылки.

detect.py file

В папке платформы необходимо создать файл detect.py со всеми реализованными методами. Этот файл необходим SCons для определения платформы как допустимого варианта для компиляции. См. файл detect.py для платформы Linux/*BSD в качестве примера.

Все методы должны быть реализованы в detect.py следующим образом:

is_active(): может использоваться для временного отключения сборки для платформы. Обычно всегда возвращает True.
get_name(): Возвращает видимое пользователю имя платформы в виде строки.
can_build(): Возвращает True, если хост-система может выполнить сборку для целевой платформы, и False в противном случае. Не добавляйте сюда медленные проверки, так как они выполняются при запросе пользователем списка платформ. Для расширенных проверок зависимостей используйте configure().
get_opts(): Возвращает список параметров сборки SCons, которые могут быть определены пользователем для этой платформы.
get_flags(): Возвращает список переопределенных флагов SCons для этой платформы.
configure(): выполнение настройки сборки, например выбор параметров компилятора в зависимости от выбранных параметров SCons.

Дополнительные возможности порта платформы

На практике, если вы хотите видеть что-либо на экране и управлять устройствами ввода, безголового режима недостаточно. Для большинства игр может также потребоваться вывод звука.

Некоторые ссылки в этом списке указывают на реализацию платформы Linux/*BSD в качестве эталона.

Один или несколько DisplayServer с реализованными методами управления окнами. DisplayServer также поддерживает такие функции, как поддержка мыши, сенсорных экранов и драйвер планшета (для ввода пером). См. заголовок DisplayServer singleton для справки.
- Для платформ, не поддерживающих полноценную работу с окнами (или если это неактуально для создаваемого вами порта), большинство функций управления окнами можно оставить практически нереализованными. Эти функции можно настроить только на проверку идентификатора окна MAIN_WINDOW_ID, а некоторые операции, такие как изменение размера, можно привязать к разрешению экрана платформы (если это применимо). Любая попытка создания или изменения других идентификаторов окон может быть отклонена.
Если целевая платформа поддерживает рассматриваемые графические API: Контекст рендеринга для Vulkan, Direct3D 12 OpenGL 3.3 или OpenGL ES 3.0.
Обработчики ввода для клавиатуры и контроллера.
Один или несколько audio drivers. Аудиодрайвер может находиться в папке platform/ (это сделано для платформ Android и Web) или в папке drivers/, если этот аудиодрайвер может использоваться на нескольких платформах. См. заголовок AudioServer singleton для справки.
Обработчик сбоев, для вывода трассировок сбоев при сбоях игры. Это упрощает устранение неполадок на платформах, где доступ к журналам затруднен.
Драйвер преобразования текста в речь (для доступности).
Export handler (для экспорта из редактора, включая Развёртывание в один клик). Не требуется, если вы собираетесь экспортировать только PCK из редактора, а затем напрямую запустить двоичный файл шаблона экспорта, переименовав его в соответствии с файлом PCK. См. заголовок EditorExportPlatform для справки. run_icon.svg (16×16) должен присутствовать в папке платформы, если Развёртывание в один клик реализован для целевой платформы. Этот значок отображается в верхней части редактора, когда для целевой платформы настроено развертывание в один клик.

Если целевая платформа не поддерживает запуск Vulkan, Direct3D 12, OpenGL 3.3 или OpenGL ES 3.0, у вас есть два варианта:

Используйте библиотеку во время выполнения для преобразования вызовов Vulkan или OpenGL в другой графический API. Например, MoltenVK используется в macOS для преобразования вызовов Vulkan в Metal во время выполнения.
Создание нового рендерера с нуля. Это серьёзная задача, особенно если вы хотите поддерживать как 2D-, так и 3D-рендеринг с расширенными функциями.

Распространение пользовательского порта платформы

Опасно

Прежде чем распространять портированную версию для какой-либо платформы, убедитесь, что у вас есть право распространять весь код, с которым она связана. Консольные SDK обычно подпадают под действие соглашений о неразглашении (NDA), которые запрещают её распространение среди публики.

Платформенные порты разработаны максимально автономными. Большая часть кода может храниться в одной папке, расположенной в platform/. Как и в случае с Собственные модули на C++, это позволяет оптимизировать процесс сборки, позволяя git clone создать папку платформы в папке platform/ клонированного репозитория Godot, а затем выполнить scons platform=<name>. Для сборки не требуется никаких дополнительных действий, за исключением случаев, когда предварительно требуется установить сторонние платформо-специфичные зависимости.

Однако, если требуется пользовательский драйвер рендеринга, необходимо добавить ещё одну папку в drivers/. В этом случае порт платформы можно распространять как ответвление репозитория Godot или как набор из нескольких папок, которые можно добавить поверх клона Git-репозитория Godot.