Pár napja, 2008. augusztus 11-én megjelent az OpenGL 3.0, és a fogadtatása – enyhén szólva – nem túl rózsás. Nézzük át, milyen változások lesznek a demoscene egyik legnépszerűbb grafikus API-jában, és miért ilyen vegyes a fejlesztői közösség reakciója.
Beküldte: Jimmi
Történet
Az OpenGL célja, hogy egy teljesen platformfüggetlen programozási felületet biztosítson a 3D grafikai megjelenítést megvalósítani kívánó programozók számára. Ehhez az ipar sok szereplőjének összefogására van szükség, így a hardver- és szoftvergyártók, valamint egyes operációs rendszerek készítői összetömörültek az Architectural Review Board nevű szervezetbe, amely az OpenGL fejlődését hivatott felügyelni és biztosítani. Azonban kiderült, hogy az ARB malomkövei túl lassan őrölnek, és a nagy rivális, a DirectX lassan jelentős technikai fölényt tudott felhalmozni a Microsoft zászlaja alatt. Így az OpenGL felügyeletét a Khronos csoport vette át, ami olyan nyílt szabványokért is felelős még, mint az OpenML multimédia API, vagy a Collada nevű 3D tartalmakat tároló formátum.
A szervezet 2007 szeptemberére igérte a végleges OpenGL 3.0 specifikációt. Az előzetes tervek alapján egészen forradalmi újításokra lehetett számítani, ami rá is fért már az öregedő és túlbonyolódó API-ra. Az új tervezet egyszerűbb és gyorsabb driverek lehetőségét igérte azzal, hogy nagyon sok idejétmúlt funkciót száműz az OpenGL-ből, helyettük moderneket, a hardverekhez jobban illeszkedőeket tesz elérhetővé. Az OpenGL ES 2.0 (ami a beágyazott rendszerekre specializált változata az OpenGL-nek) valóban egészen jól sikerült, így nagy várakozás előzte meg az új API érkeztét. Azonban 2007 szeptembere elmúlt, és a Khronos előre nem látott akadályokra hivatkozva kitolta az OpenGL 3.0 megjelenését, amelyet végül egy évnyi néma hallgatás után a 2008-as Siggraph-on mutattak be. Azonban nem egészen azt kaptuk, amire számítottunk.
Az új OpenGL specifikáció letölthető innen.
Változások
Nézzük át először az különbségeket az eddigi verziókhoz képest. Ahogy az lenni szokott, most is egy jó adag olyan eszköz került be az OpenGL magjába, amelyek eddig csak kiterjesztésként volt elérhetőek. Legfontosabbak talán a lebegőpontos textúra- és framebuffer-formátumok támogatása (GL_ARB_color_buffer_float, GL_ARB_texture_float), a textúrára renderelés képessége (GL_EXT_framebuffer_object) valamint a vertex shader kimenetének bufferbe történő visszaírása (GL_EXT_transform_feedback). Az OpenGL felhalmozott technológiai hátrányát remekül példázza, hogy ezek a funkciók DirectX-ben hosszú évek óta elérhetőek. A teljes listát a specifikáció N.1 fejezete tartalmazza.
Ami sokkal fontosabb talán, az az úgynevezett deprecation model, ami a mostani verzióval került bevezetésre. Eszerint egyes funkciók “deprecated”-nek minősülnek, így használatuk ellenjavallt, bár a driverek továbbra is támogatni fogják őket. A lényeg, hogy az OpenGL következő verziójából ezen funkciók közül kidobhatják az összest. Vagy a felét. Vagy semennyit.
A leglényegesebb dolgok, amiket a Khronos lassú halálra ítélt, s ezzel az OpenGL megtisztulását biztosítani kívánja, a következők:
– A GLSL shader nyelv korábbi (1.10, 1.20) verziói
– Az úgynevezett “immediate mode”, azaz a glBegin()…glEnd(), és minden velejáró, azaz végre repülni fog a glVertex3f(). Mostantól csak bufferben lévő vertexeket lehet renderelni majd.
– A fixed function pipeline. Mostantól csak saját vertex és pixel shadereinket használhatjuk. Ezzel együtt repülnek a mátrixműveletek is, tehát pl. a transzformációs mátrixot is magunknak kell majd előállítanunk. Az OpenGL beépített fénykezelése is a feledés jótékony homályába vész majd, amiért a cikk írója külön pezsgőt bont.
– Vastag (>1 pixel széles) vonalak
– Négyszögek, sokszögű poligononok. Tessék háromszögelni.
– Alfa-teszt, köd
– Display listek
Valóban igencsak üdvözítő lenne, ha ezek a dolgok kikerülnének az OpenGL magjából. Az eredeti igéret szerint ezek a 3.0-ban benne sem lettek volna már, esetleg egy kiegészítő, OpenGL fölé írt függvénykönyvtárból lettek volna előhívhatók, ha esetleg valakinek mégiscsak ezekre lett volna szüksége. DirectX-ben ezt a kiegészítő szerepet a D3DX nevű library látja el – szintén hosszú évek óta már.
Az új object model
A új OpenGL-lel szembeni kritikusok egyik legnagyobb szívfájdalma az új “object model” kihagyása a 3.0-ból. Eszerint a létrehozott objektumok (pl. textúrák, vertex bufferek) megváltoztathatlan tulajdonságokkal rendelkeznek, tehát fix méretűek és formátumúak. Egy esetleges bufferméret-változtatáshoz ugyanis a programozónak jelenleg egyetlen aprócska utasítás is elég, a driver pedig közben vért hány a szenvedéstől. Az új modellel a driverek felépítése jelentősen egyszerűsödött volna. Ugyancsak szép lett volna az állapotgép száműzése az OpenGL-ből (pl. “glMatrixMode(GL_MODELVIEW); glLoadMatrix(matrix);” helyett “glLoadMatrix(GL_MODELVIEW, matrix);”), de ez sem történt meg – ugyanakkor kaptunk egy GL_EXT_direct_state_access kiterjesztést, ami pont ezért felelős. Remélhetőleg a következő verzióban már benne lesz, szintén egyszerűbbé tenné a drivereket.
Geometry shader
A DirectX 10 nagy csinnadrattával beharangozott újítása volt a geometry shader. Ennek segítségével létező 3D testeket módosíthatunk, vagy akár teljesen újakat hozhatunk létre a videokártya masszívan párhuzamos GPU-ját kihasználva. A grafikus hardverek teljes programozhatósága tette lehetővé, hogy egy ennyire gyökeresen más típusú shadert is képes legyen futtatni a GPU. Erre alapszik a majdani DirectX 11-ben található compute shader is, amivel a grafikai adatoktól független, általános feladatokat futtathatunk a videokártyánkon, pl. fehérjekutatás, audio jelfeldolgozás, jelszótörés vagy tetris.
Sajnos a várakozásokkal ellentétben az OpenGL 3.0 és a GLSL 1.30 még csak említést sem tesz a fentiekről. Aki tehát ilyet szeretne, annak továbbra is a gyártóspecifikus kiterjesztéseket kell használnia. Nem süti.
Verdikt
Jómagam egészen türelmetlenül vártam az OpenGL 3.0-t. Bíztam abban, hogy végre egy naprakész, használható API-t kapunk a kezünkhöz, és ismét az OpenGL lesz a király a grafikus interfészek között. Amikor azonban elolvastam a megjelent specifikációt, sajnos szembesülnöm kellett azzal, hogy messze nem váltotta be a hozzá fűzött reményeket.
Az OpenGL 3.0 tehát joggal vívta ki a fejlesztőközösség haragját, a beigért változások közül szinte semmi sem valósult meg. Látszik ugyan, hogy a szándék megvan a Khronosban, de nem volt meg az elszántság egy igazán merész lépésre. Az OpenGL az 1.0 változat óta görget maga előtt egy egyre bonyolultabbá váló rendszert, ami ráadásul semennyire nem illik a mai hardverekhez. Cserébe átláthatatlanná teszi a drivereket, amelyek – nem kis mértékben ennek köszönhetően – eltérően, sokszor hibásan működnek. Ha a Khronos hasonlóan folytatja a munkáját, bizony hosszú éveknek kell eltelnie még, mire az OpenGL a mostani DirectX-ek fejlettségét és egyszerűségét eléri, addigra viszont az már ugyanúgy kevés lesz, mint az OpenGL 3.0 most.
Aki sok anyázást szeretne olvasni az új OpenGL-ről, olvassa el az opengl.org hivatalos fórumát a bejelentésről.
:( nagy kár érte…
Számomra pont az OpenGL ES után érthetetlen a dolog, ahol mertek vágni, még ha nem is olyan mértékben, mint amit itt igértek.
fleeeeeeeeem :) \o/
\o/ na b@szdmeg ! :) muhaha :)))))))))))))))))))) \o/
Azt írja a doksi, hogy deprecated lett a Bitmap és a DrawPixel. Szerintetek mivel érdemes kiváltani ezeket?
a driverek nem ezert nem mukodnek, hanem mert a balfasz programozok akik irjak oket nem ertenek a munkajukhoz
travis: directx-el :)))) \o/
Szerintem textúrázott mesh-ekkel, sok más lehetőséged nincs. A glBitmap és a glDrawPixels kliensoldali adatokat használ, ezeket módszeresen deprecatednek nyilvánították. Ugyanígy deprecated a vertex array is (ezt mondjuk nem írtam le a cikkben), és vertex buffer objecteket illik használni helyettük.
Akartak csinálni valami jobbat, aztán valami sokkal rosszabbat sikerült. Ezt az egészet így el kéne felejteni, hamar megtoldani a mostani opengl arhitektúrát pár extensionnal, a khoronosnak pedig újrakezdenie a kutatást. Teljesen 0-ról. Annyi közös legyen a mostani opengl-el az új opengl-nek, hogy gl-el kezdődjenek a függvénynevek. Meg ne is az opengl32.dll-t használja, az maradjon meg a régi cuccoknak. Jól elbaszták, gratula. Amúgy én már fél éve eldöntöttem, hogy 4-5 éven belül áttérek a szoftveres renderelésre. Elegem van már a sok hülye apival való szopásból, és lassan a hardveres renderelés a sok felesleges szarravaló sallang miatt nem is gyorsabb annyira a szoftveres renderelésnél, hogy egyáltalán érdemes legyen foglalkozni vele, a horribilissá válló fejlesztési időkről nem is beszélve.
És ha jönnek a kvantumszámítógépek?
Megesznek.
Könnyen lehet, hogy mindannyian ezt fogjuk tenni, ha nem is ebben a formában. Az Intel új üdvöskéje, a Larrabee ugye pont ezzel kísérletezik. Általános x86 processzorokra írnak szoftveres raszterizálót. Könnyen elképzelhetőnek tartom, hogy a jövő GPU-i is teljesen általános célú, párhuzamos processzorok lesznek, amire egy szoftveres réteget húznak. Meglátjuk.
Én annak örülnék a legjobban, ha tennének legalább 64 egyszerűsített x86 processzort egy nyákra (tehát nem ennyire komplexeket, csak ilyen 386 szintűt, persze bizonyos elvárásokat azért megfutva), így kisebb lenne a processzor mérete, nagyobb sebességen lehetne hajtani, olcsóbb lenne gyártani és tervezni, persze lehet hogy 1 mag csak fele olyan gyors lenne 4 ghz-n, mint egy mostani 2-n, viszont van rajta 64, és az egész egyben jóval nagyobb hatékonysággal rendelkezne mint a mostani komplex 2, max 4 magos processzorok.
Egy ilyen arhitektúra a grafikát is simán el bírná vinni a hátán, továbbá ha épp nem grafikára van használva, akkor futhat rajta a fizika, ai, meg a többi hülyeség is. Grafika gyanánt meg egy 32 megás integrált valamit, 2d only támogatással (a 3d-s csinálhatja a processzor akár egy normális szoftveres opengl driveren keresztül is átmenetileg) meg valami 350 körüli ramdac-cal, double bufferinggel. És akkor a fejlesztés jelentősen leegyszerűsödne, 386ot pistike is tud gyártani, nem kéne külön gpu-t venni, lehetne egy csomó gyártó, etc etc.
Hát figyelembe véve, hogy jelenleg mennyi macera, és mennyire unsafe a legegyszerűbb feladat is több szálon megvalósítva (Cell kapcsán elég sokat lehet erről olvasni), én elég szkeptikusan állok a témához.
A videokártyák gyorsak, stabilak, felxibilisek safe-ek, jó a képminőségük. Sok számításigényes feladathoz lehet jobb architechtúrát készíteni, a videokártyán azért kezdtek el mindenféle mást is számolni, mert úgy is ott van a gépben, és többnyire nem izzasztod meg, különösebben. Viszont polygon raszterizáló témában nem hinném, hogy egy hosszú évek alatt kibalanszolt, célirányos logikákkal cachekkel megtámogatotott harvderel versenyezni tudna egy x86 alapú architechtúra.
Geri: az a baj, hogy amit leírtál, annál a mostani videokártyák is sokkal gyorsabbak már. Az Ati új kártyája, a 4870 X2 konkrétan 800 (!) shader egységet tartalmaz, amelyek valószínűleg egyesével is gyorsabbak egy 386-osnál lebegőpontos műveletekben.
A cell-lel az a hihetetlenül nagy probléma, hogy egy olyan egységet is tartalmaz, amit jobb lett volna kihagyni: nevezetesen bele van gyógyítva egy töketlen ibm ppc processzor is. Ha kicsit máshogy tervezik a SPE processzorokat, akkor egy olyan arhitektúrát kaphattak volna, mint amit az előbb felsoroltam. A több szálúsítással nincs bajj, amennyiben eleve úgy tervezik az adott feladatot, hogy több szálú legyen. Amennyiben utólag akarnak valamit több szálúra gyógyítani, akkor már bajj van. A grafika, mint olyan, viszont gyakorlatilag problémák nélkül párhuzamosítható. Az x86 nem a nyers teljesítményben tud versenyezni egy célhardverrel, hanem abban, hogy egy med-end vagy egy low-end teteje beli hardverrel egyenértékű teljesítményt tud produkálni, akár kisebb költségek mellett is. Nem kell kidobni az agp.. izé.. pci-e portot a gépből, ilyet nem mondtunk. Legalábbis egyelőre :P
Jimmi: ez így igaz, viszont azok a shader egységek fizikát számolni már nem tudnak, így amit nyersz a vámon, azt bukod a postán. Jó, persze tudnak, mindenféle sdk-val, csak épp az ember megőszül, mire megírja, meg aztán cpu-ba vissza is kell azt juttatni, és még egy csomó problémát felvet a dolog. Elvégre ha minden ugyanazon a processzoron futna, akkor a teljesítmény eloszlana, nem lenne az, hogy a grafika elvesz X időt, a többi részegység meg addig áll. A 386-ot pedig a cpu gyártók minden bizonnyal képesek lennének úgy áttpofozni, hogy képes legyen float szorzás/összeadásra mondjuk 1-2 órajel alatt, esetleg valamiféle sse szerű simd képességekre annélkül, hogy az arhitektúra többi részét nekiállnának kispécizni, megspórolva a mag növeledését. A floaton kívül még a marhagyors feltételvizsgálat, és hozzá az ágbecslés az, ami fontos lehet.
http://www.firefox.hu/extensions/Nyelv-93/Details-1/Selected-281/
ez így igaz, viszont azok a shader egységek fizikát számolni már nem tudnak, így amit nyersz a
Errol meg kellene kerdezni az nVidia CUDA es a Khronos/Apple OpenCL projectjet is. Arrol nem beszelve, hogy az uj nVidia ForceWare driverben mar bekapcsoltak a fizikai modellezeshez szukseges API-kat is, ami szinten a GPU-val szamoltat. Arrol sem, hogy letezik mar szoftver, ami brute force tor MD5 hash-t es mindenfele kriptografiai modszereket GPU-n.
A 386-ot pedig a cpu gyártók minden bizonnyal képesek lennének úgy áttpofozni, hogy képes legyen float szorzás/összeadásra mondjuk 1-2 órajel alatt, esetleg valamiféle sse szerű simd képességekre annélkül, hogy az arhitektúra többi részét nekiállnának kispécizni, megspórolva a mag növeledését
Es ezzel leirtal az altalad szarnak titulalt PowerPC kovetelmenyspecifikaciobol jo nehany sort.
Cell-lel kapcsolatban sem igazan van igazad, kicsit mas elvek alapjan terveztek meg :P Ha azt csinaltak volna, amit mondasz, akkor megkaptak volna a mai tobb processzoros rendszerek minden nyugjet NUMA-stol, buszostol, istenharagjatol. Cell tervezesekor a nyers brutalitas es a minel egyszerubb hardver volt a cel, nem az altalanos celu programozhatosag. Ha azt teszik amit leirtal, akkor ugyanott tartottak volna par eve, mint amivel most epp halalra szopatja magat az Intel es az AMD is. Gyanitom – mivel a Sony igy is eleg tekintelyes veszteseggel arulja a konzoljait – nem akarta a koltsegeket tovabb srofolni, plane, hogy az igy eloallt architectura is megfelel a kivanalmaiknak.
[ módosítva Aug.15. 14:34 ]
faszt nem tudnak. Feljovoben levo iparag, hogy a videokartyakat olcso parallel szamitogepnek tekintjuk. 10x-es sebessegkulonbseget siman produkalnak. Tobbek kozott pont fizikai szimulaciok az egyik fo alkalmazasi terulet (bar ez nem az a kozepiskolas fizika amit a jatekokban nyomatnak :)
pontscho: miért nem olvasod el a gondolatok második felét is, mielőtt válaszolsz rájuk? Nehezedre esik, mi? :D
Cuda: lásd utána következő mondat.
A PowerPC is jó lenne, ha lenne rajta egy tokban mondjuk 64 mag, de nincs, ugyanis én erről beszéltem. Meg a PowerPC mióta x86? :D Részeg vagy? A Cell tervezésekor az általad felvázolt célok valóban léteztek. Erre közölte az IBM, hogy a Cell-be egy PowerPC mag KELL, mert ha nem, kipusztulnak a harcinyulak.
blala
Cuda: lásd uána következő mondat. (pedig te a multkor még tudtál olvasni :P)
Feljövőben lévő iparág, persze. És van a piacon vagy 20 játék, amely képes kihasználni, és fut az userek 5%-ánál rendesen. Ellenben a sima x86 kód minden számítógépen fut.
A fizikáról meg annyit, hogy az Ageia 1 évig próbálkozott vele, hogy a fizikára készített Physx célhardverének gyorsítóképességei elérjék a 4 ghz-s pentium4 szintjét azonos effektek mellett sebességben, amikor látták, hogy esélytelen (túl gyorsra írták meg szoftveres wrappert, és utólag már nem volt pofájuk belassítani), eladták az egészet az nvidiának. Az nvidiának volt. Annak az nvidiának, aki fpggal körömmel próbálja már a programozókat megvezetni abba az irányba, hogy számolják a fizikát is a szarjaikon, ugyanis súlyosan veszteséges negyedévet zártak, és rövidesen nem is lesz szűkség a gpu-ikra. Az nvidia tudja ezt, és most már tudjátok ti is. A grafikus gyorsító iparágnak csúnyán befellegzett. Persze nem kötelező elhinni, az utóbbi 10 évben az ilyen jellegű jóslataimnak csak a 95%-a jött be, tehát biztos most is csak hazudok :D
[ módosítva Aug.15. 16:45 ]
Szerintem a Khronos meg sem probalja igazan feltapolni az OpenGL-t. Megis minek? Mobil platformokra ott az ES, jatekfejlesztoknek ott a DX/XNA, az orvosi/CAD/stb. cuccokhoz meg boven jo a mostani OpenGL…
En csak azt nem ertem, hogy ahelyett, hogy itt szenvednek, miert nem merik felvallalni, hogy nem latnak igazan business-t mar a vanilla OpenGL-ben? :-/
En is rohadt nagyot csalodtam az OpenGL 3-ban. Ahogy egy haverom mondta: ez csak 2.2 igazabol, messze nem 3.0…. :(
SZERK: Az elobb olvastam, hogy fel even belul ki akarjak hozni a 3.1-et, amiben majd “igazi” feature-ok lesznek. A Khronos elnoke szerint ez a 3.0 release csak azert kellett, hogy megalapozzak a kesobbi, taposabb release-eket…
Lehet kovezni, de egyenlore szkeptikus vagyok…
[ módosítva Aug.16. 00:06 ]
Nekem is pont ez jutott az eszembe, hogy hivhattak volna 2.2-nek, es akkor lenyegesen kisebb lett volna a zugolodas.
Úgy hívták, aztán a marketingesek kikönyörögték, hogy 3.0 legyen..
Elvileg észhez tértek! Rájöttek, hogy az, ha az újfajta inicializáció faszságait erőltetik, rábasznak. Ha jól tudtam kivenni az nvidia szavaiból, az opengl most ilyen lett a 3.2-es verzióval:
-> sima opengl kontextus, verzió: 3.2, minden korábbi feature és az újak
-> core kontextus, verzió 3.2, csak a 3.x fő függvényei
-> compatibility kontextus, verzió 3.2, arb_compatibility ebben lehet benne
Vagyis lényegében az van, hogy van a sima opengl, ami 3.2 lett mostantól az új extekkel, illetve lett egy specifikus mód, ami arra ad lehetőséget, hogy csak a tőből támogatott hardverközeli opengl-es függvények legyenek elérhetőek, ez az opengl3.2 core mód. Van még egy deprecated mód is, ami a 3.2re építve adja a korábbi extensionokat.
Szóval, ha jól vettem ki a szavakat, akkor az opengl végre ismét életre kelhet.
Nézem, hogy augusztus 15-i a cikk – a mindenit, valaki megcsinálta az időgépet! ;) De hát ez még a tavalyi hó. Vagy inkábbb hűűű :) De még mindig jó téma.
de most aktualitasa van bery, erted, azert asodott elo megint :)
Blala, én csak örülök neki, hogy előkerült az OpenGL topic, mert szívesen olvasom ilyen témákban a véleményeket. OpenGL-t meg nem is ismerem, szóval már csak úgy tudat tagításnak (vagy módosításnak ;)) is jó.
a d3d sokkal jobb
Jól sejtettem. Az elméletem bizonyosságot nyert.
Ezt sima wglcreatecontextel kapom, meg megvannak az új ficsőrök is.
amúgy:
“Jól elbaszták, gratula. Amúgy én már fél éve eldöntöttem, hogy 4-5 éven belül áttérek a szoftveres renderelésre. “
tévedtem, jóval tovább fog tartani.
Tényleg? Miért?
Lassabban fejlődnek a procik mint ahogy arra számítottam.
Szerintem bizonyos teruleteken mar most teljesen versenykepes a szoftrender a GPU-kkal. Nemreg voltam egy cegnel, akiknek a szoftverjeben van RTRT es OpenGL renderer is, es persze az RTRT lassabb, de a legtobb esetben meg mindig interaktiv, viszont sokkal jobb minoseget eredmenyez (full GI-t tud). A raytracer sebessege elegge impressziv volt szamomra, ha jol emlekszem 4 magon futott a cucc, dehat ez nyilvan valtozni fog, hamarosan standardak lesznek a 4, 8 magos procik tehat lesz 8-16 magod egy workstationben. Arrol nem is beszelve, hogy egy 64 bites gepbe siman berakhatsz ma mondjuk 64 giga ramot, mig egy GPU-ba nehezen.
Most lehet, hogy hülyeséget mondok, de ebben a demóban szerintem szoftveres renderelés van, igaz? A gép, amin fut, egy 50MHz-es gyorsítókártyával megy, de Charlie majd kijavít, ha tévednék. Akkor miért nem elég egy 2-3GHz-es proci? Miért kell várni több, mint 5 évet?
Mert egy HD2800 15 millió polygont renderel ki 30 fps-en, egy core2duo meg 60ezret.
Jé, nincs is radeon hd2800, de remélem kb érthető mit akarok mondani :D
64 ezer polygon mindenre elég! ;)
Egyébként meg mire kell 4-5 év? Ha elég öreg scener vagy csak előveszed a 10 éves forrásaidat és kész a szoftver render ;)
A 10 éves forráskódok a mai arhitektúrák számára már nem optimálisak, mert sokat változott a processzorok belső feépítése.
(Amúgy személy szerint nekem van kész opengl alapú szoftveres rendererem :D )
[ módosítva Aug. 7. 14:46 ]
A 10 éves forráskódok a mai arhitektúrák számára már nem optimálisak, mert sokat változott a processzorok belső feépítése.
ROTFL.
Travis: Haaat, 060/66 inkabb. :) Szoval 66Mhz, sacc/kb. 110 MIPS, no L2 cache, kb. 30MB/sec RAM es 5MB/sec video savszelesseg. :) Es egy fellabas felig-szoftveres singlepipelined FPU.
Es egyebkent saccra 1-2000 poligont renderel az az engine max., es nem 60, hanem jo esetben 15-20fps-sel. De neha inkabb csak 5-tel. :) Meg azt azert ertsuk, hogy az OpenGL meg az Amiga demozas alapvetoen masrol szol. Az OpenGL-hez ugye scientific precizitas illik, az Amiga demozas meg arrol szol, hogy trukkozzuk szenne es nezzen ki kurva jol. Ennek megfeleloen az OpenGL-t hasznaljak CAD-re pl. az Amigas demok meg kurvajol neznek ki. :P
[ módosítva Aug. 7. 16:44 ]
ROTFL? Na de minek is vitatkozzak olyasvalakivel, aki a múltban él.
aki a múltban él.
ROTFL
Szép kis szókincsed van, meghajlok előtted, Mester! TANÍTS!
Mester! TANÍTS!
Próbáltuk, többen is, de reménytelen vagy.
Geri, te akarsz 386-osokra kódolni, arra meg csak jók a 10 éves források :) Egyébként meg nyilván nem tévedésből raktam kacsintást a végére :)
Bery, rossz hirem van, a 386 nem 10 eve volt, hanem 20 :) Ven faszok vagyunk :)