Ezt is megértük, bár, bevallom, jópár hónapja nem igazán hittem volna el én sem, pedig magasan a legoptimistábban álltam a dologhoz :)

Miután a kirakós legtöbb része elkészült, úgy döntöttem, ideje organizálni a rendszert egyetlen központi elemmé, ami majd végül felelni fog minden grafikus megjelenítésért.

Így született meg a mi Sziduri-nk. Mivel gyanítom itt a népesség 99%-a felkapja a fejét, hogy ez mégis miért, egy lehelletnyi háttérinformáció:

Sziduri a Gilgames eposzban a föld istennője - így erősen remélem, hogy rámosolyog a motorunkra, és segít neki, hogy megjelenítsen mindent a szigeten - meg magát a szigetet is :)

Szeretnél bétateszter lenni? Görgess a cikk aljára, és megtudod, hogyan lehetnél!

Mivel úgyis belevetettem magam a munkába, ezért végeztem egy pár optimalizálást. Tehát, a motor maga több programszálon fog futni, igyekezve kihasználni a mai többmagos gépek minden előnyét:

1, fő szál: ez külön fut majd a grafmotortól, ez a rész felel majd a parancsok osztogatásáért. Érdemi munkát nem fog végezni, szóval igazi jó főnök lett belőle :) Kiadja a betöltésre a parancsokat, eldönti, mikor aktuális a táj és minden egyéb megjelenítendő adat összeszedése - és kirajzolása.

2, Sziduri főszála: ez lesz felelős a grafmotor organizálásért, erőforrás kiosztásért, modellek betöltése, adatstruktúrák létrehozása, szükség esetén eldobása, törlése, frissítés, miegymás. Vagyis a főgépész.

3, adatgyűjtő szálak: belőlük több is lesz, ezek felelnek majd azért, hogy a városhoz, modellekhez, tájhoz és minden máshoz szükséges (és látható) adatok összeszedegetése az adatstruktúrákból (jelenleg a QuadTree-kből). Rajzolást, és egyéb érdemi munkát nem végez, össz feladata annyi lesz, hogy a háttérben összeszedi az adatokat, és, ha éppen nem zajlik rajzolás, akkor áthelyezi őket a:

4, rajzoló szál: az ő egyedi feladata lesz a kapott adatok folyamatosan, akadásmentes megjelenítése. Egyik fő prioritású programrész, így (remélhetőleg) ha nagyon sok adatot kell feldolgozni, a framerate akkor sem esik drasztikusan. Bár némileg lusta lesz, és megvárja, amíg az elsődleges fő szál kiadja a parancsot, így reményeim szerint nem lesz összeakadás, és igény esetén manuálisan is lejjebb tudom majd venni a framerate-t, ha szükséges.

És egy picit a további tervekről: személy szerint nem tervezem Sziduri-t elzárni a világtól, szóval, ha készen lesz, akkor mint opensource motor elérhetővé akarom tenni, bár, mivel erősen a Survive problémáira specializált motorról lesz szó, így nem tudom, mekkora igény lesz rá, de ez nem igazán tántorít el, a lehetőséget meg szeretném adni :)

Illetve, remélem, részemről ezzel a bejegyzéssel lezárult a kizárólag technológiai bejegyzések (rendkívül) hosszú sora, és átadhatom a helyet a látványosabb, elbűvölőbb képeknek. Szóval, kitartás, közeleg a látvány.

Ja, és említettem, hogy van egy titkos verseny, aminek a győztese automatikusan jöhet bétatesztelni? :) Neeem, még nem? :) Hát, akkor sok sikert. Annyit elárulok, hogy valamit tenni kell, amit eddig még ezen az oldalon senkisem tett meg.

Igen, még ehhez kapcsolódóan: terveim szerint két-három héten belül kezdek neki a netes kódoknak, ami azt jelenti, hogy erős igény lesz a testerekre, úgyhogy, kéretik jelentkezni, akit komolyan érdekel.

Illetve, feltételnek erre a kérdésre válaszolj:

"A tesztvárosban sétálgatva belefutsz egy házba, aminek hiányzik egy fala. Mit csinálsz?"

Pár mondatban, mert annyian jelentkeztek teszternek, hogy érdekel, ezek közül valóban vannak-e olyanok, akik tudnak is kezdeni valamit valamilyen problémával. Nem programozási választ várok, hanem józan észit. Email oldalt, kommentek odalent.