Это перевод части поста под авторством raiguard
Я уже появлялся в нескольких FFF, но никогда официально не представлялся. Меня зовут raiguard. Я играю в Factorio с июня 2017 года, делаю моды для игры с момента выпуска версии 0.17 в марте 2019 года и, наконец, присоединился к Wube в марте 2023 года. Мои основные обязанности в компании — программирование расширений и поддержка Linux, а также пропаганда. для моддерского сообщества. Я ежедневно использую Linux в течение нескольких лет и все глубже погружаюсь в черную дыру настройки и минимализма.
«Почему большинство игр не поддерживают macOS и Linux?» — это мнение, которое я часто вижу в Интернете. Поддержка новой платформы — это гораздо больше, чем просто изменение некоторых флагов и компиляция. Windows, macOS, Linux и Nintendo Switch используют разные компиляторы, разные реализации стандартной библиотеки C++ и имеют разные особенности реализации, ошибки и функции. Вам необходимо настроить CI для новой платформы, расширить систему сборки для поддержки новых компиляторов и архитектуры, а также иметь в команде хотя бы одного человека, который достаточно заботится о платформе, чтобы активно ее поддерживать. Если вы занимаетесь видеоиграми, вам, вероятно, потребуется добавить поддержку другого графического интерфейса (Vulkan или OpenGL), поскольку DirectX является эксклюзивным для Windows.
Многие разработчики, взглянув на долю рынка Windows , решат, что поддержка других платформ не стоит усилий. Кроме того, с стремительным ростом Steam Deck и Proton разработчикам игр стало проще, чем когда-либо, игнорировать поддержку Linux, потому что Valve прибегает к черной магии, которая все равно позволяет их игре работать.
Factorio так хорошо поддерживает macOS и Linux, потому что в Wube всегда был кто-то, кто активно использует эти платформы и готов взять на себя бремя их поддержки. Наша встроенная поддержка Apple Silicon — отличный тому пример. Сегодня я расскажу вам о некоторых приключениях, которые произошли со мной при поддержке Linux в Factorio.
Вейланд
Моей первой самозваной задачей после присоединения к команде было добавить в игру поддержку Wayland . Wayland — это новый протокол отображения, который разрабатывается для замены устаревшей и небезопасной системы X11 . Современные дистрибутивы Linux начинают переключаться на Wayland по умолчанию, поэтому поддержка его в Factorio имеет первостепенное значение.
Мы используем библиотеку SDL , которая аккуратно обрабатывает большинство низкоуровневых системных взаимодействий и абстрагирует их в общий интерфейс. SDL поддерживает Wayland, поэтому все, что мне теоретически нужно было сделать, — это собрать SDL с включенным Wayland, и он «просто заработал бы». Однако это не совсем просто подключи и работай. Wayland предоставляет «протоколы» в виде XML-файлов, которые вы затем используете в wayland-scannerдвоичном виде для преобразования в программу C и файлы заголовков.
Поскольку в то время я был относительно новичком в C++, мое первоначальное решение было запутанным и включало проверку сгенерированных протоколов Wayland в нашем дереве исходных кодов, чтобы их можно было регенерировать вручную каждый раз, когда мы обновляли SDL. Несколько месяцев назад, вооружившись многолетним опытом, я улучшил этот рабочий процесс, чтобы автоматически генерировать файлы как часть процесса сборки, чтобы они всегда были актуальными в соответствии с XML-файлами протокола, с которыми поставляется SDL.
Factorio поддерживает Wayland с версии 1.1.77, но его необходимо явно включить, настроив SDL_VIDEODRIVER=waylandв вашей среде. Для Factorio 2.0 я добавил раскрывающийся список для выбора ваших предпочтений в графическом интерфейсе.
Оформление окон на стороне клиента
Как только поддержка Wayland была реализована, я получил отчет об ошибке , в котором говорилось, что в окне отсутствовала строка заголовка и кнопки закрытия (так называемые «декорации окна») при работе в GNOME . Большинство сред рабочего стола позволяют окнам предоставлять свои собственные украшения, если они того пожелают, но в качестве альтернативы предоставляют реализацию по умолчанию на стороне сервера. GNOME в своей бесконечной мудрости решили, что все клиенты должны предоставлять свои собственные украшения, а если клиент этого не сделает, они просто пропадут. Я не согласен с этим решением; Factorio не нуждается в оформлении какой-либо другой платформы, более того, в любой другой среде рабочего стола, но GNOME может (ab) использовать свою популярность, чтобы заставить программы соответствовать его особенностям или остаться позади.
Чтобы исправить это, мне пришлось добавить еще одну зависимость — libdecor . Он работает, и SDL даже поддерживает его, но видеоигра вообще не должна обеспечивать оформление окон.
Я использую оконный менеджер Sway , и особенность этого оконного менеджера заключается в том, что он автоматически изменяет размер плавающих окон до размера их последнего отправленного кадра. Это выявило проблему с нашим графическим стеком: игре требуется три кадра, чтобы правильно отреагировать на изменение размера окна. В результате происходит быстрое перетягивание каната: Sway отправляет массу событий изменения размера, а Factorio отвечает устаревшими размерами кадрового буфера, вызывая хаос, показанный выше.
Я провел два полных дня, рассматривая наш графический код, но не смог придумать объяснения, почему это происходит, поэтому эта работа все еще продолжается. Поскольку эта проблема возникает только при запуске игры на Wayland под управлением Sway, это не является большим приоритетом, но это было слишком интересно, чтобы не поделиться.
Динамически подключаемые библиотеки
В программе C++ существует три способа загрузки/подключения библиотеки:
Включив его в исходный двоичный файл (статическое связывание).
Загрузка системы при запуске вашей программы (динамическое связывание).
Ваша программа загружает его явно после запуска («динамическая загрузка» или то, что я называю «связыванием во время выполнения»).
У нас есть много библиотек, таких как SDL, FontStash и Lua, которые скомпонованы статически, но в Factorio 1.1 также есть много динамически линкуемых библиотек:
rai@tantal ~/games/factorio
$ ldd bin/x64/factorio
linux-vdso.so.1 (0x00007ffc123b1000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fc182f70000)
librt.so.1 => /lib64/librt.so.1 (0x00007fc182f6b000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fc182f5a000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007fc182e13000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007fc182dff000)
libGL.so.1 => /lib64/libGL.so.1 (0x00007fc182d78000)
libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007fc182d71000)
libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007fc182d64000)
libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007fc182d57000)
libasound.so.2 => /lib64/libasound.so.2 (0x00007fc182c43000)
libpulse.so.0 => /lib64/libpulse.so.0 (0x00007fc182bf1000)
libpulse-simple.so.0 => /lib64/libpulse-simple.so.0 (0x00007fc182bea000)
libm.so.6 => /lib64/libm.so.6 (0x00007fc182b07000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fc182b02000)
libc.so.6 => /lib64/libc.so.6 (0x00007fc182920000)
/lib64/ld-linux-x86-64.so.2 (0x00007fc182f91000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fc1828f5000)
libGLX.so.0 => /lib64/libGLX.so.0 (0x00007fc1828c2000)
libGLdispatch.so.0 => /lib64/libGLdispatch.so.0 (0x00007fc18280a000)
libXrender.so.1 => /lib64/libXrender.so.1 (0x00007fc1827fc000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007fc1827f4000)
libpulsecommon-16.1.so => /usr/lib64/pulseaudio/libpulsecommon-16.1.so (0x00007fc18276f000)
libdbus-1.so.3 => /lib64/libdbus-1.so.3 (0x00007fc18271a000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007fc182714000)
libsndfile.so.1 => /lib64/libsndfile.so.1 (0x00007fc182694000)
libsystemd.so.0 => /lib64/libsystemd.so.0 (0x00007fc1825a1000)
libasyncns.so.0 => /lib64/libasyncns.so.0 (0x00007fc182599000)
libgsm.so.1 => /lib64/libgsm.so.1 (0x00007fc18258a000)
libFLAC.so.12 => /lib64/libFLAC.so.12 (0x00007fc182524000)
libvorbis.so.0 => /lib64/libvorbis.so.0 (0x00007fc1824f5000)
libvorbisenc.so.2 => /lib64/libvorbisenc.so.2 (0x00007fc182448000)
libopus.so.0 => /lib64/libopus.so.0 (0x00007fc1823ec000)
libogg.so.0 => /lib64/libogg.so.0 (0x00007fc1823e2000)
libmpg123.so.0 => /lib64/libmpg123.so.0 (0x00007fc182385000)
libmp3lame.so.0 => /lib64/libmp3lame.so.0 (0x00007fc18230d000)
libcap.so.2 => /lib64/libcap.so.2 (0x00007fc182303000)
liblz4.so.1 => /lib64/liblz4.so.1 (0x00007fc1822df000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fc1822ac000)
libzstd.so.1 => /lib64/libzstd.so.1 (0x00007fc1821f0000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fc1821cc000)
Среди этих библиотек — X11 и PulseAudio, которые устарели в пользу Wayland и PipeWire соответственно. Это вызывает кошмар совместимости, поскольку если какие-либо динамические зависимости отсутствуют, игра не запустится. Это явно не подойдет!
Наличие этих зависимостей меня смутило, поскольку мы используем SDL для большинства низкоуровневых системных вызовов, аудио и видео, а SDL полностью полагается на связывание во время выполнения. Расследование показало, что источником большинства этих зависимостей является Allegro , низкоуровневая библиотека, которую мы использовали на протяжении большей части альфа-фазы Factorio, но с тех пор заменили на SDL. Единственное оставшееся использование Allegro в версии 2.0 было в качестве вторичного аудио-сервера на случай, если у пользователя возникли проблемы с аудио-сервером SDL, но сервер SDL был стабильным в течение очень долгого времени, поэтому настало время для его удаления. Это исключило из игры 123 024 строки кода и резко сократило количество динамических зависимостей:
rai@tantal ~/dev/wube/factorio (master)
$ ldd bin/FinalReleasex64Clang/factorio
linux-vdso.so.1 (0x00007fff96ff2000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x00007fd2df8a9000)
libm. so.6 => /lib64/libm.so.6 (0x00007fd2df7c8000)
libc.so.6 => /lib64/libc.so.6 (0x00007fd2df5e6000)
/lib64/ld-linux-x86-64.so.2 (0x00007fd2df8d6000 )
Проблемы с буфером обмена
Оказывается, Allegro — не единственное, что требовало от нас связывания с X11. Еще в 2017 году мы получили сообщение об ошибке , в котором пользователь не мог вставить большие строки чертежей в игру, и Oxyd исправил это, добавив поддержку инкрементной передачи данных из буфера обмена X11 в обработчик буфера обмена нашего графического интерфейса.
Я надеялся использовать встроенную в SDL функциональность буфера обмена, но, к сожалению, SDL не поддерживает инкрементную передачу. Это означает, что есть три варианта:
1)Продолжайте связывать с X11, требуя, чтобы пользователи установили X11 в своей системе, чтобы иметь возможность запускать игру (я не хочу возиться со статическим связыванием).
2)Выясните, как выполнить связывание во время выполнения, и реализуйте это.
3)Переведите наш код инкрементной передачи в SDL, чтобы мы могли использовать функции буфера обмена SDL, а другие игры на основе SDL могли бы извлечь выгоду из нашей работы.
Как вы могли догадаться, я выбрал третий вариант. Работа над улучшением нашего кода продолжается, но она должна быть завершена к выпуску Factorio 2.0.
Асинхронное сохранение
Многие из вас, возможно, не знают, что Factorio поддерживает сохранение игры в фоновом режиме без зависания при этом. Эта функция спрятана в скрытых настройках и работает только на macOS и Linux. Это отличный пример использования возможностей платформы для пользы игры, которые были бы нам не доступны, если бы мы просто прошли через Proton.
Асинхронное сохранение работает с использованием системного вызова fork, по существу дублирующего игру. Основной экземпляр, с которым вы взаимодействуете, продолжает играть, но недавно разветвленный дочерний элемент запускает процесс сохранения и завершает работу по завершении. Я использовал его в течение многих лет, и у меня никогда не было проблем, но настройка остается скрытой, поскольку с ней есть несколько нерешенных проблем, и для ее работы требуется значительный объем оперативной памяти.
Я бы хотел продвинуть эту функцию из ее скрытого статуса в версии 2.0. Если вы играете на Linux или macOS, включите асинхронное сохранение (ctrl+alt+нажмите «Настройки» -> «Остальное» -> non-blocking-saving) и сообщайте о любых обнаруженных проблемах. Меня особенно интересует воспроизведение, казалось бы, случайного зависания , которое происходит в конце процесса. Заранее спасибо!
Постоянное развитие
Это был лишь краткий обзор работы, которую я проделал, чтобы обеспечить наилучшее качество Factorio для Linux. По-прежнему существует много открытых отчетов об ошибках и других проблемах, но в целом я доволен положением вещей и могу с уверенностью сказать, что у Factorio отличная поддержка Linux.
источник - https://factorio.com/blog/post/fff-408
