Néhány democsapat elköveti azt a hibát, hogy csak az engine fejlesztésre koncentrál, de sose készül el a demo. Most eljött az ő idejük is!
“Az engineveseny egy, immár több éve zajló egyedi, magyar hagyomány, melynek főszervezője Geri. Attól eltekintve, hogy nagyon lazára vesszük a figurát, ez egy nagyon komoly szakmai megmérettetés, ahol elsősorban nem másokkal, hanem saját magaddal versenyzel. Az engineversenyben 3d-s grafikus motorjaink teljesítményét mérjük egymáséhoz, több platformon, mindig egy megadott scenevel.”
A 4. verseny indulói pedig ITT – link javítva – köszi Geri! (Bery)
A hír beküldőjének kérésére nevét elhallgatjuk.
Categories: Programozás |
azt hittem ennek csak a szoftrender idejében volt értelme. valaki okosítson ki, úgyis a directx meg a gpu renderel, nem az engine, nem ?:)
Bocsi, de ez naív elképzelés. :P Addig amíg egy shadelt kacsát raksz ki természetesen nincs értelme, de ha egy komplex, sok objectből álló, animáló, sok fénnyel bevilágított, tükröződésekkel, árnyékokkal tarkított, komplex shadereket használó sok millió polygonos scenéről van szó, telerakva effektekkel, a végén jól posteffektezve, és mindezt egy több magos CPU-n… Így már bőven a coderek találékonyságán múlik, hogy mit hoznak ki a helyzetből.
A Smash blogját tudom megint csak ajánlani, a probléma egy kisebb részét elég érhetően megmutatja:
http://wordpress.scene.hu/?p=861
[ módosítva Jan.20. 08:09 ]
és abból nem lesznek viták, hogy X engine ilyen effektet tud, az Y meg amolyat? akkor hogy lesz összemérve a speed ? :)
Bizony. A DirectX/OpenGL APIkat lehet nagyon “elkényelmesedve” és átgondoltan is használni. Az API és a hardver nem optimalizál ki helyetted mindent (sőt), így esetenként megszenvedhet a GPU a feleslegesen nagy texturákkal, vagy éppen a kétszer annyi poligonnal is (merthogy jó esetben kioptimalizálod raszterizálás előtt a felét), ami egy sok százezres, netán több milliós poligonszámú scene-en már érződik. Meg aztán egy bonyolultabb shadert is meg lehet írni jól és rosszul. És ha már shader, ott sem mindegy, hogy mennyi poligonra kell lefutnia, ha nem post-processről van szó.
De még egy olyan egyszerű dologban is mérhető lenne ez, mint egy rengeteg texturázott, enviroment mappelt, extraként kicsit átlátszó kockákból álló, bevilágított scene. Ha kényelmes vagy, vagy ha az engined így működik, akkor minden egyes kockánál külön beállítod a render state-eket, aztán meg vissza, hogy a következő kirakandó objektnek ne kavarjon be az elállított render state. Érdemes kipróbálni, hogy milyen sebességkülönbséget hoz, ha ezt csak egyszer teszed meg, mielőtt kirakod az összes kockát. Persze vagy szerényebb videokártyával, vagy nagyon sok kockával.
Egy zártabb engine esetében lehet, hogy nem is tudsz ilyen optimalizálást megejteni. Igaz, általában nincs is szükség erre :) De azért láttunk már olyan demót, amiben sürgütt-forgott jó sok egyfoma kocka :)
És aztán még lehet pár dolog, amikkel a szerény, sok éves elmaradásban levő ismeretem – vagy inkább annak hiánya – okán nem is találkoztam. :)
[ módosítva Jan.20. 08:33 ]
404 a második link…
gma950-re kell kodolni, oszt akkor nem fognak reklamalni a juzerek :)
(amugy persze fognak akkor is)
Huhh, hát, mi tagadás, ez most egy kicsit meglepetésként ért.
Először is, itt a 4. verseny linkje:
http://legendgrafix.buzz.hu/archives/2009/03/05/4_engineverseny/
Valóban hatalmas különbségek vannak engine is engine között, a 4. engine versenyben pedig még az ég adta világon semmi effekt nem volt. Kivéve persze ha a textúrákat is effektnek tekintjük :D Az 5.-ben viszont már kell megvilágítás is. Aki indulni szeretne, annak szívesen elküldöm a megújult szabályzatot.
Amúgy, a 4. engine versenyen valóban volt még effekt verseny is, hogy ki tudja az adott jelenetet minnél szebben kirajzolni, csicsával. Sajna azonban érdeklődés hiányában ez most el fog maradni. Ezen túl valószínűleg csak sebességverseny lesz, de kárpótlásként ez most kibővül fénykezeléssel is. Komplexebb effektek azért nem lesznek kötelezők a sebességversenyben, mert ahány engine, annyi féle effekt – a kötelező effektek csak az enginek töredékében működnének. De azért így is nagyon-nagyon csúnya eltérések szoktak lenni, és meglepetések, amikor kiderül, hogy az ember kódja hány hardveren rókázza össze magát.
Aki tehát részt szeretne venni, mondjuk a demo motorjával, az jelezze nekem msn-en vagy skypeon. (de nehogy a közös scene-chatbe, mert azt meg se tudom nézni!). Hanem privátban.
Személyesen nem kell eljönni. Otthon, a fotelban kell megcsinálni mindent.
A verseny pár hét múlva kezdődik. Aki tehát jönni akar, az minnél előbb jelezze a részvételi szándékát.
“merthogy jó esetben kioptimalizálod raszterizálás előtt a felét”
azt hogy csinálom? :) ugye tökre nem értek hozzá, de kb annyit láttam hogy először feltöltöd a dxnek a geometriát. minden egyes framenél akkor másikat nyomsz fel ?
Szerintem erre gondolt:
http://en.wikipedia.org/wiki/Viewing_frustum
Oswald: ha arra gondolsz, hogy a vertex bufferbe feltöltöd-e minden frameben újra a poligonokat egy-egy object esetén, akkor ezt nyilván az adott scene-től függ. Ha megéri, akkor akár azt is, de ezt majd megmondják a nagy játékfejlesztők, akik esetleg találkoztak már ilyesmivel. Bár én azt gyanítom, hogy a nagy enginek ennél “kényelmesebben” működnek :)
De ismerten jó technika ennek egy másféle megvalósítására a LOD (Level Of Detail), amikor a távolság függvényében egyre kevésbé részletgazdag (azaz egyre kisebb poligonszámú) objektet raksz ki ugyanannak a tárgynak a megjelenítésére. Ilyenkor minden fel van előre töltve a vertexbufferbe, csak éppen a legjobb verzió kerül csak be a renderelésbe.
De például különböző technikákkal lehet szűrni Z-ben is. Legegyszerűbb, ha a nagyon messze levő dolgokat nem rakod ki. Ez kis scene esetén semmi nem hoz a konyhára. Ennél kifinomúltabb módszer, hogy az NVidia kártyák pédlául Z-bufferbe dupla gyorsan renderelnek (ATi-ról tud valaki valamit?), így megérheti előbb csak Z-t renderelni színek, textura, fény és shade nélkül, aztán kinyomni full shade-el a scene-t, hiszen a Z-buffer ki fog vágni egy csomó mindent, amikre nem kell lefutnia a shader kódoknak, ami keményebb shadelés esetén igen komoly sebességnövekedést hozhat.
Meg nyilván vannak még okosságok, amiről nekem, mint a témában nem túl járatosnak, fogalmam sincs. Remélem azért valami kis műhelytitkot csepegtetnek ide a szakemberek, hogy táthassuk a szánkat! :)
a frustumnál is a dx dönti el mi látszik, nem ? :) meg mondjuk amilyen demók vannak nem hinném hogy a polginszám lenne a legnagyobb gond. ami már effektszámba megy azt máshogy szokás renderelni, vagy AO fakeléssel tökölődnek, stb.
A pre Z passról annyit, hogy kipróbáltuk nemrég páran. Nagyon jól működik pl erdőségekre, meg ilyesmikre. Szóval bizonyos esetekben tényleg beválik. De egy sima scene esetében, amikor pl egy nagy házat renderelsz ki sok szobával, akkor kb negyedeli az fps-t sajna. Legalábbis a mi méréseink szerint.
amúgy meg a debrisben miért volt nagy szám a sok kocka? az akkori céges laptopomon 15sec/framel ment az az agyonoptimalizált csoda :)
az agyonoptimalt csodakat neha elkurjak am a borzasztoan elkurt driverek :) persze lehet hogy itt nem arrol van szo, de mindenesetre elofordul az ilyen…
gyenge volt a vas ennyi. a debirsnek újgenerációs cucc kellett hogy fusson.
Azok a nagyon furcsa akadások a debrisben érzésem szerint annak voltak köszönhetők hogy a grafikus kártya kifutott a memóriából. Legalábbis az ilyen 3 framet mozdul, aztán megáll benne a szar fél másodpercre jelenségek főleg a kevés memória mennyiségre utalnak. Vagy csak valamit 3 framenként nagyon updatelt. Mindenesetre nekem a debris a mostani gépemen (radeon 9800pro, 1666 amd) inkább diavetítésre hasonlít.
hmm, most jut eszembe, mintha a régi agp 8x-es gépemen sokkal jobban futott volna, mint a mostanin, ami 4x-es.
[ módosítva Jan.20. 15:56 ]
nekem nem akadt hanem szimplán 15sec/frame volt.
Oswald, en arra tippelnek hogy atvaltott szoftrenderbe. Viszont neha akkor is atvaltanak a driverek, amikor a vas tulajdonkeppen meg birna :)
jah, mondjuk lehet nem tudott valamit a vas ami kellett volna és inkább szoftolt. pedig egy need for speed carbon alacsony beállításokkal gyönyörűen futott rajta :)
Meg kellene pixelni a debrist, de szerintem a stencil shadow volume-ok miatt volt viszonylag nagy HW igénye, és igen, a textúramemória méretére érzékeny, előző kártyámon induláskor anno nálam is akadt 2-3 alkalommal az elején. Ma persze egy alsókategóriás gamer kártyán is vidáman elfut, csak integrált cuccok nem bírják.
Egyébként ilyen csendes SW rendering-be váltás csak OpenGL-ben van, D3D szerencsére nem okoskodik ilyeneket.
hanem, mit csinal helyette? teszemazt nem fer el a shader a kartyaban, ilyesmi. elszall hibauzenettel?
Ugyanazt csinálja mint amit OpenGL alatt tenne. Mondjuk szétvarázsolja 2 felé. Ezek a kis trükkök azért elég messze vannak a szoftveres rendereléstől.
na ne viccelj mar
Ez nem vicc.
tudnál adni valami forrást?
A DirectX-ben kis Harry Potterek vannak.
Geri: tévedsz
A D3D-ben shader modellek vannak amik deffiniálnak shaderekhez regiszter számokat, utasításkészletet… Minden egyéb paraméter caps-ból lekérdezhető. Ha egy shadert nem tudsz lefordítani, az error, olyankor nincs olyan shadered, hogy ezt hogy kezeled le, az a te dolgod.
ha az ember közvetlen írná a shader kódot azzal mennyit lehetne nyerni a sebességen ? :)
akár 2%-ot is. :)
Murphy: az oké, hülye példa is volt a shader a részemről. De a kártya kb 5%-át tudja annak hardverből, amit a driverből tudnia kell. Hogy mondjak pár szemléletesebb példát: display lists. Integer vertexek. s3tc… Folytathatnám a listát napestig. És igen, tudom hogy ezek opengles kifejezések, de directxre is ugyanez vonatkozik. Azt állítani, hogy ezek a dolgok szoftveresen futnának, hát, elég meredek. Mert ebben az esetben egy quake2 is 15 fpsen futna. Amúgy meg ez azért kell, mert másképp nem futhatna a geforce2-n pl az ut2004. Persze bizonyos, túlságosan is új featureok (pl shaderek) nem fognak működni régi (pl geforce2) kártyákon, mert azokat már semmi képpen nem lehetne megoldani rajtuk.
Ha a hardvereket teljesen api kompatibilisre akarnák írni, akkorák lennének a videókártyák, mint egy ruhásszekrény, és kis fúziós reaktorokat kellene a gép orrába szerelni hogy ellássa őket árammal.
(mondjuk az nvidia bizonyos átnevezgetett extrahighend kártyáit elnézve a szekrény effektus már megvan :D)
Geri: részben igazad van, de nagyobb részben tévedsz. A DirectX 10-től pont az az egyik nagyon lényeges előrelépése, hogy pontosan deffiniálták, hogy mit kell tudnia egy kártyának, hogy megfeleljen a szabványnak. Persze ezeknek a feature-öknek egy része mehetne akár sw-ből is, csak épp szánalmas sebességgel futna egy olyan cucc ami ezt ki is használja. Tipikus példa régebbi integrált GPU-k vertextransformja. :)
– Hogy az OpenGL-es display list a gyakorlatban hogy működik egy PC-s HW-en nem tudom, de konzolokon pl. teljesen hétköznapi, hogy preprocesszált kommand buffereket használsz kirajzolásra, amit aztán a HW egy az egyben meg tud enni CPU közreműködés nélkül.
– Az egykori S3TC (amit ma DXT1 néven ismerünk) S3 Savage kártyák legelső verziójában is létezett már, és 6-7 éve minden új videokártya támogatja.
– Az intes vertex atributumok is teljesen hétköznapi dolgok már egy pár éve, (sőt sima intnél vannak sokkal cifrább formátumok is) nézd meg kártyák D3DCAPS eredményeit.
Azért a “túlságosan is új featureok (pl shaderek)” kifejezés kicsit erős. :D
[ módosítva Jan.21. 00:05 ]
A directx10, 10.1 és 11 felemlegetése szerintem kár volt, mert összesen olyan elképzelhetetlenül minimális piacot birtokolnak jelenleg, hogy felesleges velük foglalkozni. A 11 majd biztos népszerűbb lesz később.
-Konzolokon fix hardver van, ne keverjük őket ide. PC-n manapság egyszerűen lesz belőle egy jóképű tömb.
-Az s3tc licenszköteles. OpenGL alatt már kb 1-2 éve teljesen kibányászták a driverekből, helyette csak ARB maradt. Hardverileg meg egész egyszerűen más, saját belsőszabvány textúratömörítésekre wrapperelték.
-Mellesleg én pl vertex formátumokra gondoltam. Már 10 éve csak float van, és a cad kártyákon helyenként double (64 bites) precizitás. Integer már hardverből sehol. Ugyanez vonatkozik pl a quadokra, hiába támogatja minden látszólag, úgyis triangle lesz belőle mire a videókártya ér.
De pl nézz meg egy mostani ati kártyát. Stream processzorokból épülnek fel. Gyakorlatilag az egész opengl apit shaderekkel emulálják, ugyanis a kártya már szinte semmit nem tud a régi featureokból. pl gllights, arb_shadow, locked arrays… Képzeld, mi lenne, ha a hardver támogatná a dx5öt, 6ot, 7et, 8at, 9et, 10et, 10.1et, 11-et, és a teljes opengl 3mat mondjuk tőből. Lehet hogy egy szekrény elég se lenne… talán egy kisebb csarnok :D
Geri: Szórakoztató dolog veled vitázni. Becsülöm a határozottságodat, de néha azért olvass utána. :)
– A directx 10 mint szabvány igen súlyos piacot birtokol, ez a minimális szint amit manapság egy új kártya tud. Az, hogy mint API nem terjedt el különösképp az külön kérdés, de esetkünkben lényegtelen.
– A DXT tömörítések is licence kötelesek, szerinted mennyire lenne praktikus hogy betömöríted egy veszteséges módszerrel, átadod a kártyának aztán még a driver “gyorsan” áttömi egy másik máshogy veszteségesbe? Ezeket licencelték a kártya gyártók, és minden kártya tudja évek óta. Időközben születtek új formátumok is, pl. a legismertebb az ATI2 néven futó két független grayscale csatorna tömörítésére szolgáló.
– “Már 10 éve csak float van.” :) pl az ubyte4-et ami color tárolására szolgál, és világ életében létezett hova sorolod? :D Egy Geforce 1-hez képest (ahol azthiszem csak 4 byte csatorna, vagy 1-4 float volt a supportált) éppenhogy növekedett a formátumok száma. Ajánlom figyelmedbe az alábbi linket:
http://msdn.microsoft.com/en-us/library/ee416463%28VS.85%29.aspx
Hát ezer éves dolgokat amik a jelenlegi HW képességgel könnyedén emulálhatóak még szép, hogy nem építenek rá a kártyára, de fordítva ez lényegesen nehezebb. :)
[ módosítva Jan.21. 08:13 ]
Egyébként mit kellett megjeleníteniük az engineknek a 4. versenyen? Egy screenshot azért jó lett volna az eredeti postban.
És mit kell majd az 5. versenyen?
Murphy: a color mióta vertex? :P
Directx10 – Az, hogy valami súlyos piacot birtokol, az épphogy az elterjedtségben látszik meg. Szerintem nem kéne súlyos piacnak nevezni egy olyan platformot, amelyre jobb esetben havi 2 játék megjelenik.
A textúratömörítésről: Nem te tömöríted be a textúrát, hanem a driver. Ha mégis közvetlenül betömörítve adtad be a textúrát a drivernek, imádkozhatsz, hogy a driverek felével ne nyíljanak színes pixelvirágok mindenfele. Ennyire szabvány.
Igen, az ezer éves dolgokat könnyebb emulálni, mint azokat, amik még csak most jelennek meg, de azért oda is erősen hasonló gondolkodásmód kell.
Bery: screenshotot azért nem tettünk közzé, mert elfelejtettem a szabályzatba beleírni, hogy engedélyezni kell minden résztvevőnek hogy screenshotolhassak a szoftveréből. Az újban majd benne lesz. Ezúttal amúgy valószínűleg star trek űrhajó modellek lesznek, sok, nagy polygonszámban. HA sikerül szereznem normális modelleket. Ha nem, akkor startrek helyett valami más lesz. Ha indulni kívánsz, szívesen elküldöm neked a szabályzatot privátban, mondjuk msnen.
Geri: a saját enginedre sem volt engedélyed? ;) Egy screenshot-ra gondoltam összesen, hogy mégis látszódjon, hogy mi volt a megmérettetés témája / tárgya.
Mondjuk ez, hogy egy konkrét modellt kell megjeleníteni, nem tudom, hogy mennyire mutatja meg az engine gyorsaságát. Ha mondjuk egy modellt adsz .x-ben, az szabványos DirectX módon kirakva pár utasítás. Nem is tudom, hogy ott milyen különségek lehetnek. Ha vannak takarások, fények, árnyékok, effektek, akkor azok megvalósítása már enginenként eltérhet és mérhető lehet a különbség.
Persze, ha az adott modellt átkonvertálom saját formátumra, akkor akár már annak megjelenítésében is lehet sebességkülönbség, bár itt nem érzem, hogy lehetne igazán mérhető az érték, ha csak textura és light van a scene-en. De javítsatok ki, mert nem értek hozzá, csak írkálok össze-vissza :)
Screenshotom most nincs kéznél, meg már nem is tudom hogy hol vannak azok a nevezések, de a 4.ben 60 ezer polygonos angyal modellből kellett megjeleníteni olyan 12t, meg egy csomó padot, illetve emelvényeket. Lényegében egy ilyen templom volt belső nézetből. És igen, egyszerű draw utasítások, csak az első és utolsó helyezett között helyenként jó 20x-os sebességkülönbségek voltak. Tehát a helyzet nem annyira egyszerű, hogy van pár draw call, és kész :D
A vertexcolor fogalma azért annyira nem új. :)
Nem tudom, hogy a szövegértéssel vagy a fogalmakkal van-e problémád de megpróbálom mégegyszer. :) A DirectX 10 specifikált egy featuresetet, amit minden kártyának támogatnia kell, hogy megkapja a DX10 logot. A jelenleg gyártásban lévő összes videokártya ilyen, ezen nem változtat az, hogy mennyi játék hajtja meg 10-es DirectX alól.
Fura tapasztalataid vannak, főleg annak fényében, hogy a játékok sok éve gyakorlatilag kizárólag DXT tömörítést használnak textúrák tárolására. :)
Most a technikai dolgokba ne is menjünk bele, messzire vezetne… Csak egy dolgot gondolj végig.
Ha egy új HW feature softwaresen is gond nélkül emulálható akkor vajon a gyártónak érdeke lenne-e régebbi HW-eiben is supportálni ezt? Vagy az új kártyáiba lenne-e értelme egyáltalán HW-esen implementálni?
[ módosítva Jan.21. 19:21 ]
,,játékok sok éve gyakorlatilag kizárólag DXT tömörítést használnak”
Tapasztalataim szerint a játékok nagy részében alapesetben le van tiltva a textúratömörítés.
,,.. Csak egy dolgot gondolj végig.
Ha egy új HW feature softwaresen is gond nélkül emulálható akkor vajon a gyártónak érdeke lenne-e régebbi HW-eiben is supportálni ezt?”
Nem sűrűn. De pl glsles vertex shaderek vannak geforce2vel is, különben pár igencsak népszerű játék nem mozdulna meg, ezt pedig nem engedhetik meg maguknak.
A vertexcolor fogalma nem új, valóban, de szerintem ez rossz példa volt részedről, hisz ennek tetejében szerintem az új openglből pl egy csomó formátumot kiszedtek csak azért, mert nem float pl, ha már ennyire nextgenbe tekintünk. Vertexekkel kapcsolatos formátumokat is jobbára. Bár a vertex colorok charként való átadása ugyan megmaradt, de elég sok más, hasonló dolog nem. De azt azért csak nem gondolod, hogy mind a 30 féle színátadási formátumot, és 7 féle alakzatrajzolási módot változtatás nélkül bekajálja a hardver, mind a kb 100 függvénnyel együtt, ami erre szolgál? :D
,,A jelenleg gyártásban lévő összes videokártya ilyen”
Intel GMA950, 965, GMA 3000, GMA 3100, X3000, X3100, SiS Mirage, SiS Mirage 2, S3 GammaChrome, S3 deltachrome, S3 Multichrome, S3 Unichrome, S20, Graphics 2300E, SavageXP, SiS 3xx, … Nem folytatom tovább a sort… Így is felsorolzam a teljes PC-s VGA piac piac kb 35%-át.
[ módosítva Jan.21. 20:25 ]
Geri, ezeket már nem gyártják :) GMA 4500 most, ami még gyártásban van, a többi legfeljebb megmaradt készeltből. De lassan – szó szerint lassan :) – ez is kiesik, mivel már itt van a CPU-ba integrált GPU. :)
De ezzel együtt abban igazad van, hogy ettől még piacon és a boltok polcain vannak és a notebook-ok és netbookok térhódítása révén jelentős piaci szegmenset tudhatnak magukénak az integrált grafikus vezérlők.
Ezen kártyák mindegyikét gyártják még. Hmm, bár a sis 3xxet és a savage xp-t már nem. Talán a Mirage1-et sem. A 2-t még igen, és még elég sokáig fogják is. A chomre szériából van dx10.1-es is, de gyártják még izomból a 9eseket is. Az intel féle csodaGMAakat is gyártják még sajnos, és úgy néz ki hogy soha nem is fogunk megszabadulni tőlük :D
en nem igazan ertem mar mirol beszelgettek, csak azt akarom mondani, hogy GMA950=MENŐ :)
Tapasztalataim szerint a játékok nagy részében alapesetben le van tiltva a textúratömörítés.
Meglehetősen rosszak a tapasztalataid. :) Ajánlom a PIX használatát tetszőleges D3D-s játékon az elmúlt 5 évből.
Ha egy új HW feature softwaresen is gond nélkül emulálható akkor vajon a gyártónak érdeke lenne-e régebbi HW-eiben is supportálni ezt?”
Nem sűrűn. De pl glsles vertex shaderek vannak geforce2vel is, különben pár igencsak népszerű játék nem mozdulna meg, ezt pedig nem engedhetik meg maguknak.
Fura humorod van mikor geforce 2-őt hozod fel példaként, egy olyan kártyát, amit a gyártó jó ideje már a driver szinten sem supportál. Az NVIDIA-ról beszélünk, aki egyébként 8 szériára visszamenőleg támogatja a hardvereit, de a gef2 ebbe már bőven nem fért bele. :D
Komoly fogalomkavarodást gyanítok. A vertexek formátumának pontossága a felhasználó döntése, a HW-nek ehhez semmi köze, azért tárolok valamit byte-on, mert megfelelőnek találom a pontosságát, pl. a kisebb méretért cserébe. A HW aztán befetcheli a tetszőleges formátumban tárolt vertex atributumot a saját float regisztereibe és dolgozik vele megfelelő pontossággal. Ugye a textura olvasás is pont ugyanígy történik.
Érdemes lenne D3D dokumentációt olvasnod, sokkal jobban megértenéd a HW működését.
A metódus mindig ugyanaz, te lerakod a vertex adatokat, valamilyen módon egy tömbbe, praktikusan vertex buffer objectekben, és a HW abbol felolvassa vertexenként az adatokat.
Ha mezei GLVertexet használsz a metódus akkor is ugyanez, te csak lekommunikálod az OpenGL APIval, hogy miképp helyezze el a vertexadatokat egymás után, és, hogy melyiket melyik regiszterbe olvassa majd fel. glEnd-kor pedig bekerül a command queue-ba a kirajzolas parancs. Az OpenGL ezt lekommunikálja driverrel, ami elhelyezi az adatokat a megfelelő helyre, hogy a HW aztán végre tudja hajtani. Az x féle vertex atribútum formátumot a harvernek kell megérteni, az opengl bűvos függvenyeit pedig csak az opengl ismeri, ő ez alapján előállítja a HW felé a megfelelő stream adatokat és HW commandokat.
A DX10-nek nem megfelelő kártyák témájában igazad lehet, a játékra-demózásra csak igen korlátozottan alkalmas integrált chipek között minden bizonnyal még készülnek DX9-es kártyák, még ha a felsorolással kicsit tulzásokba is estél. :)
Összegezve, a dolog nagyon egyszerű:
– Újabb HW-en régebbi feature settjét emulálni könnyedén megoldható, szokás is. (Így működik pl Radeon 8500 óta a Fixed Function Pipeline az összes kártyában)
– Régebbi HW-en újabb featuresettjét emulálni nem lehet. Vertex szintű műveleteket lehet emulálni SW-esen is, hisz transzformált vertexeket adsz át a kártyának, aztán lehet örülni, neki így csak raszterizálni kell. Ezt ki is használta több integrált videokártya is. Ilyen pl. a sokat emlegetett GMA 950 is. Egyébként a történelem folyamán történt persze olyan néhány alkalommal, hogy orbitális hackelésekkel megoldották, hogy bizonyos nem támogatott feature-ök menjenek, ilyen volt pl. a Voodoo 3-on “nagy” felbontású textúrákkal futtatott Quake 3. De egy Geforce 2-őn soha nem fogsz pl. 8 textúrát felolvasni, mert nem képes rá a HW, soha nem fogsz akár 10 utasításos pixel shadert se emulálni rajta, mert a felépítése nem alkalmas rá.
[ módosítva Jan.22. 00:10 ]
Az összegzés, amit írtál, nagyrészt stimmel, de akarnak benne tévedések is.
Először is én nem állítottam olyat, hogy majd geforce2-n 10 utasításos shaderekkel szenvedj, hanem azt, hogy kompatibilitási okokból a driver emulálja a vertex shader támogatást. A driver támogatottság meg jócskán nem a 8as szériáig tart nvidiáéknál, hisz a geforce 8as kártyák 2006 karácsonyának voltak a slágerei. Az, hogy a legújabb driverek nem visznek kisebb kártyákat, az egy dolog. Ez nem azt jelenti hogy azoknak a kártyáknak az életciklusa véget ért. Szóval a 8xxx széria személyében gyakorlatilag tehát olyan kártyákról beszélünk amiknek most volt a 3 éves születésnapjuk. Remélem azért nem gondolod, hogy ez a generáció a kategória alja, pláne, mivel egy 8800as erőteljesen elkalapálja a mostani újgenerációs kártyák közepét is, ha nem vigyázunk, tekintve, hogy ugyanannak a hardvernek a minimálisan áttervezett változatairól van szó. Illetve, ha gonoszkodni akarnék, azt mondanám, hogy átnevezgetett. A GeForce2 kártyákat azért említettem példaként, mert jól látható, hogy micsoda durva featureokat tol a driver az orrunk alá, jóllehet, a kártya a felét sem támogatja annak, és nem azért, merthogy arra buzdítanálak, hogy használd. A fogalomkavarodás valahol erre felé van, és te követted el ;) Mellesleg a pix használatát gyakorolhatod mondjuk ezekkel a kártyákkal is, de tényleg, valóban nézzél meg pár gamet… ;)
,,A HW aztán befetcheli a tetszőleges formátumban tárolt vertex atributumot a saját float regisztereibe és dolgozik vele megfelelő pontossággal. ”
Örülök neki, hogy eljutottál te is oda, amit már 2-3 hozzászólás óta írok neked. :P Ugyanez vonatkozik a többi hasonló kommentre, de az openglről írt dolgokhoz kiegészítésként még annyit fűznék hozzá, hogy opengl esetében az opengl driver a teljes opengl-t önmaga szolgáltatja, minden egyes függvényével és nyalánkságával együtt. DirectX alatt viszont kicsit más a helyzet. Az általad felhozott glend-es témából is remekül látszik, mennyi mindent kell a hardver felé ügyeskedni a drivernek, hogy egyáltalán legyen kép.
Amúgy a felsorolással nem estem túlzásba, az utolsó 2 laptop, amit a mediamarktban vettek, és kihívtak hozzá oprendszert telepíteni, sis kártyával volt szerelve.
btw, ha már orbitális hackelés: pl az s3 trio3d dx támogatása is orbitális hackelés. Kb 70%-al volt gyorsabb mint a szoftveres renderelés. Nekem van is egy. érdekes állatka. És nem, ezzel nem azt mondom, hogy használj s3 trio3d-t, hanem csak azért mondom, mert érdekesség. ;Đ
[ módosítva Jan.22. 01:02 ]
Geri: Murphy azt írta, hogy 8 generációra vissza támogat az NVidia, nem azt, hogy a 8-as generációig visszafelé :)
2003-ban én is szembesültem azzal, hogy vettem egy S3 Trio 3D-t tesztelni és ugyan DirectDraw volt a projekt alapja (azaz DirectX-es gyorsítású 2D), de tény, hogy az assemblyben megírt szoftveres függvények (image és sprite kirakás, kvázi scrollozás) alig maradtak el a hardveres sebességtől :)
“48.94% are DirectX10 systems”
http://store.steampowered.com/hwsurvey/
[ módosítva Jan.22. 09:28 ]
A steam statisztika pontatlan, mert csak 150 millió felhasználó adatait veszik alapul.
Itt van pl a piac és tőzsdefelügyelet által készített 2009 3. negyedéves részesedéstáblázat, az intel igp-k 51%-os részesedésével, a Steam meg közben mutat vagy 5%-ot az intel kártyákra.
Mellesleg a windows Vista piaci részesedése olyan 33%, melyhez hozzájön még 7%-nyi windows 7 részesedés is, ami összesen 40%-os. Csak ezeken van dx10 támogatás. Még ha azt feltételeznénk, hogy mindenki, aki vistát vagy windows 7-et használ, rendelkezik is dx10 kompatibilis videóvezérlővel (ami persze nyilván valóan nem így van, mivel az userek jelentős része ott is csodaintelekkel tolja), akkor is csak 40% lehetne a dx10 képes rendszerek aránya maximum. Én a gyakorlatilag is működő dx10es rendszereket egy durva és megalapozatlan becslés szerint olyan 20% körülire tenném. És ebben a 20%-ban ráadásul még az ilyen 16 stream processzoros extra lowend kártyák is benne vannak, amikkel erősen akad még az NFS underground is. Persze biztos ezekre is lehet fejleszteni, csakhát, eléggé értelmetlen. És ezt a fejlesztők is tudták, amikor teljesen ignorálták a dx10-et. Majd talán a dx11-nél más lesz a helyzet (de én bízom benne, hogy nem, mert nem örülnék a microsoft sikereinek ezen a téren, mert káros lenne a piacra, és nekünk is).
Tehát a steamből tájékozódni nem érdemes. Akkor lehetnek érdekesek a steam statisztikái, ha valaki direktben a hardcore gamerekre gyúr, és AAA kategóriás játékot szeretne fejleszteni.
btw, pár hete bátorkodtam az előző évi statisztikai különbségek alapján kiszámolni a várható 2009 Q4 beli részesedéseket.
itt vannak:
[ módosítva Jan.22. 11:39 ]
Jah, a Steam haszontalan, csak azokat veszi figyelembe, akik játszanak is. A rengeteg titkárnő-gépet, meg céges, ipari, stb. gépeket fontos figyelembe venni, egy játék-engine / 3D engine fejlesztésnél.
[ módosítva Jan.22. 12:01 ]
Hát ha te 900 milliós tőkéből fejlesztessz AAA játékot, akkor vedd a steamet figyelembe. Ha ez nem így van, javaslom, hogy inkább a piaci részesedésekre koncentrálj.
(Szerintem valószínűtlen hogy egy hardcore gamer a mi B vagy C kategóriás játékainkkal játszon. Aki viszont A kategóriás játékot fejleszt a munkahelyén, az vegye figyelembe az elsőt. De mivel a piacnak az AAA csak egy kis hányadát teszi ki, gondolom az itteni emberek közül kb 10ből 9 valószínűleg nem arra fejleszt.)
[ módosítva Jan.22. 12:14 ]
Szerintem játékosoknak érdemes játékot fejleszteni, ezért venném figyelembe…
[ módosítva Jan.22. 12:13 ]
Ajánlom a PIX használatát tetszőleges D3D-s játékon az elmúlt 5 évből.
probaltam, le van tiltva :)
Remage: nem csak a HD5xxxel futkosó emberke a játékos. Épp ugyanúgy játékos pl egy 1 ghz-s celeronnal jojatekozó, honfoglalozó emberke is. Ők is ugyanúgy vásárlóerőt jelentenek, mennyiségükből fakadóan pedig nem is kicsit.
És még mindig többszázezer poligont megjelenítő 3D engine-ről beszélünk?
Mert ha ilyen játékot fejlesztenék, akkor nem érintene, hogy hányan passziánszoznak a gépükön… Más piac.
Úgy vélem, mindkettőről beszélünk még, a két kategória között a határmezsgye azért nem olyan széles szerintem, hogy csak az egyikről beszélhessünk.
egyebkent steam abbol a szempontbol meg a masik iranyba csaloka hogy ugyan van rajta egy csomo AAA title, de ugyanott van mocskossok 2D meg regi / egyszerubb 3D jatek is, szal a jatekok eloszlasa se egyenletes
Télleg nem olyan széles, a minimum hardverkövetelményeket is csak viccből írják oda a játékokhoz, valójában a Crysis is fut C64-en, szoftveresen emulált DirectX10-ben.
De csak miután szétvarázsolta 2 felé. :-)
zoom: meg is látszik, de majd az arculattervezők elmagyarázzák, hogy működik, nem? ;)
[ módosítva Jan.22. 15:16 ]
Egyáltalán nem kell ahhoz arculattervezőnek lenni, józan paraszti ésszel is belátható hogy:
1. Ha AAA kategóriás játékot csinálsz ma akkor teljes mértékben leszarod a geforce2/gma/s3/akarmi tulajokat. (sőt nem is kell ehhez hogy AAA kategóriát célozd meg, egyszerűen ha 3D-ben gondolkozol akkor ma már körberöhögik azt a szintet amit egy gf2-ből ki lehet préselni, ezért nem is 3D játékot csinálsz, lásd 2-es pont)
2. Ha nem szarod le a geforce2 tulajokat akkor nem AAA kategóriás játékot csinálsz hanem browseralapú és/vagy popcap jellegűeket.
A két kategóriának egészen minimális közös halmaza van.
(egyébként nem vagyok arculattervező)
World of Warcraft. Évek óta toplistás AAA game, fut pl GeForce2-n is. Vajon toplistás game lenne, ha csak félmillió forintos gépeken futna? Hát, nem igazán hiszem. Ebből a példából kiindulva a közös halmazos dolgot szerintem gondold át picit.
A WoW-ot ne keverjük ide, az egy külön kategória. Eljutott arra a pontra ami már egy öngerjesztő folyamat és már csak azért is toplistás mert a szomszéd kutyája is azzal játszik. Nem nevezném a mai értelemben vett AAA játéknak, pontosan a sikere és felhasználóbázisa miatt fut még mindig gf2-n is, és nem fordítva.
A Spore is fut GMA950-en, mondjuk Geforce 2-n már nem :-)
Annyit zárásként még hozzáfűznék a témához, hogy a GeForce2 már a WoW megjelenésekor (2004) is 2 directx verzióval és ugyanennyi generációnyi shader modellel el volt maradva az akkor már divatos dx9től, és az ezt támogató kártyáktól.
[ módosítva Jan.22. 16:46 ]
Konyorgom, a WoW 2004-ben jott ki, amikor a GeForce 2 meg csak 4 eves volt. Azota meg gondolom nem emeltek a hardverkovetelmenyeken, nehogy elveszitsek az elofizetoiket.
Tudtommal a mai jatekok is elfutnak 4 eves kartyakon.
Állította valaki az ellenkezőjét?
Ja kozben kommenteltel, amig irtam
btw, ki küldte be a hírt?
Élvezet olvasni ezt a threadet, komolyan. :) Külön jó, hogy van nálam kóla!
Ne hagyjuk így leülni ezt a témát, hosszú ideje az egyetlen érdekes volt! :)
Én csak a játékokra alapozott tesztekben szereplő fps számokon látom, hogy milyen eltérések lehetnek megvalósításban még az “A” kategóriás játékok között is. Van olyan kártya, amelyik az egyik játékban a középmezény végén kullog, egy másikban meg a második helyen áll.
Érdekelne, hogy ki milyen “feladatot” tűzni ki egy ilyen versenyen az enginek számára, hogy közelítően reális megmérettetés és eredmény születhessen.
Jó, ennek nyilván akkor van értelme, ha közel azonos feladatra készült egninek mérkőznek meg. Nyilván egy nagy, szinte “végtelen” teret másképp kell optimalizálni, mint egy 4 szobában zajló történést.
Benne volt idáig a szabályzatba az is, hogy pontos leírást kellett volna adni arról hogy a versenyző az enginet milyen célból készítette, milyen játékok számára. Sajnos ezt a pontot még senkivel nem sikerült betartatnom.
A versenyre utoljára holnapig fogadok el további jelentkezéseket!
A verseny heteken belül indul, melynek menetéről minden résztvevő tájékoztatva lesz.
Nem lenne baj, ha lennének szabályok is (meghirdetve)…
Mivel még időben jeleztél, beszúrom ide őket:
Kedves versenyzők. Elérkezett az 5. engine-verseny ideje.
Az engineveseny egy, immár több éve zajló egyedi, magyar hagyomány, melynek főszervezője Geri.
Attól eltekintve, hogy nagyon lazára vesszük a figurát, ez egy nagyon komoly szakmai megmérettetés, ahol
elsősorban nem másokkal, hanem saját magaddal versenyzel.
De ezt úgyis tudjátok. A szabályokat alaposan olvasátok el, mert vannak változások!
A szabályokban változás állt be, ezért kérlek téged, hogy NAGYON FIGYELMESEN olvasd el az új szabályzatot. Mielőtt kérdeznél, olvasd el az egész szabályzatot, egyben, és csak utána zaklass, ne pontról pontra, ugyanis valószínűleg a kérdésed egyértelműen meg van válaszolva.
A verseny már csak egyetlen részből áll. Ez a SEBESSÉG-VERSENY, melynek lényege a megadott scene minnél gyorsabb kirajzolása. Az ide vonatkozó szabályok:
A rendszerekről:
-NT/95/98/ME/2K/XP/VISTA/WIN 7/ LINUX 2.6.x -re írt programok használhatók. DE a tesztgépeken külön-külön gépek, melyeken adott operációs rendszer van. Ez azt jelenti, hogy azt nem fogjuk lecserélni, ha az engined nem indul el vele. A felsorolt operációs rendszerek nem azért vannak kiírva, hogy ezek mindegyikén kötelezően futnia kell az enginednek. Értelem szerűen egy gépen csak egy oprendszer van. Igyekezz megoldani hogy az összes felsorolt operációs rendszer alatt megfelelően fusson a szoftvered, hogy a legtöbb pontot szerezhesd. Egyéb egzotikus/noname/kihalt platformokat (bsd, mac, mac-ppc, beos) nem fogunk használni, és ha ilyenekre fordítottad a szoftveredet, nem is áll módunkban tesztelni.
Bármilyen 3 dimenziós api használható, ajánlott: OpenGL, Direct3D 6, Direct3D 7, Direct3D 8, Direct3D 9, Szoftveres renderelés. Használható egyéb API is, mint pl a Direct3D 10, Direct3D 10.1, Direct3D 11, OpenGL 3, de ezeket elég kevés konfiguráció támogatja jelenleg, és ha az engined csak ezek közül támogat valamit, a régebbi gépeken nem fogsz tudni pontokat szerezni. A directx runtime .dll-eket és egyéb egzotikumokat MELLÉKELNI KELL az exéd mellé. Nem, nem áll módunkban kiguglizni őket.
Minden futtatáshoz szűkséges keretkörnyezetet MELLÉKELNI KELL. Még az msvc runtime DLL-jeit is. Méghozzá nem tesséklássék módon, hanem konkrétan. Még a fent említett d3dx* fájlokat is, amik kellenek a programozhoz. Ha nagy méretű a szűkséges driver vagy csomag, akkor elég mellékelni a rá mutató letöltési linket. Hiányos függőségleírás esetén ha nem indul el a programod, mi NEM FOGJUK KITALÁLNI, HOGY MIÉRT NEM MEGY, HANEM AUTOMATIKUSAN DISZKVALIFIKÁLUNK. A tesztrendszer alapesetben egy csupasz operációs rendszer, melyre a hardverekhez legibkább illő driverek vannak feltelepítve (ez új hardverek esetén a legújabb drivert, régebbiek esetén azokat a drivereket jelenti, amikkel a leggyorsabbak.). Extrém esetben készíts olyan telepítőt az enginedhez, ami a szűkséges csomagokat installálja. De a legjobb az, ha nincs semmiféle dependencia. Persze ez nem követelmény, de az isten szerelmére, úgy fordítsd le a programodat hogy elinduljon. Nem szeretnék vs debug módban fordított csodaexéket ezen a versenyen. Az ilyen entert-nyomok-és-kiírja-hogy-nem-win32-alkalmazás szerű adathalmazoktól meg görcs áll az agyamba, amit te nagyon nem szeretnél.
Bármilyen fejlesztői környezetet és libraryt használhatsz. Bármilyen programozási nyelven megírt engine jöhet. Az engine forrását NEM KELL mellékelni.
Technikai és vizuális kritériumok:
-A kamerának vezérelhetőnek kell lennie (wasd vagy kurzor vagy numpad, és egér). Lehetőleg normális módon lehessen evickélni a pályán, nem pedig 0,001m/sec sebességgel, és nem is 100m/seccel. A mozgás lehetőleg NE mindenféle teszkós tutorialból kimásolgatott nagyításos és kicsinyítéses baromság legyen, hanem kb úgy lehessen bejárni a pályát mintha épp spectatolnál valami fpsben. A kamerához ütközésvizsgálat NEM KELL.
-Semmiféle effektet, fizikát, egyebet nem kell számolni.
-Semmiféle menürendszert nem kötelező beiktatni a szoftverbe, a cucc q betűre vagy escapere lehetőleg lépjen ki.
-1024x768x32-ben kell renderelni. Ha ez a mód nem áll rendelkezésre a videókártya által, automatikusan csökkenteni kell a felbontást, vagy pedig mellékelni kell egy konfigurátort a szoftverhez.
-A mellékelt textúrák méretét megváltoztatni TILOS! Minden textúra kettőhatvány méretű, X és Y szélességük megegyezik.
-Mip-Map-ek használata engedélyezett, de:
*kép*
valahogy így. Ha a mipmapeid minősége technikai okokból nem éri el ezt a szintet, baj akkor sincs, mert az enginedet anizó filtereléssel fogjuk mérni.
-A mellékelt textúrákon színkorrekció (amennyiben ezt igényli az engined) elvégezhető.
-*VÁLTOZÁS*A modelleket csak .3ds formátumban kapod. Úgy kimentve, amit minden csodamodellező program beolvas. NEM, nem fogjuk helyetted átkonvertálni akkor se ha dorinacica1994 a nicked, majd átkonvertálod őket magad.
-A mellékelt textúrák és modellek tetszőleges formátumokba konvertálhatóak. Igen, bármilyenbe.
-Mindent ki kell renderelni minden frameben. Ilyen irányú trükközés nem megengedett. A modellek polygonszáma csökkenthető, de a csökkenés a monitorra kerülő képen nem látszódhat. (Tehát az ilyen-olyan cullingok teljes mértékben engedélyezettek és szabályosak.). viszont:
-A mellékelt modellfájlok polygonszámát megváltoztatni TILOS!
-Tilos csalni. Hogy mi számít csalásnak, az úgyis teljesen egyértelmű minden résztvevő számára. Csalás esetén nagy valószínűséggel automatikusan diszkvalifikálunk az összes jövőbeni versenyről is.
-*VÁLTOZÁS* A modelleken lennie kell MEGVILÁGÍTÁSNAK. Ez a megvilágítás bármi lehet, és bármilyen módon működhet. Vagyis a modellek fény irányába néző polygonjainak tehát fényesebbnek, az elállóaknak pedig sötétebbnek kell lenniük. Ez definicó szerint magában foglalja pl a tradícionális fixed pipeline alapú pervertex fényszámítást is, de ettől bármilyen módon eltérő/más, vagy akár komplexebb fénykezelést is hozzáadhatsz a jelenethez. A komplex fényszámítás nem követelmény: vetett árnyékok számítására, vagy global illumination effektekre természetesen nincs semmi szűkség. A lényeg csak az, hogy legyen a jelenet bevilágítva, és nézzen is ki ennek megfelelően.
-*VÁLTOZÁS* Ha az ismert FPS mérő szoftverek nem működnek együtt az engineddel, tegyél a programodba fps mérőt. DE CSAK AKKOR.
TÖLTSD KI EZEKET AZ ADATOKAT IS, ÉS CSATOLD A NEVEZÉSEDHEZ!
Fejlesztő csapat/emberke: …………………………………………………………………………………………………………..
Az engine neve, ennek hiányában kódneve: ……………………………………………………………………………………
Honlap: ………………………………………………………………………………………………………………………………….
Logód: csatold a nevezésedhez
A fejlesztés kezdete (és vége, ha már nem fejleszted tovább): ……………………………………………………………
Az engine által használt 3D-s API: ……………………………………………………………………………………………….
Az engine által használt egyéb API-k, runtimeok: ……………………………………………………………………………
Az engine forrásának a mérete (kommentekkel vagy annélkül): ………………………………………………………….
A programozási nyelv, amiben írtad, a compiler, amivel fordítottad: …………………………………………………….
Ha az engined nem önálló, hanem használ 3rd. grafikus enginet, annak a neve (pl ogre): ………………………….
Értékelési szabályok:
Sebesség-verseny: A tesztelt konfigurációk mindegyikén a renderelési sebesség alapján előáll egy sorrend, ahol a leggyorsabb motor kapja a legtöbb pontot, a leglassabb pedig a legkevesebbet. Amelyik motor nem indul el az adott konfiguráción, az 0 pontot kap. A pontok összeadódnak, így alakul ki a végső sorrend.
Tesztelni előreláthatólag a szokásos módon fogunk. Extrém low-end-től az extrém high-end-ig, a következő kártyákkal:
-nVidia (riva, geforce 2, 4, fx, 6, 7, 8, és tovább)
-ATi (rage, radeon 7,9,x1,hd2,3, stb)
-3dfx (v1,2,3,5)
-S3 (Savage4 biztos lesz)
-3dlabs (Permedia2 talán lesz)
-SiS (6326, meg még talán más is)
-Intergraph (Wildcat 4110)
-Intel (ixxx szériák, ha sikerül őket feltelepíteni)
-Más kártyák, ami a kezünkbe kerülnek
A következő processzorokkal:
-AMD (k5, k7, (a k6 elfogyott), k8, phenom)
-Intel (pentium, pentium-mmx, celeron, pentium 4, core2, core i7, az újabbakat meg a fene tudja hogy hívják)
-Cyrix
A versenyre a leadandó cuccokat egyszerű megcsinálni, viszont sokan leszünk. Nem tudom mindenkinek a dolgait a fejemben tartani. A határidőket mindenki igyekezzen betartani, és mindent pontosan dokumentálni.
Jó versenyt!
RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT RAJT
csomagokért msnen jönni!
[ módosítva Feb.28. 21:23 ]
No de nem letölthetőek a cuccok?
A verseny folyamata alatt a cuccok csak a résztvevőknek nyílvánosak. Ha részt szeretnél venni, msnen elküldöm a csomagot.
A mérés már elkezdődött, az eredmények folyamatosan frissülnek, pár naponta.
http://legendgrafix.buzz.hu/archives/2010/04/06/Engineverseny_5/
“a scene demók olyan számítógépes játékok, amikkel nem lehet játszani”
Hajrá Blueghost!
en ezt nem is ertettem sose hogy mi ez, es miert, viszont a kommentek eleg szorakoztatoak!
:-)
olvassátok a blogot, mert folyamatosan frissül, ahogy meg lett mondva!
már win7-es gépen is megmérkőztek az enginek.
Tényleg folyamatosan frissül, bár az elmúlt 2 napban nem volt semmiféle update sem, holott van már 2 eredmény is a gépemen, arra várva, hogy feltegyem őket. Dehát a lustaság fél egészség :D
http://legendgrafix.buzz.hu/archives/2010/04/06/Engineverseny_5/
eredményhirdetés.
[ módosítva May.16. 10:53 ]
PIX-el & OpenGL debuggerrel nézted, hogy mik a különbségek az enginek között? A sebességkülönbségek elképesztőek, amit egyféleképp lehet elérni, valamit rosszul/túlbonyolítva ír meg a készítő.
Nem, ilyesmiket nem használtam. De ha valaki kielemzi őket és elküldi nekem, odaadom neki a rilízeket.