Графічні системи Linux-а з точки зору ігор і мультимедіа, Linux, Операційні системи, статті

Сергій Кононенко

Передмова

Останнім часом 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. Я вважаю це великою перевагою. Звичайно, доводиться тримати велике число бібліотек, що роблять по суті одне і теж. Але розглянуті графічні бібліотеки не сильно великі, і навряд чи істотно вплинуть на економію дискового простору. Головне, щоб графічні системи не конфліктували між собою, щоб конкуренція служила стимулом вдосконалення, а не приводом для флейму. Зараз є всі можливості для написання якісних ігор, розробник може вибрати інтерфейс по своїм потребам, не забуваючи, звичайно, про наявність у користувача необхідної бібліотеки.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*