Rekl bych, ze v predchozich dvou dilech se sice vyskytlo par chyb, a ze byly i po obsahove strance trochu mimo, ale aspon to byla nejaka reakce na ty ,,blbosti``, ktere napsal autor recenze na UT2004.
Osobne si myslim, ze by bohate stacil clanek jeden, kde by bylo zdurazneno, ze to co bylo napsano u zminovane recenze na UT neni pravda.
Co se tyka toho co je napsano v tomto dilu, tak si myslim toto:
1) Jelikoz lze pomoci OGL i D3D dosahnout stejnych vysledku a jelikoz DX jede jen pod Windows, kdezto OGL lze vyuzivat temer vsude, tak je volba celkem jasna. To ze je v ramci DX i podpora pro sitovani a zvuk, bych zas jako takovou vyhodu nevidel - existuje spousta platformove nezavislych knihoven, ktere delaji to same (a i dnes si stejne napr. to sitovani kazdy pise sam)
2) DX sice dnes vyuziva 90% her na PC, ale jelikoz OGL bude vyuzivat Playstation 3, tak bych v budoucnu ten pomer videl tak, ze 70% her bude pod OGL (vzhledem k tomu, ze konzole PC hry valcuji a Playstation se prodava lepe nez XBox). O profesionalnim pouziti (vizualizace, velke CAD systemy, GIS, ...) nemluvim, protoze tam se temer vyhradne pouziva OGL (vetsina jede jen pod Unixem)
3) Objektova architektura DX je podle me spise minus - jak jiz bylo psano v diskuzi k drivejsim clankum, pokud nekdo potrebuje ,,objekt textura``, tak si to muze napsat za par minut sam a co se tyce nejake struktury pro vnitrni reprezentaci hierarchie sceny, tak to si taky kazdy napise (a pise) sam, nebo vyuzije neco co jiz existuje a je na vyssi urovni (kazdy asi tusi, ze tahle zalezitost by mela byt nadstavba a to nejlepe nezavisla na takovych ,,prkotinach`` jestli se neco vykresli pomoci DX nebo OGL) - DX i OGL (to zvlast) jsou obe dost low-level rozhrani.
4) Extensions u OGL bych nevidel tak tragicky - je jich sice spousta, ale pro ,,jednoduche`` veci jako jsou hry, jich zas tolik nikdo znat nepotrebuje - neprofesionalni graficke karty (myslim tim ty, ktere ma kazdy doma - takze ty na hry) jich ani moc nepodporuji (par ARB a EXT + NV nebo ATI + neco malo dalsich uzitecnych) a tech par co zvladnou, neni zas takova hruza vyuzit - vetsinou pribyde par novych fci a v nemalem procentu pripadu ani to ne a pouze pridavaji nejakou #define konstantu pro pouziti ve funkcich jiz existujicich.
5) OGL 2.0 je zpetne kompatibilni s OGL 1.x
6) kod u DX _JE_ v 99% pripadu delsi nez v OGL a u vetsich projektu to plati obzvlaste - navic je (diky ,,prasackemu`` navrhu celeho API (ted se nebavim o funkcnosti - ta je, jak jsem jiz psal nekde nahore, stejna)) o dost hure citelny, tudiz se v tom hure a pomaleji neco pise - takze stale plati to co rekl zde hojne citovany Carmack - a ten se ani tak nevyslovoval o funkcnosti, ale prave o tomhle aspektu, ktery je stejny jak u DX6 tak u DX9.
A to by snad uz mohlo stacit, takze ...
\bye
1) Platformova nezavislost OGL je naprosto jasnou neoddiskutovatelnou vyhodou. Diskutovat se da jenom to, kdo o ni ma a kdo nema zajem. (Jako ze existuje dost vyrobcu her, kterym je uplne jedno, ze to nikde jinde nez na woknech bezet nebude.)
2) Vesteni z kavove sedliny...
3) To je samozrejme vec vkusu, ale rozhodne to neni duvod, proc bych volil jedno nebo druhe rozhrani.
4) "jednoduche veci jako jsou hry" -- LOL, _co_ je tedy slozita vec??
5) V DX9 taky muzu pouzivat IDirectDraw2.
6) Mozna ze je delsi. Jenze to je proste architekturou, ve ktere se hledi hlavne na to, aby to bylo rychle na karte (v tomto smyslu to ma zase naopak neco z te RISCove technologie, kdyz uz sem nekdo zavadi podivne metafory), takze se za zakladni povazuji vertex buffery a uzivatelske buffery jsou jenom berlickou atd. Rozhovor s Carmackem je X let stary a kritizoval v nem prvni D3D, ktere bylo jeste mnohem vic low level, posilaly se v nem primo pakety prikazu karte.
Ad 6) i clanek: Dnesni narocne OGL aplikace (hry) pouzivaji vertex buffery. Tecka. A jejich pouziti je proti DX spis slozitejsi nez jednodussi. Totez o citelnosti: porad porovnavate trivialni OGLske Begin Vertex... End oproti komplexnim DXovym resenim s vertex buffery.
3) Nesledujes Siggraph a vyhlasenia Sony? Sony sa pripojila ku Khronos Group a PS3 bude podporovat OpenGL ES a niekolko dalsich OpenXX. Okrem toho vytvorili projekt Collada a do neho namocili Alias, Discreet a Softimage. Ano, je to boj proti MS a jeho Xboxu, Sony sa ani neobtazuje to nejako skryvat.
4) Na co myslis, ze sa pouzivaju karty od 3D Labs? Alebo ATI FireGL? Alebo Nvidia Quadro? Su ovela drahsie ako herne karty, a ovela vykonnejsie. Herne karty dokazu akurat rychlo texturovat...
Ale vazne - od CAD, CAM, GIS, cez modelovanie a animacie po kinematografiu - s hernymi kartami sa tak nacakas, ze to mozes robit rovno softwarovo. Niektore zaujimave veci s hernymi kartami sa ani nerozbehnu - vid napr. Nvidia Gelato.
2) [ne 3] Jiste, ja si jenom nejsem jist, ze to zpusobi masivni nastup OGL her.
4) Jisteze jsou vykonnejsi karty nez ty herni, ale kdyz se podivate na seznam ARB extenzi, tak vsechno jsou to veci, ktere se pouzivaji ve hrach, a to byla pointa me reakce na puvodni prispevek. (Ale pravdou je, ze mezi vendor-specific extenzemi jsou casto zcela "neherni" zalezitosti, typicky treba SGI*.)
Mistře....
---------------------------------------------------
4) Na co myslis, ze sa pouzivaju karty od 3D Labs? Alebo ATI FireGL? Alebo Nvidia Quadro? Su ovela drahsie ako herne karty, a ovela vykonnejsie. Herne karty dokazu akurat rychlo texturovat...
---------------------------------------------------
K tomuto se dá tak maximálně napsat LOL :-)
Zkus si zjistit jaky je rozdíl mezi
treba GF 4 Ti 4200 a Quadrem 750 XGL.
A pak se mi ozvi a vysvětli mi rozdíl mezi drahými kartami pro worskation aplikace a levnými herními kartami, které umějí jen rychle texturovat :-)
Já osobně si na základě tohoto myslím, že nevíš o čem mluvíš... a nejspíš se to neztahuje jen na tvrzení v bodě 4.
Veru tak, quattro seria od NVidie su iba pretaktovane cipy s rychlymi pamatami, niekedy maju upravene pocty pipelines, ale inak je to rovnaky hardware.
Nedavno som cital o tom ako si jeden chlapik upravil driver na GeForce 4 aby sa mu to hlasilo ako Quattro XXX, a 3DS MAX mu bezal 3x rychlejsie.
Myslite si, ze se v OGL nehledi na to, aby to bylo rychle na karte?
Jisteze se pouzivaji v OGL aplikacich vertex buffery (a rozhodne to neni zadna zhava novinka - pouzivaji se uz asi 8 let) a nevim o tom, co by melo byt na jejich pouziti nejak slozite. Jestli jste je nikdy nepouzival, tak se zkuste nekde podivat na nejaky zdrojak a uvidite, ze jejich kompletni pouziti je tak na 5 radku, a jako vsechno v OGL to je schema:
1) inicializace (glVertexPointer, glTexCoordPointer, ...)
2) zapnuti (glEnableClientState)
3) pouziti (glDrawElements, ...)
4) vypnuti (glDisableClientState)
Pokud nevite, jaky je rozdil mezi vertex array a vertex buffery (resp. v OGL "vertex buffer objects"), tak se budete tezko presvedcovat... (Pokud mate zajem, nejake zakladni informace budou napr. nekde kolem http://developer.nvidia.com/object/var_fence.html)
A samozrejme, ze vsichni implementatori se snazi, aby Z DANEHO ROZHRANI dostali maximalni vykon, jenze moje poznamka spocivala v tom, ze ROZHRANI DX je navrzeno, aby se dobre mapovalo na ty rychle featury (a NE, schema Begin, Vertex*N, End, se OPRAVDU nemapuje dobre na ty nejrychlejsi zpusoby vykreslovani).
To co tam je plati i pro VBO.
...Begin, Vertex*N, End, se OPRAVDU nemapuje dobre na ty nejrychlejsi zpusoby vykreslovani...
Nevim co tim myslite, to co je tam napsano funguje u VBO tak, ze se vrcholy/koordinaty textur/... nekam (VRAM, AGP RAM) poslou a pri kresleni se akorat rekne "vykreslit" a je to. Nevim jak jinak a vyhodneji by jste to chtel mapovat na ty "nejrychlejsi zpusoby vykreslovani" (muzete napsat, co si pod tim predstavujete)
Immediate rezim OGL je proste pomaly, ale pritom je to prave tohle, na cem se prezentuje jednoduchost OGL. Nejjednodussi mozny kod DX je o neco delsi, ale za to prirozene svadi k pouziti vertex/index bufferu. Ve chvili, kdy naprogramuju v OGL nejake reseni s VBO, je s DX verzi prakticky izomorfni, tam jdou snad i jednotliva volani API funkci priradit 1:1.
Puvodni rozhrani OGL proste bylo navrzene ciste jako rozhrani, bez ohledu na to, co bude pod tim. Dnes se do toho dodavaji postupne vlastnosti, ktere to umoznuji vyuzit, ale obcas to jde ztuha (viz x extenzi pro ruzne druhy VBO), zatimco DX bylo od pocatku navrzene prave naopak, s ohledem na to, co je pod tim, a postupne jde skoro by se dalo rict opacnym smerem -- zjednodusovat rozhrani.
Howgh. Uz me to nebavi ;-)
Přesnějc řečeno, DX mělo původně vedle Immediate Mode stavěného na VB ještě pomalej, avšak high level Retained Mode, kterej byl zamejšlenej v joint venture projektu s SGI (Fahrenheit) zkompletovat s OGL extenžnama do jednotnýho rozhraní pro scene graph - což se nakonec neuskutečnilo a DX RM se rozpustil v objektovým modelu DX IM.
Ještě jsem nedočetl diskuzi celou, možná je to někde níže, ale mohl by mi autor který se evidentně stydí za svůj příspěvek, když se pod něj neumí ani podepsat, poučit v bodu 6, v čem je to API tak "pasácké"? A prosil bych jinou odpověď než "to přece ví každý" či "to je jasný, nééé"?
Potom k bodu 3 - mohl by se autor podívat na web MSDN na rozhraní IDirect3DTexture9 a zopakovat mi to o těch pár minutách? Děkuji:)