Előzmények

1987-ben Major Tamás és Gábor átírta az IK+ ZX Spectrumos verzióját TVC-re. Ehhez a program képernyő kezelését, az irányító gombok működését és a hangokat kiadó részeket kellett módosítani. A feladat nehéz volt, de nem lehetetlen: néhány nap alatt megvoltak vele. A program sebessége hagyott némi kívánnivalót maga után, de ezt a kényelmetlenséget áthidalta az élmény: két játékos tudott játszani egy másik platformról áthozott játékkal, a munka színvonalát pedig emelte a képernyőn három helyen is változó grafikus mód: a pontszám kijelzés 4, a háttérkép 16, a karakterek ismét 4 színű üzemmódban voltak megjelenítve. Mindezeken felül a játék hónapokon át a magyar toplistákon szerepelt (egyszer holtversenyben a szintén Tamás által átírt Elite-tel).

IK+ TVC verzió, átirat ZX Spectrum-ról

Persze az ember mindig többet akar. Alig készült el az átirat, máris arról ábrándoztunk, mekkora dolog lenne a Commodore 64-es verziót átírni a gépre! Persze tisztában voltunk vele, hogy kis eséllyel lehetett volna egy ilyen projektet befejezni.

2

A projekt

Az álmok viszont makacs dolgok. Valamelyest eltávolodnak ugyan tőlünk, de előbb-utóbb kikényszerítik, hogy megvalósuljanak. És minél később, annál többe kerülnek. A miénk (mivel harmincöt évről beszélünk) jó sokba került. De ne vágjunk a dolgok elébe, mert a történet egész másképp indult... :)

A 2018 végén úgy döntöttem, szeretnék egy bizonyos játékot megírni TVC-re. Alig pár nappal később Bertók Zsolt (Bery) a TVC-s facebook csoportban játékfejlesztői versenyt hirdetett, aminek hatására Tamás úgy döntött, ő is beszáll a versenybe, “hivatalosan” jelezve, hogy együtt fogunk valamit készíteni. Ez azt jelentette, basic helyett egy full assembly játékot tehetünk le az asztalra, amivel nevezni (akár nyerni is) lehet.

Tamás elkezdte írni a DevTool nevű TVC-s fejlesztő rendszert (erről még lesz szó), eközben én a képernyőterveket, sprite-okat, hangokat készítettem. Mivel az animáció szerkesztő és lejátszó még készült, belefogtam egy teljesen ​másik ​játék grafikájába és pályáiba ​is​. Mikor Tamás látta ennek az állapotát (kvázi kész lett), úgy döntöttünk, hogy akkor csináljuk meg inkább azt.

Míg készült Tool, közben (pihenésképpen) más platformokról hoztam át képeket TVC-re. Ehhez egy komplett “színkonverziós-pepitázós” munkafolyamatot dolgoztam ki, amit be is mutattam a TVC csoportban és az ehhez használt “fejlesztő eszközöket” szintén közreadtam.

De az “áthozott” képek között volt egy, amit rajtam kívül még senki nem látott.

Az C64-es IK+ játékbeli képe.

Persze a színek és a felbontás miatt alaposan át kellett dolgoznom. Szétbontottam rétegekre és az eredetileg 160 pixel széles képet 128 pixelbe sűrítettem, úgy átrajzolva, hogy lehetőleg senkinek ne tűnjön fel, hogy a kép jóval keskenyebb, mint az eredeti.

Mindezek után áttoltam Tamásnak is a képet, hogy mit szól hozzá.

Nem volt nehéz kitalálni az eredményt: De jó lenne átírni ezt is! Innen még futottunk pár udvariassági kört, hogy “így-meg úgy”, de mindketten tudtuk, mostantól mi a csapásirány.

Az Interkarate Plus, C64-hez hasonló grafikával!

3

Kezdetek

Az alapállású karatékát már áthoztam TVC-re és mivel ez az egyik legnagyobb méretű sprite, ebből tettünk ki hármat és jobbra-balra mozgatva őket, a kirakó-mozgató rutint átírogatva próbáltunk minél nagyobb sebességet elérni. Több dolgot is szem előtt tartottunk: a karakterek legyenek átszínezhetők (ruha, öv, haj), lehessen tükrözni őket, maszkolhatóak legyenek, minél kevesebb helyet foglaljanak a memóriában és minél gyorsabban lehessen őket kirakni (méghozzá villogásmentesen).

A sprite-ok memóriafoglalását rögtön tudtuk felezni azzal, hogy a karaktereket az alsó nyolc színre alakítva tároltuk és a képernyőre másolás közben festettük át a kívánt színekre, kihagyva a maszkolt (lyukas) pixeleket. Emellett minden fázis tömörítve van tárolva, de erről majd később.

Tehát három sprite mozgott a képernyőn, jobbra-balra, direktben, főciklusban. Ahogy fejlődött (rövidült és gyorsult) a rutin, úgy tették meg az útjukat egyre rövidebb idő alatt. Tamás folyamatosan adta a verziókat, én pedig mértem a működési idejüket, először stopperrel, majd egy sokkal egyszerűbb és hatékonyabb módszerel: több emulátort futtattam egymás mellett, ilyen módon pedig alig egy percen belül látszott, melyik gyorsabb a másikhoz képest (hogy mennyivel, az nem volt fontos, csak hogy gyorsabb, vagy nem).

Ez a tesztelés több napon át tartott, a finomítások után javarészt gyorsabb és gyorsabb lett a rutin.

Őket mozgattuk a sebességtesztek alatt jobbra-balra

4

Render (Tamás)

A játékban a megjelenítésért egy komplett programmodul a felelős, amit általában “rendernek” hívnak “tudományos körökben”. Ez a programrész felelős a háttér letörléséért, az új kép kiszerkesztéséért illetve a képernyőre rajzolásáért. (Tehát nem csak a sprite rajzolás a feladata.)

Nagyon fontos kritérium volt, hogy a nagy sprite-ok használata ne menjen a játszhatóság rovására, azaz a program sebességét ne csökkentse túlságosan. Továbbá ragaszkodtunk hozzá, hogy a kép ne villogjon.

Az nyilvánvaló volt, hogy a játéktér újrarajzolása nem fog beleférni két megszakítás közben eltelt időbe. A megoldás: előbb rajzoljuk ki a képet a legfelső memória lapon és amikor a teljes kép ki van szerkesztve, egyetlen szubrutinnal másoljuk a képernyőre. Viszont a karatékák (és később a labdák-karatéka kombó) összességében kevesebb mint harmad annyi színes byte-ot jelent, mint a hátteret alkotó szürke byte-ok. De akkor miért másolnánk ki a video RAM-ba a teljes háttérképet?

Ennél gyorsabb megoldásra van szükség.

Minden sprite kirakása után tegyük be egy memória tömbbe a sprite köré írható téglalapot. (bal felső X, bal felső Y, szélesség, magasság). Tegyük bele utána az előző kép köré írható téglalapokat, majd ciklusban vizsgáljuk le, hogy találunk-e két olyan téglalapot, ami metszi egymást, és ha találunk ilyet, akkor vegyük e kettő téglalap köré írható téglalapot, és ezt az összevont két téglalapot vegyük ki a tömbből. És ismételjük meg ezt a folyamatot addig, amíg találunk egymást metsző téglalapokat.

Amikor az összevonás megtörtént, utána már nincs más dolgunk, mint végig menni az összevont téglalapokon és csak ezeket a téglalapokat alkotó memória területeket másoljuk a képre. Az előző fázis téglalapjait is bele kell vonni ebbe a folyamatba, hogy ha azokhoz képest az új képen elmozdulás történt, akkor íródjon felül az előző fázis területe is. Így elkerülhető, hogy a video RAM-ban “szemétként” benne maradjon az előző fázis maradéka.

A sprite kirakás sebesség optimalizációja, illetve a képernyőre részlegesen kimásolt háttérbuffer tartalom jelentős sebesség növekedést eredményez, ami igencsak kihat a játékélményre.

A fenti folyamat algoritmusának lekódolása sok időt emésztett fel, többször is újra lettek írva részei, de az eredmény - úgy gondoljuk - magáért beszél.

5

Animációk

(Misi)

Miközben a render tesztelési folyamatot végeztük, folyamatosan emeltem ki a C64-es verzióból a karakter animációs fázisokat.

Ez persze nem úgy ment ám, hogy rá lett eresztve valamilyen sprite kereső a C64 memóriájára, ami szépen kimentette nekünk a kockákat (de szép is lett volna), már csak azért sem, mert a fázisok a C64-es verzióban tömörítve vannak(!) Most lehetne azt mondani, hogy miért nem írtunk egy programot, ami a játék dekompresszorát használva kitömörít mindent szép sorjában, de mivel csak ketten voltunk, nem volt kapacitásunk ilyesmire. Maradt a favágó módszer: emulátorból mentettem le képernyőket a mozgások fázisaival.

Ilyen képekből lettek kivágva az animációs fázisok

Persze csak olyan képeket tudtunk használni, amiken a karakterek nem takarták egymást (el lehet képzelni hány mentett képből kellet ehhez válogatni miközben arra is kellett ügyelni, hogy meglévő fázisokat lehetőleg ne mentsünk ki még egyszer).

Ezekből a mentett képekből vágtam ki a mozgásfázisokat, amiket átszíneztem az alsó 8 színre, majd (hogy át lehessen látni a munkát), 8x8-as munka mátrixba rendeztem (ez táblázat a vártnál gyorsabban elfogyott, ezért nyitnom kellett egy másikat is).

Sprite-ok az alsó 8 színre átfestve (palettásítva)

6

Ezután következett a fázisok egyesével való kimentése, majd beemelésük a DevTool-ba, ahol már a tényleges animációkat fűztem össze az animátor részben. A fázisok paraméterei nem csak a képeket tartalmazták, hanem az előző fázishoz képesti x és y eltolást, a fázisok kint létének idejét, valamint a tükrözést is. Természetesen minden animációt jobbra és balra néző helyzetben is össze kellett állítani a fenti delta eltolási értékekkel.

Mindet, egyesével.

Nem csak lépés, támadás animációk vannak, hanem védekezések, sérülések, elesések is, így ezeket ki tudtuk bővíteni olyanokkal, amelyek az eredeti játékban nincsenek is. Például módunkban áll a hátraflikkelő ellenfeleket hátba-hasba, vagy az éppen ugrásuk közben levegőben lévőket földre rúgni (egy kis meglepetés a veterán IK+ harcosoknak).

Bal oldalon az animációk, jobb oldalon a kiválasztott animáció fázisai

Az editorban a mai napig minden animáció az alapállás fázissal kezdődik, de mivel ez nagy pazarlást jelentene a memóriát tekintve, a Z80 forrásba exportált adatokból ezek a fázisok ki lettek véve (természetesen utólag, kézzel).

Minden byte-ra szükségünk volt.

7

Találat ellenőrzés

A találat ellenőrzést először táblázatból akartuk megoldani, de nem volt teljesen világos a módszer, ezért Tamás úgy gondolta, kicsit komolyabbra vesszük a figurát, már-már tekken szintű vizsgálattal. Készült is rá koncept, hogyan kéne definiálni az ütő és érzékelő pontokat, de ezt elég gyorsan elvetettük, így maradt a táblázat, amit sokkal egyszerűbb és gyorsabb is volt vizsgálni.

A vízszintesen a támadó technikák, a függőlegesen a támadott fázisok, a számok az eltolási értékek)

A támadó és sérülési pontok - szerencsére kivitelezni nem kellett :)

8

AI (mesterséges intelligencia)

(Tamás)

A játék alatt az az igazi, amikor két játékos egymás ellen küzd, de még ebben az esetben is ott a harmadik karatéka, akinek azért illik tevékenyen beszállni a küzdelembe (hacsak nem akar egy “come on” intést a Mestertől). Tehát minimum egy játékost a számítógépnek kell irányítani.

Mivel a program nem átirat, ezért az AI is teljesen saját elgondolás és ötletek alapján készült.

Amikor a számítógép egy karatékát mozgatni kezd, megvizsgálja, hogy a másik két karatéka áll-e, vagy mozgásban van-e (ha igen, akkor milyenben), Ezután a találat ellenőrzési táblázat és néhány véletlen generátoron alapuló paraméter alapján kiválasztja a számára optimálisnak ítélt mozgást, és mintha csak joystickkal irányítaná a saját emberkéjét ezt a “joystick kódot” adja át a játéknak.

Először úgy volt megcsinálva a játékosok gépi mozgása, hogy a végrehajtandó karate technikában - mintegy előre gondolkodva - vegye számításba azt is, hogy amikor a technika “berobban” akkor az ellenfél melyik mozgás fázisban lesz.

Meglepetésünkre az intelligencia hatékonysága nem volt sokkal jobb, mint amikor csak az ellenfelek pillanatnyi helyzetét veszi figyelembe, ezért ezt az “előre gondolkodós” verziót elvetettük és csak a “pillanatnyi helyzetet figyelembe vevő” változatot hagytuk meg, ami harmad akkora kód méretet eredményezett.

Lehetett volna még egy-két plusz paramétert figyelembe venni az AI döntéshozásához, de ezek a későbbiekben már nem fértek be a programkódba és nem is hozott volna jelentős változatosságot a gépi játékba.

A végső döntés eredményeképp (egy véletlen faktor figyelembevételével) vagy a megtalált támadó technikát, vagy az odaillő védekezést választja a program.

Hátránya ennek a verziónak, hogy a véletlengenerátor olyan amilyen, illetve a találati táblázatban szekvenciálisan keres az algoritmus és ha talál szerinte optimális technikát, akkor nem keres tovább, hanem azt indítja el. Ennek okán történik az, hogy ha a játékos csak egy technikát használ, akkor az AI sok esetben nem tud optimálisan dönteni.

De hát melyik karatebajnok tökéletes?

9

Labdák

(Misi)

A projekt elején még nem volt biztos hogy bele kerül-e a “labdázás”. Valahol tudat alatt éreztük hogy ez nem lesz egyszerű történet (de nem gondoltuk, hogy ennyire nem).

Az eredeti játékban két küzdelem-menet után labdákat kell kivédeni (ha ezt “pihentető résznek” szánták, pont az ellenkező hatást érték el vele). Minden labdáért pontokat kapunk és ha végigcsináljuk, akkor még egy rakás pontot. Mivel a maximális játékélményre törekedtünk, sok dolgot kellett megoldani. Hol is kezdjem..?

Az egyik ilyen a labdák vágása volt (amihez Tamásnak módosítania kellett a sprite kirakót), jobbról és balról is tudni kellett vágni a képernyő szélén. A másik, hogy a lehető legfinomabb mozgást akartuk elérni, minél kevesebb, de persze minél gyorsabb kóddal. Pixelenként kellett tudni mozgatni a labdákat, de nem akartunk ​menet ​közben biteltolást használni (a sebesség miatt). Ezért minden labda fázis kétszer van meg a memóriában, egyszer a helyén, egyszer egy pixellel eltolva. Mozgás közben hol a páros, hol a páratlan pixelre eső fázist rakjuk ki.

A labdák, ahogy a memóriában vannak (az eltolt fázisokkal együtt)

A következő dolog a szinuszos, gravitációt és pattogást modellező mozgás volt. Ehhez egy negyed ciklusnyi táblázatot használtunk, amit Tamás oda-vissza játszott le (memória spórolás ismét) a függőleges tengelyen. Most nem mesélem el, mi mindenen mentünk ehhez keresztül (még az Appaloosa engine-jében készített Amiga ball-omat is előszedtem megnézni) és a menet közbeni sebesség növekedés+amplitúdó-összefüggés vitáinkat sem bontanám ki (sok órát rágódtunk ezen).

Az árnyékolt labda

A kódolás és tesztelés közben közben felmerült, hogy egyszerűsítünk C64-es kinézetű labdákra, de a magam részéről ragaszkodtam az Amigásokhoz (nagyon). Ezeket eleve nem két, hanem négy színnel rajzoltam meg, hogy a labdák alja “árnyékolva” legyen (ilyen szempontból még szebbek is vagyunk, mint az Amigás labdák). A labdák eredeti négy színe menet közben módosítva van, nyolc féle “pepita” kombinációban rajzolódnak ki.

10

Természetesen nem maradhatott ki az árnyékuk a képernyő alján (amihez egy “vágással” is kellett kiegészíteni a sprite kirakó rutint), ami fontos látványelem, emellett a visszapattanás pontját is segíti megállapítani a játékosnak.

Mikor a hangok is elkészültek, rájöttünk, hogy még egy “apróság” hiányzik a labdázás teljességéhez (amit gyorsan meg is csináltunk és alig pár perc alatt be is lőttünk): a pajzs és a labdák pattogásának folyamatosan emelkedő hangja.

A kivédendő labdák darabszámát 32-re állítottuk be (a C64-es verzióban 64db van), mert a folyamatos sebességnövekedés és a keskenyebb képernyő miatt nem lenne elég idő reagálni rájuk.

Mikor mindezzel megvoltunk, találtunk egy furcsa hibát: elméletileg minden harmadik pályán kellett volna hogy labdázzunk, ami első körben stimmelt is. Két pálya, egy labdázás. De innentől már minden küzdelem után jött egy labdás rész és ez ismétlődött, egyesével váltogatva egymást.

Látszólag egyszerű hiba volt, mégis hosszú órákba telt, mire ki tudtuk javítani.

A labdák sebességét is jól be kellett állítani

11

Pontozás, övfokozatok színei

A memóriát teletöltő adatmennyiség és a gép sebessége miatt gyorsan eldőlt, hogy nem tesszük ki a technikákért kapott pontokat a játékosok fele fölé (ahogyan egyébként a többi gépen történik).

Ehelyett inkább megcsináltuk azt, hogy az övek színe a pontszámok függvényében változzon a karaktereken (tudomásunk szerint ilyen kizárólag Amigán van), ezért a ruhák egyik “színét” (amit a program a karatékák kirakása közben átszínez), az övre használtunk el.

A memóriában tárolt és a menet közben színezett karakter

Az övek színezésén túl, a jobb felső sarokban is mindig a legmagasabb övfokozat neve van, természetesen szintén az övnek megfelelő színnel kiírva.

Eredetileg volt még plusz két övfokozat (és szín), de végül maradtunk annyinál, amennyi a többi verzióban is van.

A pontozáson viszont már változtattunk, úgy, hogy kicsit magasabb ponthatárokat állítottunk be az övfokozatok eléréséhez. Az eredetiekhez képest talán egy kicsit arányosabban is osztottuk el őket.

12

Buborékok

A Mesterrel és a mondanivalóival pont annyit dolgoztunk (és szenvedtünk), amennyit előre is gondoltunk. Ehhez először is a Mestert a karatékáktól minél messzebbre kellett kitenni, emellett a feje fölött megjelenített buborék nem lóghatott ki a képernyőről (ami a c64-esnél jóval keskenyebb és emiatt zsúfoltabb is).

Tamás több algoritmust is írt, ami a mester pozícióját igyekezett kiszámítani. Ezek között volt egyszerűbb és bonyolultabb, végül a harmadik vagy negyedik vált be annyira, hogy száz mester megjelenésből kilencven biztosan helyesen van elrendezve. Ez egyébként olyan pontos, hogy néha egyetlen pixelnyi(!) különbség dönti el, hová kerül a Mester a képen.

A szövegek mondatai indexelt szavakból (félmondatokból) tevődnek össze, ezeket táblázatokban definiáltuk. Fontos volt, hogy a mondatokban bizonyos szavak lecserélhetőek legyenek (pl. ​red/white/blue wins/out), a cserék pedig természetesen eseményvezérelten történnek meg.

Nem csak a játék, hanem a demózás alatt is jelennek meg szövegek (többféle, mint a játék alatt), ezeket egy-egy küzdelem, high scores tábla után léptetjük körbe-körbe (sokat szórakoztam azzal, hogy minél szebben tördeljem ezeket a sorokat).

A játékos észre sem veszi, de ​a buborékok mérete dinamikusan változik​. Figyelembe véve a sorok hosszát, Tamás kóddal rajzolja ki őket a Mester feje fölé, kiegészítve a Mester felé mutató nyilacskával). Erre a méretre igazított buborékra jönnek a tényleges szövegek.

Demó alatti szövegbuborék

13

Ponttáblázat

(Tamás)

Mivel a játék kifejezetten pontra megy (az övfokozatokat is eszerint osztja a program), a ponttáblázatot mindenképp meg akartunk csinálni. Több verzió elvetése után a legegyszerűbb nyert (a “kevesebb: több” elve szerint) és úgy láttuk, hogy az eredeti harminc soros listához képest elég lesz nekünk a tízes is. Négy oszlop: helyezés, név, öv, pontszám. Egyszerű, mint a faék, nem igaz? Mi is azt hittük...

Először a lista megjelenítése készült el (majdnem), de már a legelső tesztnél valami egészen furcsa dolog történt: a “helyezés” oszlop egytől-tízig való számai közé bekeveredtek más számok (még nulla is), igencsak bizarr hatást keltve. Értetlenül bámultunk ki a fejünkből (hiszen egyszerűbb kiírónk nem is lehetett volna), hogy kerülhetnek oda ​random​számok?

Kiderült, hogy a megszakítás a “bűnös”, ezért a táblázat kirakása elé betettünk egy “halt” utasítást, hogy megvárjuk a következő megszakítást. Az “összefirkálások” ugyan ritkultak, de nem szűntek meg. A hosszú-hosszú hibakeresés közben észrevettük, hogy csak a számokat rontja el a táblázat kirakó. Na de mi az, ami ​összefügg ​a szám kirakással és a megszakítással? Hát az idő kijelző! A játék közben a program méri az kumite idejét: 30 másodpercről számol vissza.

Szép lassan összeállt a kép: amikor a számokat megjelenítendő karakterekké alakítjuk, akkor egy 6 byte-os memória bufferbe tesszük le sorba a karaktereket, majd amikor kész a szám átalakítása, akkor (mint egyszerű szöveget) kitesszük a képernyőre. Szépen el is kezdtük kirakni a táblázatot.. Aztán jött egy megszakítás ami kirakta az időt (is): ami ugye szintén számokból áll, szintén ​ugyanabba ​a memória bufferbe teszi le a karaktereket - ezzel szépen felül is írva a táblázatban épp kijelezni készülő pontszám karaktereit. A megoldás az lett, hogy végül két ​különböző ​memória buffert használtunk a számok karakterekké alakításához. Az egyik bufferbe csak a megszakítás dolgozott, a másikba pedig maga a főprogram. De mire az egész működési láncot és az abból következő hibát feltártuk (és megoldottuk), hosszú órák teltek el...

Csapatunk tagjai is szerepelnek

A név beírása már nem okozott problémát: a joy fel-le állítja az aktuális karaktert az ABC-ben előre-hátra haladva, jobbra a következő karakterre lép, balra töröl, tűzgombra pedig kész, ekkor a lista előtt álló nyertes karatéka meg is hajol.

Apropó, a ​demózás közben​lista előtt álló, táblát tartó karatékáról még lesz szó!

14

Átszínezés

(Misi)

Már a tervezés korai szakaszában (tehát több, mint harminc évvel ezelőtt) úgy akartuk elkészíteni a programot, hogy a játékosok tetszőlegesen állíthassák be a karaktereik színeit (persze egy adott szín csak egy karatékán lehet), így nem csak fehér-piros-kék, hanem bármilyen (TVC palettájából származó) színű ruhában küzdhetnek. A színek léptetését három billentyű nyomogatásával lehet elérni, kizárva közben a “színazonosságot” is. Persze ezt sem ment simán, itt a billentyűkezeléssel gyűlt meg a bajunk: hol érzéketlen, hol meg túlérzékeny lett, többször újra lett írva, de végül sikerült elérni, amit akartunk.

Madarak

Tamás szívügye volt a madarak megléte és mozgása. Nem volt egyszerű összehozni, mert több dolognak is stimmelnie kellett. A magam részéről szerettem volna elkerülni a maszkolást (a kapu mögött takarni kell őket, ami gépidő), ezért olyan mozgáspályákat javasoltam, ami azt a helyet elkerüli. Aztán felmerült, hogy csak fekete madarak legyenek, így (mivel a kapu nagy része fekete) többfelé is tudnak mozogni anélkül, hogy maszkolni kelljen.

De aztán nem volt kerülőút: teljesen korrektre kell megírni, mert hol egy, hol két madárnak kell tudnia repülni, fehér és fekete színben is, lehetőleg random pontoktól-random pontig, így a takarásuk is elengedhetetlen. Tamásnak azt is meg kellett oldania, hogy pixelesen mozogjanak, ami újabb kódrészt igényelt, meg aztán volt pár bug, pl. néha a memóriába teleportáltak azok a madarak, stb. Összességében a madár-ügy ilyen módon belekerült jó két napba. Micsoda befektetés volt ez ez kétszer három pixel mozgatásába!

Demo

Teljesen nyilvánvaló, hogy a demózást nem lehetett kihagyni, ami Tamás előrelátó kódolásának hála nem volt olyan bonyolult, mint amilyennek látszik. A kék karatéka egyébként is a gép által van irányítva, ami voltaképp “joystick-szimulációval” lett megoldva, így a demó alatt a másik két karakter is ugyanezen a módon lett vezérelve (ugyanazt az intelligenciát használva a támadásokhoz).

Fejlesztés közben felmerült, hogy esetleg mindhárom karatékát ember irányítsa, de az nagyon belekavart volna a szabályrendszerbe, így ejtettük a megvalósítását.

Szerencsére, mert utólag visszatekintve nem fértünk volna be a memóriába.

15

Pause

Ez is olyan pont volt, amiben nem voltunk biztosak, hogy lesz. A memória végén jártunk (nagyon), a legkisebb lépést is meg kellett gondolnunk. Az gyorsan kikristályosodott, hogy a képernyő mérete és a TVC sebessége miatt három karatéka lesz öt helyett. Amíg Tamás írta a pause kódját, addig a C64-es verzió pause mozgási láncát néztem le és az ehhez illeszkedő animációink index számait kikeresve egyszerű szöveg táblázatba írtam őket. Ez került végül a kód-datába is (annyi előnyünk volt, hogy mindhárom karakter ugyanazt a mozgást végzi).

Apró részlet, de a “paused” feliratot is meg kellett csinálni, majd visszacserélni a “level”-re

Az eredmény olyannyira sikerült, hogy mikor az összehasonlító, promóciós videót készítettem, tökéletesen egymásra illeszkedett a mozgás (és a karakterek pozíciója) az eredeti, ZX-Spectrumos verzióval.

Idő kijelző

Az memória végének pár byte-ja az idő kijelző átszínezésére lett felhasználva. Az utolsó tíz másodperc kiírása pirossal történik (a villogtatásra már nem volt elég erőforrásunk, illetve akkor más, lényegesebb részek minőségét kellett volna csökkenteni, ami nem érte volna meg).

16

Kivételek

Bizonyos sprite-ok valós 16 színben lettek elkészítve és használva, ilyen volt például a Mester, akit TVC-n a (többi gépen való megjelenéshez képest) a lehető legszebbre akartuk csinálni. Természetesen nem hiányozhatott a lábfejének animációja sem (Tamás megtalálta a módját hogy beférjen a memóriába és maradhasson), a demózás alatt ezzel a topogással jelzi, hogy várja a küzdeni akaró játékosokat.

A C64 és TVC verzió

Van egy karakter, aki a küzdelemben semmilyen módon nem vesz részt, csak.. áll. Őt egyszerűen csak Mumusnak hívtam, mert a háttérkép után a legtöbb helyet foglalja a memóriában (leírni is szörnyű: tömörítve 420 byte!). Ő az, aki a highscores top ten tábláját tartja...

Mumus

17

Optimalizálás

Ahhoz képest, hogy a legelején több háttérképet is terveztünk betenni a játékba, nagyon gyorsan a memória végére értünk. Kénytelenek voltunk elővenni az ecetes ollót és vágni ahol csak tudtunk, hogy beleférjünk a .cas formátum és a memória keretei közé.

Első körben elvetettünk bizonyos, még le sem kódolt részeket (az esetleg már bekerült grafikával együtt). Rögtön mellőztük például a “több háttér” ötletét, maradt az eredeti. Kivettük a nadrág lecsúszás geg-et is, mert a megjelenési gyakoriságához képest túl sok helyet foglalt volna. A pók, kukac és társai amúgy sem kerültek volna bele, mivel azok hi-res animációk, amelyek a 16 színű, dupla széles pixeles módban nem mutattak volna jól.

A kézfújás volt az első animáció, ahol elkezdtünk kivételeket tenni a sprite kirakásban. Sok memóriát pancsoltunk volna el, ha ezt az animot egész alakosan tároljuk le, ehelyett csak részleteiben írtuk felül a karaktert, kisebb méretű sprite-okkal (amihez ismét a sprite kirakó lett módosítva) és mindig csak akkora méretűvel, amekkora változás történt az előző fázishoz képest (ennél spórolósabbra nehéz lett volna csinálni).

Mindezek mellé társult a simább lejátszás előnye is, mert csak akkor fújja a kezét a karakter, ha mindkét ellenfél fekszik a földön és a processzornak nem kell foglalkoznia sem az AI-val, sem az irányítással (egyik karakternél sem).

A kézfújás sprite részlet-fázisai

18

Háttér

Amire viszont nagyon ki kellett találni valamit, a háttérkép. Mivel ez foglalta a legnagyobb helyet a memóriában, kipróbáltunk valami merész, új dolgot: a színenkénti tömörítést. Az egész képet színeire bontottam és Tamás különálló képekként tömörítette le őket. Pár óra múlva beláttuk, hogy ennek hatékonysága elmaradt a byte tömörítéstől, körülbelül 300 byte-ot nyertünk vele összesen, aminél azért többre volt szükség. Csak utólag jöttünk rá, hogy voltaképp egy IFF-ILBM formátumhoz hasonlót akartunk csinálni, TVC-re!

Színre bontott rétegek (részlet)

19

A vége persze az lett, amit a legkevésbé akartam: alaposan átrajzolni a képet (hogy a byte tömörítésnek minél inkább tetsszen). Kezdtem a felhőkkel, “byte határ” felbontásra tettem át őket (ez játék alatt annyira nem zavaró, de tömörítve sokat számít), majd következett a fa lombjának teljes újrarajzolása, a part és hegyek vonalának finomítása, a kapu oszlopainak levágása. Ezeket Tamás inkább programból húzta meg.

A egész kép úgy lett összeállítva, hogy az ismétlődések kevésbé legyenek láthatók és minél jobban kihasználjuk a kompresszor lehetőségeit. Kibontva mindkét kép 6144 byte, de tömörítve sokat nyertünk a második verzión az elsőhöz képest: (4283 vs 3506 byte).

Az oszlop rajzoló kóddal és a hozzá szükséges táblázattal (ez együtt 129 byte) összesen a 648 byte volt a teljes nyereség a két tömörített verzió között!

Optimalizálatlan háttér (4283 byte)

Optimalizált háttér (3506 byte)

20

További csökkentést értünk el azzal, hogy bizonyos animációs fázisokat töröltünk és hasonlókkal helyettesítettük őket. Így a kétfelé rúgásból, ugró rúgásból, hasba rúgásból ki tudtunk venni egy-egy fázist. Gyakorlatlan szem észre sem veszi. Aztán egyszer csak oda jutottunk, hogy már nem volt mit kivenni, ​sehonnan​.

Legalábbis azt hittük.

Aztán egy napon… Kéne még 20-30 byte! - szólt Tamás. Hát persze hogy kéne, de ​honnan​? Ami memóriában volt, mindenre szükség volt, már nem volt mit ​kitörölni​. Márpedig elő kell teremteni azt a pár byte-ot, ha törik, ha szakad. És mivel kódból nem lehetett törölni semmit, nekem kell tenni valamit, kontent oldalról.

Ezért bizonyos animációs fázisokat elkezdtem a kompresszorhoz igazítani.

Hogy hogyan? Ahogy a háttérképet is: innen elvettem egy pixelt, amoda pedig betettem. A nadrág szárába plusz egy pixel, a karjából le egy pixel. Alig néhány sprite-hoz nyúltam hozzá, máris 26 byte-nál tartottunk, így meg lett Tamásnak a kellő hely.

Számítva rá, hogy további byte-mentésre szükség lesz még, egyelőre nem használtam ki az ebből fakadó összes lehetőséget. Az ember legyen óvatos, gondolkodjon előre…

Nem kellett sokáig várni. Hamarosan ismét szükség volt “néhány byte-ra” (talán a highscores táblázat következett), de már tudtam hova nyúlni, volt egy kis mozgásterünk (hogy pontosan mekkora, azt persze nem tudtuk). Ezután már nem vártam, az összes fázist átalakítottam a fenti módon, első körben 80, összesen pedig közel 200(!) byte-ot felszabadítva.

256/253 és 293/283 byte (a különbséget piros pixelek mutatják)

Mondanom sem kell, hogy minél több ilyen pixel-variációt próbáltam ki egy-egy képen, annál inkább kellett emlékezni azokra, amelyekkel addig a legtöbbet tudtam nyerni (és hogy ne csináljak olyat, amit már egyszer próbáltam).

21

Közjáték

Az utóbbi években többször is nyüstöltem Tamást, ássa elő a régi kazettáit, mentsük meg ami menthető és ki tudja, talán elfeledett kincsekre is lelhetünk közben… Aztán végre hozott nekem egy csomó anyagot (közben öcsém megajándékozott egy működőképes rádiómagnóval) és bedigitalizáltuk az összes megtalált kazettát. Többször is.

A kazettákon voltak HomeLab és TVC programok, és ezekhez mindenféle egyéb fájlok (például screen mentések, adatok, stb). Meglett többek között Tamásék egyik (még BASIC) játéka, a “Katakombák Mélyén”. Örömömben nekiálltam egy kicsit pimpelgetni (címképernyő, pályaszínesítések, HUD, stb), aztán Tamás is belenyúlt itt-ott és az egésznek a vége az lett, hogy versenyen kívül (és nagyon alaposan kitesztelve) még a nyáron ki is adtuk.

Pihenésképpen ezt is kiadtuk (versenyen kívül)

22

Aranyhíd

A háttérkép aranyhídját nyilvánvalóan nem hagyhattuk ki (az egyik fő, állandóan szem előtt lévő látványelem). Tamás felvetette hogy egyben lévő animációként játsszuk le, de számomra egyértelmű volt, hogy ez teljesen esélytelen (annyi fázis kéne hozzá, hogy ha semmi más nem lenne a memóriában csak ez, akkor sem férne be).

Ehelyett egy algoritmust javasoltam, amit aztán gyorsan meg is írt (őszintén szólva majdnem gyorsabban, mint amennyi idő alatt el tudtam neki magyarázni, mit is akarok). Aztán persze kellett még finomhangolni, de az már apróság.

Az aranyíd alap mintája

Az algoritmus egyszerű, látványos eredményű és igen takarékos. A “híd” képe egyben van a memóriában, de hogy a háttér adott sorára a híd ​melyik ​sorát másoljuk be, azt már egy táblázatból vesszük ki.

Az aranyhíd vízen lévő helyének minden sorára meg volt adva, hogy a híd képének melyik sorától melyik soráig vegyen mintát (ciklusonként haladva a táblázaton). A kirajzolás eredménye azért ​tűnik ​random hullámzásnak, mert a híd képéből való, soronkénti mintavétel ​darabszámban eltérő ​(hol három, hol négy, hol öt) és a program ezeket ping-pong módon olvasva teszi ki a táblázat rá vonatkozó sorából.

Emiatt alakul ki a rendezetlennek tűnő látvány (ami ennek ellenére mindig ugyanazt a lejátszási mintát követi).

Az algoritmussal kevert kép

Végül Tamás megfelezte az aranyhíd minta-képet és inkább kódból tükrözte meg a képernyőre kirakáskor. Ezzel is spóroltunk pár byte-ot.

23

Particle

Két hely is van a játékban, ahová particle készült: az egyik a víz felszíne, a másik az éppen megjelenő Mester körüli terület. Ráadásul minden particle sprite-ja egyben animáció is.

A Mester körüli csillogás három, oda-vissza lejátszott fázisból áll (szintén indítási eltolással).

Mester és particle

A víz csillogása egy táblázatban meghatározott területen belül, random helyre kerül kirakásra, ugyanúgy, ahogy a Mester körül is.

A víz esetében először minden animáció azonos fázisban volt indítva, ami előre várható módon nem volt túl szép (akkor sem, ha az animációk különböztek egymástól), ezért indítási offset értéket is kellett, hogy tudjon a rutin.

A fázisok grafikailag maszkolatlanok (nem lyukasak) és az összes szín használható bennük. A csillogás grafikai tömbjében négy darab, nyolc fázisból álló animáció található, amelyek mindkét irányban lejátszhatók.

A csillogási fázisok négy elnyújtott pixelnyi szélesek.

24

Zene

Kezdettől fogva kérdéses volt, lesz-e a játéknak zenéje. Felmerült, hogy csak prütty-prütty effektek lesznek és kész, hiszen a gépnek ​egyetlen ​hangcsatornája van, amin csak a hangmagasság és hangerő állítható - semmi több.

Aztán ott volt a szükséges memória kérdése… ennyi grafika és kód mellé hová férhetne be a song data (nem beszélve magáról a lejátszóról)? Na és melyik zenét írjuk meg: az Amigás, a C64-es, vagy valami saját verziót)? Milyen zeneszerkesztőt csináljunk ehhez (hiszen ki vágyik arra, hogy a forrásban, sima dw/db datában adja meg a hangokat)? Az ilyen kényelmetlen kérdések miatt a zene a legvégére maradt, “ki tudja lesz-e belőle valami, ezer fontosabb dolog van előtte amúgy is” - felkiáltással.

Így mentünk bele a novemberbe. Hat hét volt a határidő végéig.

Ekkortájt kezdtünk kísérletezni egy egyszerű lejátszóval, ami (mivel még nem volt része a játéknak) nem megszakításból, hanem, saját főciklusban futott. Világos volt, hogy két (ál)csatornánál nem lehet több (basszus+szóló), így első körben a ​mixelést ​teszteltük. Milyen gyorsan váltogassuk a csatornák között? Milyen tempóban játsszuk le a zenét? Hogy fog az egész szólni? Lesz egyáltalán értelme az egésznek?

Megelőzendő a felesleges kódolást, elővettem a SID lejátszót és kiexportáltam az IK+ zenéjének csatornáit külön wav-okba. De úgy, hogy az adott csatorna 100% hangereje mellett szólt a másik kettő is, de csak 10-10% hangerővel.

Ezekből hallás útján beírtam (tesztnek) a finálé basszus+szólóját, úgy, hogy a patternek dupla sebességgel futottak, a leütések pedig felváltva szóltak a két csatornán (mintha már TVC-n hallgatnánk, “mixelve”). Hogy minél jobban hasonlítson a leendő hangzásra, generáltam négyszög wav-okat is, ezekkel szólaltattam meg a note-okat.

A felváltva szóló note-ok

25

Már az elejétől nem hagyott nyugodni, hogy az emulátorban kiadott hang valamiért másképp szól mint a fent említett, generált négyszög jel, ezért emulátorból is mentettem ki wav-okat. Kiderült, hogy ezek hullámformája csak ​hasonlít ​a négyszögre. Hát, ha így szól a TVC hardvere, akkor a teszt zene is úgy szóljon, ahogy a TVC, ezért ezt hangot használtam a továbbiakban.

Nem éppen sima négyszög jel :)

A minél valósághűbb szimuláció kedvéért kiexportáltam wav-ba a már TVC-ül hangzó részt és grabbeltem egy videót a futó játékunkból. Összerendereltem a kettőt és csak néztem, néztem… észbe kaptam és áttoltam Tamásnak is, várva a hatást... Úh, ez marhajó, megcsináljuk!

És hogy fog mindez beférni a gépbe? Kit érdekel? Megoldjuk és kész!

Zeneszerkesztő tekintetében (több évtizedes tapasztalatunk alapján - számunkra nyilvánvalóan) az Amigás és PC-s trackerek világából indultunk ki, annyi különbséggel, hogy a mi patternjeink nem egyben, hanem ​sávonként ​lettek tárolva - ebből következően töredékére lehetett csökkenteni a patternek számát és a zene data méretét.

További (nem éppen elhanyagolható) különbség, hogy a patternjeink hosszát tetszőlegesen lehetett beállítani, amivel a két sáv teljesen függetlenedni tudott egymástól, persze nagyon ügyelni kellett arra, hogy ne csússzon szét a szinkron közöttük sem zeneileg, sem technikailag.

De amíg Tamás írta a zeneszerkesztőt, nekem foglalkoznom kellett valami mással is.

Mégpedig azzal, hogy a Protrackerben kiadott hangmagasság függ a hangszer eredeti mintavételi frekvenciájától - tehát hiába írom én meg a zenét csilli-villire, ha az el lesz transzponálódva az eredetitől. Meg kellett tehát tudni a zene eredeti hangfekvését.

26

A SID2MIDI-vel a nevéből következően MIDI-be lehet exportálni a SID zenéket (meglepő, nemde?). Így már az első leütésből tudni fogom, mi a bázishang - gondoltam én. Az export után vettem észre, hogy hoppá, tud ez .txt-be is exportálni… kettő századmásodpercenként...(!) ami jó, mert látszanak a arpeggio-k is.. és nem jó, mert az ebből keletkező .txt 23.118 sor ritkítására nincs opció exportkor.

Szóltam Tamásnak, hogy a fő leütések közül ki kellene szedni nyolc-nyolc sort egy txt fájlból. Pár perc alatt írt egy ilyen rutint. Ráfuttatta a .txt-re, majd visszaküldte. Nyugtalanító eredmény született: alig pár sor után egy csomó note is eltűnt össze-vissza. Jó, akkor hét sort vegyünk ki a leütések közül. Az sem lett jó. Legyen hat… elszórakoztunk ezzel egy darabig, akkor esett le a tantusz: Rob Hubbard (egyébként fantasztikus) SID lejátszója ​pontatlan!

Már az eredeti vason is hallható, hogy néha elcsúsznak a hangok időben egymáshoz képest (ez például a Sanxion boot zenéjében “kiválóan” hallatszik) ebből következően az exportált note-ok hangközei szintén “pontatlanok”. Így a 2.495.545 byte-os .txt teljes hosszából kénytelen voltam magam kiszedni a felesleget, manuálisan. Erre a Notepad++ makróját használtam, amivel egy mozdulattal ki tudtam törölni hét sort, és ha volt még egy sornyi csúszás, akkor azt kézzel vettem ki. Ezután átléptem a következő (valós) leütést, megint futtattam a makrót... és így tovább, minden egyes valós note után, mind a 23.118 sort átvizsgálva. Olyasmi érzés volt ez, mint mikor a Jurassic Park könyvben elkezdik végignézni a park CRAY-re írt programjának forráskódját, hogy mit kavart el Nedry benne.

Így megkaptuk a valós, nettó note-okat, ami alapján (még mindig Protrackerben) megírtam a zenét teljes, 60 patternes hosszában (nyilvánvalóan nem használhattam ki a patternezés fő lényegét, az ismétlődést). Az első csatornára a szóló, a harmadikra a basszus, a másodikra az éppen valamelyik szabad “csatornára” (majdan) beférő köztes hangok, a negyedikre egy egyszerű dob szekvencia került (csak úgy).

Közben valamennyire elkészült a DevTool zeneszerkesztője is (persze nyilván fapados módra, házi használatra).

De még mielőtt elkezdődhetett volna a tényleges, TVC-re készülő patternek beírása a saját szerkesztőnkbe, hátra volt még egy előkészítő munkafázis: Kiexportáltam a Protracker song datáját is .txt-be, amit aztán sávonként és patternenként bemásoltam egy google sheet táblázatba úgy, hogy (megfelelően megszínezve őket) már ott lehessen látni a zenei ismétlődéseket. Így kaptunk egy 60 oszlopos, 3 zenei sávos, 204 soros táblázatot, beleírva a DevTool-os note pozíciók számával (3.744), a tényleges note-okkal egyetemben (összesen 12.240 cellában).

Talán túldolgozásnak tűnhet mindez, de itt nem lehetett viccelni, a csaknem nyolc perces zenének minden egyes hangját kézben kellett tartani.

27

Részlet a pozíció-pattern-note-táblázatból

Csak ​mindezek után következett a TVC-n megszólaló zene hangjainak beírása A DevTool zene szerkesztőjébe.

A legfontosabb az volt, hogy a zene teljes hossza minél előbb legyen meg. Ezért készült egy 64 és egy 32 soros “üres” pattern is (note-ok nélkül), ezeket használtam a szinkronizálásra és placeholderként.. Először a basszus sávot írtam meg, mondhatni alfa állapotra (folyamatosan hallgattam össze a C64-es wav exporttal). Utána következett a szóló sáv. Ennek írása közben ügyelni kellett arra is, hogy a patternek hossza és a bennük lévő leütések száma minél optimálisabb legyen, adattárolás szempontjából. Tehát ​menet közben kellett a TVC-s patternek számát megállapítani és a pozíció szerkesztőbe is beleírni.

A patternek egyébként szintén (mondhatni) “tömörítve” vannak, például a leütések közötti szünetek úgy vannak tárolva hogy “szünet, x darab”.

Minden kisebb-nagyobb zenei szakaszt össze kellett hasonlítani az eredetivel, hogy a patternek egymás után stimmeljenek és az elütéseket is észrevegyem. Ez persze nem úgy ment, ahogy általában gondoljuk, hogy “play és meghallgatom”, á, dehogy! Minden egyes meghallgatáshoz ki kellett menteni a trackerünk songját, utána exportálni a clipboardra, ezt bemásolni a Z80 forráskód megfelelő helyére, lefordítani futtatható .cas-ra, betölteni az emulátorba és visszahallgatni (a fapad varázsa ugye).

Nem tudom megmondani, hány százszor csináltam meg ezeket a lépéseket, csak azt, hogy a végére teljesen kikészültem a 12Hz-es kemény arpeggio-csiripolástól, a végén minden hang kalapácsként ütötte a halló idegrendszeremet, tényleges fájdalmat okozva. De hát a tökéletességnek ára van…

Közben a lejátszó kapott egy új feature-t is: képes lett a hangerőt is állítani, így már lehetett ADSR-hez közelítő “hangszereket” összerakni (persze kézzel beírva az értékeket), amiket a hangerő-sor végétől visszafelé tetszőleges szakaszon loopolni is lehetett(!)

28

Nosza, lehetett az összes note-hoz (egyesével) hangszert is beállítani. Aztán rendbe tenni az oktávokat. Utána kitölteni a rendelkezésre álló helyeket töltelékhangokkal. Ezután optimalizálni úgy, hogy mégiscsak vegyünk ki néhány hangot, hogy jobb legyen a pattern méret-teljesítmény viszonya (minden exportáláskor kiíródott a zene hossza, ez alapján folyamatosan próbáltam csökkenteni a méretet). Végre elértük (és még kisebbre is vettük) azt a zene hosszt, mint ahová be akartuk cipőkanalazni: a tömörített háttérkép helyére.

A kezdő taktusok

A következő nagy lépés az volt, mikor a lejátszó bekerült a játék alá és megszakításból kezdett működni. Kicsit tartottunk attól, mennyi időt fog megenni a processzortól, de nem tapasztaltunk érezhető sebesség csökkenést a játékmenetben. Így következhettek a...

Hangeffektek

Az effektek szintén patternek, csak rövidebbek. Olyan hangokat próbáltam csinálni, amelyek önmagukban is több csatornásnak hatnak, mély és magas hangok vegyesen, ütések, elesések, stb., a labdák például kifejezetten gumilabdás hangzást kaptak.

Az egész lejátszót úgy írta meg Tamás, hogy mikor egy effektet ki kell adni, a zene szóló sávján játssza le őket, majd folytatja a zenét tovább, mindemellett bármikor kikapcsolható akár a zene, akár az effektek (amely növeli a játék komfort érzetét).

Hang és zene ügyben az első kapavágást 2019.11.05-én tettük meg és 19-én zártuk le.

29

Zene utántöltés

Tamásnak a következő tennivalója az volt, hogy a zenét és hangeffekeket kitegye egy külön

.cas-ba, amit a főprogram tölt be, közvetlenül azután, hogy a háttérképet kirakta a képernyőre. És oda töltse be, ahol ez a kép kompresszorozva tárolódott. Ezt meg is csinálta, remekül működött a töltés, így minden adat, a zene is a helyére került és futott minden szépen.

Legalábbis neki, floppy emulációban, .dsk-ról.

A kazettás dolgokkal én foglalkoztam. A főprogramból és a zene .cas-ból generált wav-okat egymás után másolva és betöltve nekem is ment minden, egészen addig, amíg ki nem próbáltam 2.2-es ROM-mal. Mivel ott 42.155 byte-ot ír a BASIC-re, ki kellett próbálni, ott is működik-e minden, ahogy kell.

Egy darabig ment is, épp csak a zenetöltő nem működött.. De miért is? Mert a kazettáról töltéshez a 2.2-es ROM-ban ​máshol kellett a töltőrutint meghívni (egyből beugrott egy régi emlék, hogy ebbe már a 80-as években is beleütköztünk).

Mivel Tamásnak egyéb elfoglaltsága akadt, az (esélytelenek nyugalmával) magam kezdtem megkeresni a töltési hívást a másik ROM-ban. Olyan ​nagy ​különbség csak nincs a két ROM között… Pár perc alatt meg is találtam, így Tamás másnap olyan univerzálisra lett írta a töltőt, hogy bármilyen TVC ROM-mal működjön, kazettán is.

A két ROM cím közötti eltérés a betöltés meghívásához

30

Címképernyő

És most következhetett valami egészen más (egyik vesszőparipám): a title képernyős loader. Ilyen méretű és kaliberű játéknál semmiképp sem akartam hogy kimaradjon (az eredetileg Jon Egg által készített képet már hónapokkal előbb átalakítottam TVC-re). Nyilvánvaló igény volt, hogy semmilyen töltési üzenet (searching, reading, stb.) ne látsszon rajta és hogy ​ugyanaz ​a loader .cas képes legyen floppyról és kazettáról is betölteni magát a játékot.

Tamás összedobta a képkirakót a loaderrel és áttolta nekem, hogy szórakozzak vele én, ha már annyira akarom… Így komoly programozói teljesítményt nyújtva (beleírtam kettő sort az assembly forrásba, hihi) kiegészítettem azzal, hogy letiltottam minden BASIC visszajelzést (hogy ne legyenek töltési üzenetek és a teljes képernyőt ki tudjuk használni).

Remekül működött is minden. Lemezről...

Mert kazettán valami borzalmas pokoljárás kezdődött. A képet kirakta ugyan, épp csak semmiképp nem akarta betölteni a főprogramot. Súlyos, órákon át tartó wtf-ezések és file név próbálkozások után rájöttünk, hogy nagyon ​nem mindegy​, hogy kis-, vagy nagybetűkkel van a wav fejlécében a cas neve (ez persze csak akkor derült ki, mikor kínomban visszakapcsoltam az üzeneteket és a “found:” szöveget írta ki a “reading:” helyett). Közben folyamatosan csörgött a telefonunk, utóbb kiderült, a torkos borz hívott minket, hogy adjuk már át neki ennek a szívásnak a receptjét…

31

Lezárás

Tulajdonképpen végeztünk, már csak apróságok voltak hátra. Például beilleszteni a készítők

nevét is a játékba...

A string-szeletekben tárolt szövegek közé először a civil neveink voltak beírva, de Tamás azt mondta, miért ne használjuk a fun nevünket, a Doberdo Brothers-t? Ez nagyon helyénvaló ötletnek bizonyult és az sem volt mindegy, hogy mindez kevesebb karaktert jelentett, mint a kettőnk nevei összesen. Aztán be kellett még írni a music/sound on/off és a ruhák színeinek állítását vezérlő gombokat is a Mester buborékjába, mikor demózik a játék.

A szövegek bekerültek a forrásba, csak volt egy kis probléma. Csak egy egészen “apró”. A lefordított cas hossza 42.256 byte lett. ​Eggyel ​több, mint a memóriába tölthető adatok hossza… Ha írunk egy programot, ami hosszabb mint memória hossza, a program értéke egyenlő a nullával, hiszen ez ​bármilyen ​hibát okozhat.

Próbálkoztam mindenféle variációval, de a .cas makacsul tartotta ezt a hosszt (vagy épp egy byte-tal még hosszabb lett). Mi a megoldás? Mert valaminek lennie kell…

Észrevettem, hogy a szövegtáblánkban az 1 és a 2 stringek így vannak definiálva:”1 “, “2 “. Vagyis mindkettő után van egy-egy space, hogy ne folyjanak össze az utánuk kiírt szavakkal. Meg aztán a ruha színváltást kiíró mondat egyik stringje is így nézett ki: “4 5 6 ”. Ezek a szóközök összesen három byte-ot jelentettek. Viszont mind a “2 ”, mint a “4 5 6 ” string kiírása után ​mindig ​a “keys” szó következett. Ebből jött az ötlet: a 2 és a 6 utáni szóközt kivettem, és inkább a “keys” elé tettem szóközt. Így nyertünk egy byte-ot!

Ezzel lett a cas végleges hossza a maximális 42.255 byte. A program értéke “nulláról-egyre” egyetlen space-n múlt!

Legalábbis addig, amíg ki nem vettük a többek által (jogosan) kifogásolt stop gombot, így végre nem lehetett véletlenül rányomva kilépni a játékból (ezzel is nyertünk pár byte-ot, így lett a fő

.cas hossza 42.241 byte).

32

DevTool

(Tamás)

A fejlesztés kezdetén lepróbáltam a TVCStudio-t. Akkor még nem tudta a Z80 nem publikált utasításait, különös tekintettel az index regiszterek alsó és felső regisztereinek a használatára (ixh,ixl,iyh,iyl), holott tapasztalatból tudtam, hogy ezekre nagyon nagy szükségem lesz. Eszembe jutott, hogy körülbelül tíz éve írtam már egy Z80 fordítót, ami már akkor is tudta ezeket (viszont nem volt tesztelve és igazából soha nem használtam fel).

Adta magát a lehetőség, hogy akkor ezt tegyük bele a DevTool-ba (ami a kezdetektől úgy készült, hogy minél inkább kompatibilis legyen a TVCStudio-val), bár később még módosítani kellett pár helyen, mert itt-ott akadtak fordítási hibái, illetve a játék megkövetelte, hogy az index regiszterekkel címezve struktúrákat is kezeljünk (erre találták ki ezt a címzési módot).

Ehhez tudnom kellett a struktúra minden változójának offset címét. Ezt eleinte “equ” val adtam meg, de kényelmetlen volt, ezért bevezettem az “enum” ill. a “struct” direktívát. Később ennek hatalmas előnyét láttuk.

Történt, hogy egyszer csak - ki tudja hanyadjára - elfogyott a memória. Mivel a legfelső (harmadik) lapot is RAM-ként használtuk, adta magát az ötlet: a program változóit tegyük fel a legfelső lap elejére, ahol van szabad hely. A “struct” direktívákkal felépített struktúra láncolatban elég volt a kezdő címet módosítani és máris felkerült az egész változó tömb a legfelső lapra. Több, mint 700(!) byte-ot nyertünk ezzel a .cas memória területen.

33

Promóció

(Misi)

A projekt vége felé elkezdtük a reklámozást, figyelemfelkeltést. Óvatos voltam, nem akartam, hogy túl hamar kiderüljön mit is csinálunk (bombaként akartuk robbantani), ezért formabontó módon tettem közzé részleteket. Például a címképből, a játék hátteréből csak néhány csíkot mutattam meg és olyan dolgokat, amiből nem derülhetett ki, miről van szó. Például a dokumentációból, szövegbuborékból, pontlistából is kerültek fel részletek.

Címképernyő részlet :)

Elsöprő sikerre persze nem számítottunk, de elértük hogy fejekben ott voltunk. Bár az igazsághoz az is hozzátartozik, hogy a számításunkba így is hiba csúszott: mikor a játék háttérképének egyetlen pixeloszlopát széthúztam teljes szélességűre, hát Buza Laci nem kitalálta? :)

Ki is feküdtem rögtön :)

34

Kiadás

A fentiek után a kiadást sem akartuk elaprózni. Sőt, ebből kifejezetten stratégiai előnyt akartunk kovácsolni. Ne feledjük el, hogy versenyeztünk (kőkeményen) és ez olyan pontja a játéknak, ahol szintén próbáltunk többet nyújtani a többieknél (akik talán nem is gondoltak erre a lehetőségre). Ezért olyan komplettre akartuk csinálni, amilyenre csak lehet, minél több “szolgáltatást” nyújtva a “vevőknek”. Amíg Tamás a kód egyéb részeivel foglalkozott, a “kiadást” magamra vállaltam.

A nyomtatható borító is tesztelve lett(!)

Ennek természetesen tartalmaznia kellett a .dsk és .wav fájlokat (utóbbi kazettára vehető (vagy magnó emulátorba, telefonra tölthető), ahonnan vasba betölthető). Emellé kapott egy .pdf fájlt, teljes, minden részletre kiterjedő “gyári” leírással. Készült hozzá színes, méretarányos (külső-belső) kazettaborító is, hátha valakinek kedve lesz (akár fotópapírra) kinyomtatni. Bónuszként pedig készült .stl 3D nyomtatható modell is (pici talpakkal). Ennél a modellnél egyszerre sík és 3D is a karakter, anyagától függően kézzel ki is festhető.

Nyomtatható 3d karakterek

Ahogy a gép memóriáját dugig töltöttük intelligens információval, ugyanezt műveltük a .dsk-val is: felkerült rá a .pdf dokumentáció is, így ha TVC-n elolvasni talán nem is, de fizikai lemezen (is) terjeszteni lehet vele a kézikönyvet.

35

Első helyezés

A facebookos TVC csoportban történt szavazásban elsők lettünk. Kemény munka, sok lemondás, feszültség, stressz, bizakodás, öröm. Hogy mindez megérte-e? Szerintünk igen.

A szavazás végeredménye

Olyan dolgot tettünk le az asztalra, ami világviszonylatban is komoly teljesítmény. A gépet a végletekig kihasználtuk, minden erőforrásával éltünk. Mi - a Doberdo Brothers - úgy véljük ilyen hozzáállással érdemes bármit csinálni, amit szeretünk.

36

Utóélet

Nagy örömünkre szolgált látni, hogy ​egy teljes egészében emulátoron fejlesztett játék igazi hardveren is tökéletesen fut​. Köszönetünket fejezzük ki azon fejlesztőknek, akik ezeken dolgoztak (akár éveken át), szívüket-lelküket beletéve, hogy minél inkább lemodellezzék az eredeti gépet. Ez a tökéletességre törekvő, hosszútávú gondolkodás az, ami sikerünket is lehetővé tette, meg tudtuk valósítani gyerekkori álmunkat, emellett (mellékesen) versenyt is nyertünk vele.

Az egyik legérdekesebb élményünk az volt, mikor egy görög srác gépén láttuk futni a játékunkat (amit természetesen görögül kommentált és ahogy kiejtette a nevünket, már önmagában show-elemnek éreztük).

Videó, egy messzi, messzi gépről felvéve :)

Szerénytelenségnek tűnhet, de mikor 2019 novemben (Csoki klubnapon) arra a kérdésre, hogy mit csinálunk most, azt találtam mondani ADT-nek (amit komolyan is gondoltam), hogy “a világ legjobb TVC-s programjának zenéjét csinálom”. Szerintünk az idő minket igazolt. És hogy nevezünk-e a 2020-as év játékfejlesztői versenyére? Meglátjuk. Ja! Már neveztünk! :D

37