Tegnap éjjel volt egy olyan élményem, ami keményen visszarepített kb. 2005-be, amikor még semmit sem tudtam erről az egész menedzser-dologról, hanem a kódolás volt a mindenem. (Más kérdés, hogy azóta is az maradt, de hát az ember tervez.. Na mindegy! ) Szóval anno, mikor 2005 környékén keményen dolgoztam a diplomamunkámon, etc. kedvenc témám volt a profiling, azóta szinte viszont nem foglalkoztam vele szinte egyáltalán. A válasz egyszerű: mert nem ilyesmivel dolgozom. Tudom, hogy hülyén hangzik, de bátran kijelenthetem, hogy nagyon sokszor nem üzleti érdek a performance, még az IT világban sem. Lehet WTF-elni, de így van! A dolog rém egyszerű:

– Működik? – kérdezi a megrendelő
– Igen, bár még… – kezdi a fejlesztő
– Akkor mikor kapom meg?!
– De még…
– Kész vagy nincs kész?
– … (Vigyed!)

Ugye sok embernek ismerős? Más kérdés, hogy utólag persze megy a sírás, hogy lassú a rendszer, de akkor, miután nem akarja a nulláról telepíteni az egészet, jön az, hogy atomerőművet vesz alá, patch-eket követel, új verziót rendel, stb. A fejlesztő pedig örömmel leszállítja a jó öreg munka = bevétel = pénz = boldogság képlet miatt. (Mert márpedig igen, a pénz indirekt módon, de boldogít!)

Nos, ez az IT világ bizonyos területein működik, más területeken meg nem… Ezt a legegyszerűbben akkor lehet észrevenni, mikor a telekommunikációban, webfejlesztésben vagy egyéb, erősen megrendelői igények gyors (és nem maximalista) kielégítése köré orientált területen dolgozó egyszeri fejlesztő meglátja a 64k demót és egy rövid “Eztmeghogyarákba?!” felkiáltással reagálja le. Mikor pedig valaki azt mondja, hogy profiler, debugger, runtime packer, optimizáció, akkor a fejét vakarja. Na várjunk… igen, talán az utóbbit hallotta. Az egyetemen volt valami a stringek összehasonlításával kapcsolatban, meg “a zordó-logenn” nevű misztikus cuccról is hallott. Vagy nem. Régen aki ezek nélkül élt, az nem volt programozó. Persze nem ő az, aki tehet róla. Ahogy írtam is: vannak az IT világban olyan területek, ahol az ilyesmi voodoo mágiának számít – sajnos. Ha értett is hozzá régen, hát közben már elfelejtette.

Tehát visszakanyarodva a bevezetőm elejéhez – tegnap éjszaka céges kódot profile-oztam, úri passzióból és eszembe jutott, hogy ez mennyire nem dívik újabban. A megrendelőnek minden azonnal kell, akkor is, ha félkész vacak. Ha akarná is az ember az ilyet, nem hagyják neki. Nincs idő rá! Menjen ki az a release! Na, itt döntöttem úgy, hogy azért is erről fogok cikket írni. Legyen ez az én tiltakozásom fejlesztőknek a corporate bullshit-be és a megrendelők követelődzésébe történő belefolytása ellen!

Mi az a profiling?

Meg sem próbálom kitalálni, miért így nevezték el ezt a hibakeresési technikát, biztos történelmi oka van. A lényeg, hogy ez egy olyan, opcionális lépése a fejlesztésnek, amely alapvetően nehezen felderíthető, performancia-hibák felderítésére szolgál. A profiling valahogy így illeszkedik a fejlesztési folyamatba:

• Implementáció – a kód megírása
• Fordítás és szintaxis-elemzés – a szintaxisbeli hibák megtalálása (tipikusan: pontosvessző-hiba, stb.)
• Statikus kódelemzés – egyszerűbb szemantikai hibák megtalálása (tipikusan: nem inicializált változók, létrehozott, de sosem használt változók, antipattern-ek, stb.)
• Unit-tesztelés – funkcionális tesztelés a bonyolultabb szemantikai hibák felderítésére (tipikusan: itt jövünk rá, hogy az algoritmus nem jó, a ciklus 0 helyett 1-től számol, stb.)
• Profiling – Na ez egy automatizált tesztelés, melynek célja performancia-veszteséggel járó szemantikai hibák megtalálása (tipikusan: miért ilyen lassú a render?! )
• Fix – guess what? Az előző négy lépés valamelyikében feltárt hiba javítása!

Na most, nem kell Nobel-díjasnak lenni, hogy az ember tudja: a fejlesztés márpedig iteratív folyamat. Olyat még az életben nem látott senki, hogy valaki valamit megírt és az elsőre szintaktikailag, szemantikailag és minden egyéb értelemben tökéletes volt. Ha az ember igazán alapos, akkor egy esetleges fix után újra végignyomja az előtte már sikeresen letudott lépéseket. (Hiszen a fix is hozhat be bugot!)

A profiling alapvetőleg egy tág fogalom – több fajtája van, olyan is, amit jómagam sem használtam még az életben sem!

Amire a legtöbb fejlesztő a profiling említésekor gondol, az az ún “CPU profiling“, aminek az alapfeladata az úgynevezett hotspotok megtalálása, analízise és szükség esetén kiiktatása. Meglepő módon, az ezt végző tool neve a (CPU) profiler.

Nos, mi is az a hotspot? A kód olyan része, ahol a program/algoritmus/whatever a futásidő (vélhetően indokolatlanul) nagy részét eltölti. Csak egy példa: tegyük fel, hogy van egy programunk, amelyik konfigurációs fileból olvas be valamit, ami a működéséhez kell. Tegyük fel, hogy a profiling eredményeképp felfedezzük, hogy a futásidő 30%-át a program a beszédes nevű readConfigurationFile() függvényben tölti, ami mondjuk a tetejébe a 10 perces futás alatt 500 alkalommal lett felhívva. Nos, ilyenkor felmerül a kérdés: Miért? Vajon újra és újra felolvassa a file-t? (Láthatólag igen!) Tényleg szükséges ez? Vagy csak véletlen? Tegyük fel, hogy ez a program terveink szerint csak egyszer kellene, hogy felolvassa ezt a config file-t, majd egy gyors futással befejezné a működését. Miután viszont a file-felolvasás újra és újra megtörténik, a program futásideje megnő, vagyis “lassú lesz”. Miután egy hotspotról kiderül, hogy ilyen tipikusan értelmetlen, szuboptimális része a programnak, onnantól már nem hotspot, hanem bottleneck névre hallgat (hiszen belassítja a futást, mint az ital kiöntését az üveg nyaka! ) és alapvetőleg negatívumnak tekintendő.

A CPU profiling tehát alapvetőleg nem más, mint bottleneck vadászat. Ez a cikk erre koncentrál főleg. (Egy másik fontos profiling módszer a memory profiling, amelyik bottleneck-ek helyett memorí leak-ekről szól, vagyis olyan memóriaterületekről, amelyeket a program feleslegesen foglal le, vagy tart lefoglalva annak ellenére, hogy nincs szüksége rájuk).

Hogy azért ne legyen ennyire triviális a dolog, hangsúlyozni kell, hogy nem minden hotspot automatikusan bottleneck! Egy egyszerű OpenGL-es program meglepő módon tipikusan a render() metódusban fogja tölteni az ideje nagy részét. Ilyen esetben tovább kell bontanunk a dolgot: ok, az idő 80%-át a render() metódusban töltjük. És mivel hány százalékát töltjük a render() metódusban töltött időnek? Egy jó profiler tool erre bőven ad lehetőséget, megjelenítve számunkra az ún. call hierarchy-t, ami nem más, mint egy fastruktúra, mely azt mutatja, hogy melyik metódus melyik metódust hívta (és mennyi idő telt el a meghívás és a visszatérés között!).

Itt ismét bejön két fogalom a képbe…

Az inclusive time – vagyis az az idő, amennyit egy adott metódusban a program eltöltött, beleértve minden olyan metódusban eltöltött időt, amelyet ebből a metódusból hívtunk.
Az exclusive time – értelemszerűen az előbbi ellentéte, szigorúan a metódusban eltöltött idő.

Ez utóbbit szokták “self time”-nak is hívni. A kettő elkülönítése egyébként nem teljesen egzakt dolog, mert tipikusan attól függ, hogy az adott nyelvben mi számít atomi, beépített műveletnek. Gondoljunk pl. a standard output-ra. Van nyelv, ahol alap dolog, van olyan, ahol egy függvény – vagy akár egy objektum metódusa! Ez utóbbi esetben tipikusan nem számít bele az exclusive time-ba, míg az előbbiben tipikusan igen, pont mint az elepvető vezérlési szerkezetek, az if, else, for, while, stb. Vannak profiler-ek, amik megkülönböztetik a kettőt, vannak amelyek nem – mint mondtam, nem egzakt dolog – de sejthetjük: preferált az olyan tool, amelyik igen.

Hogyan működik?

Egy profiler működése alapvetően egyszerű egy, az azt használó fejlesztő szemszögéből. Ideális esetben semmi egyebet nem kell tennünk, mint futtatni az alkalmazásunkat, majd valamilyen módon megmondani a profilernek, hogy melyik process-t figyelje. Ezután a profiler mintákat gyűjt a futó processről, majd ebből számolja ki a felismert metódusokra az inclusive és exclusive time-ot, a hívások számát, etc. Ezt az adott profiler tool terminológiájától függően általában sampling-nak vagy instrumentation-nek hívják. A végén ideális esetben a kimenet valami ilyesmi (ismét csak alkalmazásfüggő), mi pedig ámulunk…

A SlimTune .NET profiler a gyakorlatban

/folyt. köv./

Nos, nem kapcsolódik szervesen a blog témájához ez a bejegyzés, s egy szép hosszú kihagyás után nem biztos, hogy mindenki erre a témára vár, de ez valami olyasmi, amiről nem tudok nem blogolni – ráadásul, ha az OpenGL-hez nem is feltétlenül, de a játékfejlesztéshez mindenképpen van köze…

Nos, az egész úgy indult, hogy a Hardwired-et olvasgattam, ahol feltűnt egy igen körbehype-olt játék, a Wasteland 2. Sok embernek a Wasteland már nem mond semmit, hiszen az első rész valamikor a Commodore-os idők végének és DOS-os idők elejének korából származik. Akkoriban ez egy kultuszjáték volt, s sajnálatos módon nekem kimaradt. Ez már csak azért is fájdalmas, mert ezt a játékot tekintik a Fallout-széria által a köztudatba sikeresen bevonultatott poszt-apokaliptikus szerepjátékok ősatyjának. De hát ez van, szerintem 10-12 éves kis csíra lehettem akkoriban – kimaradt. Majd kipróbálom a második részt, az élményt pótolandó. Nos, a Wasteland-re nem is pazarolnék több szót, mivel a játék tervezési fázisban van. Sokkal viccesebb azonban a mögötte levő üzleti modell! Ez az, aminek láttán leesett az állam…

Létezik valahol a WWW (Wild Wild Web ) rengetegében szolidan megbújva egy website, a Kickstarter – történetesen ez áll a Wasteland 2 fejlesztése mögött. Az oldal célja baromi egyszerű: regisztrálsz egy projectet, bemutatod, hogy mit akarsz, elmondod, hogy mennyi pénz kellene hozzá, s mindenki, aki fantáziát láthat benne, adományozhat. Nincs kiadó, nincs reklámcég, kiadó, hardware-gyártó, aki szponzorál, s cserébe beleugat a projectedbe! Semmi, csak az emberi jószándék… Utópisztikusnak hangzik? Igen! Nekem legalábbis marhára annak tűnt… Aztán megláttam a Wasteland 2 adatait. Az eredeti készítők összeálltak, hogy sok-sok év elteltével megcsinálják a folytatást, csak épp egyetlen kiadó sem látott benne fantáziát. A gond az, hogy egy grandiózus projectet nem két nap lefejleszteni, s bizony szabadidejükben sosem készülnének el vele. Gondoltak tehát egy merészet, s regelték a cuccot a Kickstarter-re. Nem kisebb elvárással állítottak oda, mint azzal, hogy 900.000$ kell nekik és kb. 1.5 év. S csodák csodája, pár nappal a kiírás után kb. 1.300.000 dodonál járnak!!!

Na most, gondolkodjunk el egy kicsit… Fejlesztési költségekre ott a Kickstarter, terjesztésre ott a Steam, PR-nak ott YouTube, a Facebook, a Twitter és még egymillió más ingyenes médium. Mégis lenne esélye a garázsprojectként indult játékoknak? Nos, hölgyek-urak… úgy tűnik igen! Felejtsd el a sales-t, felejstd el a kiadót, meg a hasonló lehúzásokat! Csak legyen egy jó ötleted és légy elég kitartó!

Néhány kérdést igyekszek ezzel a posttal megválaszolni. Nem azért, mert sok kedvem van hozzá, hanem mert úgy érzem, igény van rá… A téma: hova tűnt a régi fórum, miért Facebook-accal lehet kommentelni, etc? Visszaállítom-e a régi állapotot, etc?

Nos, a válasz röviden: Biztos nem kerül már vissza a klasszikus regisztráció, se a fórum. Kicsit hosszabban, pontokba szedve:

• A FB-ra 1x regelsz öt perc alatt és utána nem kell egyesével minden blogra, site-ra, stb. regelned. Ha nem is használod aktívan a Facebook-ot, tekintheted úgy, mint egy univerzális auth provider-t, mint a .NET Passport vagy az IndaPass, etc. Ha még nem vagy FB-n, annyi idő oda is regelni, mint ide.
• Ha paranoid az ember, még mindig regelhet fake adatokkal, illetve kitöltheti akár rendes névvel, kép nélkül, stb, stb. Hacsak nem vagy celeb, politikus vagy maffiozó, kb. senkit sem fog érdekelni a neved. Főleg, miután mindenki tudja, hogy lehet akár fake is.
• A fórum engine-ből már rövidtávon is elegem volt. Nem csak azért, mert a WP megerőszakolása – nem is fejlesztették normálisan – hanem mert kb. minden WP update után darabjaira hullott szét a szerencsétlen, folyamatosan hegeszteni kellett a template-jét, hogy kinézzen valahogy, stb. Mindemellett minimális volt a kihasználtsága.
• Szintén elegem lett a botokból… Megmondom őszintén, rühellem a Captcha-t meg ilyeneket, de nincs kedvem egyesével engedélyezni a regisztrációkat, meg a kommenteket, takarítani az adatbázisból a spamet, stb. Felnőtt ember vagyok, dolgozom, hiányzik ez a ráknak.
• Nagyon sok ember a nevét, arcát adja a 9gag-en meg a hasonló vicc-oldalakon a hülyeségeihez, blogokon, portálokon a politikai-vallási nézeteihez, stb. Aki még fake adatokkal sem meri a nevét adni ahhoz, hogy mi a véleménye egy algoritmusról vagy egy OpenGL tutorialról, az valószínűleg annyira sötét alak, hogy nem is sajnálom, ha nem kommentel a blogomon. A fotelharcosokat meg trollokat amúgy sem kedveljük…
• Értem én, hogy lélekben sokan húzunk még mindig a 90-as évekhez, mikor mindenki lopott Windows alól netezett és biztonságosnak tűnt a nickneve mögé bújni (nem mintha nem lett volna már akkor is illúzió a legtöbb embernek), csak éppen 2012-t írunk és az emberek egy “OmgHax0rDud3″ névre már jobban felhúzzák a szemöldöküket, mint egy Kovács József-re. Emellett ez egy szakmai blog, ráadásul moderált is, s mint olyan, semmi illegális dolog vagy hasonló nem zajlik itt, ami miatt szükség lenne nicknevekre egyáltalán.
• Nyugaton már évek óta bevett dolog, hogy valaki a nevét adja a neten a szakmai dolgokhoz. Hogy miért? Mert egy állásinterjún még hasznodra is válhat, ha a leendő munkaadód egyszer csak a homlokára csap, s azt mondja: “Áh, emlékszem önre. Ha jól láttam, elég aktívan publikál az XY kutatási project kapcsán…” vagy épp “Láttam a projectjét a Sourceforge-on, kiváló munka!”, stb.

Azt hiszem, kifogytam az argumentumokból. A lényeg: felnőtt emberek vagyunk, a téma pedig nem kínos, stb, így nem látom értelmét, hogy extra terhet vegyek magamra… Előre is köszönöm a megértést.

Biztos a karácsony miatt, vagy valami, de egy darab visszajelzést nem kaptam az előző postra, pedig rohadtul vártam… Na mindegy Így aztán döntöttem: maradok a framework-jelleg mellett. Következő lépésként gondoltam egy merészet és…

• Kreáltam egy virtuális gépet
• Feldobtam rá egy Kubuntut (igen, lehet kövezni, de piszok egyszerű használni, s nekem más nem is kell jelen pillanatban!)
• apt-get-eltem sokat, hogy legyen mindenféle opengl-es libem, ami kell a példaprogikhoz (freeglut, etc.)
• Source-ból buildeltem Code::Blocks-ot
• Saját SVN-ből a OpenGL.Hu példaprogi forráskódokat checkout-oltam a virtuális-gépre, a Windows-os C::B project-el együtt
• Némi vooodoo-mágia és kecskegida-áldozat árán összehoztam egy olyan C::B project file-t, amiben mindkét platformhoz vannak targetek
• Hekkeltem Linux alá timeGetTime() és Sleep() függvényeket

És az eredmény:

VirtualBox + Linux + Code::Blocks + OpenGL.Hu = F. YEA!

Végezetül pár gondolat…

• Basszus, tényleg nagyot fejlődött a Code::Blocks a legutóbbi stabil release óta! Magamban már leírtam 1x, de most simán visszatértem hozzá a crossplatform móka miatt… (Persze azért felhúztam a projectbe targetnek az MSVC-t is!)
• Nagyon durva az új TortoiseSVN kliens!!!!!! Végre nincs egycsillió picike .svn könyvtár, hanem 1 db van, a project rootban!!! Ezen kívül tud még egy csomó vicces újdonságot, de számomra ez a legjobb!
• Életemben először úgy mókoltam össze-vissza desktop linux-al (server hekkelés az napi rutin, de a kde libek, stb mindig az őrületbe kergettek!), hogy minden simán ment… WTF
• Jah, és igen… a lényeg nem is annyira az volt, hogy OMG Linuxon is menjen a cucc, hanem az, hogy legyen egy viszonyítási alapom ahhoz, hogy crossplatform kódban kezdjek el gondolkodni (Windows-only helyett)

Azt hiszem, ez méltó lezárása a blogban a 2011-es évnek!

Köszönjük, 2011, BÚÉK! Jövőre, ugyanitt!

Na most jön elő az, hogy a blog, meg úgy az internet általában, egy interaktív dolog és hogy ez milyen jó… Kellene egy visszajelzés, mert leragadtam a tutorialoknál. Nem kicsit, nagyon.

Szóval, ott tartok, hogy a 12. cikket írom bőszen épp, s közben csiszolgatom a példakódot is… Aztán 1x csak azon kaptam magam, hogy az előző példaprogikból továbbhurcolt classok, amik az ablakkreálásért, kameráért, textúráért, etc. felelősek, szépen kezdik magukat egy framework-é kinőni. Na most, ahogy ez megy, a cikkek kezdenek egyre jobban olyan irányt venni, mintha arról szólnának, hogy “hogyan írjunk könnyen és gyorsan programokat MaNiAc OpenGL framework-jével?” Csak épp, az eredeti célom nem ez volt. A kérdés: rossz-e ez az irány?

Pro:

• jól elkülöníthető, hogy mi a cikk lényege és mi a “szükséges rossz”, mert classokba (és headerekbe) van szétkapva az egész és nem 1 db 50k-s source file van, mint sok neten levő példakódban
• könnyű lesz majd kidobni a fixed functiont, ha odaérek
• mikor már könyékig túrunk a shaderekben, senkit sem fog érdekelni a GL kód, csak a GLSL

Kontra:

• a lényeg sokszor (pl. kamera) el van rejtve egy classba, stb. és nem olyan egyszerű onnan kiemelni, ha valaki csak copy-pastelni akarna
• a főprogram fele már most abból áll, hogy

  #include "oglhu.h"
   
  oglhuTexture * tex;
  oglhuCamera * cam;
  .
  .
  .
  cam->....
  .
  .
  .

• Sajnos, mivel minden class-t viszek tovább, valahol a 30. cikk környékén már tele lesz a cikkhez tartozó példakód olyan dolgokkal, amik irrelevánsak az adott cikk szempontjából… bár igaz, hogy az irreleváns headert nem kell nézegetni és kész

Szóval… vélemények?

Hát, sajnos nem alakul olyan jól a szabadidőm, mint gondoltam, de azért kész lettem egy új cikkel (lásd az előző postot). Az eredeti terv az lett volna, hogy karácsonyi ajándékként hármat dobok fel egyszerre, de sajna nem jött össze… Mivel az utolsó cikkhez a példaprogi (ami már rég kész van) amúgy is karácsonyi témát kapott, gondoltam csinálok belőle egy teaser videót…

Ezzel szeretnék minden kedves olvasómnak Békés, Boldog Karácsonyt kivánni!

Előszóként megjegyzem, hogy ez a cikk (mostanra már irreleváns okok miatt) időrendben később íródott, mint jó néhány az utána következők közül, így ha valaki inkonzisztens utalásokat vagy hasonlókat találna, elnézést kérek érte. Hasonló módon előfordulhat, hogy a példakód tartalmaz olyan részeket, amelyek későbbi cikkekben kerülnek tárgyalásra. Igyekeztem ezek számát nullára redukálni, de…

A cikk témája, mint már ki lehetett találni: az OpenGL kamerakezelése. A dolog maga pofonegyszerű, de hogy ne csak vakon dobálózzunk össze-vissza mindenféle GL parancsokkal, jöjjön egy kis elmélet első körben.

Continue reading »

Péntek délután, én meg az irodában rohadok… várok egy fontos e-mailre, amit valószínűleg ma már úgy sem kapok meg, s közben egy doksit bütykölök, pedig semmi kedvem hozzá. Ittam egy energiaitalt, amitől kb. akkora a pupillám, mint egy traktorkerék, hiszen jó ideje leálltam az ilyen szintű koffeinbevitellel, s most olyan, mint egy lórúgás… Nincs kedvem azt a rohadt doksit bütykölni, így gondoltam lazítok egy picit: nosza, olvassunk valami blogot, ha már csocsózni nem lehet, mert nem ér rá senki. Aztán persze vissza doksizni… Nos, itt követtem el a hibát (?), aminek ez a blogbejegyzés a végkifejlete.

Elolvastam Humus legutóbbi bejegyzését, aminek a címe: “Rewriting from scratch? Yeah, it’s a bad idea.”. Természesen az engine-jéről ír a srác, amivel pontosan úgy járt, mint én az enyémmel… Ez persze engem is megihletett, s gondoltam leírom én is a magam kis sztoriját mások – de főleg a magam – okulására. Szóval, here we go….

• 2002 – megveszem az első hardware TnL-es kártyámat és megismerkedek az OpenGL-lel a NeHe site-nak köszönhetően
• 2003 – elkezdek dolgozni az első engine-en, aminek a neve qLight (ami a “Quake Light” – vagyis egy gagyi Q3-szerű engine) elnevezést kapja. Nagyon fapados, gyakorlatilag valami netről összevakart Q3 BSP betöltő köré épül. Kap mellé prefab-okat (ami meg az UT engine-ből származik, ha jól emlékszem és a prefabricated object rövidítése) – ezek gyakorlatilag statikus meshek, amiket be lehet dobálni a pályára, de nem részei annak. Ezzel az lett volna a célom, hogy az amúgy totál steril pályákat fel lehessen dobni változtatható környezeti elemekkel – mondjuk scriptekből. Sajnos a prefabok normális megvilágítását sosem sikerült megoldani értelmesen, hiszen nem igazán tudtam beilleszteni őket a pályák lightmapes megvilágításába, realtime megvilágításhoz és dinamikus árnyékokhoz meg kevés volt az akkori hardware. A shadow mappinghoz is hülye voltam még…
• 2004 – ekkor már teljes az nVidia-szerelem, hiszen az nVidia eddigre elég rendesen nyomja a developer supportot, amit az ATi részéről mindenki csak remél… Mindeközben én rájövök, hogy teljesen saját engine kellene, nem pedig egy tutorial kódját hekkelni szénné. Így lesz az első engine rewrite neve nLight.
• 2005 – Elkövetem az egyik legnagyobb hibámat: az engine-t elkezdem platformként látni. Kapásból audioban, hálózatban, multithreadingben gondolkodom. Temérdek időt pazarlok el erre, miközben a renderer sehogysem áll. Eddigre már megy a blog – vissza is lehet nézni, hogy mivel bohóckodtam el ennek az évnek kb. a felét. Utólag visszanézve: gyász. De sokat tanultam, szóval…. na mindegy.
• 2006 – Itt már eléggé jól eljátszadozok a shaderek gondolatával, tekintve, hogy időközben megvettem a GeForce 6600GT-met, ami akkoriban, ha jól emlékszem pont jó volt arra, hogy shadereket fejlesszek-teszteljek rajta. Sajnos a shaderekkel együtt jönnek a material, azzal együtt a material library, hiszen azt a tonna file-t kezelni kell valahogy. Ez egyenes út a VFS-hez (virtuális filerendszer) – s megint ott vagyok, ahol a part szakad: kernelt buzergálok a renderer helyett. Ennek eredménye – guess what? Egy újabb engine rewrite: i:FX néven (az iNSANE FX rövidítése). Yay…..
• 2007 – Újabb hülyeség: jön a C# mánia… Először próbálgatom az engine-t wrappelgetni p/Invoke-olgatni, stb, de persze a kisördög már meg-megjelenik: újra kellene írni. El is kezdek valamivel bohóckodni, aminek FX2 lesz a neve – Lua.NET scripting, Tao, meg ilyen finomságok. Tök jó, sokat tanulok a C#-ról és a .NET-ről közben, csak az engine nem halad. Újraírásnak ezt még nem nevezném, mert sosem lesz belőle értelmes dolog, de….
• 2008 – Az NFX éve. Ekkor kezdtünk el Georgy-val valamit, amiből később még egy Function release is lett. Ez már igazi engine volt, csak éppen baromi körülményes volt vele dolgozni. .NET és Tao alapok, ofc. készült hozzá demotool is NFX Workshop néven, ami sosem készült el teljesen. Sajnos az első és egyetlen Georgy-val közös demonk, a Narkolepsia megmutatta, hogy a túlbonyolított engine eredménye a kérdéses performance. Más szóval: NEEXT! —> Újraírás.
• 2009 – Ez volt az az év, mikor semmi értelmeset nem alkottam engine témában. Ez volt kb. az OpenGL mélypontja is szerintem, s itt jól elszórakoztam mindennel, ami 3D… Egy kis XNA, egy kis MDX, etc. Kissé nehezen dolgoztam fel az NFX kudarcát (?), illetve Georgy is elkezdett a 64k intrókkal foglalkozni PC demók helyett.
• 2010 – eXceSs. Ez lett volna az a félig-managed engine, amit az NFX hibáiból tanulva tervezek meg. C++ renderer core, körülötte C# wrapperek, toolkit, stb. Itt leragadtam olyan részleteknél, hogy hogyan share-eljem meg a logokat és a VFS-t a C# és a C++ kód között, etc. Ráadásul a P/Invoke undorító, a managed C++ meg rohadtul zsákutcának tűnik számomra… Az ötlet maga jó volt, de a megvalósítás fájdalmasan lassan haladt.
• 2011 – Ez az az év, mikor vissza akartam térni egy teljesen managed enginere, de besokalltam attól, hogy a Tao halála miatt most akkor át kellene állnom az OpenTK-ra – ami ki tudja, meddig fog létezni… És utána mire állok át? Szóval ismét egy rewrite! Teljesen GL 4 alapú és visszatértem a C++hoz. Vagyis nem… a C#-hoz… vagyis… C# és C++ és…. Lua! WTF? Hjah… vicces ötletem támadt, hogyan küszöböljem ki az eXceSs kínját a P/Invoke-al, hogyan tartsam meg a C++os renderer performance-át és flexibilitását (semmi sem flexibilisebb annál, ha nem kell wrappelned egy tonna függvényt!), de emellett legyen szexi kis C#/Windows Forms alapú GUI a content WYSIWYG szerkesztéséhez. Nos, a megoldás olyan beteg, hogy az engine-nek adta magát a Sorcery név! Ha bejön a nagy terv, majd blogolok róla…

A probléma csak az, hogy újabban nagyon sokat dolgozom és házas lettem. Jól át kell gondolnom mindent, hiszen egy rossz döntés hónapokkal tolhat el mindent… Néha azon töröm a fejem, elrontottam-e valahol valamit azzal, hogy ennyiszer újrakezdtem? Ha megálltam volna valahol, hol kellett volna? Vagy jó volt ez így?

Egy ideje törtem már a fejem, hogy videokártyát kellene cserélni, mert iszonyat kiváncsi vagyok pár OpenGL 4.x újdonságra. Hosszas keresgélés után – miközben nVidia-fan létemre már AMD kártyákon is törtem a fejem – az ASUS GTX560 DirectCU II TOP mellett kötöttem ki. Review-t itt már nem fogok írni róla, hiszen van róla elég a neten (pl. itt), de annyit már most kijelentek, hogy jó ideig nem fogom tudni kihasználni a cuccot. Egy brutális állat – és teljesen belezúgtam! Ráadásul az eddigi legdizájnosabb kis kártya, ami a kezemben volt! Jah, és hatalmas… az alaplap szélességénel nagyobb a hossza, így simán dominálja a gépházat! Nem bírtam megállni, hogy ne postoljak ki róla legalább 1-2 képet…

Dizájnos doboz...

...egy brutális kártyának!

Az egyetlen vicces dolog, amit majdnem megszívtam, az az, hogy a kártya hossza miatt nem minden alaplapba jó! Az enyémen ott, ahol a PCI-E véget ér, az összes SATA csatlakozó foglal helyet, így – ha nem találtam volna 90 fokban meghajlított csatlakozójú kábeleket – akár komoly gondban is lehettem volna. Aki ilyen karit vesz microATX-es lapba az mocskosul vigyázzon, mert ezeknél spórolnak a hellyel, s jobb eséllyel kerül valami alkatrész a kártya útjába.

Tudom, tudom, hogy nem OpenGL, etc, de ezt muszáj! Ehhez sajnos nem tudok mit kommentálni… de azt hiszem találó válasz arra, hogy miért nincs semmi kedvem játszani a manapság oly divatos class-based medices-spyos-tankos-helikopteres-katonás vackokkal.