Friday 24 June 2011

Kokokon kokokokokoko kokko

Tämä alkaa pahasti kääntyä xkcd-blogiksi. En ole varma, oliko se juuri xkcd, jossa esiteltiin kaveri, joka kirjoittaa blogiinsa neljä kertaa vuodessa, pahoitellen joka kerta kun ei ole jaksanut kirjoittaa enemmän, mutta joka tapauksessa ymmärtänette millaiseksi suureksi puujalaksi olen alkanut näin juhannuksen kunniaksi.

Kokko syttyy


Tänään pohdimme, jokavuotisen juhannusperinteen vuoksi, tulen syvintä olemusta. Tuli on runollisesti kiva. Tuli on loistava, vahva ja voittamaton... mutta niin helposti kaatuva. Tulen mukanaantuomat lämpö ja valo katoavat myös maailmasta helposti. Jos leirinuotion päälle sataa, palelevat leiriläiset koko yön. Myös ihmisten sisimmässä palaa vertauskuvallinen tuli, joka loistaa, valaisten ihmisten kättenjälkeä. Jos tämä tuli sammuu, katoaa käsituosta hohto. Tämä tapahtuu pelottavan helposti.

Kokko on aivan liekeissä
Juhannus on muistaakseni valon juhla. Jaksamatta tarkistaa wikipediasta, voisin olettaa juhannuskokkojen tehtävän olevan valon ja lämmön levittäminen kylmien ja pimeiden suomalaisten sydä....ntalviin. Tämän kun yhdistää suomalaiseen tapaan karkotaa pahoja henkiä juopottelemalla, saadaan lämminveristen ihmisten verestä paljon lämpöä tulevaa talvea varten :P

Liekit nousevat korkealle kuin kerrostalo
Erittäin hyvällä mielikuvituksella, sillä samalla jolle perustetaan uudenvuoden tinataiat, voi juhannuskokon liekeissä nähdä tulevaa ja mennyttä. Ylläolevassa kuvassa ainakin näkyy selvästi torso, kaksi kädenalkua ja pää, joka jäi kuvan yläpuolelle :P Jos oikein hassusti sitä katsoo, voi siinä nähdä mitä vain tulevan morsiamen ja ties minkä väliltä.

Sehän on sarvipää
Asiansa osaavan pyromaanin tapoihin kuuluu myös paloturvallisuudesta huolehtiminen. Ei saa jättää metsäpaloja, ei ruohikkopaloja eikä elävää palanutta. Ei myöskään kannata hukkua :P Se on äärimmäisen typerää.

Nauttikaa loppukesästä kuunnellen suomalaisen musiikkikulttuurin kauneinta helmeä.

 

Loput kuvat löytyvät joko showAll-PHP-skriptillä tai kansiosta

Tuesday 21 June 2011

Pyöritys on rikki :(

Javan kuvanpyöritin ei jostain syystä toimi. Näinollessa ei kannata ihmetellä ongelmaa, vaan kannattaa siirtyä ratkaisemaan helpompia ongelmia, antaen suuremman ongelman muhia päässä. Mainitsin jossain, että MEMAPPERin uuden koodipohjan eka beta tulisi kun tilet voivat pyöriä kuin karuselli, ja karttoja voi tallentaa ja ladata. Taidanpa kuitenkin toteuttaa jotain tosi helppoa ennen tiedostopuolelle siirtymistä: hit-datan nimittäin.

Tuo ei ole todellakaan vaikea toteuttaa. Tällä hetkellä ohjelman globaali tietovarasto omaa layersäilön, listamaisen rakenteen  layereitä. Tämä lista läpikäydään aina kun kartta renderöidään ruudulle. Hit-datan saisi toteutettua jalostamalla layer-luokasta uuden luokan, jonka tilejen tilalla on booleaneja. Tämä kerros piirrettäisiin ruudulle vain, jos hitdatan muokkain on valittuna.

Hitdataa muokkaavan työkalun toiminta taas on tuttua vanhasta koodipohjasta. Kun työkaluoliota ensimmäisen kerran kutsutaan, luodaan kartanW * kartanH kokoinen taulukko booleaneja, ja aina kun työkalua kutsutaan, pidetään silmällä millä tileillä on jo käyty, eikä muuteta niiden arvoja. Tämä toiminta on vielä hieman suunnittelun alla, mutta valmiista tuotteesta nähnemme mitä sain aikaiseksi :P

Monday 20 June 2011

Vähän ajatuksia pröngistä

Alkuun mainos:

Yool kansainvälistyy, avasin DICiin enkunkielisen blogin englannintaitojeni kehittämisen... ja, no, huvin vuoksi. Siellä on vain yksi teksti nyt, mutta lisää tulee kun jaksan tehdä (mikä muuten, yllättäen, pätee kaikkiin blogeihini :P). Tämä pysynee pääblogina, mutten takaa että kaikki faktat päätyvät molempiin blogeihin. Kannattaa siksi lukea molempia ja huomautella kun pahoinpitelen englannin kieltä.

Jatkoon vähän asiaakin.

 Mainitsin pari kuukautta sitten Pröngin laudalla ~puoli vuotta vanhan koodin haisevan kolme vuotta vanhalta. Nyt olen parin kuukauden ajan keräillyt laudalta ehdotuksia uuteen Pröngiin, ja nyt julkistan hieman ajatuksia aiheesta. Alkuun raaka changelist:

  • Tietokanta, jonka rakennetta kehtaa katsoa vielä syksylläkin
  • Fiksu ongelmien hallinta
  • Mobiili www-toteutus
  • BB-/HTML-muotoilut
  • Headers already sent - virsettä karttava koodin rakenne
  • Satunnaisesti valittu "slogan-luonnos"
Tietokannan uudelleentoteutus tarkoittaa sitä, että suunnittelen kantaan jonkinlaisia yhteyksiä taulujen välille, enkä vain lyö kantaan ilmassa roikkuvia tauluja eri asioille. Tällä hetkellä kanta ei mm. ymmärrä, että käyttäjät tuottavat ja lukevat luonnoksia, tai että kommentit kommentoivat luonnoksia. Kanta ymmärtää vain, että on luonnoksia, on kommentteja, on käytttäjiä ja on helvetisti purkkaa, joka toteuttaa nämä yhteydet.

Ongelmienhallinta tarkoittaa sitä, että minä voisin reagoida PHP:n virheisiin kuin työpöydällä poikkeuksiin. Tällä hetkellä kun PHP kohtaa virheen pröngin koodissa, koodin suoritus pysähtyy ja käyttäjä saa ruman (ja useimmiten siansaksaa olevan) virheen(, jos käyttäjä ei tunne PHP:n käyttäytymistä) (vertaa tilannetta nykyCB:n MAViin). Erästä DIC-tutoriaalia pohjana käyttävä systeemi antaisi mahdollisuuden joko toipua virheestä, tai ainakin tulostaa oma, selkeä virheviesti (ja tehdä virheen edellyttämät rituaalit, kuten esim. lähettää emaili virheestä minulle) (vertaa mm. C-kielten exceptioneihin).

Mobiilitoteutuksesta en ole enää varma. Nettitikun heräämisen myötä minulta katosi mahdollisuudet testata pröngiä "tyhmällä kännykällä", ja ainakin Androidin selain renderöi pröngin kuin FF/Chrome. Jos alan väsäämään tätä, saa Tässi vähintään hoitaa testauksen ja mahdollisesti keräillä muotoiluja, jotka ovat vaikeita hänen kännynsä selaimelle ja Opera Minille.

BB- tai HTML-muotoilut ovat ehdoton pakko. Näiden välillä ei tässä yhteydessä ole muuta eroa kuin se, että BB-tagit ympäröidään [näin], kun taas HTML . Menen todennäköisesti BB:llä, ettei ihmisille tule intoa alkaa eksperimentoimaan kummallisia tageja. Tämä mahdollistaa myös enemmän jännempiä tageja vähemmällä "ei tuon näköiset tagit kuulu siihen_ja_tähän standardiin! >:(" huutelulla. Joka tapauksessa, vähintään quote, b, i, u ja url - tageja pitäisi tukea. Lisää tageja tulee jos tulee tarvetta.

Nykyinen koodi huutaisi virhettä jokaisella sivulla ilman ob_ - funktioita, jotka puskuroivat tulostuksen siihen asti kunnes keksejä ei enää tarvitse käsitellä. Tämä ominaisuus vaikeutti muistaakseni kehitystä viimeksi, ja nyt kun olen oppinut ajattelemaan, hoidan keksi- ja muut header-asiat ennenkuin tulostan yhtään mitään.

Tuo slogan-luonnos tarkoittaa sitä, että sivun ylätunnisteessa on jossain "Pröng - tähän_kiva_luonnos" - tyyppinen teksti. Todennäköisesti titlestä tulee samanlainen, vaikka kukaan tuskin huomaa tätä koska prong.tk:n kautta titleksi tulee yksinkertaisesti "prong.tk".

Kuten sanoin, ainakin etusivu saa ylätunnisteen, johon voi laittaa muutakin informaatiota kuin "Olet pröngissä, senkin sherlokki". Esimerkkinä viime lauantaihin asti pröngissä näkynyt "Kippis ja kujaus" - banneri olisi ehdottomasti tarvinnut vähintään oman divinsä, jottei se olisi sotkenut etusivun layouttia.

Lisäksi, ennenkuin itse Pröng alkaa kehittyä, tehnen alle PHP-frameworkin/CMS:n, joka mahdollistaa myös merpg.webs.comin siirron jonnekin Viuhkan kaltaiselle vähällä vaivalla. Tuo CMS-systeemi vaatinee oman tekstinsä, ja minua väsyttää muutenkin, joten julkaisen tämän nyt tälläisenä :P

Saturday 11 June 2011

Karttatiedoston lisäspeksausta

Kuten hyvin tietänette, MERPGin ja MEMAPPERin lataamat karttatiedostot ovat hassusti nimettyjä zip-tiedostoja, ja tämä tuo minulle mahdollisuuksia, jotka tajusin vasta vähän aikaa sitten. Zippitiedostoon voi nimittäin piilottaa vaikka minkälaista tietoa, joka ei häiritse muuta tiedostossa olevaa dataa, ja jonka olemassaolosta ei lataava ohjelma edes tiedä, ellei se tiedä mitä on hakemassa.

Tämä mahdollistaa mm. sen, että saan annettua jokaiselle karttatiedoston layerille oman opacity - arvon. Tämä arvo tuottaa saman efektin, kuin Paint.netin vastaava, joten en ala selittämään sen toimintaa enempää kuin sanomalla, että toiminta on identtinen pdn:n vastaavan kanssa. Mainitsen vain, että sekä editori että pelimoottori tukevat tätä ominaisuutta.

Merkitsen layerien opacityt todennäköisesti sillä helpoimmalla mahdollisella tavalla, joka avaa ovet myös modaajille, jotka eivät jaksa harrastaa MEMAPPERia. Merkitsen tekstitiedostoon raakatekstinä joka riville jokaisen layerin opacityn. Tuo arvo on, luonnollisesti, välillä 0-255, koska pikselin alfa voi olla vain tuolla välillä.

Minua tosin jännittää miten aion toteuttaa tuon opacity-arvon käytännössä. Todennäköisesti parasta olisi ensin piirtää koko layer yhdelle pinnalle, laskea pinnan jokaisen pikselin alfaa (255-LayerinOpacity)n verran, ja sitten piirtää pinta näytölle.

Toinen sovelluskohde tälle zippirakenteelle on metadata. Pelimoottori ei tee mitään tiedolla siitä, minkäniminen mikäkin layer on, mutta editorin käyttäjät tahtonevat antaa layereille fiksumpia nimiä kuin "Layer N" (missä 0>=N>LayerCount). Tälläisen ominaisuuden implementointi on sitäpaitsi erittäin helppoa. Yksi tekstitiedosto, jonka jokainen rivi kertoo jokaisen layerin nimen (missä piirtojonon alin layer saa tekstitiedostosta ylimmällä rivillä olevan nimen).

Taidanpa siirtyä toteuttamaan näitä.

Wednesday 8 June 2011

Työkalupakki pitäisi koota

En ole kai julkaissut yhtään betaa tästä uudesta MEMAPPER-koodipohjasta, mutta koodaustahti on ollut sitäkin kovempi. Kun ensimmäinen beta on julkaisuvalmis, on ohjelma parempi kuin vanha viimeisinä päivinään. Mutta, mieleni teki taas tehdä hieman yhteenvetoa.

Toteutin viime postissa mainitut datarakenteet. Sen jälkeen käytännössä uudelleentoteutin tile- ja karttapinnat, ja ylikirjoitin JPanel - luokan paintComponent() - funktion omallani, joka lukee (pinnan tehtävästä riippuvia) arvoja suuresta, globaalista Tietovarastosta ja piirtää valitun tilesetin ja valitut layerit asianmukaisille pinnoille.

Jotta näiden pintojen mukanapysymistä voi testata, pitäisi minun seuraavaksi kirjoittaa työkalurajapinta, jota vasten kaikki työkalut pitäisi toteuttaa. Rajapinta vaatii toteuttajaltaan vain yhden funktion, use(). Tämä saa parametrikseen Layer- ja Tilesettisäilöt, sekä MouseEvent - olion, josta voi kalastaa missäpäin karttapintaa tapahtui klikkaus, jonka vuoksi työkaluoliota kutsuttiin. Lisäksi rajapinnan use() - funktio voisi saada parametrina valittuna olevan Tile - olion.

Kun tulee sen aika, todennäköisesti toteutan näiden pohjalta myös plugin-apin. Plug-in - luokkien on täytettävä yllämainittu rajapinta ja oltava jossain kivassa kansiossa. Kun se on toteutettu, tehnen julkiset speksit plug-ineille, mutta se on tulevaisuuden murhe. Nyt tärkeintä on saada ohjelma toimivaksi.

Nyt kun otsikon aihe on käsitelty, olen miettinyt jos kokeilisi vaihtoehtoisia blogialustoja blogspotin/bloggerin rinnalla. Yksi mitä olen miettinyt vahvasti, olisi blogailu DICissä, mikä vahvistaisi englannintaitoani. Toinen vaihtoehto olisi kokeilla wordpressiä. Yoolia tuskin alan uudelleenkirjoittamaan nykypäivän vaatimusten tasolle nyt, kun MERPG on työnalla todennäköisesti koko vuoden.