Предисловие
Что для геймера может быть страшнее отвала видеокарты? Отобрать компьютер целиком? Нет, достаточно просто удалить Windows и заставить пользоваться только Linux, поверьте, это будет самая настоящая пытка практически для любого геймера, особенно если при этом ограничить скорость интернета до условных 5 Мбит/с.
К сожалению, а может и к счастью, меня сложно отнести к геймерам, хотя в игры я не брезгую поиграть, особенно когда игра сделана действительно хорошо.
Но оставим геймеров в покое, у них и так жизнь непроста, в последнее время постоянно кормят какими-то "лучами", фейковыми кадрами для накрутки счётчика FPS, растянутыми 720p до 4K на RTX 4090, ибо реальные 4K даже такая видеокарта иногда не способна достойно вытянуть, и т.п...
В предыдущей части рассказано про основные проблемы линуксов для игр, в принципе уже можно бросать всё и возвращаться в Windows, однако так не интересно, нужно ведь проверить в деле, а то вдруг в линуксах действительно "один клик, и всё работает даже лучше винды", а я просто неправильно оценил всё?
MX Linux и игры: Основные проблемы Linux для игр
Так что берём колотушку в руки и начинаем весёлые пляски с бубном вокруг костра! Ведь плясать действительно есть над чем!
-
Wine
Что первым делом нужно любому геймеру который окунается в линукс? Правильно, это костыль Wine, все любимые игры скорее всего разработаны только для Windows, и без костылей их никак не запустить.
Так как я не хочу постоянно пердолить репозитории выкачивая гигабайтами бесконечные зависимости при переустановке системы, или при установке софта в виртуальной машине, то скачиваю приложение один раз через команду "sudo apt-get --download-only install winehq-staging", а после копирую из кэша загруженные пакеты в отдельную папку под названием wine812, а кэш в обязательном порядке очищаю, само собой это можно сделать только используя root права.
Естественно это всё лучше делать в виртуальной машине с абсолютно голым дистрибутивом, а не на реальном ПК, ибо в реальном ПК уже могут быть какие-то зависимости от другого софта, и они не будут загружены... Если вдруг нужно переустановить линукс, и установить всю эту дичайшую охапку зависимостей ради WineHQ, а там вдруг чего-то не найдётся, то пиши пропало:
Важно заметить! Метод скачивания зависимостей через --download-only работает только в пределах одного конкретного дистрибутива! Если вы таким образом скачаете приложение в MX Linux 23 KDE, а установить попытаетесь в MX Linux 23 Xfce, то есть вероятность конфликта или нехватки каких-то зависимостей! Этот способ не решает ад зависимостей и проблемы репозиториев!
Попытка установить WineHQ в Ubuntu 16.04 LTS:
В общем WineHQ у меня установлен, ведь без него ну никуда, даже скомпилировать игру в Godot Engine невозможно по-человечески для платформы Windows, ещё иногда говорят что линуксы просто идеальны для всех разработчиков, ага, охотно верю, пожалуйста, снимите лапшу с моих ушей...
-
--
Proton
Установил значит WineHQ, и тут прибегают линуксоиды, начинают рассказывать какой я весь неправильный, ведь нужно ставить СВЯТОЙ ПРОТОН! Просто одну команду в терминал или пара кликов в центре приложений! Окей, иду в центр приложений и вбиваю в поиск "proton":
Что дальше? Дистрибутив не дистрибутив? Руки кривые? Мозги вендузятные? Что устанавливать?
Но я же не буду бросать на этом всё? Найду этот несчастный Proton? Ну найду ведь? Конечно найду, правда это будет нечто сомнительное...
Если пошарить по всем доступным репозиториям, то можно найти proton-caller, который по краткому описанию - то самое:
Столбцы не растягиваются как в Windows, потому список выглядит немного криво...
Но если заглянуть в подробное описание, то всплывает масса вопросов, а что по зависимостям? Мне нужен оригинальный Proton от Valve, или оно само там как-нибудь родит под себя? А мне нужно Wine устанавливать и настраивать, или оно опять как-то само там перекрутиться с тем что есть? А Steam клиент мне нужно устанавливать? Я не хочу устанавливать DRM платформу под названием Steam, оно само установит её без моего разрешения? Или как это вообще у них там крутиться? Может мне еще мануалы нужно курить и заклинания через терминал вбивать?
Вроде вот и список зависимостей минимальный, но предлагает steam, да и размер неадекватно маленький какой-то, а в описании столько всего наговорили, что это просто какой-то комбайн всемогущий:
А ведь действительно, куда без мануалов и заучивания заклинаний для терминала, чтобы всё делать "правильно", там же выяснилось, что нужно ещё с конфигами ковыряться:
Так, окей, я вижу ссылку на DEB пакет, это уже интересно:
Да, технически DEB пакет есть, но весит он всего две сотни килобайт, ну не может здоровенный костыль для запуска Windows игр так мало весить!
В общем за дело! Скачиваю proton-caller из репозитория, и да, действительно только один пакет загрузился в кэш, значит дела очень плохи, ведь насасывать все зависимости будет само приложение, а это порой гораздо тяжелее развернуть заново после переустановки ОС, или на несколько разных ПК для тестов, чем если просто взять папку с дичайшей охапкой зависимостей под один конкретный дистрибутив:
Ведь одно дело пачку установочных пакетов собрать в кучу, а другое дело выковыривать по линуксоидным закоулкам куски одного приложения, а потом ещё правильно разложить обратно и заставить работать...
А ещё меня максимально напрягает тот факт, что загруженный из GitHub пакет, и загруженный из репозитория дистрибутива, это разные пакеты с одинаковым именем! У них банально разный размер файла!
Вы как хотите, а я не хочу сейчас начинать неистовые пляски с "протоном", уже видно, что пляски наверняка будут, и это может занять просто неадекватное количество времени. Я понятия не имею сколько там этот proton-caller насосёт зависимостей после установки в систему, и что вообще из этого выйдет, если вообще выйдет...
Но постойте, там же был ещё какой-то protontricks! Да, есть такое, очередной сомнительный костыль для костылей, еще и зависит от питухона (Python) и winetricks, последний у меня не установлен даже, уже молчу про непонятный zenity:
В общем оставим в покое несчастный Proton, пока линукс в очередной раз не поломался...
-
--
---
Что дальше?
Честно? Я сам уже запутался немного, Wine установили, Proton отфутболил от греха подальше, в принципе можно запускать игры созданные для Windows? В целом да, но погодите немного, начнём с более простого, а именно ChimbaBench.
Есть у меня значит портативный бенчмарк как в 32 битном виде, так и 64 битном:
С 64 битной версией проблем никаких, всё запускается и работает, проблемы начинаются при попытке запустить 32 битную версию приложения!
Запустив 32 битную версию приложения у меня попросту начала прерываться музыка в браузере, раза 3-4 прерывалась секунд на 5-6, но в итоге ничего не запустилось:
В общем, как всегда, всё через жопу в линуксах, 64 битный дистрибутив не может запустить 32 битный софт? Это нормально! Только для линуксов конечно, но ведь нормально же!
Само собой и Wine страдает от неполноценности "пингвинов", которые не способны запускать 32 битный софт, и правда, кому вообще сдалась масса 32 битного софта и игр...
Наверное нужно поплясать с бубном, подтянуть каким-то раком зависимости, каким-то чудом умудриться скачать и заставить работать 32 битные библиотеки в системе, настроить префиксы Wine, и всё такое... Короче, давайте просто смиримся с тем фактом, что 32 битные игры не сможем запустить, эх, а я хотел поиграть в Project IGI 2 под линуксом:
-
--
---
ChimbaBench v2.5
Ладно, в игры я точно уже не поиграю в пределах данной статьи, так хотя бы прогоню свои же тесты производительности, который в отличие от линуксоидного софта, не нужно сосать из репозиториев захламляя систему мегатоннами зависимостей.
Его можно просто взять, и запустить двойным кликом по "экзешнику" практически в любом дистрибутиве Linux 2013 года и новее, да, иконки у исполняемого файла нет, спасибо неполноценным линуксиодным исполняемым файлам, и 32 битные версии не смогу протестировать, ибо дистрибутив умеет только в 64 бита:
Сейчас у меня драйвер видеокарты "из коробки", то есть Nouveau, и производительность оставляет желать лучшего, это была Windows версия ChimbaBench запущенная через Wine:
И даже можно сказать что с графикой всё нормально, если бы не артефакты выявленные в процессе тестирования:
Далее Linux версия ChimbaBench, в принципе уровень производительности такой же, как и артефакты, не вижу разницы между Windows версией через Wine, а теперь обратим внимание на очень интересный нюанс:
Заметили подвох? А теперь?
Для тех кто не понял, правый счётчик FPS это функция игрового движка Godot Engine, ну чтобы разработчики игр не писали свои счётчики FPS для отладки игры, а просто использовали уже готовый, логично? Логично. Слева мой самодельный счетчик, подсчитывающий средний FPS на протяжении теста, и он работает максимально дубово, берёт общее количество отработанных циклов _process(delta) и делит на время выполнения теста, по умолчанию 60 секунд:
Получается, игровой движок выдает неправильное значение средней частоты кадров? Ведь показывает 4-5 FPS всегда, в том числе во время проведения теста, а мой таймер насчитывает средний FPS 7.5, так кому верить?
Вообще я записал на видео небольшой фрагмент тестирования, и внимательно проверил через Kkenlive, оказалось, что на самом деле там всего 4-5 кадра в секунду, то есть функция Godot Engine работает правильно, выходит мой счётчик неправильно работает? Ух, как же так может быть...
Такое может быть если _process(delta) иногда работает "вхолостую" без отрисовки кадра, что на самом деле очень паршиво, так как может приводить к рывкам изображения, потому что в логике игры может что-то произойти, но не попасть на экран когда должно.
Хотя в моём случае бенчмарк просто работает гораздо дольше заданного времени, ~100 секунд вместо заданных 60, отсюда и счётчик насчитал больше положенного, и средний результат получился больше, ведь я полагаюсь на стандартный таймер Godot Engine при тестировании, именно стандартная функция таймера Godot Engine считает время, а это значит лишь одно, это не мой косяк...
На всякий случай пересмотрел скриншоты с результатами которые были сделаны в среде Windows, и да, в среде Windows результат не отклонялся никуда, да и визуально в среде Windows тест работал нормально, а сейчас в линуксе он прямо откровенно долго крутился, хотя я не сразу обратил на это внимание, а зря:
И что с этим делать? Исправлять свой код подсчитывающий результат? Там исправлять нечего, он прост как пробка. Отказаться от использования стандартных таймеров игрового движка Godot Engine, и куролесить свой собственный? Очень не хотелось бы...
Так или иначе косяк обнаружен, даже в виртуальной машине в Linux Mint 15 таймер считает неправильно, и выдает ровно такой же средний FPS 7.5, хотя фактический там был всего 2-3 при разрешении 640x360...
Чтобы окончательно поставить точку, я специально запустил Windows 7, бенчмарку выставил разрешение 2160p, 16x сглаживание, таким образом смог уронить FPS примерно до 15, запустил тест и все таймеры сошлись тютелька в тютельку, как и результаты:
О чём это говорит сейчас? Можно сказать что это косяк линукса? Если бы я был предвзят к линуксам, так бы и сказал, но это явно косяк таймеров Godot Engine, я ещё раз специально загрузил Windows 7, и на этот раз подсунул LLVMpipe драйвер приложению, ну чтобы наверняка уронить FPS на дно... И это сработало, надпись "Preparing" должна висеть ровно две секунды, но она висит уже даже хрен не знает сколько:
Крайне паршивая ситуация однако. Судя по всему, минимальный FPS при котором стандартные таймеры адекватно работают на уровне всего 7.5...
Если FPS ниже - начинаются "чудеса", а это может даже стать лёгким способом читерить в играх, просто опускаем FPS до 3-4 и спокойно проходим испытания на время, таймеры всё равно ведь будут считать в разы медленнее положенного, и игра будет считать что это нормально, если конечно не сверять время с часами операционной системы, что не только лишний геморрой, но и тоже вполне можно "подкрутить".
-
--
---
Продолжение следует...
Вместо того, чтобы просто начать играть, я в очередной раз застрял с косяками.
Но кое-что было действительно неожиданно, это кривая работа таймеров Godot Engine при FPS ниже 8, тут даже я офигел, хотя казалось бы, столько косяков уже повидал.
Вот как решить эту проблему с таймерами? Переписывать игровой движок? Вообще не вариант. Попробовать сменить режим работы таймера, привязав его к _physics_process? Возможно сработает, но это нужно проверять и экспериментировать...
В любом случае я рад выявленному косяку, теперь мы все немного больше знаем о поведении Godot Engine в нетипичных условиях, а кто-то вероятно даже не знал, и уже набросал целую игру набитую тысячами таймеров... Могу только посочувствовать, особенно если это позволяет игрокам нечестно получать преимущество в игре.
Вот же...
Я наконец уже поиграю в игры, или так и буду ловить бесконечные косяки?! Как же меня расстраивает тот факт, что в среде Windows я просто запускаю игру, и спокойно играю, а в линуксах вот это всё странное дерьмо вечно заставляет танцевать с бубном.
Благодарю за внимание, больше интересных статей в блоге Hard-Workshop.
