*Háttér: egy középkori vártorony, odakinn sötét ég, villámok csapkodnak mindenfelé*

Kaptam pár érdeklődést, hogy mégis mi is az az octree, illetve a quadtree? (Emailt még mindig nem küldött senki, pedig ott a címünk!)

Végül beláttam, hogy egyáltalán nem egyértelmű, hogy mi is ez a két fogalom, illetve, ezzel együtt kitérek arra is (szerintem legalábbis) érdekes témára, miszerint hogyan is néz ki az optimalizálás  (bizonyos mértékig, persze, mielőtt Gizmo bántalmazna).

Tehát, elsőnek is, egy kis belátás a kulisszák mögé, vagyis hogyan jelenít meg a számítógép (vagyis a videokártya) bármiféle képet.

Elsőnek is szeretnék tájékoztatni mindenkit, hogy én sem lopom a napot, és szépen haladok. Elméletileg, ha minden jól megy, ma készen lesz a grafmotor szíve, és, reményeim szerint, sikerül 10.000 falat akadás nélkül betölteni, és használni. Ez a mai cél.

UPDATE:
A nagy tervekből természetesen nem lett sok minden. Belefutottam jópár legyőzendő akadályba, így a quadtree elkészülése, és életre hozása csúszik holnapra (remélem legalábbis, mert csak írni kell.)

Hát... ennyivel:

Ahogy tanulgatom a monádikus kódok írását, azt veszem észre, hogy a Haskell nyelv rengeteg stílust megenged. Vegyünk egy példát: van egy Graph osztályunk, amiben van két lista, illetve két egész szám, amik meghatározzák, hogy a kövektkezőnek gráfhoz adandó élnek vagy pontnak mi lesz az indexe (ami után - ugyebár - meg kell növelni ezt az értéket eggyel). (Persze ez nem a leghatékonyabb, mert pl. törlésnél keletkeznek felhasználatlan indexek is, de most a példánál erre nem lesz szükségünk.) Az első lista minden eleme egy pár, aminek az első része egy gráfpont, a második pedig egy index (egész szám). A második lista is ugyanígy néz ki, csak a párok első eleme nem gráfpont, hanem gráfél. Minden gráfpontnak van egy pozíciója, és tartalmazza az összes belőle kiinduló él sorszámát. Az élek pedig tudják magukról, hogy kik a végpontjaik (tartalmazzák az indexüket).

Hát, tutorialt nem írok, de ha valakit bővebben is érdekel, hogy mi miatt téptem a hajamat mostanában, annak megpróbálok valami magyarázatfélét összedobni. Ugye a Haskell egy tiszta funkcionális nyelv, ami azt jelenti, hogy minden függvény egyedül a bemeneti paraméterektől függ, és mástól nem. Tehát nem függ semmiféle állapottól, globális változóktól, ilyesmiktől. Persze, minden program, ami megírható C-ben, az megírható Haskellben is, de ha ennél a módszernél maradnánk, a Haskellerek kihalnának koffein-túladagolásban (én mondjuk előbb keresnék más nyelvet, mint hogy rászokjak a kávéra, de ez most részletkérdés :)).

Hát akkor ilyenkor mit lehet tenni?

rekurzió: (főnév) lásd: rekurzió

És megvan a hiba. Miután az előző bejegyzésben említett debugprinteket használva lokalizáltam a végtelen ciklus forrását, hatalmas megvilágosodásban volt részem: a terminálatlan rekurzió bizony terminálatlan marad saját maga meghívása után is. Persze, hozzá kell tegyem, hogy nem egészen vagyok tisztában még a típusosztályokkal, de nagy nehezen sikerült rájönnöm a probléma okára.

Ismét mérföldkőhöz érkeztünk, és főbb vonalakban már át is léptünk rajta.

Szeretném bejelenteni, hogy elkészült az első ház, ami már abból az adatstruktúrából épül fel, ami a későbbi várost fogja magában tartani.

Ugyan, ez a bejegyzés a naplóba valamilyen szinten jobban illene, mint ide, de végül úgy döntöttem, elég fontos, hogy a főoldalra kerüljön.

Tehát:

Miután a távolabbi, a játékhoz rendkívül szervesen nem kapcsolódó részek elkészültek (vagyis: freeflycamera illetve a post-process framework), nem tudom kerülgetni tovább a dolgot: létrehoztam a Survive! projectet, ami már valóban magát a játékot fogja tartalmazni. (És persze a hozzá tartozó rengeteg DLL fájlt.)

Ígyhát, létrejött a (egyelőre üres) keret, amit már játékkal, és nem techdemókkal fogunk feltölteni.

Így, akit érdekel, az a "Tovább" gomb alatt megláthatja a (na jó,történelminek nem történelmi) pillanatot, illetve az üres keretet.