D&W:n puolella ehdinkin jo analysoida mennyttä vuotta; nyt on aika analysoida tulevaa. Kirjoitan tätä Egyptistä, ilman internet-yhteyttä, joten en voi ottaa kantaa vuoden ensimmäisen viikon mahdollisiin tapahtumiin MERPGin ja muiden ympärillä, vaan sen sijaan kirjoittelen altaalla ja lämmöstä nauttiessa syntyneistä ideoista. Näitä on monia, ainakin kolme, ja jokainen näistä ideoista tuo lisäarvoa MERPGiin tai tiimille.
mAnimaattori
Tarve tälle projektille on ollut olemassa yhtä kauan kuin MERPGistä on puhuttu, mutta nyt vasta osaan antaa sille nimen. Aikoinaan oletin että Coolbasic-foorumin Latexi95:n Animaattori valmistuisi sopivasti MERPGin animointivaiheeseen, mutta nyt näyttää siltä kuin Animaattori 3:n toinen inkarnaatio on jäätynyt ja haudattu. Etelänlomani aikana "tulin lukeneeksi" viimeiset 300 sivua Clojure-raamatustani (ja Pitkä Sigma 4:n, ja 200 sivua Poea, hienoja kirjoja), ja nyt minulla on jonkinlainen käsitys siitä miltä oman animaattorin tulisi näyttää.
MERPGin animaatiot tunnetusti ovat framecount*frameW pikselin levyisiä ja frameH korkuisia animaatioita. Javan kaksiulotteiset grafiikkaluokat muistaakseni sallivat kuvien helpon jakamisen ja yhdistelyn, joten animaattorin ainoa "iso" ongelma on freimien käsittelyyn käytettävän käyttöliittymäkomponentin löytäminen/rakentaminen. Olisi kiva jos varsinaisen kuvankäsittelyn voisi ulkoistaa Paint.NETille upottamalla sen Swing-layouttiin, mutta se on vaikeampi toteuttaa kuin Emacsin tekstieditorin integrointi Visual Studioon, toisinsanoen siis mahdotonta. Onneksi javakäyttöliittymien rakentaminen ei vuodenvaihdetta edeltäneiden kokeilujeni pohjalta ole Clojurella ja Seesaw'lla lainkaan samanlainen PITA kuin raa'alla Swingillä.
Käytännössä tämän ohjelman malliksi riittäisi lista/vektori java.awt.Image'ista, jotka tallennusmetodi yhdistäisi yhdeksi Imageksi, joka kirjoitetaan ImageIO:lla levylle. Luonnollisesti latausmetodi lataisi kuvan, hajottaisi sen useaksi imageksi, ja muodostaisi näistä listan. Freimien määrä pitäisi myös jostain päätellä, minä en ainakaan keksi miten sen voisi päätellä pelkästä png-kuvasta rajoittamatta joko freimien leveyttä tai jotain muuta suuretta. Pöljempi voisi luulla että koska MEMAPPERin tilet ovat 50x50, animaatioidenkaan ei ole mitään syytä olla eri kokoisia, mutta se on väärin, koska viime keväänä päätin että hahmojen liike on jatkuvaa, eivätkä ne ole muutenkaan 50x50 - tilejen rajoittamia
Yksi tapa ratkaista ongelma olisi rakentaa Clojuren record, johon tallennetaan Image-lista ja tilejen määrä. Tämä sitten sarjallistettaisiin java.io.Writeobjectilla (tai jollain sellaisella, en omaa localhostissa javadoceja, joista luntata nimiä), jolloin ei IO:n yhteydessä tarvitsisi leikkiä ImageIOlla. Tässä kohtaa todellakin toivon java.awt.Image - luokan olevan sarjallistuskelpoinen.
Näkymään koostuisi yhdestä ikkunasta. Tässä ikkunassa olisi kolme osaa: piirtopinta, AKA "PDN-klooni", työkalualue, ja aikajana. Aikajanalla näytetään jokaisesta freimistä thumnail, ja siltä pystyy ottamaan jokaisen freimin lähempään tarkasteluun piirtopinnalle. Kun freimejä on enemmän kuin ikkunaan mahtuu, näytetään joko nuolinapit, tai sitten toteutetaan jonkinlainen hiireen perustuva animaationsisälläliikkumismenetelmä. Aikajana tarjoaa myös taikanapin freimien lisäämiselle, sekä napin, joka ensin varmistaa että olethan nyt varma, ja sen jälkeen poistaa jos käyttäjä oli varma.
Sitten on työkalualue. Alussa siellä on todennäköisesti tasan pikselintarkka kynä, ja ehkä jotain muototyökaluja. Muut työkalut yritän kirjoittaa pyynnöstä, tai annan ohjelmointitukea kaikille, joilla on abstrakti algoritmi, jonka haluavat muuttaa Clojureksi, mAnimaattorin ladattavaan muotoon. Lisäksi työkalualueella on väridialogi ja "Outline - Filled - Outline & Filled" - valinnat, jotka toimivat kuten PDN:ssä. Työkalujen kirjoituksen tueksi kirjoittanen deftool-makron, joka antaa värin ja Outline-valinnan arvon ohjelmoijalle. Tietysti jos hyvä ohjelmoija olisi, tekisi näille arvoille myös funktiorajapinnat, jotta HOFfien käytöstä ei tulisi ihan kamalaa.
Tätä ohjelmaa helpottaisi kuitenkin jos löytyy Swing-yhteensopiva, upotettava kuvienmuokkas-UI-elementti.
MEsE
Clojureraamattua lukiessani huomasin Leiningenin, Clojuren Mavenin, olevan aika tajuttoman kiva kapistus. Viuhkaan, jonne en jumalauta yhtään .waria laita enää ikinä, laittaessani MEsEn palvelinpuolta, ensin piti shellillä tappaa tomcat, sitten netbeansissa clean&buildata uusi koodi, ftp:llä siirtää 25-megainen .war (...ehti hyvin keittää teetä yhden siirron aikana, ja huh hellettä jos huomasit paketissa bugeja...), riidellä tomcat päälle, ja toivoa että se oli päällä vielä huomennakin. Tämä on ihan yhtä pöljä tapa ohjelmoida kuin miltä kuulostaakin. Sen sijaan, edellämainitusta Clojureraamatusta luin leinin kykenevän tekemään tämän saman Amazonin clj-ympäristöön seuraavan proseduurin mukaan: kirjoitetaan % lein deploy shelliin. Okei, myönnetään, project.clj vaatii hieman määrityksiä ennen kuin deploy - komento on olemassa, mutta silti erittäin paljon pienempi PITA (kiva akronyymi <3 ) rakentaa asianmukainen project.clj kuin tehdä ensimmäinen prosessi neljä kertaa päivässä yhden nullpointerin etsimisen vuoksi, ja huomata sen jälkeen aamun muuttuneen aamuyöksi.
En takaa että korrekti komento oli lein deploy. Kirjoitan tätä tekstiä ulkomuistista, tarkistamatta mitään mistään, joten mikään ei välttämättä pidä paikkaansa, mutta joka tapauksessa kyseessä oli yksinkertainen, lyhyt lein-komento.
Näinollen, kunhan kotiin pääsen, on minun tarkistettava mitä Amazonin ympäristö maksaa, ja tarjoaisiko Leiningen yhtä kivan tuen ilmaiselle Google App Enginelle. Jos (käy ihme ja ) Amazonia voi yksityisenä käyttää ilmaiseksi, tai GAElle tarjotaan samaa tukea, tiputan vanhan MEsErver-koodipohjan ja aloitan sen suosiolla alusta Clojurella. Tämä ratkaisisi monia ongelmia, joita vanhassa koodissa on, deployingin (mitä hittoa se on suomeksi?) lisäksi. Javan Collections - API on olevinaan kiva, mutta MEsErverissä se oli enemmän kuutamolla kuin normaalisti. Jostain syystä olioita, jotka olin tasan tarkkaan laittanut kokoelmiien, ei enää hetken päästä löytynyt niistä, eivätkä oliot poistuneet pyydettäessä. Lisäksi yhtään monimutkaisemmat datankäsittelyoperaatiot javakokoelmilla ovat juuri niitä: monimutkaisia. Miten kukaan selviää ilman mappia/selectiä, filtteriä/whereä ja muita!?
Joka tapauksessa, tutkin siis kotiinpäästyäni MEsEn toteutusmahdollisuuksia Clojure-palvelimella.
Salaperäinen kolmas projekti
Ehdin jo unohtaa mikä tämä oli. Ehkä Javaan pohjautuva MEserver GAElle, jos lein ei tue ympäristöä? En tiedä.
No comments:
Post a Comment