Varjoblogi
Aiheet
Nelicorellista autuutta | Anti-aliasoitu BOB | Extended Window Manager Hints | Erään pelin päiväkirjaa - Rendailua | Erään pelin päiväkirjaa
Nelicorellista autuutta
Published by Jani on May 15, 2009
Pakottavan tarpeen painaessa päälle hankin viimeinkin uuden tietokoneen vanhan 750MHz K7:n tilalle. Uusi kone on mallia neliytiminen 2.60GHz AMD PhenomII kahdeksalla gigatavulla RAM muistia ja neljällä teratavulla levytilaa, kaikki asetettuna siististi mustaan 4U räkkikoteloon. Uusi kone sai nimekseen bifrost, sen korvatessa vanhan ja uskollisen sotaratsuni yggdrasil'n.
Yleensä tykkään käyttää NetBSD:tä tietokoneen juoksuttajana sen nopeuden ja askeettisuuden takia. Uuteen masiinaan oli kuitenkin asennettava joko Windows tai Linux johtuen koneen pääasiallisesta käyttötarkoituksesta, 3D grafiikan renderöinnistä, NetBSD:lle ei ole olemassa tähän tarkoitukseen käyttämiäni ohjelmia. Siis Linux. Tapani mukaan omaan käyttöön hankittuun uuteen koneeseen asennan aina Linuxin kokonaan itse kääntämällä kuten olin tehnyt myös yggdrasil:n kohdalla, en siis käytä mitään valmista distribuutiota. Mielestäni valmiista distribuutioista käyttökelpoisin on kenties Debian, mutta siinäkin on omat vastemielisyytensä, muun muassa ihan liian monimutkainen ja sekava bootti prosessi, 'herkkä' paketinhallinta - siis jos kosket johonkin tiedostoon ohi paketinhallinnan dpkg kieltäytyy toimimasta, ja tietynlainen yleinen sekavuus. Mutta onneksi omassa systeemissäni ei tällaisia ongelmia ole, kaikki toimii juuri niinkuin haluan. Kernelin, glibc:n, coreutilsit jne. peruskalut joita koneen boottaamiseen tarvitaan sain käännettyä uudelle arkkitehtuurille parissa illassa, lisäkirjastojen ja muiden suht' tarpeellisten ohjelmien kääntämiseen, sellaisten joita tarvitaan jotta koneella yleensä mitään tekee meni toinen mokoma. Tähän listaan kuuluu esimerkiksi x.org, erinäinen läjä apuohjelmia ja mainittakoon vaikkapa gimp, ogle, xephem sekä iso liuta tavaraa ftp.gnu.org:sta.
Koska en omaa hienointakaan taipumusta koti-diktatuuriin enkä ole koneeni ainoa käyttäjä vaan sitä tahtoo käyttää myös aviopuolisoni, oli häntä varten asennettava jokin intuitiivinen työpöytäympäristö, harva tykästyy pelkästä itselleni niin läheiseksi muodostuneesta twm:stä ilman minkäänlaisia kuvakkeita tms. turhakkeita työpäydällä. Tätä varten kääntelin koneelle myös ihka uuden Qt4 käyttöliittymäkirjaston sekä KDE4:sen. Aikaisemmin en ollut huomannut neljän ytimen tuomaa mieletöntä nopeudenlisäystä verrattuna vanhaan 750MHz K7:aan, ja olinkin hieman pettynyt uuden koneen tietynlaiseen laiskuuteen. Mutta mutta, annas olla, Qt4:sta ja KDE:tä kääntäessä asetin make:lle parametriksi -j8, eli make käyttää kahdeksaa yhtaikaista c-kääntäjää käännösprosessissa. Vasta tämän jälkeen nelicorellisen Phenomin nopeus oikeasti näkyi: Qt4 kirjaston kääntö kaikilla lisukkeilla, kera demojen ja esimerkkien, vei kaikenkaikkiaan 24 minuuttia ja 18 sekuntia, kun se vanhalla koneellani kesti vähintäänkin kahdeksan tuntia. Lisäksi koko KDE4 työpöytäympäristön kääntö oli ohi kaikkine säätöineen vajaassa neljässä tunnissa, kun vanhalla koneella siihen olisi pitänyt varata aikaa ainakin viikko. CPU:n Lämpötilat nousivat Qt:n ja KDE:n käännön aikana muutaman asteen, ennen käännön aloittamista lämpötila oli 41C ja käännön loputtua 51C. Varsinaiseen työhön, eli 3D renderöintiin en ole konetta vielä saanut valjastettua johtuen kunnollisen näytönohjaimen puutteesta, väliaikaisessa käytössä oleva emolevylle integroitu joku ATI/AMD:n malli ei toimi OpenGL:n kanssa hyvin, ollen siten käyttökelvoton. Mutta virittely jatkuu uuden näytönohjaimen myötä, kiikarissa onkin jo GeForce 260GTX, ja kenties hankintalistalle päätyy vielä digitv korttikin jolloin konetta voisi käyttää myös TV ohjelmien tallentamiseen. Toivottavasti tällä kokoonpanolla pärjätään taas reilut viisi vuotta, koneen vaihto on kuitenkin aina oma rasittava hommansa. Mutta nyt onnellisesti takanapäin.
Jos haluat tutustua tekemiini yksinkertaisiin ja toimiviin boottiskripteihin, lataa paketti alta. Huomaa, että skriptit eivät ole tarkoitettu vasta-alkajalle, varsinkin jos suunnittelet omien bootti scriptiesi korvaamista näillä, muista että saat koneesi helposti boottaamattomaan tilaan. Älä edes yritä muuttaa boottiskriptejä tai bootti proseduuria ellet ole aivan varma mitä olet tekemässä.
Anti-aliasoitu BOB
Published by Jani on November 14, 2008
Jälleen perjantainen väsymys kiireisen viikon jälkeen. Kaupungille olen liian väsynyt, ja muutenkaan sää ei juuri ulos houkuttele, joten vietän tämän perjantain sohvalla läppäriä nakutellen. Olen hieman yllättynyt itsestäni että jaksan koodintäyteisen viikon jälkeen vielä miettiä grafiikkarutiininen optimointikikkoja, ja varsinkin kirjoitella yleisölle aikaisemmin tekemästäni, anti-aliasoidun bobin blittaamisesta framebufferiin.
Siis, anti-aliasoitu bob. Bob tulee sanasta Blitter OBject, jota kai nykyään nimitetään spriteksi. Itse olen oppinut bob termin Amiga-ajalta, Amigalla oli tapana käyttää emolevylle integroitua blitteriä grafiikan kopioimiseen paikasta toiseen, spritet Amigalla taas olivat ikäänkuin grafiikan päällä leijuvia, max. 16 pikselin levyisiä itsenäisiä grafiikkaobjekteja, esimerkiksi hiiren osoitin on Amigassa raudalla toteutettu sprite eikä siten osa framebufferia. No, se historiasta, käytän tässä kuitenkin termiä bob, vanhalle koirallehan on turha opettaa uusia kujeita. Itse asiassa bobikin on terminä hieman virheellinen, koska käsittelen tässä grafiikan kopioimista ja objektin käsittelyä framebufferissa prosessorilla, grafiikkaa ei siis kopioida blitterillä, eli näytönohjaimen kiihdytinpiirillä, vaan käyttäen prosessorin aritmetiikkakäskyjä.
Yleispätevä formaatti PC koneiden framebufferin kanssa puljaamiseen on BMP, joka 54 tavua pitkän headerin jälkeen on suoraan framebufferkäypää tavaraa, kuvan voi siis kopioida sellaisenaan framebufferiin. Muistathan että jotkut ohjelmat 'avuliaasti' kääntävät BMP kuvan ylösalaisin (esimerkiksi GIMP tekee näin), eli tällöin kuva tulee kääntää ylösalaisin ennen tallennusta jotta kuva olisi sitten framebufferissa oikeinpäin. Itse käytän 24 bittistä taustakuvaa 24 tai 32 bittisessä framebufferissa, riippuen X ruudun syvyydestä. X ruudun syvyyden sekä muuta hyödyllistä infoa ruudusta voi lukea XGetWindowAttributes funktiolla:
{
Display *newDisplay;
Window newWindow;
XWindowAttributes winAttrs;
if(!XGetWindowAttributes(newDisplay, newWindow, &winAttrs)) {
// virhe -> plan B
}
w = winAttrs.width; // ruudun leveys
h = winAttrs.height; // ruudun korkeus
d = winAttrs.depth; // ruudun syvyys
}
Myös bobit tallennan 24 bitin syvyyttä käyttäen, ja konvertoin ne 32 bittisiksi siten, että ylimääräinen tavu (bitit 24-31) varataan ns. anti-alias maskille. Tätä ylimääräistä tavua voidaan käyttää tällaiseen tarkoitukseen, koska bobin ruudulle kopioimisvaiheessa huomioidaan vain ensimmäiset kolme tavua, R(ed), G(reen) ja B(lue) (bitit 0-23). Viimeiseen, anti-aliasmaskitavuun muodostetaan bobin ääriviiva. Ääriviivan piirtämiseen anti-aliasmaskitavuun olen tehnyt tarkoitukseen sopivan apuohjelman, jota en jaa tässä sen koon takia, mutta sen saa kyllä vapaasti käyttöön lähdekoodeineen minulta pyytämällä. Kuva selventänee kenties sekavahkoa ääriviiva-asiaa, vasemmalla bobin grafiikkadata (bitit 0-23) ja oikealla ääriviiva (bitit 24-31):
Sitten ajallaan kun bobi on tarkoitus kopioida framebufferiin näkyviin, kopioidaan RGB tavut (siis ne kolme ensimmäistä jotka sisältävät grafiikkadataa) normaalisti ruudulle, taustan päälle. En käsittele tässä varsinaista grafiikan kopiointia, backplane restoring, doublebuffering yms. tekniikoita, koska oman kopiointirutiinin tekeminen on hyvin yksinkertaista.
Bobin anti-aliasoimiseen tarvitaan tuota aikaisemmin luotua bobin ääriviivaa. Homman juju on käydä anti-aliasmaski läpi piste pisteeltä, ja jos maski ei jonkin pisteen kohdalla ole tyhjä, eli siinä on ääriviivaa, tehdään tämän pikselin kohdalle 4+1 tai 8+1 blur. Siis käytännössä sulautetaan/häivytetään bobin ääriviiva taustaan. Esimerkki 60 pikseliä leveästä merirosvolaivasta, vasemmalla ilman anti-aliasointia ja oikella anti-aliasoinnin kanssa:
Blur menetelmähän on hyvin yksinkertainen, blurrattavan pikselin + sitä ympäröivien pikselien RGB arvot lasketaan yhteen ja jaetaan ympäröivien pikselien määrällä + 1 (siis keskiarvo) joka on blurrattavan pikselin uusi väriarvo. Kuvassa on 8+1 blur, sininen väri kuvastaa taustaa, punainen bobia sekä harmaa blurrattavaa pikseliä. Pikselit 1-9 ovat lähdepikselit, siis ne joiden väriarvoista lasketaan keskiarvo, ja tämä keskiarvo on sitten pikselin 9 uusi väriarvo:
4+1 blur menetelmässä lähdepikseleitä olisivat 2, 4, 5, 7 ja 9. 8+1 menetelmä on kuitenkin näyttävämpi ja suositeltavampi käyttää. HC optimoija voi pudottaa pois vaikkapa pikselin 8, jolloin lähdepikseleitä on kahdeksan - tällöin keskiarvon laskemisessa tarvittava jakolasku voidaan tehdä suoraan bitin siirrolla (>>3), joka on paljon nopeampi toimenpide kuin 'oikea' jakolasku. Tämä pseudokoodi selventänee ideaa:
{
for(i = 0; i < bob_height; i++) {
for(j = 0; j < bob_width; j++) {
if(bob_aa_mask[x, y] == 0) {
// ääriviivaa ei ole tälle pikselille, seuraava
continue;
}
unsigned int newR = 0;
unsigned int newG = 0;
unsigned int newB = 0;
// tämä toistetaan kaikille kahdeksalle lähdepikselille
newR += (unsigned char) frame_buffer[x, y];
newG += (unsigned char) frame_buffer[x, y + 1];
newB += (unsigned char) frame_buffer[x, y + 2];
// jaetaan rgb komponentit kahdeksalla
newR >>= 3;
newG >>= 3;
newB >>= 3;
// asetetaan blurratun pikselin uusi väriarvo
frame_buffer[x, y] = newR;
frame_buffer[x, y + 1] = newG;
frame_buffer[x, y + 2] = newB;
}
}
}
Jahka jaksan ja kerkeän, jatkan juttua bobien läpinäkyvyydestä ja -kuultavuudesta blittauksessa - siis kopioinnissa prosessorilla framebufferiin - ilman alpha channelia, blitteriä ja turhia kirjastoja ja rajapintoja. Siihen asti hyvää talven odotusta!
Extended Window Manager Hints
Published by Jani on August 30, 2008
Perjantai, Murphy's stout, Tiamatin Clouds ja näppis. Tämän perjantaisen alkuillan aion viettää kotosalla yksin suurenmoisesta irkkubissestä, vanhasta hevistä ja koodauksesta nauttien. Tämän illan ohjelmassa, siis koodauksen osalta on tehdä yksikertainen X ohjelma, joka näyttää prosessoriajan kulutuksen prosentteina. Ei muuta. Lisäksi ohjelma on tarkoitus saada 'liimattua' työpöytään siten, että sitä ei erota omaksi ohjelmakseen, vaan se ikäänkuin kuuluu kalustukseen. Tätä varten ohjelma on saatava käynnistymään niin ettei ikkunamanageri piirrä sille kehyksiä eikä otsikkopalkkia. Tokihan tämän toiminnallisuuden voi tehdä vaikkapa .twmrc:tä muokkaamalla, mutta haluan ohjelman toimivan itsenäisesti. Tämänlaiset kikat, kuin myös esimerkiksi virtuaalityöpöytien kanssa puljaaminen, ikkunan läpinäkyvyydet jne. edellyttävät Extended Window Manager Hints standardiin tutustumista. 'Mutta tällaisia ohjelmiahan on olemassa vaikka kuinka', kuulen lukijan ajattelevan. Toki niitä onkin, mutta ei ensimmäistäkään kevyttä, pelkän X kirjaston päällä toimivaa. Tarjontaa on KDE:lle, Gnomelle, Xfce:lle jne, mutten todellakaan halua asentaa vaikkapa KDE libsejä (~100Mt) pelkän prosessoriajan näyttämistä varten. Tämäkin pikku ohjelma on siis tehtävä itse.
Eipä sitten muuta kuin IDE - siis vi käyntiin ja homma alulle, naputtaen ensimmäiselle riville '#include <stdio.h>'. Ensimmäinen etappi on saada jonkunlainen ikkuna avatuksi ja perusohjelmarunko toimivaksi. Perusteiden jälkeen voinkin siirtyä itselleni uuteen aiheeseen, eli varsinaisiin Extended Window Manager Hintseihin. Tässä pikku projektissa kiinnostavia atomeja ovat _NET_WM_DESKTOP, _NET_WM_STATE, _NET_WM_STATE_STICKY, _NET_WM_STATE_SKIP_TASKBAR sekä _NET_WM_WINDOW_OPACITY. Näillä ikkunanmanager vihjeillä saadaan ohjelman ikkunasta poistettua kehykset, liimattua se ruutuun niin että ohjelma seuraa virtuaalityöpöydältä toiselle, poistettua ohjelma taskbarista ja muutettua ikkunan läpinäkyvyyttä. Ikäväkseni voin todeta että suosikki ikkunamanagerini, twm, ei tue esimerkiksi _NET_WM_WINDOW_OPACITY vihjettä, mutta läppäriini asennettu Gnome tukee. Joudunkin siis pitkin hampain käyttämään läppäriäni ja tuskaista Gnomea testialustana. No, yhden illan proggishan tämä vain on.
Sticky toiminnallisuus, siis liimataan ikkuna ruutuun pysyvästi, sekä ikkunan poisto taskbarista saadaan tehtyä helposti seuraavanalaisen koodinpätkän avulla:
{
Atom atomDesktop, atomState, atomStates[2];
Display *newDisplay;
Window newWindow;
int newDesktops = 0xffffffff; // Ikkuna halutaan kaikille työpöydille
atomDesktop = XInternAtom(newDisplay, "_NET_WM_DESKTOP", False);
atomState = XInternAtom(newDisplay, "_NET_WM_STATE", False);
atomStates[0] = XInternAtom(newDisplay, "_NET_WM_STATE_STICKY", False);
atomStates[1] = XInternAtom(newDisplay, "_NET_WM_STATE_SKIP_TASKBAR", False);
XChangeProperty(newDisplay, newWindow, atomDesktop, XA_CARDINAL, 32,
PropModeReplace, (unsigned char *) &newDesktops, 1);
ChangeProperty(newDisplay, newWindow, atomState, XA_ATOM, 32,
PropModeReplace, (unsigned char *) atomStates, 2);
}
Homma hoituu siis näin yksinkertaisesti. Kannattaa tutustua XChangeProperty funktion ohjesivuun mikäli funktion toiminta ei ole tuttu. Ikkunan läpinäkyvyyttä taas voidaan muuttaa seuraavasti
{
Atom atomOpacity;
Display *newDisplay;
Window newWindow;
unsigned int winOpacity; // Ikkunan läpinäkyvyys, 0 = ei läpinäkyvyyttä,
// 0xffffffff = täysi läpinäkyvyys
double opacity; // Läpinäkyvyyden säädin, 0.0 - 1.0
opacity = 0.5; // Halutaan puoliksi (50%) läpinäkyvä ikkuna
winOpacity = (unsigned int) (0xffffffff * opacity);
atomOpacity = XInternAtom(newDisplay, "_NET_WM_WINDOW_OPACITY", False);
XChangeProperty(newDisplay, newWindow, atomOpacity, XA_CARDINAL, 32,
PropModeReplace, (unsigned char *) &winOpacity, 1);
}
Näin. Muuta ei tarvita. Paitsi tietysti siis ikkunamanageri joka näitä vihjeitä tukee, homma toimii ainakin Gnomessa ja KDE:ssä, Xfce:n kanssa toimivuudesta en tiedä, todennäköisesti toimii.
Kuvankaltaisen prosessoriajan näyttimen saa komennolla: 'xaload -b peachpuff -x 10 -y 980 -v 32 -a -o -s'
Lataa vielä keskeneräinen prosessoriajan näytin alta. Ohjelma on ikkunan osalta jo valmis, mutta prosessoriajan näyttämisessä on vähän tekemistä, se ei siis sovellu tuotantokäyttöön vielä, esimerkiksi Extended Window Manager Hintseistä kylläkin. Käynnistä käännetty ohjelma 'xaload' vivulla -h joka tulostaa ohjesivun kaikista komentorivioptioista. Optioilla voi säädellä esimerkiksi läpinäkyvyyttä haluamakseen.
Erään pelin päiväkirjaa - Rendailua
Published by Jani on August 20, 2008
Tämä elokuinen viikonloppu on mennyt poikkeuksellisesti rendaillessa ja sivusilmällä olympiakisoja seuratessa, yleensä vietän viikonloput livemusiikista ja mallasjuomista nauttien. Ensimmäistä kertaa sitten milleniumin joudun miettimään uuden tietokoneen hankintaa, tuolla vanhalla 750MHz K7 pömpelillä rendausajat ovat luokkaa muutama vuorokausi per frame. Ihan liikaa. Ehdinkin jo katsella hieman tänäpäivänä myytäviä prosessoreja, ja täytyy myöntää että ihan mielenkiintoisia vaihtoehtoja olisi tarjolla. AMD Phenom neljällä corella voisi olla kiva, toisaalta en kyllä lämpene PC:n ostosta mutta Mac on taas hirmu kallis. Hm. Taidan viisaasti odotella kahdeksanytimisiä prosessoreja julkaistavaksi. PC:n hankinnassa ei pidä hosua.
Tuossa seläntakana humisevassa koneessa rendautuu parhaillaan näkymä merirosvokaupungin torilta. Ploygoneja näkymässä on hieman alle kolme miljoonaa, eri tekstuureja puolisen sataa noin 1000×1000 resoluutiolla. Tuon scenen lataaminen kestää pari minuuttia, kuluttaa muistia noin 1100Mt, siis reilun gigatavun. Olenkin joutunut keksimään erilaisia kikkoja jolla voin renderöidä monimutkaisia scenejä 1.5Gt muistillisessa koneessa kohtuullisessa ajassa. Yksi käyttökelpoinen konsti on rendata vain osa scenestä kerralla, tallentaa valmis kuva targa formaatissa ja avata vaikkapa gimpillä yksi targa kuva omana layerina. Sitten layerit yhdistetään ja kas, tuloksena on valmis kuva. Tämä kikka ei tosin ole aina käyttökelpoinen, varsinkaan jos materiaalit heijastuvat toisiinsa.
Asiasta toiseen, mielenkiintoista on Linuxin pikkuhiljainen nouseminen 3D mallintajienkin käyttöjärjestelmäksi. Linuxille on saatavana erinomainen Maya ohjelmisto - jota itse käytän - sekä itselleni uusi tuttavuus Houdini. Houdiniin aion tutustua paremmalla ajalla enemmän, Houdinista on ladattavissa ilmainen Apprentice versio, jossa on samat ominaisuudet kuin kaupallisessakin versiossa, apprentice versiolla rendattuihin kuviin kylläkin lisätään vesileima. Ihka oikeassa käytössä Houdinin joutuu siis ostamaan noin 7.000 dollarin hintaan. Myös kotimaisesta Real 3D:sta on olemassa Linux versio, joka ainakin pari vuotta takaperin oli hyvin epävakaa ja siten käyttökelvoton. Real 3D:n nykytoimivuudesta Linuxilla en tiedä. Itse tutustuin Real 3D:hen alunperin Amigalla viitisentoista vuotta sitten, onkin mukavaa nähdä vanha tuttavuus edelleen kehitettävänä sille 'omalle' käyttöjärjestelmälle. Ah niin, mainittakoon tässä myös Blender, joka omassa installaatiossani toimii vain .3ds objektien muuttamiseen .obj:ksi, eli Mayalla avattavaan muotoon.
Erään pelin päiväkirja saa jatkoa jälleen jahka ehdin kiireiltäni kirjoittelemaan.
Erään pelin päiväkirjaa
Published by Jani on April 9, 2008
Melko tarkalleen vuosi sitten, siitä edelleen vuoden taaksepäin hautunut idea alkoi konkretisoitua. Sysimusta ikkuna popsahti auki työpöydälleni, ilman minkäänlaista sisältöä tai intuitiivisuutta. Mustaa taustaa vasten pystyin mielessäni kuvittelemaan pelini valmiina, tyhjästä tekemisen joskus niin ohdakkeisella, mutta toisaalta palkitsevalla polulla. Olen tehnyt muutama vuosi sitten x86 assemblerilla merirosvoaiheisen matematiikka-opetuspelin BSD, Linux, Solaris ja Windows käyttöjärjestelmille, jonka kehitys hyytyi omaan mahdottomuuteensa sekä myöskin turhautumiseen ja kiinnostuksen puutteeseen. Mutta nyt, vuoden jälkeen uusi, kokonaan C:llä tehty peli alkaa olla teknisiltä perustuksiltaan valmis, sisältäen lennossa pakkaavat (omalla algoritmilla, tottakai ;) tiedostonkäsittely-, verkko-, tietokanta-, ääni-, cd-soitin- ja grafiikkapalikat. Kyse on edelleen BSD, Linux, Solaris ja Windows ympäristössä toimivasta opetuspelistä, sijoittuen jonnekin Karibianmeren saarelle. Pelissä on tietysti paljon taustahälinää, vedestä pomppivia kaloja, liiteleviä papukaijoja, tulikärpäsiä, seilaavia merirosvolaivoja ja paljon muuta ala-aste ikäiselle pelaajalle ihmeteltävää. Sisältääpä peli jopa suurennuslasin jolla pienenpieniä yksityiskohtia voi ottaa tarkempaan syyniin, sekä ystävällismielisiä merirosvoja joiden kanssa höpistä päivän tapahtumista.
Silloin ennen (cliche), kun koneilla väännettiin koodia ilman minkäänlaisia rajapintoja, oli mielenkiintoista optimoida grafiikkarutiineja viimosen päälle, minunkin 14MHz Amiga 1200:sen välkkyvällä ja päänsärkyä aiheuttavalla 640×512 interlaced ruudulla kieppui jos jonkinlaista m68k assemblerilla tehtyä sykkyrää ja syheröä. Nykyään, kun vältän ja karsastan edelleenkin ylimääräisiä kirjastoja ja rajapintoja, onkin mielenkiintoista tehdä nykyherzihirmuilla suoraan framebufferia sorkkivia rutiineja, esimerkiksi anti-aliasoituja bobeja tms. ja yllätys, huomata ettei nyky PC:t niin nopeita olekaan varsinkin jos ohjelma käyttää runsaasti muistiosoituksia.
Unix-versio pelistäni käyttää tietysti vain ja ainoastaan libc:n sekä Xlib:n palveluja, vaikka Unixille onkin yksi toimiva käyttöliittymäkirjasto: Motif. Kyllä, tuo vanha ja ruma nahjuke. Jotkut vannovat Gtk:n tai Qt:n nimeen, minä en. Pari vuotta sitten Gtk1 kirjastosta tuli 'deprecated', ja olemassa olevat softat piti portata Gtk2:lle. Miksi helvetissä? Jos porttaan, niin entäs taas parin vuoden päästä? Joskus tulevaisuudessa varmasti ilmestyy Gtk3, ja Gtk2:n statukseksi tulee 'deprecated'. Sama ralli taas edessä. Nou thänks. Qt:kin on tehty jo neljään kertaan, Qt4:n ollessa tietysti yhteensopimaton Qt3:n kanssa.
Entäs pelin äänet? Käytänkö ALSA:a vai OSS:aa? Onko alsa vielä parin vuoden päästä olemassa, tai 'se' jota tulisi käyttää? Harmi kun ei ole (toimivaa) kristallipalloa, voisin helposti valita pakollisista rajapinnoista ne, joiden tuki ulottuu kauimmas tulevaisuuteen. No, ei auta, tuurilla laivatkin seilaavat.
Grafiikka on onneksi ajatonta ja aina toimivaa, varsinkin merirosvo sellainen, eikä kerran kunnolla tehtyä kuvaa tarvitse ajanmukaistaa. Tosin omalla tyhjästä nyhjäistyllä distovapaalla Linuxilla (750MHz K7, 1.5Gb ram) Autodesk Mayan käyttäminen saa minut joskus repimään hiuksia päästäni, Maya ei ole kevein käyttämäni ohjelma. Toisaalta Maya on valmis (ja käyttää Motif:ia, hooray!), ja sillä saan tehtyä juuri sellaisia taustakuvia ja bobeja peliini kun itse haluan, mitään keskeneräistä finnipersenörttisoftaa from freshmeat ei tarvitse käyttää (sorry opensource/gpl-fanaatikot).
Pelin tekeminen on ollut nyt kuukauden jumissa, lähinnä juonen mietinnän takia. Ja hyvä näin, on ollut enemmän aikaa keskittyä muihin asioihin, kuten taidemaalaukseen joka on yksi intohimojani, vaikka taulujen tuotantotahti onkin ollut viimeisen vuoden melko vaimea.
Jatkoa seuraa, sitämukaa kun projekti etenee.