2. Fórumok
  3. Videokártyák
  4. Mi a diff d3d és opengl között?
  5. (téma lezárva)
Keresés

Aktív témák

  • #63 rudi nagyúr Raymond #62
    #63
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz Raymond #62 üzenetére

    Még nem volt időm elmélyedni az OGSL-ben, de hétvégén (vagy jövő hétvégén) igyexem időt szakítani rá. Nekem eddig tetszett a HLSL, hogy bele lehetett nyúlni ASM szinten, így aki még régről ismerte a trükköket, az most kamatoztathatta tudását. Kíváncsi vagyok milyen lesz ez profi OpenGL megközelítésben.

  • #61 rudi nagyúr Raymond #51
    #61
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz Raymond #51 üzenetére

    Szerintem meg nem. A Geo-Mod csak a jó öreg quake II motor átépítése volt.

  • #50 rudi nagyúr faster #49
    #50
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz faster #49 üzenetére

    Hát ez tényleg igaz! Inkébb Quake 1. Azért írtam a Red Faction-t mert annak is csak a váza quakeII, de van hozzá új fizika (visszapattanó lövedékek), sérülésmodell, bontható pálya és még sokminden. Lényeg, hogy ezek a motorok jó rugalmasak, tudtommal sokkal rugalmasabbak mint az Unreal motor. Lehet, hogy ez éppen az OpenGL miatt van, de valószínűbb hogy a jól elvégzett munka gyümölcse a rugalmasság.

  • #48 rudi nagyúr pukk #46
    #48
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz pukk #46 üzenetére

    Senki nem állította hogy Q3 motorosok lennének. Arra reagáltam, hogy Ijk kérdezte, hogy miért van az hogy ők lanon túlnyomoórészt OpenGL-es gamekat nyomnak. Általában quake motorokról volt szó, ugyanis ezek mind OpenGL-esek. A Half-Life is quake motort használ (számszerűen Quake II), de azt használta a Red Faction is.

    Az a +200% nekem nagyon neccesnek hangzik, különösen egy régi DX7-es kártyán. Az sem világos, hogy mihez képes lesz ez a 200%...

  • #45 rudi nagyúr Ijk #44
    #45
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz Ijk #44 üzenetére

    Nem vételtlen, mert quake motoros FPS cuccokkal nyomultok (CS, Quake, CoD, Mohaa, RTCW, SoF, SS).

  • #42 rudi nagyúr rog #41
    #42
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz rog #41 üzenetére

    És ha abból indulunk ki, hogy az NV-s gC (vagy Cg) crossAPI, vagyis OpenGL és D3D kódot is tud gyártani, és hogy aki render monkey-ban kódol, az HLSL kódot generál csúszkák tologatásával és mellette kapja a shader ASM kódot is, amibe szintén beledolgozhat, akkor nagyon szétcsúsznak a határok az API és a programozói felület között. Persze az API - application programming interface, de ez milyen viszonyban is van egy SDK-val?

    A peszeudokódos és mikrokódos fogalmak egyenesen ATI doksiból jönnek. Természetesen processzorközeli peszeudokódról van szó, ami rögzíti, hogy valami regiszter kell, de majd később a mikrokódban az éppen aktuális ''környezeti viszonyokkal'' konkretizálódik, hogy éppen melyik regiszter lesz az.

    Ha Te másképp gondolod/tudod lécci magyarázd el vagy oszd meg velünk a forrást, ahonnan másképp tudod.

  • #39 rudi nagyúr rog #37
    #39
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz rog #37 üzenetére

    akkor nem sikerült... szerintem ezek így vannak. Szerinted mi van másképp?

  • #36 rudi nagyúr
    #36
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    A dll amit emlegettek lehet, hogy optimalizálva van, de szerintem ikább olyanokban, hogy valamiféle képminőségbeli megszorítást tesz, amitől egyszerűsödnek bizonyos számítások, ezáltal gyorsabb lesz az alkalmazás, de valamit gyengül a minősége is. Majd utánanézünk.

  • #35 rudi nagyúr rog #27
    #35
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz rog #27 üzenetére

    [L]http://vganfo.uw.hu/ddd.gif[/L] ez egy irományom egy része amivel jó lenne többet foglalkoznom. Még alfa állapotban van csak, de kb. válaszol néhány kérdésedre és jo sok továbbit eredményez (szerencsés esetben ...)

  • #34 rudi nagyúr _cirmos_ #30
    #34
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz _cirmos_ #30 üzenetére

    Nem ez a helyzet, vagyis nem éppen ez! Ajánlani tudom ezt a cikket [L]http://www.digit-life.com/articles2/dx-next/index.html[/L] bár már régen olvastam, asszem ebben van jól leírva az alapvető eltérés az ATI és NV chipek feldolgozási folyamata között.

    A lényeg, hogy a hardver adott, azt valami alapján meg kell tervezni és utána már csak a meghajtón lehetet csiszolni. Az NV régóta benne van a profi OpenGL bizniszben is, az ő agyuk inkább arra jár; míg az ATI inkább játékra gyúr és a DX igényeinek próbál megfelelni, annak a megszorításai alapján készül a chip is. És itt a pro biznisz a mérvadó. Ha ott hibázik a hardvergyártó, akkor a nagy animációs cégeknél @nyáznak a grafikusok, ott nem lehet ''optimalizálni'' ott trilinearnak kell lennie a trilinearnak stb. A gamer piac sokkal veszélytelenebb, lehet trükközni és az igények sem olyan nagyok, no meg a Microsoft tolja a fejlesztői toolokat és korábban volt shader programozó nyelv is.

    De a lényeg. Az ATI hardvere nem rosszabb mint az NV-jé náluk inkább az OpenGL meghajtóval kellene valamit kezdeni és éppen ebben van az NV előnye, hogy náluk már jó régen megy az alapos OpenGL fejlesztés és ott van egy John Carmack nevű emberke is a közelükben...

  • #22 rudi nagyúr _cirmos_ #21
    #22
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    válasz _cirmos_ #21 üzenetére

    Azt mondanám, hogy a válasz is. Az említett 8 bites LoD precizitás tudtommal egyáltalán nincs meg a Radeonokban, de a legtöbb használatos extension megy ugyan az ATI kártyákon is, csak lassabban. Itt két (vagyis inkább három) komoly pont van, ahol D3D és OpenGL eltérhet, és ezek a fordítók. A programozói felület és az API közötti fordító az első lépés. Ha optimalizálnak a fordítón, akkor az jobb OpenGL vagy éppen D3D kódot csinál, ezzel jó esetben minden kártya gyorsul. Ha az OpenGL driver értelmezésén javít a gyártó, akkor csak a saját cuccai gyorsulnak. Mondhatnánk, hogy a driver is egy fordító, ami az OpenGL-ből (vagy D3Dből) fordít a hardver mikrokódos nyelvére. A harmadik javítási lehetőség amit említettem az a mikrokód jobb feldolgozása hardver szinten, vagyis a chip fizikai optimalizálása. (lehetne még egyet csavarni, mert a chipet is egy szoftver segítségével tervezik ezt is lehet optimalizálni).

    A Te kártyád azért lassulhat be időnként mert feltételezem, hogy 32 MB memória van rajta és a komolyabb jelenetekben ez már kevés a United Offensive-nek, mert azt a mai nyugati igények szerint 64+ MB memóriára tervezték (több és nagyobb textúra, stb.).

  • #20 rudi nagyúr
    #20
    Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra
    Privát üzenet küldése

    rudi

    nagyúr

    Hú ez jó kis téma lesz :D

    Az első és legfontosabb:
    A DirectX (garfikus rész a Direct3D) KŐBE VAN BETONOZVA VERZIÓNKÉNT, olyan szentírás jelleggel, mígy az OpenGL kiegészítésekkel (extension) állandóan bővül.

    Az OpenGL alaposabb profeszionálisabb, a D3D kommerszebb. Jó példa erre, hogy a LoD (level of detail váltó) OpenGL-ben 8 bites, míg D3D-ben csak 5. Programozás tekintetében most a shaderek világában már nem olyan nagy az eltérés, de korábban az OpenGl sokkal kényelmesebb volt és a Microsoft HATALMAS pénzeket fektetett a D3D népszerűsítésébe a játékfejlesztőknél. Mivel a D3D M$ tulajdon ezért (és még a rugalmasság, pontosság és társai miatt) a profi alkalmazók maradtak OpenGL-en, az megy Mac, SGI meg mindenféle platformon.

    Szemre eltérés nincs ha ugyanúgy van megvalósítva egy efektus, de sok függ a megvalósítás módjától. Általában OpenGL-ben több lehetőség van mindenre mint D3D-ben, de a D3D-s lehetőség megvan OpenGL-ben. Példa erre a bump mapping, amire D3D-ben van 1-2 módszer, míg OpenGL-ben több, sok olyan, amit csak bizonyos hardverek támogatnak.

    És itt van talán az alapvető eltérés:
    A D3D úgy készül, hogy megszabnak követelményeket (X shaderkódhossz, Y regiszter, Z utasítá, W bitmélység stb) és ehhez kell (érdemes) a hardvergyártóknak alkalmazkodniuk. OpenGL-ben fordított a helyzet: csinál a gyártó egy hardvertének egy tulajdonságot és ahhoz egy OpenGL extensiont, amivel ez a tulajdonság kihasználható.

    Persze ezzel megérkeztünk egy újabb szintre, ahol az a kérdés, hogy hol is helyezkedik el a D3D és OpegGL a programozó és a hardver közötti úton.

    Induljunk a hardvertől
    hardver
    hardverközeli mikrokód
    driver
    API (openGL és D3D)
    programozói felület - HLSL, CG, ASHLI, RenderMonkey stb.

    A szintek között fordítók és értelmezők (compilerek) vannak. A legtöbb programozó valamilyen felületet használ, ami egy magasszintű programozási nyelvre (jellemzőne C++ jellegű) támaszkodik és abból egy beépített fordító csinál az API-nak megfelelő kódot, amiben aztán optimalizáln lehet.

Aktív témák

Hirdetés