Egy előző bejegyzésben említettem, hogy az OpenGL függvényeit bezártam egy osztályba, ez kapcsolódik egy (render) context-hez, az egész kiegészítve pedig egy olyasmi device-t ad, erős túlzással, mint a D3D interfésze. Persze, egyre több extension függvény is bekerül a wrapperbe, amiket a device létrejöttekor inicializálok (vagy mi), így abszolút semmi különbség nincs a glBindTexture és a glMultitexCoord(..., ...) hívása között (csak példa).

Erre azért térek ki megint, mert a dolog odáig fajult, hogy a terv az, hogy egy direktívával kapcsolhatom fordításkor, hogy statikusan avagy dinamikusan akarom linkelni az OpenGL-t. Ez annyit tesz, hogy

a.) a project library-k közé felveszem az opengl32.lib-et (MSVC), és belefordul a kódba ami kell

b.) a program indulásakor, az említett device létrejöttekor betöltődik a OpenGL32.dll fájl, ahonnan ekkor kérem le a kívánt függvények belépési pontját.

Ez utóbbi előnye, hogy enged valamennyi ellenőrzést a dolog felett. Tegyük fel, hogy nincs meg a dll, 'a' esetben a program nem indul el, míg 'b' esetben ezt lekezelhetem, pl. dobhatok egy log-ot róla.

A másik előnye ennek az egésznek, hogy megismertem a dll-ek működését.

A probléma a következő:

Emberke megírja az SSE támogatást, remélvén, hogy majd de sokat gyorsít a vektor műveleteken, és az milyen jó.

Ugye ezt valós akció előtt le kell tesztelni. Mondjuk úgy, hogy:

QueryPerformanceCounter(&start);
   
for(long i=0; i<10000000; ++i)
{
    divSSE(&v1.x, &v2.x, &v3.x);
}

QueryPerformanceCounter(&stop);

Az időt meg megkapjuk: (stop - start) / queryPerfFreq. Tiszta ügy. DE! Azt kell, lássuk, hogy az SSE csodaszer nem működik, sőt sokkal lassabb mint egy:

void divNoSSE(float* a, float* b, float* c)
{
    c[0] = a[0] / b[0];
    c[1] = a[1] / b[1];
    c[2] = a[2] / b[2];
    c[3] = a[3] / b[3];
}

Az alsó kép a fontos most. Igazából a poént már le is lőttem, de azért megpróbálom megmagyarázni. No, valójában egy ilyen ciklussal nem tudjuk lemérni pontosan, hogy ez az egymillió vektor osztás mennyi időt is vesz igénybe.

for(long i=0; i<10000000; ++i)

{

    divSSE(&v1.x, &v2.x, &v3.x);

}

Ez a ciklus le fog nekünk futni tisztességesen egymilliószor,

for(long i=0; i<10000000; ++i)
{
    divNoSSE(&v1.x, &v2.x, &v3.x);
}

míg ez nem. A miértre a válasz csak annyi, hogy a fordító kioptimalizálja a kódot, és a 'divNoSSE' csak EGYSZER fog lefutni. Egyszer, azért mert látja, hogy hiába számolja ki, nem használjuk fel az eredményt. Ezért, ahogy a képen is látjuk, ez az idő nem igazán mérhető le.

Viszont, ha az alap "Maximize Speed (/O2)"-t lecseréljük (a teszt idejére) egy "Disable /Od"-re, akkor már a második ciklus is le fog futni annyiszor, ahányszor szeretnénk.

Visual C++-ban ez a Project - Properties - C/C++ - Optimization tab első beállitása.

A tévedésre a jogot fenntartom.

... ez egy saját programom, tool-om neve. A történet annyi, hogy mostanában elkezdtem foglalkozni a grafika mellett a hangokkal is, persze prog. szemszögből. A sima betöltöm és lejátszom helyett, én inkább real time akarom előállitani a különféle zajokat, esetleg zenéket. Igen, igen, demoscene.

Szóval jó lenne valami kis tool, ami megeszik egy lua fájlt, és meg is jeleniti nekem. Erre hivatott ez a tool-ocska. Egyelőre még elég sovány a tudása, de remélhetőleg változni fog. Szóval:

- lua fájl, ami a hullámok jellemzőit illeti (tehát csak reload és már látjuk is az eredményt)

- több hullámot is képes legyen megjeleníteni, színekkel megkülönböztetve

- különböző műveletek a hullámokkal

- hullám szerkesztése és export (bár ez annyira nem fontos, mivel ugye ez ugyan az mintha betöltök egy wav-ot)

Egyelőre ez a terv. Mellékelek egy képet is :

Egy időre letiltottam a kommenteket, no nem mintha annyi lett volna, csak ez a trackback-es spam teljesen kiidegelt.

Blogos társak nem szenvedtek ettől?

Itt a nyár, jött ez a kurva meleg, de már nem kell emiatt idegeskednem, áldom a légkondit!

Nem olyan régen szereztem egy ilyen kis gépet (gyengébbek kedvéért [Sony] PlayStation Portable).

Kis FW frissités után (akinek van, az érti, miért is kellett ez a lépés ), már futtattam is rajta az első psp-s programomat. (hát mit hittetek, játszani fogok rajta?)

Első lépésben (és ez volt a legmacerásabb is) be kellett lőni az egész környzetet, cygwin-estől, pspsdk-stól együtt. Utána már gyerekjáték az egész programirás rá. Amit megemlitnék, hogy pspsdk-t böngészve elég logikusnak tűnik az egész felépitése, és elég beszédes fügvénynevek vannak. Ami azért is fontos, mivel sima notepad++-ban kódolok, és azért ott nem ugrik elő az IntelliSense.

A napokban lettem kész az (alap) opengl wrapperemmel, ami lazán annyit jelent, hogy van egy osztályom, melynek minden opengl (1.1!) függvény tagfüggvénye. Ez most úgy néz ki, kis túlzással, mint a DX. Az engine render context osztályának van egy példánya ebből a wrapperből, s ezen keresztül hivogatom az ogl-es fv.-ket.

Na, kis példa, hogy miről is beszélek:

ptrCore->wfglColor3f(1.0f, 1.0f, 0.0f);

ptrCore->wfglPointSize(5.0f);

ptrCore->wfglPushMatrix();

ptrCore->wfglRotatef(rot, 0.0f, 1.0f, 0.0f);

ptrCore->wfglBegin(GL_TRIANGLES);

ptrCore->wfglVertex3f(-2.0f, 0.0f, -2.0f);

ptrCore->wfglVertex3f(2.0f, 0.0f, -2.0f);

ptrCore->wfglVertex3f(2.0f, 0.0f, 2.0f);

ptrCore->wfglEnd();

ptrCore->wfglPopMatrix();

Ez igy miért is jó? Főleg, és emiatt irtam is meg, hogy nyomon tudjam követni az ogl hivásokat, magyarul, nem tudom minden honnan össze-vissza hivogatni a függvényeket. Ez pedig jó. Egyébként még azt is piszok egyszerű lekezelni, hogy egy-egy fv. hivás után keletkezett-e belső (glGetError, vagy valami ilyesmi a neve ) hiba. Debug módban erre kapok egy MessageBox-ot, hogy ez, meg ez a gl hivás sikertelen volt.

Persze, ezzel a wrapperes megoldással arra is kényszeritem magam, hogy logikusabban tervezzem a felépitését az egész rendszernek, elvégre fontolóra kell venni, ki, mit, hogyan érhet el. Szerintem ez is jó.

Jah, igen, emlitettem, hogy ez "vanilla" opengl wrapper, ergo a kiterjesztéseket nem tartalmazza. Ezt is megoldottam :P, mégpedig úgy hogy az egész wrapper egy COGLWrapperExt osztályból származik, tehát már maga az OGLWrapper tartalmazza a kiterjesztéseket is (pl. glMultiTexCoordxx...).

Piszok sok gépelés minden függvényt (főleg az olyanokat mint a glVertexNX, ahol N=2-3-4, X=i, iv, s, sv, f, fv, d, dv, stb) leirni, de egyszer kell vele szivni.

Ha megleszek teljesen, akkor publikálni akarom az wgész wrapper osztályt, hátha másnak is jól jön majd.

Még annyit, hogy kikerült a jatekfejlesztes.hu-ra két cikkem (1, 2), melyekben a windows ablak, és az opengl render context létrehozását boncolgatom, főleg kezdőket célozva meg.

Biztos ismeritek a jelenséget, mikor egy aktiv ablaknál megnyomjuk az Alt gombot: lényegében előjön egy menü, hogy restore, move, size... Az helyzet az, hogy az F10 is ilyen gomb.

Ha pl. egy 3d-s programot irunk, akkor elég zavaró tud lenni, hogy alt is, és f10 is foglalt, sőt bezavarhat rendesen (f10-re pl. aktiváljuk a menüt, de nem jelenik meg, render viszont megáll).

Hogy az ezek által kiváltott eseményeket kikerüljük, a wndproc-ban csak le kell kezelni három esemény, névlegesen: WM_SYSKEYDOWN, WM_SYSKEYUP és a WM_SYSCHAR-t. Nem kell semmi extra kódot irni (ha nem akarjuk kezelni), csak simán:

case WM_SYSKEYDOWN:
case WM_SYSKEYUP:
case WM_SYSCHAR:
    return 0;

Öröm és boldogság, nem zavar be az alt (meg az f10) többé!

Kicsit meglepő, mert mostanában nagyon nem ment...

Biztos sokan láttatok már olyan programot, aminek nem szokványos alakja, kinézete volt. Konkrétan a formájára gondolok. Itt van pl. a bsPlayer, vagy régebben a crackelt játékok mellett volt ilyen kis ablak, ki törte fel, vagy pár demo inditóképernyője.

Szerintem magamon kivül senki sem érti, mit is magyarázok.

if(érted && kiváncsivagyahowtora) olvasstovább; else klikkazxre;

Szóval, azt szeretném megmutatni, hogyan is lehet is pofás win ablakot létrehozni.

Gondolom, a CreateWindow(Ex)-ig mindenki eljutott már. Ha már van egy működő (egyelőre átlagos) ablakunk, akkor a következő lépésként létre kell hozzunk egy "régiót", ami az ablak területét irja le.

HRGN ghRgn;

ghRgn = CreateRectRgn(0, 0, w, h);

paraméterként két koordinátát vár, x,y és x1,y1. A terület méretei.

Ezután betöltünk egy bmp képet (vagy ami akarunk), egy tömbben tárolva az rgb adatokat. Ezután nincs mit tenni, végigmegyünk a tömbbön, és ahol rgb a megfelelő értékű (értsd, ahol átlátszó a kép, ergo ha a fehér az átlátszó, akkor r = g = b = 0) ott a területünk is átlátszó:

HRGN temp = CreateRectRgn(x, y, x+1, y+1);

CombineRgn(ghRgn, ghRgn, temp, RGN_XOR);

DeleteObject(temp);

Ebben a CreateRectRgn-ben x és y ciklus számlálok, vagyis a képünk x, y paramétere. Kombinálva az eredeti (teljes) területtel végül megkapjuk a kivánt alakot:

(persze, ez a már a ciklus után van)

SetWindowRgn(ghWnd, ghRgn, true);

ghWnd az ablakunk érvényes kezelője!

A törlésnél ne feledkezzünk meg a régió törléséről sem

DeleteObject(ghRgn);

Ez a kód csak az alakot olvassa ki a bmp-ből, tehát nem fog a bmp megjelenni az ablakunkra húzva, arról magunk kell gondoskonunk (BitBlt pl.).

Ha nem képből akarunk extrém kinézeteket létrehozni, biztosit a winAPI pár függvényt, pl. kör alakú forma létrehozásához is (CreateXYRgn függvények).

Az eredmény:

Ha még valaki nem tudná, annak adok egy tanácsot: soha, khm SOHA, ne akarjon forgatni mátrixokkal.

Kis engine-em kamera kezelője még valamikor a múlt század elején került implemetálásra, működött is alapfokon. Az utóbbi időben viszon sokszor bírálta felül az én utasításaimat (nem úgy működött, ahogy én akartam ). Miért? Mert mátrixok segítségével állította elő modellnézeti mátrixot. Bizony, az a bizonyos gimbal lock. Eddig nem sokszor futottam bele ebbe a hibába, nem zavart annyira. De most nagyon. Le is cseréltem kvaterniósra (helyes igy magyarul vajon? quaternion - kvaternió?). A fájdalom megszűnk, boldog mindenki. Főleg a kamerám.

Van itt még egy ilyen "mindenkitudjacsakénnem": párszor előfordult, hogy win ablak létrehozásnál a RegisterClassEx sikeres, viszon a CreateWindow(Ex) már érvénytelen (hwnd == 0) hwnd-t ad vissza. A kód pedig jó. Már ott tartottam, hogy biztos a forditó a hülye. De nem. A történet ugyanis ott kezdődik, hogy a CreateWindow dob egy WM_CREATE üzenetet a kezelőnek. Ha ezt senki nem kezeli le, akkor jön a null hwnd. Szóval lényegtelen, hogy mi magunk, vagy a DefWindowProc kezeli-e le. Jó tudni.

Megint sikerült halálértelmeset produkálnom blog cimen...Ehh, ehh.

... de szerencsére nem saját "gyártmány". Végülis, hogy kié, az most tök mindegy, már pár napja szivatott rendesen.

A lényeg, hogy a program Debug módban egyszer csak leáll itt (xutility.h):

    __CLR_OR_THIS_CALL ~_Iterator_base()
        {    // destroy the iterator
        _Lockit _Lock(_LOCK_DEBUG);
        _Orphan_me();
        }

Na szép. Google, s meg is van a megoldás, mely szerinte ez egy bug, tudnak róla, köszönik, majd javitják. Azért közöltek egy megoldást is, tehát:

#ifdef __DEBUG
#define _HAS_ITERATOR_DEBUGGING        1
#endif

Ahogy látom, ez meg is oldotta a problémát. Irány az ágy!

Az elmúlt napokban lecseréltem a saját kis kezdetleges memory manager modulomat, egy komolyabbra. Konkrétan a Paul Nettle félére (PaulNettle.com-on megtalálható).

Viszont ekkor kezdődött a pokol. A Doom semmi ehhez képest. Első körben a project összes header fájlját (99 százalékban csak a header-be teszek include-ot, forrásfájlba csak a hozzá tartozó headert) át kellett szerkeszteni: standard headerek előre, mem manager header utána, s legvégül a saját headerek. Nagy nehezen sikerült úgy elrendezni az include-okat, hogy végre nem kaptam 500 forditási hibát egy fájlra.

Viszont ez semmi szarkodás, ahhoz képest, hogy mennyit segitett, vagy 190 memory leak maradt a program után. :S

Nem akarom elkiabálni, de most úgy tűnik, szinte egy bitnyi (hehh, van ilyen szó?:D) fel nem szabaditott memóriát nem hagy a program maga után.

Ha már itt tartunk, szeretném megemliteni, hogy: A*Z*T*A*B*Ü*D*Ö*S K*U*R*V*A*E*G*E*T a 0xfeeefeee-nek! Pusztuljon!

A cim a kis enginemre utal, ugyanis az elmúlt hetekben kapott pár újitást.

Először is végre implementáltam a pak fájl kezelést. Ha valakinek magyarázni kell, mi is ez, az biztos még nem játszott Doom-mal. Szóval, mikor több adatfájlt (textúra, modellek, hangok) egy nagyba csomagolunk.  Olyasmi mint a zip. Gondolkodtam is, hogy kapjon-e valami tömöritést is, de mivel "on the fly" töltöm be az adatokat, nem lenne szerencsés még a kitömöritéssel is bajlódni, plusz idő. Elvetve. A pak fájl struktúrája viszonylag egyszerű:

- fájl header

    - egy hat bájtos ASCII sztring, azaz a szokásos fájl azonosító ('BSTPAK' - (milyen ötletes, heh?:D))

    - egy egész tipus, ami a fájlok számát jelöli a csomagban.

- fájl adatok

- s a fájl végére egy lista, ami a fájlban tárolt adatokról ad bővebb infót:

    - fájl neve, ez a név alapján hivatkozhatunk rá (pl. 'walltexture.tga')

    - egész szám, fájl offset (franc tudja, van-e rá magyar kifejezés :S), vagyis hol KEZDŐDIK a fájl tartalma         a csomagon belül.

    - s végül a fájl mérete.

A fájl mérete végülis elhagyható, mert a média lerió lista olyan sorrendben van, amilyenben a fájlok a csomagban, vagyis könnyen ki lehetne számolni (következő offset - aktuális offset). Egyelőre hagyom igy. Azt pedig, hogy hol kezdődnek a végén a leirók, pedig úgy kapom, meg, hogy (sizeof(leiró_struktúra) * fájlok_száma_a_headerből), s a fájl végétől ennyit hajtok vissza.

(Minap újra elővettem a Doom-ot (nem, nem a 3-ast), s láttam, hogy Carmack is igy oldotta meg a WAD fájlokat: header előre, adatok középre, leirók legvégére. Nem meglepő.)

Ez igy nagyon jól hangzik (legalábbis nekem ), de ez igy még magában elég kevés. Ezért is jött létre még egy osztály, ami annyit tesz, hogy fájlokat keres. Van egy RequestFile nevű függvénye, melynek paramétere a fájl neve. Egyelőre minden elérési út nélkül kell megani neki, tehát pl. 'walltexture.tga', a visszatérési értéke pedig egy sztring, a fájl teljes útvonala az exe-hez viszonyitva. Nem tudom, hogy ez jó megoldás-e, de eddig nem ütköztem olyan dologba, ami kétsége vonná... Szóval, ez az osztály, ha fájl kérésnél nem találja a kért fájl, akkor átnézi a pak fájlokat (már ha vannak, ugye), s benne van a kért fájl, kicsomagolja, s visszaadja az elérési útvonalát.

S van még egy fontos osztály: ResourceManager. Alapból 5 féle resource van: textúra (vagy kép), mesh (modellek), material (anyagleiró xml-ek), sounds (hangok), és végül music (vagyis a zene fájlok). Ez a resource manager kezeli a fájlkéréseket, valamint törli az ideiglenes fájlokat. Ideiglenes fájlok azok, amelyek a pak fájlból lettek kicsomagolva.

Egyelőre a megoldás hátrány, hogy ha van kettő (vagy több) azonos nevű fájl (külön mappában persze), akkor lehet gubanc. De majd vigyázok.

Olvasgatva különböző fórumokat, azon gondolkodám, hogy vajon akik adják a "hozzáértőt", azok vajon tényleg többet látnak egy film tréleréből, mint mi, földi halandók, egyszerű filmrajongók?

Vagy csak azért lesznek ők profi filmkritikusok, mert széllel szembe pisálnak, direkt lefikáznak mindent?

Egyébként most nem prog.hu-ra gondoltam, nem is programozásra, hanem a szórakoztató média különböző területeire (zene, film, játékok, ésatöbbi)...

Rejtély.

Tegnap/ma bekerült ez a bizonyos npots (non power of two size - nem kettő hatvány méretű) textúra támogatás a render engine-embe. Viszont akkor néztem nagyot mikor dokumentációjában megláttam, hogy az ilyen tipusú textúrák paraméterezése nem 0..1 tartományban történik, hanem 0..width/height, vagyis 0-tól a textúra valós méretéig. Hirtelen elgondolkodtam. Vajon ebben az esetben egy opengl-lel most ismerkedő user, hogyan oldaná meg a dolgot? Alapból úgy UV-zné a modellt, hogy a texcoord-ok ebben a tartományban legyenek? Vagy végigfutna és beszorozgatná a textúra koordinátákat renderelés előtt? Hirtelen nekem is ez az utóbbi jotott eszembe, de aztán az is, hogy vertex buffer-nél ez alapból ki van lőve. Gondolkodjunk. Aha, glMatrixMode(GL_TEXTURE), glScalef(width, height, 0). Tádá! S már működik is.

Újra itthon, ugyanis tegnap ért véget a nyaralás. Volt tengerpart, sósviz, jó csajok meg minden egyéb.

A legmeglepőbb számomra az volt, hogy egy pár éve még kis semmi tengerparti "város", mára Montenegro (Petrovacról beszélünk) egyik legdárgább helyének mondható. Pár négyzetméteres telkeket milliós nagyságú (euró) összegekért vesznek meg (ahogy mesélték, orosz "businessmanek"). Bárcsak lenne egy kis telkem ott.

Próbáltam annyira nem lebarnulni, hogy valami afrikai turástának nézzenek itthon, de azért ez nem olyan könnyű a strandon.

Unalmas perceimben a telefon jegyzetfüzetébe hello world, c/c++ forráskódokat irkálatam.

Egyébként, ami még elég durva volt a nyaralásban, az az oda vezető út. Innen tőlünk (Szerbia legészakibb kis faluja:D (határmenti falu/Horgos)) le a tengerig, egy irányba kb. 700-750km között van. A gáz hogy ebből a fele csak a sima egyenes út, mikor már lejjebbleértünk, kezdődtek a hegyek, jöttek a kanyargós utak. Jobbról szikla, balról vagy 200m szakadék. :S S felváltva. Nem kis teljesitmény ott lehajtani kocsival.

Egyébként meg micsoda dolog, hogy ilyen hőségbe kell hazajönnöm?:) Lent a tengerparton nem volt ilyen kurva meleg. Borzasztó.

Indulás előtt (kb. 2 hete) elkezdtem az engine-emhez irni a pak fájl támogatást, fájl IO meg is lett belőle (vagyis a fájl IO támogatás már régen benne van/volt az engine-emben), de most valahogy nincs kedvem kódolni. Egyébként ezen gondolkodom, hogy vannak ezek a pak fájlok. Eddig ok, vannak mondjuk bináris (pl. textúrák, modellek) és sima text (script-ek, xml-ek) fájljaim. Ha ezeket egy nagy fájlként össze akarom fűzni, akkor minden fájlt beolvasok text-ként, és text-ként is irom ki őket? Ez nem világos. Asszem lépek is google barátomhoz...