pamatuju se jak mi kamaradi , kteri me ucili programovat grafiku vzdycky rikali. Pokud neumis programovat v directX a openGL stejne nikdy nekritizuj ten ktery API :)
V oblasti programovani her a vubec 3dgrafiky se trochu pohybuju takze si dovolim par nazoru.
Obecne vlastnosti openGL :
nezavisle na operacnim systemu a na HW,
slouzi pro psani grafickych aplikaci
nepodporuje okenka
neni objektove orientovany (openGL 2 s velkym ? )
bylo uznane jako standard
primo lze vykreslovat pouze body,usecky, polygony a bitmapy. Geometricke objekty ve 2d i 3d se proto vykresluji sledem jejich vrcholu coz vyhovuje zejmena grafickym akceleratorum.
Pro me asi ma OpenGL omezeni prave v tom , ze chybi prikazy pro praci s komplexnimi objekty .Take je spousta fint , ktere jsou v directX a v openGL se musi resit pres extensions. V tech je celkem bordel a nekdy je k nim problem sehnat dokumentaci.
Samozrejme zasadni vyhoda pro toho co neprogramuje jenom pro win je prenositelnost ovsem dan za to je prave tech par nevyhod vyse.
Ted k directX
Co se mi zda vyhodne oproti OGL:
Samozrejme technologie COM(component object model)
Komplexnost DirectX je zajistena vyrobci HW , protoze tyto komponenty stavi primo na miru tomuto API.Je to kupodivu diky politice MS , ktery definoval konvence(promenne,struktura dat take funce a dalsi) kterymi se vyrobci primo ridi .Prave proto na rozdil od OpenGL se pri programovani direcX clovek nemusi ohlizet na nejake HW vlastnosti komponent.
Samozrejme zasadni nevyhoda pro zdejsi osazenstvo je neprenostilenost :)) No a taky u programovani v directX je nutno ovladat objektove orientovane programovani , ale to snad uz neni o cem se bavit. Proto se zda ze OpenGL je jednodussi jenze takhle muze mluvit pouze zacatecnik , ktery programuje tocici se krychli . Jakmile kod naroste je vyhoda na strane directx.
Neco o rychlosti. V podstate uz davno neni co resit rychlost daneho grafickeho bazmeku uz zalezi daleko vic na optimalizaci kodu nez na druhu API to uz je obecne znamy fakt takze pri volbe jestli to nebo rozhoduji jine vlastnosti .
jinak treba k tomu Carmakovi a doomu 3. Kdyz Carmack fuckoval directx tak byla venku verze 5 .Ted naposled kdyz jsem cetl jeho nazory tak psal , ze sila a vlastnosti directx se rozhodne uz nedaji prehlizet.
sry za ten delsi text ale to co je v tom clanku je opruz uvidime ta pokracovani :)
no ja vidim hlavni rozdil v tom OpenGL je proceduralni
glBegin (GL_TRIANGLES);
glVertex (0,0,0);
glVertex (1,1,0);
glVertex (2,0,0);
glEnd ();
a D3D je pres bufry, tj. neco jako (velmi znamy priklad)
v = &buffer.vertexes[0];
v->x = 0; v->y = 0; v->z = 0;
v++;
v->x = 1; v->y = 1; v->z = 0;
v++;
v->x = 2; v->y = 0; v->z = 0;
c = &buffer.commands;
c->operation = DRAW_TRIANGLE;
c->vertexes[0] = 0;
c->vertexes[1] = 1;
c->vertexes[2] = 2;
IssueExecuteBuffer (buffer);
To ze OpenGL implementuje minimimum beru jako vyhodu, zbytek se da delat pomoci GLU nebo jinych veci treba (pro mne zajimave http://glscene.sourceforge.net/)
atd.
To, že OpenGl implementuje minimum znamená, že je v ní take minimum věcí implementováno standardně.
A nějaké objektová architektura by OpenGL také neuškodilo, zvlášť ve 3D grafice, která přirozeně tíhne k objektovému modelu (doufám, že tušíte, co je to OOP a jaké má výhody). Ovšem respektuji, že alternativní platformy nemají výkonné binární rozhraní aka COM, takže jim vlastně pro její implementaci schází základní infrastruktura.
Eeee?
Co to meles?
Takce ten rok trvajici projekt v C++ na Linuxu, co jsem prave dokoncil vlastne nebyl OOP, protoze nepouzival COM?
Co ma, probuh, spolecneho OOP a COM?
COM objekt je prachobycejna dynamic loadable knihovna implementujici povinne rozhrani pro pristup zvenci, jednotlive instance se pak daji z vnejsku volat obdobne jako JAVA beans. (to ostatne obyc knihovny taky, jenom interface neni zarucen) Tim cely "zazrak" konci, v linuxu viz DCOP, CORBA.
Napsat si objektovy wrapper nad cokoliv (nejen OpenGL) je otazka par clovekohodin, vyvoj pak neni omezen na predpripravenou objektovou enkapsulaci.
Jeziskunakrisku, vypada to, ze se tu zacinaji stahovat znalci z www.zive.cz.
Můžu se jen zeptat, psal jsi takový objektový wrapper právě na OpenGL? Znám spíš DX, ale když vidím jeho rozsah, tak napsat takový "malý" wrapper by podle mě zabralo řekněme 3, 4 měsíce? Nevím, je to hodně hrubý odhad, ale mluvit tu o pár člověkohodinách.. Kolik je přibližně pár? :)
Jinak samozřejmě souhlasím s tím, že COM ne= OOP. Ale možná to šlo vyjádřit i jinak. Konkrétně ta poznámka o Živě mi přijde, no, ... ale já taky někdy ujedu..
Jinak doufám, že dnes nepřidělám Johance práci a nezblbnu ji:)
Psat "objektovy wrapper" na openGL je blbost a jako takova byla ARBem zamitnuta na vecne casy a to z 3 duvodu:
1. Vsechny hlavni jazyky umi volat ceckovskou API. Namapovat vlastni obekty na C++ obekty ovsem neumi zadny.
2. Hlavni uzivatele OpenGL (GIS, CAD/CAM ale i Hry) nevidi zadny problem s jeho "seriovou" podstatou. Navrh na zmenu k objektum obvykle prijdou ze strany byvalich uzivatelu DX standardu ktery se jeste nezabydleli. Objektove programy (vcetne velkych CAD/CAM a GIS systemu, temer vzdy C++) se velmi dobre obejdou s takovym OpenGL API, jake zatim je.
3. Pokud si nekdo presto mysli ze objekt "textura" je vlastne dobry napad, muze si najit nejaky OSS wrapper na webu a neotravovat s tim zbytek (spokojenych) uzivatelu OGL
Je mi líto, žes nepochopil mou reakci. Nekritizuji ani DX ani OGL (už jen proto, že ho nepužívám!). Myslím, že nikoho neotravuji s tím, že objekt textura je dobrý nápad. Kdes na to přišel?... Já jsem pouze někde výše řekl, že MĚ OSOBNĚ tento přístup víc vyhovuje... Nikomu nevnucuji svou myšlenku.
Jen tak obecný výkřik. Doufal jsem, že tady na Rootu nebude docházet k podobně agresivním výstřelkům... zmýlil jsem se... Ach jo, kdyby jen nebyli všichni tak militantní a taky poslouchali, co ostatní říkají a nehájili jen slepě svůj názor.
Nevim jak moc tomu rozumíte, ale v čem vám přijde, že je bordel v extenzích u OpenGL?? Tohle tvrdí hlavně lidi, co se v tom moc neorientují.
Pokud děláte hru, kde použijete všechny běžné technologie krom shaderů, tak vám stačí používat extenze ARB (tj. žádný problém). Se shaderama 2.0+ opět není problém. Jediný problém je pouze u shaderů 1.0-1.4. Ovšem i tam stačí udělat jen 2. možnosti navíc (ATI, nVidia).