За мои 2 года использования Linux, я обнаружил, что счастье приходит от самодостаточности. А самодостаточность приходит от личных знаний. Это то, для
чего написан этот документ. Увеличение ваших знаний в вопросах, которые относятся к играм для Linux.
Половина просьб о помощи, которые я видел в usenet, исходили от людей, которые
не имели достаточных знаний даже для того, чтобы правильно сформулировать
ворос. Поэтому, первая часть этого документа посвящена различным компонентам,
которые составляют вашу графическую систему.
Позвольте мне ответить постепенно, поскольку вопрос немного запутанный. Glide2 -- это API плюс драйвер, который обращается к аппаратно ускоренным 3D функциям видеокарт Voodoo I, II и III, основанным на чипсетах производства ныне не существующего 3Dfx. Glide2 работает на очень низком уровне: он поддерживает определение view point, отображение текстур, отправку треугольников и т. п.. Некоторые возможности Glide2 напоминают OpenGL, а некоторые -- не имеют аналогов.
Программа имеет доступ к специальным возможностям этих карт ТОЛЬКО посредством
библиотеки Glide2 одним из двух способов:
* непосредственно: программа написана для использования Glide2
* косвенно: программа использует Mesa+Glide2 (Mesa реализует OpenGL через Glide2)
Примерами программ, написанных специально для использования Glide2, могут служить Myth 2, Descent 3, Unreal Tournament, Rune и Deus Ex от компании Loki Software. Подавляющее же большинство игр использует Glide2 косвенно, при помощи Mesa с поддержкой Glide2 (существуют также их порты в OpenGL).
Glide2 больше не является закрытым. Компания 3dfx открыла спецификации и исходный код для open source community. Это обеспечивает заметную долю рынка для Linux. В Linux Glide2 портировал Daryll Strauss.
К несчастью, Glide2 почти "мертв". Он реализован только в X 3.3 (большинство людей использует сейчас 4.0) и используется только картами Voodoo I, II и III.
Можно с уверенностью утверждать, что под Glide2 игры больше писаться не будут. Что же насчет Glide3? Прежде всего, Glide3 -- не "прямой" API. Он существует только для поддержки DRI картами Voodoo III, IV и V под XFree86 4.0. Ни одна игра, используюшая для рендеринга Glide2, не будет работать под Glide3. Как правило, система, поддерживаюшая рендеринг с использованием Glide2, имеет лучшую производительность. Однако, такая конфигурация становится сегодня все менее распространенной.
Glide Версия X Поддерживаемые карты
Замечания
Существуют игры, непосредственно использующие Glide2 (в отличие от использования Glide2 через Mesa). Myth2 -- пример игры, написанной конкретно для Glide2, хотя она также может рендерить и в OpenGL (см. следующий вопрос).
Quake3 является примером OpenGL-игры, которая может использовать glide2 при
помощи Mesa с поддержкой Glide2.
Еще одна разница состоит в том, что Glide2 использует специальный 3dfx-модуль
для ядра, чтобы разрешить доступ к 3D-ускорению для обычных пользователей.
Другими словами, без него только пользователь root имеет доступ к 3D
возможностям карты.
OpenGL -- это графический API высокого уровня, в оригинале разработанный SGI на
основе их предыдущего закрытого API Iris GL, и ставший несколько лет назад
индустриальным стандартом. Он определяется и утверждается организацией
Architectural Revision Board (ARB), которая включает в себя членов SGI, IBM
DEC и Microsoft. OpenGL обеспечивает мощный, полный и обобщенный набор
возможностей для графических опреаций в 2D и 3D.
Существует 4 части OpenGL и его канонических расширений:
OpenGL -- это не только API, но и его реализация, написанная SGI. Она пытается использовать аппаратное ускорение для различных графических операций, там где это возможно; это зависит от видеокарты, которая установлена в вашем компьютере. Если для некоторой задачи ускорение не доступно, OpenGL осуществляет программный рендеринг. Это значит, что если вы берете OpenGL у SGI и при этом хотитие получить хоть какое-нибудь аппаратное ускорение, то это должна быть реализация, которая написана и откомпилирована специально для вашей видеокарты. Иначе, все что вы получите -- software rendering. То же самое верно и для OpenGL-клонов, таких как Mesa. OpenGL является open source эквивалентом DirectX. Важное отличие между ними состоит в том, что, поскольку OpenGL открыт (DirectX закрыт), игры написанные для OpenGL гораздо легче портировать в Linux, тогда как портирование DirectX-игр сейчас попросту невозможно. Факт, что если вы начинаете с нуля, то написание игры, которая будет компилироваться и в Linux, и в Win32, является абсолютно тривиальной задачей.
Mesa -- это свободная реализация OpenGL API, которую придумал и написал Brian Paul. Несмотря на отсутствие официального сертификата, это практически полностью совместимая с оригиалом OpenGL-реализация, соответствующая спецификациям ARB. Сообщается, что Mesa даже быстрее реализации OpenGL от SGI.
Как и OpenGL, Mesa использует аппаратное ускорение, там где это возможно. Это означает, что существуют разные "версии" или "сборки" Mesa, в зависимости от видеокарты, которая у вас установлена. Если у вас Voodoo I, II или III, то предполагается использование "mesa+glide2" (автор David Bucciarelli), которая является реализацией OpenGL, использующей glide в качестве средства для рендеринга определенных графических операций.
В рендеринге графики участвуют 3 игрока: приложение-клиент (такое как Quake 3), X-сервер и железо (видеокарта). Раньше клиентам строго запрещалась запись непосредственно в аппаратную часть, и для этого была хорошая причина. Программа, которой позволено напрямую обращаться к железу, различными путями может привести систему к зависанию. Вместо того, чтобы довериться программистам, Linux просто запрещает это делать. Однако, это изменилось с появлением X 4.0 и Direct Rendering Infrastructure (DRI). DRI свободно разрешает X-клиентам коллективную запись информации 3D рендеринга непосредственно в видеокарту безопасным путем. DRI "убирает с дороги" X-сервер, и 3D драйвер (Mesa или OpenGL) может использовать железо напрямую. Это делает процесс быстрее. Информация 3D рендеринга не должна обязательно аппаратно ускоряться.
С технической точки зрения, это имеет несколько достоинств.
GLX -- это расширение X, используемое OpenGL-программами, "клей" между не зависящим от платформы OpenGL и привязанным к платформе X.
Проект Utah GLX является предшественником DRI. Он основывается на несколько других дизайнерских решениях в отношении разделения данных и методов доступа к видеокарте. (К примеру, он рассчитывает на привелегии root, вместо создания инфраструктуры ядра, необходимой для безопасного доступа). Он обеспечивает поддержку (на данный момент) нескольких карт, которые не очень хорошо поддерживаются в DRI. В частности, семейство ATI Rage Pro, S3 Virge (хотя тот, кто использует это для игр -- просто чудак) и open source драйвер для TNT/TNT2 (очень недоделанный). Драйвер TNT/TNT2 основан на реверс-инженеринге невнятных исходников драйверов для X 3.3 от nVidia. Однако, они абсолютно незавершенные и на деле не пригодны для использования. Кстати, пока поддержка G400 не будет *действительно* исправлена в DRI, для нее Utah GLX тоже будет лучшим решением; однако, ко времени опубликования этого HOWTO, это, вероятно, не будет проблемой.
Иногда встречаются больные (говорю с уважением), которые пишут игры под xlib, иначе я даже не упомянул бы о здесь об этом. xlib -- это набор C-библиотек, предназначенных для программирования под XFree86 на самом низком уровне. Любая графическая программа в X очень активно использует xlib.
По праву можно сказать, что xlib запутанна и сложна. Я бы сказал, что это наиболее трудное и требующее наибольшего времени на освоение явление в программировании. Программа, которая просто подключается к X-серверу, выводит окно и больше вообще ничего не делает, может состоять из 40 строк, включающих всебя запутанные вызовы функций с очень длинными именами. По этой причине, существует масса библиотек, которые скрывают от нас детали xlib-программирования. Некоторые из них фокусируются на рисовании в окнах
(такие как SDL). Другие больше сконцентрированы на элементах управления в окнах (например, выпадающие меню, радио-кнопки, и текстовые поля); эти библиотеки, соответственно, называют наборами элементов управления. Gtk -- мать всех подобных библиотек, но есть и много других, таких как fltk и Qt.
SDL (Simple DirectMedia Layer) -- это библиотека от Sam Lantiga из Loki Software (закончившего UCD!!). В действительности, это meta-библиотека; в том смысле, что она не только графическая, скрывающая программирование под xlib, но еще и обеспечивающая простой интерфейс к звуку, музыке и обработке системных событий. Она распространяется под лицензией LGPL и обеспечивает также поддержку джойстика и OpenGL. 40-строчная запутанная программа, которую я упоминал в секции о xlib, при помощи SDL может быть легко написана в 6 строк читабельного кода.
Наиболее сильная сторона SDL -- ее кроссплатформенность. За исключением нескольких деталей, касающихся заголовочных файлов и компиляции, программа написанная для SDL может быть откомпилирована под Linux, *BSD, Windows*, MacOS and BeOS. Существуют расширения SDL, написанные разными людьми, для таких вещей, как поддержка любых нужных вам графических форматов, проигрывания видео в формате mpeg, отображения шрифтов truetype, поддержка спрайтов, а также почти всего другого, что существует под Солнцем. Вполне очевидно, что SDL -- это пример того, к чему должны стремиться все остальные библиотеки. Единственный недостаток -- нехватка документации (вздох), но, насколько я понимаю, книга об SDL не за горами. Если вы программируете игры, окажите услугу человечеству -- используйте SDL.
У Сэма есть скрытый мотив для написания такой крутой библиотеки. Он -- ведущий программист компании Loki Software, которая использовала SDL во всех своих играх, за исключением Quake3.
Я сам не очень уверен, что знаю. Не может-ли кто-нибудь пожертвовать параграф-другой?
Если вам еще никто этого не объяснил, консоль -- это темный текстовый экран, который вы видите после включения вашего компьютера (при условии, что у вас не происходит запуск xdm или gdm). Ее можно противопоставить среде X, в которой имеются всевозможные GUI-приложения, такие как xterm. Распространенным заблуждением является мнение, что X обозначает графику, а консоль -- отсутствие таковой. В консоли, несомненно, графика есть -- она полноэкранна, крайне быстра и крайне убедительна.
SVGAlib -- это графическая библиотека, позволяющая вам отображать графику в консоли. Существует много игр, использующих SVGAlib и я являюсь большим поклонником этой библиотеки и вообще графических консольных игрушек. SVGAlib вызывает небольшой хруст в суставах, потому что исполняемый файл должен запускаться из-под root или быть setuid, но библиотека должна запускаться под root только при первом старте приложения. Она сразу же освобождается от root'ового статуса.
Фрэймбуферы подобны консоли, но они работают в графическом, а не текстовом режиме. Почему может понадобится симулировать текстовый режим из графического?
Это позволяет нам запускать графические приложения, такие как просмотрщики postscript, прямо из консоли. Это также позволяет выбрать не только размер консольного шрифта, но и вообще другой шрифт! Представляете себе в консоли шрифт Comic Sans MS? В LDP есть хороший HOWTO о фрэймбуферах.