OpenGL a DirectX III. - VII.

Podpora "starých" funkcí

Mnoho lidí, mezi nimi i autor výše uvedeného článku o UT 2004 si myslí, že cituji: Bohužel je vidět, že v oblasti 3D grafiky se OpenGL nemůže DirectX v kvalitě obrazu rovnat. Zatímco DX 9.0 představuje hardwarovou podporu bump mapingu, pixel shaderů a krásných světelných efektů, musíme se v OpenGL spokojit s poněkud horší kvalitou obrazu.

Z tohoto citátu je jasně vidět, že tito lidé ABSOLUTNĚ neví, o čem mluví nebo v jeho případě dokonce píšou. Mohu jen odkázat na NeHe Tutoriály 22 - Bump Mapping a Multitexturing (tady je ale bump mapping počítán ještě softwarově :-( a 47 - CG vertex shader.

Bump Mapping (SW) a Multitexturing (HW)

Vertex shader (HW)

No, a co se týče světel, nevím, jestli je tohle v D3D 9.0 oproti jeho předchozím verzím nějaká převratná novinka (není), ty jsou v OpenGL od samého začátku - cca. 15 let.

Na druhou stranu D3D ještě donedávna nemělo ani takové základní funkce jako backface culling [3]! Pro ty, co neví, o čem je řeč... Jakýkoli polygon se vždy renderuje "dvakrát", nejdříve přední strana a pak zadní (zjednodušeně řečeno) - samozřejmě v programu se vertexy definují pouze jednou. Když se podíváte na list papíru uvidíte přední stranu a po otočení zadní (ve skutečném světě už jako přední, pro OpenGL stále zadní).

U uzavřených objektů, které nikdy nepůjdou vidět zevnitř (bedna ve scéně) nebo zvenku (skybox, místnost), se toho může využít a jednu stranu odstranit. V OpenGL stačí jediná funkce:

glCullFace(GL_FRONT);// Odstraňovat přední strany
glCullFace(GL_BACK);// Odstraňovat zadní strany
glCullFace(GL_FRONT_AND_BACK);// Odstraňovat obě strany

No dobře, dvě funkce, ještě se to musí zapnout...

glEnable(GL_CULL_FACE);

Abyste viděli názorně, o co se jedná, screenshot z NeHe Tutoriálu č. 11 - Efekt vlnící se vlajky. Mimochodem první OpenGL tutoriál, který jsem přeložil do češtiny...

Přední strana vyplněná, zadní linkami

Pozn.: Zde nebyl použit culling, ale tzv. módy polygonů - na tomto jde totiž culling vidět :-), ve skutečnosti při ořezání polygonu neuvidíte nic. Obě techniky pracují na stejném principu.

glPolygonMode(GL_BACK, GL_FILL);// Zadní strana vyplněná
glPolygonMode(GL_FRONT, GL_LINE);// Přední strana mřížkou

Abychom trochu zrychlili, o dalších základních věcech, které GL umí a D3D ne, pouze citát z [3]:

Pozn.: Tento zdroj je už relativně starý (min. 3 roky), takže u nových verzí DX už všechno nemusí být pravda (např. zmíněný face-culling).

Na druhou stranu se zabývá i věcmi, které D3D umí lépe:

BTW: Goraudovo a Phongovo stínování - nikdy jsem se nedočetl, jaký je mezi nimi rozdíl, snad jen to, že Phongovo je lepší. Všude bývá uvedeno, že ho OpenGL narozdíl od DirectX nepodporuje... a vždycky u této zprávy bývá malými písmeny, že v DirectX ještě není implementováno :-).

Podpora HW funkcí nových grafických karet

Právě na tomto tématu spočívá tíha největší mystifikace "DX fandů". (Tedy kromě toho, že se OpenGL nemůže ve vlastnostech zobrazení... atd.) Ti, co v životě neslyšeli o tzv. OpenGL rozšířeních (OpenGL extensions) a naopak slyšeli, že se OpenGL standard od svého uvedení na začátku devadesátých let minulého století nijak výrazně nezměnil, pravděpodobně kroutí nechápavě hlavou. Ani se jim nedivím, vždyť karty před patnácti lety "skoro nepodporovaly ani textový režim" (nad tím v uvozovkách nepřemýšlejte :-).

Modelová situace: Výrobce karty (NVIDIA, Ati...) přidá novou převratnou vlastnost, při jejímž použití se extrémně urychlí rendering. Za jak dlouho ji může Woq programátor (analogie na Frantu uživatele, pro naše Linuxové kamarády BFU) použít? Pokud si tuto kartu koupí, aby měl na čem testovat, a používá OpenGL... ihned. Přestože nebyla vytvořena žádná nová verze (jak bylo uvedeno, standard se téměř nezměnil), díky extensionům je možné zpřístupnit jakékoli HW funkce karty.

To, jaká OpenGL rozšíření vaše karta podporuje, můžete zjistit hned několika způsoby. Každého asi napadnou webové stránky výrobce. Tuto možnost bohužel nemám ověřenou, v praxi jsem ji nikdy nepotřeboval - hned pochopíte. Ve Win bych něco takového hledal asi ve vlastnostech obrazovky, Linux má příkaz "glinfo".

S největší pravděpodobností bude tento příkaz dostupný pouze s nainstalovanými NVIDIA drivery, takže pokud u vás nefunguje zkuste prohrabat Ovládací centrum (MDK) nebo KDE nastavení prostředí - někde jsem to tam viděl. V neposlední řadě můžete zkusit NeHe Tutoriál 24 - Výpis OpenGL rozšíření, respektive program, který se v něm vytváří.

Výpis OpenGL rozšíření

Při kódování programu se detekce dostupnosti rozšíření provádí přes volání funkce glGetString(GL_EXTENSIONS), která vrátí ukazatel na řetězec mezerami oddělených názvů podporovaných rozšíření (podobné jako u výpisu glinfo výše). Pokud je dané rozšíření podporováno, zavolá se SDL_GL_GetProcAddress() (ve Win32 API wglGetProcAddress()), které vrátí ukazatel na "HW funkci" implementující dané rozšíření. Na následujícím obrázku je vyobrazen hardwarový multitexturing.

Multitexturing (HW)

Na druhou stranu, pokud rozšíření dostupné není, může programátor zkusit vše dopočítat softwarově na CPU - např. jednoduchý multitexturing lze vytvořit, mimo jiné, dvěma objekty na stejném místě, ten druhý musí být průhledný. Pokud si zvětšíte screenshot NeHe Tutoriálu 26 - Odrazy a jejich ořezávání za použití stencil bufferu, uvidíte na plážovém míči "odrazy světla", způsobilo je vykreslení druhého poloprůhledného a stejně velkého objektu s jinou texturou.

Multitexturing (SW)

V případě složitějších extensionů (dobrým příkladem jsou vertex a fragment shadery), může být SW implementace "doma na koleně" nereálná, takže buď aplikace daný grafický efekt nepoužije, nebo pokud je tato funkce pro program zásadní, vyhodí program při inicializaci MessageBox() s "Extension XXX is not supported!" a ukončí se.

Kód pro zpřístupnění jakékoli HW funkce karty v OpenGL, může vypadat např. takto (ukázka na multitexturingu):

#include <glext.h>// Hlavička pro extensiony

// Globální ukazatele na multitexturing funkce
PFNGLACTIVETEXTUREARBPROC glActiveTextureARB = NULL;
PFNGLMULTITEXCOORD2FARBPROC glMultiTexCoord2fARB = NULL;

// V Inicializaci
  if(IsExtensionSupported("GL_ARB_multitexture"))
  {
    glActiveTextureARB = (PFNGLACTIVETEXTUREARBPROC)
      SDL_GL_GetProcAddress("glActiveTextureARB");
    glMultiTexCoord2fARB = (PFNGLMULTITEXCOORD2FARBPROC)
      SDL_GL_GetProcAddress("glMultiTexCoord2fARB");

    if(!glActiveTextureARB || !glMultiTexCoord2fARB)
    {
      // Multitexturing se nepodařilo inicializovat
      // Použít verzi bez HW multitexturingu
    }
  }
  else
  {
    // Multitexturing není podporován
    // Použít verzi bez HW multitexturingu
  }

A jak to probíhá u Direct3D? Opět stejný scénář: Woq programátor si za dvacet tisíc koupí novou brutaltotalultraextra grafickou kartu a chce začít ve svých programech implementovat všechny její vymoženosti. S největší pravděpodobností si nějakou dobu počká až se "Ó, veliký Microsoft®" uráčí vydat DirectX 23.0 a po dvacáté druhé se naučí kompletně změněné API. Mezitím cena karty klesne na desetinu a až pak může začít programovat.

Ne, omlouvám se, trochu jsem to přehnal, nicméně dost lidí to tak vidí (já také). V praxi je to tak, že Microsoft spolupracuje s výrobci karet, takže např. shadery vznikly mimo jiné také díky tomu, že začal pracovat na herní konzole XBox [2].

Architektura

Z dosavadního popisu je více než jasné, že se architektura OpenGL a Direct3D výrazně liší.

Architektura OpenGL

OpenGL představuje cca. 150 funkcí, s jejichž pomocí programátor komunikuje přímo s hardwarem karty. Pokud se v počítači 3D akcelerátor nenachází, mohou se všechny výpočty realizovat softwarově. Obecně se dá říci, že o tom, co se pošle hardwaru a co ne, rozhoduje výhradně implementace OpenGL (ten, kdo ji naprogramoval) a každá implementace pracuje jinak. Jedinou podmínkou však je, že se pro aplikaci musí navenek tvářit, že podporuje naprosto vše a předem definovaným způsobem.

Téměř všechny změny v OpenGL (1.1, 1.2 atd.) spočívají v přidání extensionů, které už za dobu od svého uvedení podporuje naprostá většina běžně používaných karet, do "základního standardu". Původně navržená koncepce tedy zůstává prakticky nezměněna. Kromě toho je vždy možné jakékoli HW funkce nových karet, které se nenachází v "základním standardu" používat přes extensiony.

Jedinou nevýhodou rozšíření (a docela podstatnou) je jejich množství. Několik desítek, by bylo ještě bez větších problémů, nicméně v současnosti začíná jejich počet u nových grafických karet dosahovat řádu stovek (odhaduji cca. 200) a stále roste. Druhou nevýhodou je, že naprostá většina z nich je málo popsaná. Samozřejmě myslím v češtině, anglicky mluvící (rozuměj čtoucí :-) programátoři větší problémy mít nebudou.

Architektura Direct3D je oproti OpenGL, které leží přímo na hardwaru, o něco složitější. Aplikační vrstva (to, co píše programátor) komunikuje s vrstvou Direct3D, rozhraní je v tomto případě vždy jednotné a to, co se nachází ve standardu Direct3D dané verze, je vždy možno provést, přičemž nezáleží na tom, jestli je toho HW schopen. Poslední z vrstev, když nepočítáme DDI (Device Driver Interface, tzv. ovladače karty), je vrstva HAL (Hardware Abstraction Layer), kterou dodává každý výrobce grafické karty a která defakto vrstvě Direct3D oznamuje: "Ano, toto udělám na hardwaru, nestarej se o to.", respektive: "Ne, toto hardware neumí, musíš to dopočítat softwarově." Obecně se dá říci, že vrstva Direct3D musí být schopna kompletně všechny efekty provést softwarově a teoreticky umět vykreslovat i bez jakékoli grafické karty v počítači.

Architektura Direct3D 9.0

Abych pravdu řekl, jsem tak trochu na rozpacích, protože to, co jsem právě napsal vůbec nemusí být pravda - tedy celkový smysl je určitě správný, ale podrobnosti mohou být jinak. Zkrátka, tak tomu rozumím já, v DirectX opravdu neprogramuji.

Vycházel jsem ze zdroje [1]. Zdroj [3] uvádí trochu odlišnou strukturu, ve které zkratka HAL neznamená "Hardware Abstraction Layer", ale "Hardware Activation Layer". Dále je přidána vrstva HEL (Hardware Emulation Layer), která filtruje vstupní funkce (to, co píše programátor) a rozhoduje, jestli je grafická karta umí provést nebo ne. V případě, že ne, vypočte se efekt softwarově pomocí této vrstvy, pokud ano, použije se HAL, která požádá hardware. Dále je přístupná i vrstva DirectDraw, kterou Direct3D používá pro mapování textur. Důvodem takto komplikované struktury je možnost aplikace manipulovat s ovladači a dotazovat se na to, co karta ve skutečnosti umí.

Jiná verze architektury Direct3D

Kdybych měl určit, která z těchto dvou verzí je správná, rozhodl bych se asi pro tu první. Především proto, že je to tištěná kniha a ne PDF dokument stáhnutý z internetu a že od verzí DX novějších (tuším) než 7 chybí podpora 2D grafiky (kniha je o verzi 9.0). DirectDraw bylo tehdy sloučeno s Direct3D a už jako takové neexistuje.

Tak či tak, získal jsem zcela neplánovaný důkaz, že se po přechodu na novější verzi DirectX můžete začít učit spoustu věcí od znova. Opět podotýkám, že se OpenGL změnilo pouze minimálně...

Shrnutí architektury - výhody a nevýhody

Stručně a neodborně, jak tedy Direct3D pracuje? Jeho hlavní výhodou je, že lze všechny převratné funkce nových grafických karet spustit i na starých kartách, a to i přesto, že nic takového vůbec nepodporují. Direct3D nemá nic podobného OpenGL extensionům, proto aby udrželo krok, musí se neustále a co nejrychleji inovovat a přidávat do sebe nové vlastnosti.

Na jednu stranu programátoři mají jistotu, že když nějakou extrémně novou funkci použijí, tak se provede i na starém hardwaru (softwarově), který v době svého vzniku neměl nejmenší tušení, že něco podobného bude kdy existovat. Na druhou stranu, při počítání většiny věcí na CPU, bude program tak pomalý, že to stejně nemá význam - hra (většinou se jedná o hry) bude prostě nehratelná.

Osobně si nedokážu představit, že by na softwaru běžel např. vertex/fragment shader - označení FPS (počet snímků za sekundu) by jednoznačně ztratilo jakýkoli význam, spíše by se mohlo počítat za kolik minut/hodin se vykreslí jeden snímek. Nevím, jestli může DirectX programátor nějak zjistit, co karta podporuje (asi ano) a podle toho se rozhodnout, jestli použít efekt přes kompletní emulaci pomocí DirectX (efekt, jak by ho provedl HW), částečnou emulaci vlastním kódem (analogický efekt v horší/mizerné kvalitě) nebo daný efekt nepoužít - v OpenGL je tohle na denním pořádku - o všem rozhoduje programátor aplikace. Akorát, že kdyby chtěl OpenGL programátor použít kompletní softwarovou emulaci, jak ji dělá Direct3D, musel by si vše naprogramovat sám, což jak jistě uznáte, je prakticky neproveditelné... nicméně Microsoft to musí provádět v každé verzi Direct3D.

Zmíněné architektury mají ve svém důsledku ještě jeden efekt. Když někdo implementuje OpenGL ve svém zařízení, má množinu funkcí, které budou fungovat hardwarově a množinu, kterou musí implementovat softwarově, aby byly pro aplikaci dostupné naprosto všechny funkce nacházející se v obecném standardu. V případě Direct3D, které si do sebe naváže ovladače karty, aby s nimi mohlo obousměrně komunikovat a zjišťovat si, co karta podporuje a co ne, se musí provádět náročné testy pro všechny karty, se kterými bude pracovat. U OpenGL toto odpadá.

Přenositelnost programů

Právě se dostáváme k opravdové lahůdce. Dosud jsem nezmínil, že DirectX je vázáno na technologii COM (Common Object Model) navrženou, stejně jako DirectX, Microsoftem. Nebudu se o ní zbytečně rozepisovat především proto, že v podstatě nevím, o co jde :-). Nicméně co vím s naprostou jistotou, je to, že funguje výhradně pod Windows.

Co se dá ještě říci o přenositelnosti DirectX? Asi jen to, že dříve nefungovalo ani ve Windows NT [3]. Po odklonu Microsoftu od "dosovských Windows" (Win 9x) se s tím však muselo něco udělat, takže v současnosti funguje, když nikde jinde, tak alespoň ve všech Windows (tedy 9x, Me, NT, 2000, XP), což ovšem např. uživatelům Linuxu, MacOS a dalších až tak stačit nemusí :-(

Naproti tomu je OpenGL od samého začátku koncipováno jako nezávislé na platformě, operačním systému (a programovacím jazyce). V současnosti ho lze najít téměř všude: Unix-like systémy (IRIX, Unix, Linux, Sun Solaris, Free/Open/Net-BSD...), Dos-like systémy (MS-Dos (neviděl jsem to, ale prý ano [3]), Win 3.x, Windows 9x, Me), Windows NT-like (Windows NT, 2000, XP, IBM OS/2), MacOS, BeOS a dalších. Lze ho najít i na některých palmtopech [3].

Teoreticky (toto je jen můj postřeh) by mohlo fungovat i na mobilech s Javou, protože nejnovější verze tohoto programovacího jazyka OpenGL přímo podporují. Otázkou je především rychlost a to, jestli v mobilech není pouze nějaká osekaná verze - s tímto opravdu nemám zkušenosti.

Bohužel, jak už to bývá, mnoho programátorů jednu z nejdůležitějších vlastností OpenGL, přenositelnost, doslova vyhazuje oknem (toto není narážka na ten OS, ale jen slovní obrat :-), protože váží své aplikace na nepřenositelné systémové API - většinou Win32 API. Existuje množství knihoven, díky kterým mohou být OpenGL programy s velmi malým úsilím libovolně přenositelné na úrovni zdrojových kódů. Jmenuji pouze dvě, pravděpodobně nejpoužívanější, se kterými mám (kromě Win32 API) nějaké zkušenosti: GLUT (OpenGL Utility Toolkit) a SDL (Simple DirectMedia Layer). GLUT zná asi každý OpenGL programátor, takže se mu moc věnovat nebudu. Dá se říci, že je to (oficiální) rozšíření OpenGL o nejvíce systémově závislé funkce, jako je vytváření oken a práce s nimi.

SDL je doma na Linuxu, jedná se o knihovnu určenou primárně pro tvorbu 2D her, ale díky tomu, že přímo podporuje OpenGL, není problém ani s 3D grafikou. Používám ji od té doby, co jsem přešel na Linux (už to bude skoro rok) a v současnosti pracuji na základním kódu pro OpenGL aplikace, který je/bude kompletně vystavěn na SDL a jeho podknihovnách (SDL_Image, SDL_Sound, SDL_Net aj.). Takže až někde uvidíte nápis Free3D (33D) Basecode, je to moje práce :-). Zatím je to sice projekt jednoho člověka, ale kdyby se chtěl někdo přidat...

OpenGL pod Linuxem (KDE - Plastik)

OpenGL pod Linuxem (Enlightenment)

OpenGL pod MS Windows XP

Rychlost renderingu

Jedna z posledních věcí, které se budeme v tomto článku věnovat, je rychlost OpenGL a Direct3D programů. Původně jsem chtěl z internetu stáhnout nějaké Direct3D zdrojové kódy a přepsat je do OpenGL, nicméně mě upoutal v [3] začátek jednoho odstavce: Přímé srovnání grafického výkonu OpenGL a Direct3D je docela komplikované, protože obě API mají trochu jiné konečné určení. OpenGL a Direct3D je navíc třeba srovnávat pouze pod Windows, protože jinde Direct3D nechodí.

Než jsem tedy začal stahovat D3D programy, zkusil jsem nejprve OpenGL program, na kterém právě dělám (ten částicový systém výše), spustit pod Mandrake 10.0 Linuxem a následně ve Windows XP (na stejném počítači), jiné operační systémy jsou pro mě v tuto chvíli nedostupné.

To, co teď napíšu, rozhodně neberte jako "další kydání na Windows". Abych pravdu řekl, výsledná FPS mě, stejně jako určitě i vás, totálně šokovala. Přestože se jednalo o naprosto stejný zdrojový kód zkompilovaný akorát pro dva různé systémy, byly výsledky extrémně odlišné. Pro kompilaci bylo ve Windows použito vývojové prostředí MS Visual C++ 6.0 a v Linuxu standardní g++ (KDevelop):

[woq@localhost tmp]$ g++ --version
g++ (GCC) 3.3.2 (Mandrake Linux 10.0 3.3.2-6mdk)
Copyright (C) 2003 Free Software Foundation, Inc.
This is free software; ...atd.

Následující tabulka vyjadřuje hodnoty FPS programu po ustálení v "klidovém stavu počítače" - tzn. nic se nemačká na klávesnici, nehýbá se myší apod. Jsou uvedeny minimální a maximální hodnoty. Možná by bylo lepší spočítat průměr za např. tisíc překreslení, ale nechtělo se mi s tím hrát - rozdíly jsou tak zřetelné, že hovoří za vše.

Pozn.: Námitka, že to dělá stáří Visual C++ (vyšlo myslím 1998), neobstojí. Zkoušel jsem to i v nejnovějším Dev-C++ a hodnoty byly prakticky stejné. Navíc ve Windows byl kromě testovaného programu spuštěn pouze Total Commander, kdežto v Linuxu mám standardně po pracovních plochách rozházených nejméně deset dalších aplikací ((průměrně) 5 KWritů, Operu, Konqueror, Gimp, KDevelop, Konzoli, do toho Apache, MySQL... je toho fakt hodně).

Kvůli těmto ne zrovna pozitivním výsledkům (ve Windows) jsem se rozhodl, porovnání s DirectX neprovádět, opravdu asi záleží hodně na tom, pod jakým systémem se spustí. Mimochodem, to víte, že OpenGL běží ve Windows vlastně na Direct3D? I když to v programu nikde explicitně neurčíte, po spuštění v Debug (F5 ve Visual C++), se zobrazí TRACE() zpráva ohledně DDRAW.DLL. Kdysi jsem o tom viděl i nadpis nějakého článku na http://www.opengl.org/.

A ještě si neodpustím jednu zmínku o rychlosti DirectX. Kdysi se v počítačových časopisech rozšířila zpráva, že se po instalaci nové verze (buď 6 nebo 7, už nevím) zvýší výkon grafické karty až o 40 procent. Všichni jásali, ale napadlo vůbec někoho: "A nešlo to udělat pořádně už v té minulé verzi?!".

Citace (ne)profesionála

Bernard Lidický, který vede jeden z nejstarších free-vývojových týmů v ČR - Hippo Games, byl pro mě vždy programátorským a Linuxovým GURU. Právě on mě opravdu dostal k Linuxu - před tím to byly jen takové krátkodobé pokusy. Ale proč to sem píšu, před časem mi poslal článek o tvorbě počítačových her [4]. O DirectX v něm píše, cituji:

Abyste si nemysleli, on tomu fakt rozumí... :-]

Kulič 2 - final beta 0.005

Linux i Windows verzi Kuliče, včetně zdrojových kódů, možno stáhnout na webu Hippo Games.

Fahrenheit

Pod tímto pojmem se skrývá projekt Microsoftu a SGI, který by spojil OpenGL a DirectX do jediného nového standardu. Pokud se chcete dočíst několik podrobností o jeho návrhu, odkazuji na [3]. Důvod, proč o něm nebudu psát, je ten, že byl ze strany Microsoftu vypovězen, a to z důvodu pomalosti vývoje u SGI. Osobně nedokáži posoudit, jestli jsem měl slovo "vypovězen" v minulé větě blíže specifikovat příslovci "bohužel" nebo "naštěstí".

Jak se portují programy

Skončíme na začátku rychlým popisem problémů ohledně portace počítačových her a obecně jakýchkoli programů na jiné systémy, než pro které byly primárně vyvíjeny. Připomínám, že díky recenzi UT 2004 defakto vznikl celý tento článek.

Obecně se dá říci, že pokud na něco takového, jako je přenositelnost programu, od samého začátku nemyslíte, bývá nejlepší cestou veškeré portování (ve smyslu složitých úprav zdrojových kódů) ignorovat a začít dělat na úplně jiném programu, kde s během na více systémech počítáte od začátku.

Po svém přechodu z Windows na Linux jsem "takovou blbost", jako je pokus o portaci, zkoušel u jediného programu, který však dosud denně používám při své práci. Jedná se o textovou aplikaci, které se při spuštění do parametrů main() předají jména C/C++ souborů a ona je označkuje do HTML. Při psaní tutoriálů o programování se nemusíte starat o formátování zdrojových kódů.

Přestože se jednalo o jednoduchý program skládající se z jediné funkce, muselo se nejprve přepsat wokenní rozhraní do textu, ale s tím se samozřejmě muselo počítat. Dále se muselo odbourat rozhraní přes paměťově mapované soubory (soubor se chová jako obyčejné pole, o načítání dat, buffery ap. se stará Windows), přepsat veškeré znaky '\' v diskových cestách na '/', přepsat Windows typy proměnných (DWORD, LPCTSTR...) na céčkovské typy (unsigned int, const char * ...) atd. atd. atd. - práce na dvě hodiny (celý program zabral tři :-).

Osobně si portaci jednou napsaného DirectX programu do OpenGL (nemyslím současný vývoj), aby mohl být spuštěn ve více systémech, naprosto nedokážu představit. A pokud by to už nějaký hyperaktivní programátor dělal, určitě nečekejte, že by po spuštění obě verze vypadaly stejně. Čím déle na portaci pracujete, tím více začínáte ignorovat podrobnosti typu: Power upy nesvítí, kapky deště nejsou 3D a vrhané stíny se nerozmazávají podle vzdálenosti od světelného zdroje.

Podrobnosti zkrátka přestanou být podstatné, smysl hry je zachován. Nicméně nazývat to jako lenost programátorů... dalo by se to tak sice říct, ale fakt nevím. Chtěl bych vidět, jak by vypadala vaše verze. Jedno však vím jistě - paření her a kritizování jejich programátorů je určitě jednodušší...

Literatura

• [0] Vlastní zkušenosti s 3D grafikou
• [1] Clayton Walnum: Programujeme grafiku v Microsoft® Direct3D (9.0), Computer Press 2004, první vydání, 358 stran
• [2] Chip 01/2004, Hardwarový fotorealismus: Možnosti moderních 3D grafických akcelerátorů, str. 96-100)
• [3] Daniel Čech: OpenGL - Referát na praktikum z informatiky (PDF) - Opravdu kvalitní text
• [4] Bernard Lidický: Několik poznámek k tvorbě počítačových her (PDF) - Věnuje se především tématům, jaké hry programovat a v čem (přenositelné knihovny Allegro a SDL)
• [5] Linuxové hry (47): Unreal Tournament 2004 - Hlavní impuls pro vznik tohoto článku - Hlavní impuls pro vznik tohoto článku

Další informace

• Seriál o DirectX na Chip CD - vychází/vycházel (už neodebírám) hodně dlouho
• http://www.root.cz - Vychází zde (i) články o OpenGL a spřízněných technologiích
• http://nehe.ceske-hry.cz/ - Rozsáhlý server o OpenGL (můj :-)
• http://nehe.gamedev.net/ - To samé (a spousta věcí navíc) anglicky
• http://www.opengl.org/ - Domovská stránka OpenGL
• http://www.microsoft.com/windows/directx - Domovská stránka DirectX
• http://www.libsdl.org/ - SDL, knihovna pro vývoj přenositelných her

Použité názvy programových produktů, firem apod. mohou být ochrannými známkami nebo registrovanými ochrannými známkami příslušných vlastníků. Linux je registrovaná obchodní známka pana Linuse Torvaldse.