Grassal elhatároztuk, hogy idén valami nagy durranással fogjuk meglepni a közönséget. Az ötlet már jó ideje érlelődik bennünk. Vázlatosan már a Wayang után megfogalmazódtak bennünk, de azt is tudtuk, hogy a programozói tudásom még nincs azon a szinten, hogy bele merjünk vágni.

Az azóta eltelt évek során annyi magabiztosságot szereztem, hogy úgy érzem, elég időráfordítással meg tudjuk csinálni, és ami a legfontosabb, úgy tudjuk megcsinálni, hogy azt a demoscene közösség is díjazni fogja. Legalábbis most még így gondoljuk.

A nagyszabású ötletekhez jó tervezés kell. Először az időpontot tűztük ki. A tervek szerint a 2013-as Assemblyre adjuk be, ami valamikor augusztusban lesz. Ez elég idő ad nekünk, hogy a felmerülő nehézségek esetén is tartani tudjuk az ütemtervet. (Nehézségek pedig adódtak, például új munkahelyet kellett keresni). Ennek ellenére úgy döntöttünk, hogy a minőségből nem engedünk, ezért ha nem készülünk el, akkor nem adunk ki valami félig kész művet, hogy utána Pouet.net-en csak hümmögjenek rá.

A második fontos lépés, hogy meghatározzuk, milyen eszközökkel tudunk hatékonyan dolgozni. Olyan eszközökre van szükség, amivel Grass gyorsan meg tudja tervezni a jeleneteket. Én látom, hogy miként képzeli el azokat, és hogyan kell megjeleníteni. Harmadrészt szakítani kell azzal a hagyománnyal, hogy az én tudásom limitálja a grafikát.

1. 3D szerkesztő

Kellett keresni egy olyan 3D szerkesztőt, amit tetszés szerint tudunk bővíteni saját egységekkel, Grass könnyen tudja használni, stabil. A saját szerkesztő írását rögtön elvetettük, mert nem akarjuk az életünket arra áldozni, hogy a saját fejlesztésű szerkesztőnket debuggoljuk. Épp elég lesz a demóban megkeresni a hibákat.

Próbáltam a Blender mellett kardoskodni, mert fut Linux alatt, ingyenes és Pythonnal könnyen lehet szkriptelni. A Biopunk című demónkban is használtuk, ennek ellenére Grass megvétózta. Mivel ő fogja használni, ezért nem tehettem semmit. 3D Studio volt a másik javaslatom, mert igaz, hogy Windowsos, de azt még én is tudom használni. Grass viszont a Cinema4D-t használta szinte mindenhez, tehát nekem kellett alkalmazkodni. De ha már Ciname4D-t használunk, akkor a verziószámot rögzítettem 13-ban, ugyanis már ezt is lehet Pythonban szkriptelni.

Ez viszont egy újabb akadályt gördített elém. A fejlesztést át kellett tennem Windowsra.

2. Demo motor

Ha már Windows alatt készül a tartalom, célszerű a demó motort is az alá fejleszteni, mert az elkészült tartalmakat anélkül lehet megnézni a demóban, hogy újra kellene indítani a gépet. (Virtuális gépben az OpenGL támogatásról ne beszéljünk) A másik ok, hogy Windowst használunk, hogy azt szeretnénk, ha sok emberhez eljutna az üzenet. Ezért töltjük fel YouTube-ra is a demókat.

A Cinema4D-ből tehát a jeleneteket be kell juttatni a demóba. Erre négy stratégiát gondoltam ki:

1. Metaprogramozás

Legeneráljuk a C forrásfájlt, majd lefordítjuk. Ez nekem egyszerű lenne, mert eddig is forrásfájlba voltak bedrótozva a jelenetek, csak shadereket, textúrákat, modelleket, zenét töltöttem be. Az időzítés kódból ment. Hátránya, hogy Grass gépére is fejlesztőkörnyezetet kell telepíteni. A fordítás hosszú, ha hiba van a rendszerben, akkor a felderítés és javítás hosszadalmas. (Grass ír e-mailt, én két nap múlva elolvasom, nem értem, mi a hiba, visszaírok)

2. Szkript nyelv

Generálunk egy szkript nyelvet, amit nem csak az erőforrásokat írja le, hanem programlogikát is. A demó egy általános megjelenítő alkalmazás lenne, csak egyszer kellene lefordítani, utána akár az én segítségem nélkül is mehetne a demógyártás. De azért a szkript értelmező fejlesztése idő. Habár ez lenne a legoptimálisabb megoldás, most valami egyszerűbb megoldás kellene, mert egy jó szkript nyelvet tervezni nem könnyű. Ráadásul még Windows alatt is meg kell tanulnom fejleszteni, ott is lehetnek nem várt problémák.

3. DSL

Igazából a szkript is DSL lenne, de én itt most csak leírónyelvet készítenék, nagyon szigorú szintaktikával. Az ötlet azért merült fel bennem, mert ha megnézzük a demóim forráskódját, akkor azt látjuk, hogy minden jelenetnek van egy kezdete, vége és egy paraméter (vagy több), ami ez idő alatt változik. A változás is általában lineáris. Nincs szükség komoly kalkulációkra, ráadásul a megjelenítés nagy részét shaderek végzik. Vagyis kisszámú rögzített paraméter van a CPU kódban (milyen modellt rajzoljunk ki, hogyan álljon a kamera), a GPU-ba az idő, textúrák és a vertexek mennek át, a többi kalkuláció ezeket használja fel. Erre egy leírónyelv elég. XML-t csak azért nem akarok használni, mert egyszerűbb szintaktikát szeretnék.

3. Bővítmények

A fejlesztések száma nagyobb lesz, mint a korábbi demóink esetén, mert nem csak a demó kódját kell lefejleszteni, hanem a Cinema4D-hez is kell bővítményeket írni. Első lépésben egy export plug-in kell, amivel az jelenetet DSL-é alakítjuk, de valószínű kelleni fog néhány render plug-in, ha valami egyéni látványvilágot akarunk létrehozni, és fontos, hogy ugyan az jelenjen meg a szerkesztőben, mint a demóban.

4. Kihívás faktor

Az összes demónkban volt valami, ami nekem kihívást jelentett fejlesztési oldalról. Már eddig is jó sok újítás lesz. Új operációs rendszer, támogató szoftverek, de ez még nem kimondottan kihívás. A for ciklust nem kell máshogy megírni Windows alatt sem, támogató szoftverek eddig is mindig kellettek. Már a legelső demómhoz is kellett SVG konvertáló. Valami olyan kihívás kellene, amiből később profitálhatok. Ezért úgy döntöttem C++-ban fogom megírni.

Jó, tudom, C++ a Gonosz, nincs jövője, felesleges, stb. De elég sokan használják, nem tehetem meg, hogy teljesen ignoráljam az életemből. Már eddig is kódoltam kisebb dolgokat C++-ban, de nincs elég tapasztalatom benne és nem profihoz méltó hozzáállás, hogy ignoráljunk valamit, csak azért, mert egy bizonyos programozási nyelven íródott.

Végszó

Tehát a nagy mű készítése elkezdődött, a folyamatról és a közben felmerülő problémákról és azok megoldásáról írni fogok