Сергей Кононенко
Предисловие
В последнее время Linux все активнее завоевывает рынок desktop-систем, идя в этой области далеко впереди остальных Unix-ов. Все больше программистов пишут приложения, ориентированные на конечного пользователя. Многие фирмы всерьез рассматривают desktop-linux как выгодный коммерческий продукт.
Linux уже неплохо обосновался на рынке офис-систем и стал активно продвигаться на рынок домашних компьютеров. Вообще говоря, Linux и раньше чаще встречался дома, чем в офисе. Поэтому под активным продвижением, я имею в виду развитие мультимедийных программ и игр. Долгое время пользователям Linux приходилось довольствоваться маленькими freeware играми, которые за редкими исключениями, не соответствовали современному уровню (в основном, из-за качества графики и слабо продуманного сценария). Единственной "отрадой" были игры от id Software, которые не уступали версиям для других платформ. С появлением фирмы Loki Software ситуация резко изменилась. Loki уже успешно портировала под Linux некоторые "культовые" игры (например Heroes of Might and Magic III), и похоже, не собирается останавливаться на достигнутом. Возможно, успехи Loki заставят последовать ее примеру другие фирмы, возможно, версии под Linux будут делать сами разработчики. Конкуренция со стороны фирм заставит свободных программистов лучше прорабатывать свои игры. В любом случае, у игровой сферы под Linux-ом хорошие перспективы.
Но среди всех программ для desktop-систем, игры, похоже, наиболее требовательны к системным ресурсам. Поэтому, для реализации игры на конкретной платформе, нужно, чтобы там был мощный графический интерфейс: быстрый, удобный для программиста и позволяющий использовать все возможности железа. Не секрет, что именно появление DirectX способствовало переходу разработчиков игр с уже устаревшего DOS-a на Windows. Для Linux-а существует несколько графических систем, и в этой статье я хочу рассмотреть их возможности и недостатки с точки зрения игр и мультимедийных приложений.
X Window system
X Window является традиционной и основной графической системой для Linux-a и всего Unix-сообщества. Это мощная, профессиональная система, обладающая большим набором возможностей. Большинство пользователей Linux-а работают с системой XFree86, которая является бесплатной реализацией X11 Realise 6 и входит в состав всех известных дистрибутивов. Некоторые предпочитают коммерческие варианты: AcceleratedX и MetroX. Говорить о X Window можно очень долго, но сразу стоит отметить, что эта система создавалась не для desktop-компьютеров. X Window ориентирована на сеть и построена по клиент-серверной технологии. Прикладные программы с помощью библиотек системы по специальному протоколу обмениваются графической и управляющей информацией с X-сервером, который занимается отображением графики и работает с мышью и клавиатурой. Причем связь может осуществляться как через локальный сокет, так и через TCP/IP. То есть существует реальная возможность выполнять программу на одном компьютере, а отображать графику на другом. В свое время на меня большое впечатление произвел Netscape, запущенный подобным образом и работающий с весьма приличной скоростью. Похоже, что в области сетевых распределенных систем X Window до сих пор вне конкуренции.
Но в нашем случае, сетевые возможности X Window превращается в основной недостаток этой системы. Большинство игр и мультимедийных программ активно используют копирование в видеопамять (на это может уходить от 20 до 70 процентов времени, затрачиваемого на обработку одного кадра). Соответственно, эта операция должна быть оптимизирована по максимуму. Поэтому передачу данных через сокет (т.е. по сути двойное копирование) нельзя назвать хорошим решением в данном случае. Это одна из основных причин, по которым X Window в некоторых задачах отстает в скорости по сравнению с GDI Windows.
К счастью X Window не только мощная но и гибкая система (как и сам Linux), она позволяет с помощью расширений добавлять новые функции, не нарушая основных принципов системы. Поэтому появилось расширение, призванное решить описанную выше проблему.
XShm (MIT Shm)
XShm (X Shared Memory) - расширение X Window, позволяющее копировать изображения напрямую в видеопамять (в пределах окна программы). При этом графическая данные хранятся в общей памяти, c которой работает как прикладная программа, так и X сервер. Таким образом удается избежать двойного копирования, не затрагивая основных принципов X Window. Это расширение появилось достаточно давно, оно присутствует в большинстве реализаций X Window, и почти все программы, требующие быстрого отображения графики используют XShm.
XShm - эффективный метод, он дает возможность получить быстродействие, близкое к максимально возможному. Достаточно будет сказать, что Quake2 в софтварном режиме, на сервере с 8-битной глубиной цвета у меня показывает те же fps, что и версия под Windows с наиболее быстрым драйвером, который мне удалось достать для моей S3Trio64.
Чаще всего скорость при использовании XShm падает из-за несовпадения глубины цвета данных и глубины цвета, установленной в X-сервере. В этом случае какое-то время тратится на преобразование, которое, следует отметить, делается "прозрачно" и достаточно быстро. В остальных случаях все в порядке, о чем говорит приведенный выше пример.
XShm достаточно прост с точки зрения разработчика. Фактически в нем реализованы аналоги стандартных PutImage и GetImage, поэтому переделать программу под это расширение несложно. Сложнее работать с X Window без высокоуровневых библиотек, но это уже другой вопрос.
XShm всем хорош например для видеоплейеров, но во многих играх нужен полноэкранный режим, и здесь XShm уже не поможет. Эту проблему призвано решить другое расширение X Window.
DGA
DGA (Direct Graphics Access) является специфическим расширением XFree86, и насколько я знаю, в других системах X Window не существует, или существует в другом виде. DGA позволяет прикладным программам получать прямой доступ к видеопамяти (фреймбуферу) и работать в полноэкранном режиме. Также программа может перехватывать на себя все сообщения от клавиатуры и мыши. Таким образом, этот интерфейс в какой-то мере является аналогом DirectDraw для Windows.
Достоинства этого метода очевидны: он позволяет работать с железом почти на прямую и выжать максимальное быстродействие. Но, пожалуй, этим все и ограничивается.
DGA - хорошая идея, но реализация, к сожалению, имеет много недостатков. Во-первых, это невозможность изменения "на лету" глубины цвета видеорежима (хотя, это скорее недостаток X Window вообще). Во-вторых невозможность вернутся в обычный режим, если программа, работающая с DGA не предоставит такую возможность: переключение между виртуальными консолями в этом случае не работает, а никакого аналога Alt-Enter из Windows не существует. Мне часто после зависания StarCraft-а в Wine, использующего DGA, приходилось ``убивать'' X-сервер, и с помощью хитрых манипуляций вслепую с SysRq и restoretextmode восстанавливать нормальную работу консоли (причем не всегда успешно). В-третьих для использования DGA нужны права root-а, что иногда вызывает проблемы с безопасностью.
С точки зрения программиста DGA тоже далек от идеала. Во первых, это крайне бедный набор функций, по сути сводящихся к установке видеорежима и получению адреса фреймбуфера. В более поздних версиях (например, в XFree 3.3.6) появился интерфейс для функций 2d-ускорителя, реализованных в X Window. В некоторых случаях блиттер (перемещающий прямоугольники в пределах экрана) бывает очень полезен. К сожалению, заставить работать эти функции в DGA мне не удалось, хотя вообще они работают. Во вторых, проблема с отладкой программ, опять из-за невозможности переключать консоли или возвращаться в обычный режим.
К счастью, DGA не стоит на месте. В долгожданной XFree 4.0 появилось расширение DGA2, которое должно исправить недостатки первой версии и предоставить новые возможности. К сожалению, XFree 4.0 не работает с моей видеокартой, поэтому пока о DGA2 ничего сказать не могу.
А пока некоторые проблемы DGA может решить библиотека SDL, о которой пойдет речь ниже.
Svgalib
Второй по распространенности графической системой для Linux-а несомненно является Svgalib. Эта библиотека предоставляет программам интерфейс для консольной полноэкранной графики и никак не зависит от X Window. В отличие от последней, эта система разрабатывалась специально для игр и мультимедийных программ. Она возникла потому, что X Window не устраивала многих разработчиков игр из-за сложности и громоздкости (а также отсутствия в то время DGA). Нужна была маленькая компактная библиотека, которая предоставляла бы разработчикам среду, похожую на Dos-овскую.
Фактически Svgalib представляет собой набор драйверов для различных видеокарт, которые реализуют основные графические примитивы: Line, Rectangle, Circle, PutImage, работу с палитрами, видеопамятью и так далее. Кроме этого в библиотеке есть интерфейс для работы с клавиатурой, мышью и джойстиком. Svgalib работает в полноэкранном режиме, но позволяет переключать консоли. Кроме того, она почти работала в бэкграунде, т. е. программа не останавливалась, когда переключаешься на другую консоль. В последних версиях, к моему удивлению, эта почти работоспособная возможность была убрана.
Из достоинств Svgalib можно назвать уже упомянутый маленький размер и компактность, простоту, высокое быстродействие, полноэкранный режим и т.д. Казалось бы, это идеальное решение, созданное специально для разработчиков игр, но есть и недостатки, которые ограничивают применение этой системы.
Во первых, многие считают Svgalib нестабильной, потому что она не всегда восстанавливает текстовый режим в случае аварийного останова программы (для этого как раз и существует утилита restoretextmode), хотя в последнее время я с этой проблемой не сталкивался. Во-вторых, при работе с видеопамятью Svgalib по умолчанию использует режим с переключением банков, а не линейный доступ к фреймбуферу, что уменьшает производительность. Для примера сравните результаты, которые выдают программы speedtest и linearspeed из комплекта Svgalib. Это объясняется тем, что не все драйвера видеокарт поддерживают линейный фреймбуфер (для S3 мне пришлось писать эту поддержку самому). C 2d-ускорением ситуация еще хуже: есть неплохой интерфейс, но реализован он только в 2-3-х драйверах.
Другим недостатком является необходимость наличия root-овских прав для работы с Svgalib, так как она обращается напрямую к портам железа. Чтобы программы могли запускать обычные пользователи, на них необходимо ставить suid-флаг, что влечет за собой проблемы с безопасностью. За последнее время я не видел эксплоиты к Svgalib-ским программам, тем не менее большинство системных администраторов относятся с большим подозрением к этой библиотеке, потому что, чем меньше в системе программ с suid-флагами, тем спокойнее. Хотя пользователям домашних компьютеров это не важно.
И, наконец, независимость Svgalib от X Window далеко не всегда является достоинством. Эти системы могут конфликтовать при совместной работе, хотя я с этим не сталкивался. Некоторые видеокарты поддерживаются в X-ах, но не в Svgalib, и часто приходится тратить немало сил, чтобы перенести драйвер из одной системы в другую.
Для программистов Svgalib достаточно удобна, особенно для тех, кто писал программы под Dos на Borland C или Watcom С. Помимо стандартных низкоуровневых функций, в состав Svgalib входит библиотека vgagl, предоставляющая удобный абстрактный интерфейс более высокого уровня. Единственный недостаток - проблема с отладкой, так как переключение консолей в режиме трассировки не работает. Но, в отличие от DGA, можно обойтись без второго терминала, переключая консоль с помощью специальной функции в текстовый режим и обратно. Правда тогда прийдеться забыть о DDD и других графических оболочках для gdb.
Несмотря на достоинства и устранимость недостатков, будущее Svgalib туманно. "Серьезные разработчики" (фирмы) стараются не использовать эту "нестандартную" библиотеку, считая X Window единственно возможной графической системой. Поэтому коммерческие игры (кроме разве что id-шных) вряд ли будут использовать этот интерфейс. Но хорошего и полного аналога Svgalib тем не менее нет, поэтому свободные программисты вряд ли откажутся от этой библиотеки.
Не так давно от основной версии Svgalib отделилась нестабильная ветка 1.9.x, которая должна перерасти в 2.0.0. Там появилось много принципиальных изменений, но пока эта версия библиотеки неработоспособна (по крайней мере у меня), поэтому говорить о ней что-то определенное трудно. Надеюсь, в будущем Svgalib порадует нас приятными сюрпризами.
GGI
GGI (General Graphics Interface) - графическая система нового поколения, предоставляющая для прикладных программ абстрактный интерфейс, не зависящий от конкретного "железа" и особенностей операционной системы. GGI предназначена для решения того же класса задач, что и Svgalib, но на более современном и продвинутом уровне.
GGI построена по модульному принципу. Абстрактный уровень и графические примитивы реализуются самой библиотекой, а непосредственная отрисовка осуществляется с помощью загружаемых драйверов, которые используют либо низкоуровневые интерфейсы (framebuffer device), либо другие графические системы: X Window (с DGA и без), Svgalib и т.д. Кроме того, модули могут делать дополнительные функции: отображать виртуальный truecolor экран на реальном дисплее с 8-битной глубиной цвета и наооборот; выводить графику на удаленном сервере и т.д.
В проект GGI входят также библиотеки libgii (General Input Interface) для обработки сообщений от клавиатуры и мыши, libggi2d и libgg3d, которые реализуют интерфейс более высокого уровня для 2D и 3D графики соответственно. Но последние две библиотеки находятся пока в начальной стадии разработки, поэтому говорить о них всерьез пока рано. Все они также построены по модульному принципу.
Основные достоинства GGI - неплохое быстродействие, небольшой размер, модульный принцип, предоставляющий неограниченные возможности для расширения и реализации "экзотических" функций: например, можно сделать модуль, который делает стереокартинку, поддерживает систему виртуальной реальности и т.д. Абстрактный интерфейс позволят программе по собственной инициативе или по вашему желанию работать в окошке, на весь экран (через DGA), в консоли (через Svgalib или fbdev). Кроме это в GGI активно используется линейный фреймбуфер и 2d-ускорение графических примитивов (рисование линий, прямоугольников, пресловутый блиттер), если, конечно, это поддерживает низкоуровневый драйвер.
Основным недостатком можно назвать тот же абстрактный интерфейс, поскольку обычно GGI используется как "обертка" для других систем (X Window, Svgalib), что ведет к небольшой потере производительности. Также, за счет этого, GGI автоматически вбирает в себя недостатки используемых систем (хотя, в случае DGA, сглаживает их). Это не связано с GGI напрямую, так как по задумке он должен работать через низкоуровневый интерфейс KGI, который будет рассмотрен ниже.
Помимо всего, GGI еще достаточно "сырая": есть недостатки в интерфейсе, путаница с модулями и тому подобное.
GGI очень привлекательна для разработчиков, так как имеет элегантный и продуманный программный интерфейс, который, с одной стороны позволяет не заботится о низкоуровневых особенностях, с другой стороны эффективно использовать все возможности системы. Программы под GGI обещают быть легко переносимыми. Планируется реализация GGI не только под Linux и другие Unix-ы, но и под Windows, OS/2 и т.д. Довольно удобен процесс отладки, так как программу можно отлаживать в окне X Window, используя графическую оболочку для gdb, а рабочую версию запускать на весь экран через DGA или Svgalib.
В целом GGI выглядит многообещающе, но его будущее так же не определено. Особого интереса к интерфейсу со стороны разработчиков коммерческого софта не наблюдается. Во многих freeware играх поддержка GGI появилась лишь как дань моде. Я считаю, что все это связано с низкой активностью руководителей проекта, потому что разработка и продвижение GGI идет довольно вяло. GGI - это хорошая идея, и при желании всех заинтересованных сторон этот интерфейс может стать аналогом DirectX.
Интересно заметить, что все рассмотренные графические системы являются программами или библиотеками пользовательского уровня, хотя в desktop-системах (Windows и OS/2) поддержка графики находится в ядре. О том, какие графические возможности предоставляет ядро Linux-а, пойдет речь дальше.
Framebuffer device
В ядре Linux-а начиная с серии 2.1.* появилось устройство framebuffer device (/dev/fb*), которое предоставляет доступ к видеопамяти, позволяет управлять экраном и работать с консолью в графическом режиме. Таким образом, уже сейчас в ядре есть графический интерфейс. Интересно, что он получил широкое распространение на неинтеловских платформах. Появилось множество драйверов для видеосистем, используемых в этих архитектурах. Скорее всего, это объясняется тем, что на этих платформах существуют проблемы с реализацией X Window и Svgalib, поэтому фреймбуфер является единственным путем для использования графики.
На интеловской платформе фреймбуфер развивается достаточно вяло, драйверов для видеокарточек немного. Почти все польщователи ставят драйвер vesafb, который работает через VBE BIOS карточки. К сожалению, vesafb годится только для демонстрации симпатичного пингвина во время загрузки системы или работы с "большой" консолью, поскольку не позволяет менять видеорежимы после загрузки ядра.
Правда фреймбуфер (как и в случае неинтеловких платформ) может помочь тем, чья видеокарта не поддерживается XFree, и кто тем не менее хочет работать в SVGA-режимах. Существует сервер XF86_FBDev, который работает через фреймбуфер, но функции ускорения не поддерживает. Понятно, что этот метод родился не от хорошей жизни, поэтому назвать его оптимальным нельзя. По тем же самым причинам с фреймбуфером не может эффективно работать и GGI.
Существует много мнений о том, в какую сторону должен развиваться графический интерфейс в ядре Linux-а. Я расскажу о некоторых из них.
KGI
KGI (Kernel Graphics Interface) появился, как часть проекта GGI. Представляет собой расширение функций framebuffer devic-a, чтобы на уровне ядра поддерживать GGI. KGI позволяет использовать возможности 2D ускорителей, устанавливать параметры видеорежимов (как modeline в X Window), обращаться к Ramdac-у и ClockChip-у видеокарты, задавать (а может, и автоматически определять) параметры монитора. В KGI уже есть драйвера для многих распространенных видеокарточек, хотя далеко не всех. К сожалению, моя S3Trio64 не поддерживается, а попытки переделать драйвер от родственной карточки пока не увенчались успехом. Поэтому протестировать все возможности KGI мне не удалось, хотя vga-драйвер, которым я пользовался, вполне работоспособен и производит хорошее впечатление.
В целом, KGI выглядит неплохой идеей, поскольку позволяет GGI показать себя во всей красе. Тем не менее будущее KGI под вопросом. Например, пока что не предвидется официальное включение этого интерфейса в ядро, и тому есть немало причин.
Уже давно среди разработчиков Linux-а ведутся споры о том, нужна поддержка графики на уровне ядра, или нет. Аргументы "За" выглядят следующим образом. Во-первых, "идеологически правильно", когда все обращения к портам устройств производятся из области ядра, а не прикладных программ (как в случае X Window и Svgalib). Отпала бы необходимость в suid-флагах, и таким образом решились бы проблемы безопасности. Не возникали бы конфликты между разными системами, которые одновременно и напрямую обращаются к видеокарте (опять X Window и Svgalib). И наконец наличие единого интерфейса избавило бы от "лишней" работы по написанию низкоуровневых драйверов для различных систем. И наконец, поддержка на уровне ядра может дать некоторый выигрыш в производительности.
Тем не менее, есть и аргументы "Против". Чаще всего ссылаются на то, что ядро и так сильно распухло, поэтому включение большого числа драйверов различных видеокарт нежелательно. Во вторых, в случае "внутриядерного" интерфейса, глюки на уровне железа, которые не редко встречаются во многих видеокарточках, могут привести к остановке ядра. А это не вяжется с концепцией стабильности Linux-а. В третьих, возникнут большие трудности (как технические, так и организационные) при переносе драйверов из X Window в ядро, так как XFree ориентируется не только на Linux сообщество. Если же X-ы оставить в покое, тогда идея интерфейса в ядре потеряет смысл.
Однако, я считаю, что развитию KGI мешают не эти причины, а опять таки недостаточная настойчивость и организованность руководителей проекта GGI. Появление фреймбуфера, похоже решило вопрос, быть или не быть графическому интерфейсу в ядре, а изменения, вносимые KGI, не нарушают принципа этой архитектуры.
А пока вопрос о KGI остается открытым, в нестабильной ветке ядра 2.3.* появился интерфейс, имеющий прямое отношение к графическим системам.
DRM
DRM (Direct Rendering Manager) создан, как поддержка внутри ядра интерфейса DRI (Direct Rendering Infrastructure), который был включен в XFree 4.0. DRM не является полноценным графическим интерфейсам, скорее всего, он призван взять на себя функции XFree, наиболее требовательные к производительности, и которые эффективней выполнять на уровне ядра: синхронизация обмена данными с видеокартой, DMA, использования ускорителя и т.п. Пока что в состав DRM входят драйвера только для двух карточек: 3dfx Banshee/Voodoo3 и 3dlabs GMX 2000. Если DRM покажет хорошие результаты в связке с XFree, то поддержка других карт, скорей всего, не заставит себя ждать. Многие фирмы - производители видеокарточек заинтересовались DRM. Но пока сказать о DRI что-либо определенное довольно трудно.
SDL
SDL (Simple DirectMedia Layer). Я не зря пишу о SDL в самом конце. Во-первых, эту библиотеку я увидел, когда большая часть статьи уже была написана, во-вторых SDL это больше чем графическая система. В README написано, что SDL - интерфейс, предоставляющий низкоуровневый доступ к видеопамяти, звуковой карте, клавиатуре и мыши. На самом деле это многофункциональная библиотека для разработчиков игр и мультимедиа программ. Помимо стандартных возможностей в SDL реализованы функции, часто использующиеся в играх: библиотека позволяет загружать графические и звуковые файлы (пока только BMP и WAV), работать с CD-ROM-ом, считать временные задержки. Во многом SDL похожа на GGI, она тоже работает как оболочка для других графических систем: сейчас графика может отображаться в окне X Window (XShm) или на весь экран, используя DGA. Есть возможность работы с framebuffer device (c определенными видеокартами). Должна появится поддержка OpenGL, Svgalib и GGI (интересно представить программу, работ
ающую по цепочке SDL --> GGI --> X Window).
У SDL много достоинств: небольшой размер, компактность (в отличие от GGI библиотека состоит из одного файла и может линковаться статически), неплохое быстродействие. Для ускорения графических операций задействована мини-библиотека Hermes, использующая MMX. Но, главное, SDL умеет "на лету" переходить из оконного режима в полноэкранный, устраняя тем самым основной недостаток DGA. Для этого раньше служила знакомая по Windows комбинация Alt-Enter, но в последних версиях эту возможность убрали, переложив ответственность за переключение на прикладную программу, что по-моему, возвращает все к ситуации с DGA.
Недостатков не так много, но они есть. SDL в X Window не использует аппаратное 2d-ускорение, отсутствие которого сказывается на некоторых играх. Как оболочка, SDL наследует недостатки низкоуровневых графических систем.
Для программиста SDL выглядит очень привлекательно. Простой и удобный интерфейс предоставляет "в одном флаконе" почти все функции, необходимые разработчику игр. Единственно, настораживает малое число поддерживаемых форматов данных (я, например, не хочу хранить графику в BMP), но надеюсь, что это дело поправимое. Удобно отлаживать программы, используя, как и в случае GGI, оконный режим. SDL позволяет нормально работать c DGA. Библиотека поддерживает threads, что дает преимущество на многопроцессорных платформах и зачастую просто удобно для программиста. И, наконец, SDL многоплатформенная библиотека, уже сейчас есть реализации под Windows, BeOS и Solaris, скоро будут под FreeBSD и MacOS. Так что портировать игры будет довольно легко.
Очевидно, что у SDL радужные перспективы на будущее. Похоже, это основной претендент на место аналога DirectX для Linux-а. Единственный конкурент GGI немного отстал. К тому же SDL пользуется любовью коммерческих разработчиков: достаточно сказать, что Loki Software для портирования игр использует именно эту библиотеку (по крайней мере, в Heroes3). Не меньше популярность SDL и среди свободных программистов. Так что у нее есть все шансы победить конкурентов.
3D-графика
Я не буду писать о 3d-интерфейсах, потому что, во-первых, это тема для отдельной статьи, даже большей, чем эта; во-вторых, у меня нет 3d-ускорителя, а пересказывать чужие мнения по этому поводу мне не хочется. Хочу лишь сказать, что в этой области реальной альтернативы OpenGL нет. Уже есть бесплатная библиотека Mesa3D, реализующая этот интерфейс на 3dfx-чипах. Сейчас поддержкой OpenGL в Linux-е занимается SGI и NVidia, уже появились реализации для других 3d-ускорителей. Так что, в этой области Linux-у, скорей всего, не грозит отставание от других платформ.
Заключение
Несмотря на успехи SDL, она вряд ли в ближайшее время станет единым стандартом. Некоторым хватает расширения XShm, некоторые привыкли к Svgalib, многие отдали свое предпочтение GGI. По-моему, это даже неплохо. Я люблю Linux в основном за гибкость и свободу выбора. Для большинства программ можно найти аналоги. Я могу выбрать реализацию X Window или оконный менеджер. Могу выбирать между GTK и Qt, KDE и GNOME. Я считаю это большим преимуществом. Конечно, приходится держать большое число библиотек, делающих по сути одно и тоже. Но рассмотренные графические библиотеки не сильно большие, и врядли существенно повлияют на экономию дискового пространства. Главное, чтобы графические системы не конфликтовали между собой, чтобы конкуренция служила стимулом совершенствования, а не поводом для флейма. Сейчас есть все возможности для написания качественных игр, разработчик может выбрать интерфейс по своим потребностям, не забывая, конечно, о наличии у пользователя необходимой библиотеки.
Оригинальная статься http://www.sdteam.com/?tid=1409
