Кроссплатформенный игровой движок C4 Engine отказался от поддержки Linux
6Иллюстрация с сайта phoronix.com
11 января вышла новая версия кроссплатформенного игрового движка — C4 Engine 4.2 — без поддержки GNU/Linux. Официальная причина: ведущий разработчик «не осилил» Linux.
С4 Engine — проприетарный игровой движок, портированный на Linux в 2012 году. Он поддерживает Windows начиная с XP и новее, Mac OS и PlayStation 4 и другие системы. Эрик Ленгйел (Eric Lengyel) создал движок и компанию, занимающуюся его развитием — Terathon Software.
Отказ от Linux Ленгйел комментирует в анонсе новой версии: «Поддержка Linux была удалена из C4 Engine с версии 4.2. Решение принято на основании несоразмерных затрат времени и денег, которые мы несём поддерживая Linux, к возврату на инвестиции. Также на решение повлияло желание сохранить собственный рассудок, т.к. мой личный опыт с Linux был крайне негативным и привёл к огромным потерям времени, которые можно было направить на более продуктивные задачи. Terathon Software больше не будет способствовать популярности системы, которая, на мой взгляд, уступает по дизайну и Windows, и Mac OS. Linux показал себя как Франкенштейн ОС, собранная из разрозненных и едва функционирующих частей с отвратительной надёжностью и ничтожной надеждой на исправление в будущем. Время, расходуемое на Linux, теперь будет потрачено на усиление нашего продукта на более жизнеспособных системах».
При этом Эрик Ленгйел указывает, что в будущем они могут поддерживать SteamOS, но не позволят запускать движок на обычном Linux.
Постоянная ссылка к новости: http://www.nixp.ru/news/13088.html. Никита Лялин по материалам phoronix.com.
GameShell — модульная консоль в духе Game Boy для классических игр с GNU/Linux 2
Прощание с LiMux: Полный возврат Мюнхена с Linux на Windows обойдётся почти в 50 миллионов евро 3 19
Статистика от Steam: Доля Linux-геймеров резко сократилась, составив всего 0,35 % 2
Гоночная компьютерная игра F1 2017 станет доступна Linux-пользователям 2 ноября 1 1
Ataribox — консоль с классическими играми и Linux за 249 USD 3
Спустя три года: Unreal Tournament 3 для Linux не будет 15 2
Последние комментарии
- OlegL, 17 декабря 2023 года в 15:00 → Перекличка 21
- REDkiy, 8 июня 2023 года в 9:09 → Как «замокать» файл для юниттеста в Python? 2
- fhunter, 29 ноября 2022 года в 2:09 → Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt? 6
- Иванн, 9 апреля 2022 года в 8:31 → Ассоциация РАСПО провела первое учредительное собрание 1
- Kiri11.ADV1, 7 марта 2021 года в 12:01 → Логи catalina.out в TomCat 9 в формате JSON 1
>они могут поддерживать SteamOS, но не позволят запускать движок на обычном Linux.
Что за наркомания вообще? И что вообще за игры есть на этом движке?
Тивоизация или как там её )
в этом вся и суть — тыркнул, не пошло, кака — бросил. человеческий мозг трудиться не любит, затратно это. Да и рынок не такой большой как Win.
Как-то это очень странно звучит на фоне:
«Дрю Блисс (Drew Bliss) из компании-разработчика игр Valve, выступая на мероприятии для разработчиков Ubuntu (Ubuntu Developer Summit), сообщил, что Linux становится всё более и более перспективной платформой для игр на фоне выхода Microsoft Windows 8.»
http://www.nixp.ru/news/11967.html
Судя по отзывам — автор нарвался на Ubuntu 14.04, ну и…. дальше пошёл троллинг. А разработчик у движка вроде бы только один.
Дословно там было вплоть до «sudo apt-get install это кошмар». Есть подозрение что автор не осилил командную строку, а без неё работать в linux тоскливо.
Жирный лойс, товарищ!
http://www.terathon.com/forums/viewtopic.php?f=2&t=14050&start=25#p127661
Здесь отписался сам автор.
Вообще, тред интересный. Хотя автор так толком и не отписал «что именно» ему не нравится.
Процитированное натолкнуло меня на предположение, что автор использует какие-то специфичные инструменты разработки, которые либо сложно, либо невозможно поднять в линуксе, что и вызывает такую реакцию. У меня примерно такую же реакцию вызывает разработка в Windows, где единственный способ получить адекватную командную строку — это что-то типа mingw/cygwin, но оба этих проекта инородны для венды, и создать на их основе окружение для работы схожее с тем, что я имею в linux довольно сложно и требует утомительной возни.
Учтём при этом, что скорее всего он поставил win8 с линуксом в дуалбуте — а я с этим поимел радостей совсем недавно: говорят с использованием UEFI ещё как-то можно, но подружить вендовый загрузчик с линуксовым при legacy загрузке мне не удалось. Правда я не пробовал закатать grub в mbr, очень хотелось оставить там именно вендовый загрузчик, но… Но общий результат печален: загрузка идёт через EasyBoot, который типа запускает свою собственную копию grub. При этом, во-первых, дождаться когда вендовый загрузчик отдаст управление grub не намного проще, чем дождаться загрузки венды — я не знаю, чем именно там загрузчик венды занимается, складывается впечатление, что он загружает венду, после чего выводит загрузочное меню, и после этого устраивает софтовую перезагрузку в grub. Во-вторых, я так и не понял как грубу из easyboot можно подсунуть конфиг-файл, те же что по-умолчанию не работает — то есть мне приходилось каждый раз вгонять команды загрузки в командную строку grub. С grub’ом установленным в дистрибутиве линукса мне так и не удалось подружить вендовый загрузчик: я уж и так и эдак с device-map тыкался — эквипенисуально, grub всё равно не находит свои stage 1.5 и прочие.
Подводя итог: если бы мне пришлось поддерживать порт своей программы для венды, то я бы может быть годик выдержал бы, а потом сказал то же самое что и Ленгйел, мои слова ненависти отличались бы от его лишь заменой Linux на Windows. Точнее не совсем — я бы поплевавшись засунул бы венду в KVM, и запускал бы её в виде линуксового процесса. Он до этого видимо не догадался, или может быть в венде всё не так просто с виртуализацией.
У любой виртуализации все не так просто с GPU… Вон Интелы собирались пропатчить ядро для виртуализации GPU, посмотрим…
Вроде ж прокидывают в гостевую систему? Или я что-то не так понимаю?
Неа, очень всё медленно и жутко. по крайней мере с virtualbox. Правда детально мы не копали за отсутствием времени, может и можно завести чтобы нормально работало…
Насколько я знаю, можно любую железяку отдать под управление гостевой системе. То есть она напрямую будет рулить железякой, пользуясь своими дровами. Это плюс-минус то же самое, как запуск dosemu из-под рута, с прописанным в конфиге разрешением для dosemu напрямую обращаться к портам ввода-вывода. То же самое, только с меньшим количеством софтовых костылей. И это не должно быть сильно тормознее чем напрямую без виртуализации. Думаю, что не больше 10% замедления выйдет.
Мне просто всё никак не добраться до этих экспериментов: у меня слишком древний проц для аппаратной виртуализации CPU, без неё виртуализация реально тормозит, да и какой-то практической пользы для себя я не вижу, только чистое любопытство движет мною.
Неа, не выйдет. Да, можно заюзать видяшку для вычислений. А вывести изображение как? Весь сыр-бор в том, что надо как-то получить контекст экрана хостовой системы для вывода туда. Да, мы могем быстро посчитать. И что с того?.. Как эффективно обмениваться посчитанной картинкой с хост-системой, чтобы та ее отобразила?..
Дать доступ к DMA? DMA не такая уж и сложная штука, на него поверх можно одеть софтварную эмуляцию, которая даст гостю интерфейс к железному DMA, причём снимет конфликты между гостем и хостом.
Я не вижу на этом пути каких-то принципиальных проблем.
DMA и видео-память — вещи совсем-совсем разные. В том и дело, что DMA — это программируемый контроллер, который сам выполняет работу. Его надо запрограммировать и подождать результата. А тут — доступ в память. Или вы имели в виду DRM? Небезопасно, поскольку туда могут выполнять запись и другие программы и тд, и тп. И софтверная эмуляция… Она родимая и тормозит процесс. Или это должно быть частью ядра. Или драйвера устройства должны что-то знать о виртуализации как таковой. Что и делают интела в своем патче.
Доступ к памяти настраивается через mmap. Гостю можно создать произвольную конфигурацию его «физического» адресного пространства. Если прав, конечно, хватит. Но руту хватит без вопросов, при этом, вероятно, не обязательно иметь права рута, достаточно иметь rw права на несколько файликов из /dev (быть может на эти: find /dev -group video). Другие процессы весьма ограничены в плане доступа к АП данного процесса. Требуется ряд соблюдённых условий. Которые легко не соблюсти, сделав невозможным ни для кого получить доступ к этой памяти. Например запустив виртуалку под выделенным под эти цели пользователем.
Ну, а то, что вообще небезопасно давать доступ к железу — это понятно. Но чем это принципиально отличается в плане безопасности от натуральной установки венды, с полным доступом для неё для всего железа? Мне кажется, что имеющиеся отличия — скорее в лучшую сторону отличия, потому что гость будет иметь доступ только туда, куда мы разрешили.
Виртуализация — в первуюочередь это изолирование. Полное. От других процессов, не обязательно иметь в виду доступ к диску, например. И аппаратная поддержка виртуализации на 90 процентов состоит в том, что контроллер памяти знает о существовании гипервизора и гостей. И умеет аппаратно разделять доступ к страницам памяти. В результате чего имеется возможность запустить ядро другой операционки (а ведь ему тоже нужен доступ к 0 кольцу режима работы процессора). А без аппаратной поддержки пользовательская программа следила за этим. В результате что? Переключение контекста в случае доступа к странице памяти, что очень долго. А вы хотите, например, чтобы гость имел доступ к видеопамяти без аппаратного разделения, где вы вводите в браузере данные своей кредитки? В общем, все не так уж и просто. И речь даже не сколько в безопасности, а в том, как разограничить доступ к видеопамяти? Как взять воображаемый мютекс, дабы не попортить иным «писателям/читателям» чего? Без модификации гостевой операционной системы и ее графической подсистемы…
И да. Нельзя физически влазить в память гостя, а уж тем более и гипервизора. Аппаратура против…
Вы отстали от жизни. Виртуализация давно гораздо больше, чем «полное изолирование». Правильнее сказать, что весьма гибкое изолирование, позволяющее точно контролировать степень изоляции.
Если я запускаю фуллскрин игрушку, то браузер не обращается к видеопамяти. Ну, точнее теоретически он может. Но так же теоретически, он может не обращаться, так же теоретически эти обращения возможно срезать на уровне Xorg или ниже. Сложнее будет если у меня несколько процессов напрямую пишущих в память… Но я не настолько хорошо знаю как работает графический стек, чтобы говорить возможно ли просто вырезать эти обращения и проигнорировать. Ну, например, повесив всем offscreen процессам флаг ro на страницы видеопамяти, и просто игнорируя все попытки туда писать.
Просто не давать им писать и всё. Сделать на каждого гостя по самостоятельному «рабочему столу». Немного поплясать с бубном вокруг операции переключения между рабочими столами.
Переключение контекстов будет происходить тогда, когда я переключаюсь между «рабочими столами» — но этот процесс сильно завязан на мою скорость восприятия информации, и скорость переключения контекстов на этом фоне — ничто.
И… Как бы это сказать… Вот смотрите, вы тут доказываете мне что это невозможно. Зачем? Чего вы хотите добиться? Убедить меня в том, что прокинутая видеокарта будет тормозить? Если да, то мне придётся вас огорчить: выбранный вами подход для достижения вашей цели неработоспособен. Он не может привести вас к цели.
Я объясню почему. Судя по вашим словам вы никогда не делали ничего подобного и даже не пытались. Вы понимаете, что вы можете тут десять трактатов написать о том, почему это будет тормозить, я всё равно выкину все ваши слова в окно? Просто потому, что я знаю, что люди прокидывают видеокарты в гостевую венду, чтобы поиграть в игрушки. В современные игрушки. Может быть конечно у них при этом железо полученное из будущего при помощи машины времени — я не знаю. Но и тем не менее, знание мною самого факта прокидывания видеокарты ради игры приводит к тому, что я присваиваю вероятность >50% тому, что существенных тормозов из-за этого не возникает. И умозрительные умствования имеют весьма низкий приоритет перед фактами. Даже если факты столь неопределённы. Выше я показал это и уже неоднократно: вы умозрительно находите какие-то потенциальные преграды для производительности, я умозрительно же нахожу обходные пути. Мы можем до скончания века заниматься этой мастурбацией не изменив реальность ни на грош. И не изменив ни на грош убеждений друг друга.
Если вы хотите меня переубедить — прокиньте видеокарту. Запустите тесты. Напишите статью о том, что вы делали, как вы делали, как ещё можно было сделать и как вы не делали. Приложите к статье результаты тестирования производительности. Оставьте здесь ссылку на статью. Если вы проделаете всё это, то это может сработать. Может и не сработать — тут я не могу дать гарантий до того, как ознакомлюсь со статьёй, но может и сработать. А тот подход который вы практикуете сейчас заведомо бесперспективен.
О да. Я знаю, что на текущий момент практически все вендоры в своих драйверах пилят возможность этого долбанного Passthrough. Абы драйвер не офигел от того, что не он один рулит железкой. А есть еще какой-то хмырь, пытающийся это сделать.
И уж чего я не буду делать, так это ублажать Вас, уважаемый, доказывая очевидное. Ваши неведомые «люди» сделали то, что судорожно пытаются сделать писатели драйверов для видеокарт, респект им. Да только экспериментальной поддержкой NVIDIA CUDA для подобного разделения люди хвастаются на профильных конференциях — т.е. далеко от обычного пользователя. Я специально порылся в сетке, может я действительно головой бахнулся. И нашел доказательства своим словам. Вы хотите верить себе? Да пожалуйста. Оставлю Вас в Вашей вселенной в покое. И мне хорошо, и Вам не напрягаться.
Вот это правильно.
Эта штука у AMD звалась IOMMUv2. аналогичное было и у Intel, но это железная фича.
4.2 =))))
Может ему надо было на кикстартере денег насобирать на дополнительного разработчика, шарящего в Linux, а не опускать руки?
Ты можешь всё изменить одним простым письмом! ;-)
Если бы он просто отказался от поддержки — я бы его понял. И денег бы дал на kickstarter-е.
Но то как был сделан этот отказ….
Нет, после объяснения позиции (а она была том thread-е, и с ней я могу частично согласиться), я могу понять, и частично согласиться.
Но простить и помогать после этого… Спасибо, не буду точно.