Uncategorized

3D-grafiikkaa Linuxilla, osa 1: alkulätinät

3D -grafiikka on mielenkiintoinen aihe, siinäkin mielessä että usein ensi-innostuksen jälkeen aihepiiri voi jäädä hyllylle. Grafiikka voi toisaalta olla elämänpituinen intohimo, sekä tuleva ammatti.

Esittelen tässä sarjassa 3D-grafiikan alusta “loppuun”, niin että pääset kirjoittamaan koodia Linuxilla. Esimerkeissä käytetään OpenGL ja GLUT kirjastoja, mikä lienee kohtuullisen yleinen vaihtoehto. Kaupallisiin tai muihin valmiisiin pelialustoihin todennäköisesti ei tutustuta. Voi olla, että jos käytän myöhemmin jotain tällaista, siitä erillinen sarjansa.

Tässä jaksossa…

  1. höpistään hieman taustoja grafiikasta
  2. juodaan kahvia
  3. mietitään miksi vasta sarjan seuraavassa osassa päästään koodaamaan

Mutta – se on lopulta kaikki vain pikseleitä!

Grafiikan ideathan ovat universaaleja, mutta lopulta iteratiivisen testailun ja viihtymisen vuoksi jollain laitteistolla ja softakirjastoilla homma on lopulta tehtävä. Eli kädet on lyötävä saveen, ja koodia kirjoitettava.

Ideatasolla ymmärrämme jo ihmisenä mistä grafiikassa on kyse; näemmehän jatkuvasti erilaisia pintoja, esineitä, ihmiskasvoja, taivaan, jne ympärillämme. Grafiikkaohjelmoinnissa luodaan illuusio siitä, että se, mikä (usein 2-ulotteisella) ruudulla näkyy vain tasossa, esittää tuota oikeaa kolmiulotteista maailmaa.

Joskus 3D-ohjelmointia ensimmäisen kerran lähestyessä voi mielen vallata kaaos: erilaiset konseptit pulppuavat tulvana mieleen, ja mikäli ei naulaa tiettyjä perusasioita jämäkästi kiinni, voi olla, että ohjelmointi jää sikseen.

Anna esineille oma rauhansa

Esineet elävät omaa elämäänsä. Eli ne voidaan määritellä riippumatta, miten ne myöhemmin tulevat esiintymään 3D-maailmassa. Tämä on eräs fundamentaali oivallus, joka ainakin itselleni toi mielenrauhaa. Jos olet leikkinyt 3D-ohjelmilla, aika nopeasti idea kolmesta akselista (X,Y,Z) ja esineiden muodostuminen näihin alkaa tuntua luontevalta. Suosittelen nimenomaan “aivotonta kokeilua”. Silloin saa tuntumaa myös ohjelmointiin. Älä aluksi yritä tehdä mitään mestariteoksia.

Aivan mainioita harjoituskappaleita ovat säännölliset laatikot, kuin myös pyramidi, tangot, palikat.

Asenna vaikka Blender, joka on täysin ilmainen ja erittäin laadukas softa. Blenderillä on tehty elokuvia ja pelejä, mutta nyt alkuun siitä on iloa nimenomaan 3-ulotteisten esineiden muovaamisessa. Ohjelmoinnin kannalta Blender ei ole mitenkään pakollinen, mutta se on kiehtova softa jos mallinnus kiinnostaa.

Illuusion ytimessä: projisointi

Kolmiulotteisessa grafiikassa esineet piirretään tasoon (monitorille) siten, p_projektiot_seinaettä niiden muoto muuttuu antaen illuusion katselukulmasta ja esineen etäisyydestä katsojaan. Kun soppaan lisätään valaistus, varjot, ja muita efektejä, gourmé -ateria on valmis! Yksinkertaistettuna siis näin.

Teknisesti kyse on projisoinnista. Esineistä, joilla on 3-ulotteiset koordinaatit, piirretään meihin, “katsojan silmään”, viivat, ja nuo viivat katkaistaan ruudun (tason) kohdalla. Jos olemme esineen sisällä, esimerkiksi talossa, jätetään taaksemme menevät esineet vain piirtämättä (meillä ei ole silmää takaraivossa). Matemaattisesti kyse on suhteellisen yksinkertaisesta ratkaisusta: jos projisoidun pinnan syvyys (z-koordinaatti) on negatiivinen, sen voi jättää huomiotta.

 

Tietokonegrafiikka kehittyi mustavalkoisesta 2-ulotteisesta grafiikasta ensin värigrafiikkaan. Oli “kova juttu” että esimerkiksi PC:lle löytyi CGA -grafiikkaominaisuuksia tukevissa korteissa 3 omituista väriä ja lisäksi musta. CGA-grafiikka näytti tuolta vieressä olevalta.

Hiljalleen 1980-luvun tienoilla tietokoneisiin ohjelmoitiin (softalla) 3D-grafiikan rutiinit itse. Jokaisella ohjelmoijalla oli siis kivinen mutta toisaalta antoisa tie kuljettavanaan, koska pikselin- ja viivanpiirrosta lähtien kaikki piti tehdä itse. Bresenham oli tuolloin kova sana – keksijänsä mukaan nimetty algoritmi, jolla saatiin tehtyä mielivaltainen viiva kahden pisteen välille, siten että se ei näyttänyt “tyhmältä” eikä kuluttanut yhtään liikaa prosessoriaikaa.

Alkoi grafiikkakorttien valtakausi. 2D -piirtämisen oltua “riittävän hyvällä” tasolla kolmiulotteisten rutiinien kilpavarustelu oli tuleva taistelutanner seuraavien parinkymmenen vuoden ajan. Muistimäärät kasvoivat myös näytönohjaimissa reippaasti alkuperäisistä. Tavallaan modernin peligrafiikan taustalla on sopiva määrä elektroniikan ja ohjelmistojen kehitystä.

 

Mikä OpenGL on?

OpenGL tarjoaa rajapinnan grafiikkakorteille. Sen tarkoitus on eriyttää laitevalmistajakohtaiset yksityiskohdat, jotta ohjelmoijat voisivat tehdä heille mielekkäitä asioita sen sijaan että miettisivät eri valmistajien ja korttimallien kanssa temppuilemista.

OpenGL-kirjasto kulkee versiossa 4 tällä hetkellä. OpenGL on tavallaan hyvin matalan tason, laitteistoläheinen yhteys. Kirjasto tarjoaa siis C/C++ kielelle funktiot ja vakiot grafiikkakortin ohjaamiseen. OpenGL:n tärkeimpiä ominaisuuksia on ohjelmoitavuus: sen avulla voidaan luoda uusia efektejä, jotka tietenkin lopulta lankeavat grafiikkakortin suoritettavaksi, mutta näin päästään grafiikkaohjelmoinnissa liikkumaan hieman korkeammalla tasolla.

Kun laitevalmistajat tarjoavat uusia ominaisuuksia raudalla, OpenGL seuraa kehityksessä näitä.

Entä mikä on GLUT?

GLUT taas on pieni kehikko grafiikkaohjelman yleisimpien peruselementtien tekemiseksi. GLUT liittyy enemmän Linuxin työpöydän ikkunointiin ja sen sellaiseen. Eli GLUT helpottaa “toimivan” kokonaisuuden protoilua. OpenGL:n mielestä maailmassa on sen sjiaan vain olemassa raakoja suorakulmion muotoisia alueita näytöltä, joihin piirrellään pikseleitä. OpenGL ei ota kantaa “käytännöllisempiin” asioihin ohjelman rakentamisessa.

 

Uncategorized

Papa docs: Windows phone 8 sovelluskehitys

From: papapapa

To: lukijat

Subject: kuinka koodata Windows Phone 8 sovellus

No terve!

Symbianin kohdalla en koskaan jaksanut kahlata läpi kehitystyökaluja, joita tulisi kehityskoneelle asennettavaksi käsittääkseni vähintään 7-8 erilaista, jotta yksinkertaisen softan olisi voinut kääntää lähdekoodista puhelimelle. Rest in pieces, Symbian.On uuden avoimemman aikakauden vuoro. Nokian kohdalla riippuminen Symbianissa saattoi olla yksi keskeisiä syitä, miksi muutamat kilpailijat painoivat ohi ja lujaa. Mutta peli ei suinkaan ole vielä kokonaan pelattu.

Mietin, että asioita opetellessani tekisin 3- tai 4-osaisen kirjoitussarjan Windows Phone -kehityksestä. Julkaisun aikataulu on vielä kysymysmerkki, ja erityisesti tuo 2. osan ilmestyminen on varmaankin se isompi haaste. Nyt tässä ensimmäisessä osassa käyn läpi hieman WP8 taustoja ja erityisesti sitä lähtökohtaa, jolta itse ponnistan asian suhteen. Huom! En kirjoita tätä artikkelisarjaa asiantuntija-näkökulmasta, vaan nimenomaan uteliaana amatöörinä. Jos löydät asiavirheitä tai parannettavaa, pistä ihmeessä joko kommentti blogiin tai suoraan sähköpostia.

Windows Phone on mennyt mielestäni Symbianiin verrattuna hyvään suuntaan; nyt tuo oma pieni sovellusprojekti vaikuttaa jo “doable” -tasolta. Toisaalta ohjelmointitaustassani on jonkin verran (ei-natiivi) Windows koodaamista, lähinnä VisualBasic:lla, joten osa Windows Phonen sisältämistä teknologioista ovat tuttuja. Samoin ylläpitäjänä monet Microsoftin konseptit ovat tulleet vuosien mittaan kohtuullisen tutuiksi.

Kirjastosta löytyi varsin kelpo opas, Moonsoftin ohjelmistokonsultin Jani Järvisen (junassa kirjoittama!) uusi “Windows Phone 8 sovelluskehitys”. Painelin sitä eteenpäin ensi-istumalta 40 sivua. Innostuin aihepiiristä aika lailla, ja uskon, että tässä on se kipinä, joka johtaa lopulta ihka oikean WP8 sovelluksen valmistumiseen. Mutta eipä nuolaista aivan vielä.

Järvisen opas lähtee reippaasti käyntiin, jonka jälkeen jumitutaan hieman aikaa Microsoftin muiden tuotteiden ja lisenssoinnin parissa, mutta ko. firman kohdalla näistä on hyvä / pakollista tietää vaikka haluaisikin “vain” kehittää mobiilisoftaa. Lyhyesti sanottuna on hyvä tietää, että ainakaan tällä hetkellä WP8 alustalle ei ole mahdollista kehittää ilmaiseksi ohjelmia. Kehittäjälisenssi maksaa 99 USD per vuosi, ja sen saa Microsoftin Windows Phone Developer -sivulta. Kannattaa lukea aika tarkkaan kehittäjälisenssiin liittyvät julkaisuehdot ja kehittäjän vastuu ohjelmansa hyväntahtoisuudesta sekä kriittisten virheiden käsittely.

Ohjelmoinnissahan on mielenkiintoinen paradoksi historian valossa: ennen se oli helpompaa! Kun aloittelin itse ohjelmoinnin vuonna 1983, riitti, kun kirjoitin pari riviä (tai vain yhden rivin), ja sen jälkeen ajoin ohjelman RUN -komennolla. Tulos oli välitöntä, ja prosessi oli hyvin yksinkertainen. Koko hela hoito tapahtui pikkuriikkisessä muistimäärässä, hyvin heppoisilla resursseilla, armoitetun Commodore 64 -kotitietokoneen uumenissa.  Nykypäivänä edelleen on olemassa teknologioita, joissa pääsee hyvin nopeasti käyntiin ja kokeilemaan (mieleen tulevat erityisesti web-kehityksessä suosituksi noussut Javascript ja monet Linux/Unix maailman kielet kuten Perl, PHP ja Python). Toisessa päässä on sitten tällainen “raskas” sovelluskehitys, johon Windows Phone 8 -kehitys lukeutuu myös.
Microsoftin kohdallahan kehitystyökalujen pino on usein hyvin määritelty (“well defined”), mutta vastapainoksi se on aika proprietary
ja hinnakas (Järvisen kirjassa olevien suositusten mukaan peruskokoonpano jolla kehitystyötä voi tehdä maksaisi kone mukaanlukien
suurinpiirtein tuossa 1300-1500 euron tienoilla – jos mukaan laitetaan yksi Windows-palvelin, hinta noussee jonnekin 3000 euron tienoille). Microsoft on muuttunut vuosien mittaan hyvinkin paljon avoimemman ohjelmistokehitysmallin suuntaan. Silti koska kyseessä on suhteellisen perinteisellä liiketoimintamallilla toimiva yritys, se ei voi antaa kaikkea ulos ilmaiseksi.

Tuotteet on usein nivelletty keskenään “sopivasti” niin että Järvinenkin mainitsee kirjassaan, että vaikka kyse on puhelinkoodin
kehittämisestä, yllättäen kuitenkin mm. Office-, Azure-, jne palvelut tulevat usein käytännössä vastaan ja niiden osaamisesta
on hyötyä. Hieman MS-pakkosyöttöä toisin sanoen tiedossa, mutta en ole varma, onko tuo aivan absoluuttinen vaatimus vai nice-to-know. Käyn tulevissa osissa läpi erityisesti myös näitä, sikäli kun katson että kehittäjälle niistä on hyötyä. Toistaiseksi en voi sanoa juuta enkä jaata asian suhteen, kokemattomuuttani.

Microsoft tuntee sen, miten opittuja asioita kannattaa kierrättää järkevästi uusissa asiayhteyksissä. Toisaalta firma on myös tunnettu toisinaan varsin karskeista epäjatkuvuuskohdista, esimerkiksi nyt WP7 ja WP8 käyttöjärjestelmiin ei kannata haaveilla vanhan .NET koodin kääntämisestä. Asialla on myös hyviä puolia. Yllättäen nimittäin kun perheeseemme tulia Lumia 920 -puhelin, etsin melkein ensimmäisten asennettavien ohjelmien joukossa virusturvaa. Kävi ilmi, että virusten elosta tällä alustalla on tehty hyvin vaikeaa. Ensinnäkin jokainen puhelimessa ajettava app elää omassa eristetyssä hiekkalaatikossaan (‘sandboxing‘) ja lisäksi jokainen markkinoille hyväksyttävä ohjelma käy läpi Microsoftin testauksen.

Seuraavassa osassa: ensimmäinen toimiva ohjelma!

Uncategorized

Koodia kapulaan! osa 1

Blaise Pascal first explained his wager in Pen...
Blaise Pascal first explained his wager in Pensées (1669) (Photo credit: Wikipedia)

Vihdoin vanhallakin välähtää. Yleensä pyrin ahtamaan artikkeliin kamalasti tauhkaa, mutta mietin että nytpä olisi hyvä idea kirjoittaa samaan tahtiin, kun opettelen itse kirjoittamaan koodia Androidille.

Taustana on javaa ja kahvia; sinänsä artikkeli ei tule olemaan kovin teknisesti haastava, vaan enemmänkin joriseva ja mobiilimaailmaa kahlaileva. Toivon, että se innostaa porukkaa tutustumaan oman puhelimensa ohjelmoitavuuteen, ja kenties voi olla jollekulle ponnahduslauta ohjelmoinnin jaloon maailmaan.

Kirjoitan myös hieman puhelinteknologiasta ja verkoista, sikäli kun ymmärrän niitä itse. En ole tämän alan ekspertti, vaan enemmän keskittynyt nimenomaan kirjoittamaan koodia, käyttöliittymiä ja selittämään näitä kahta. Mobiilikoodi on ollut oppimislistalla pitkään, mutta joskus homma on aloitettava. Androidin myötä tulee selkeä Java-rajapinta, joka näyttää hyvin puhtaalta ainakin tällaisen keltanokan silmään.

Artikkelisarja on jaoteltu näin:

  1. osa: “miten ennen kaikki oli paremmin, ja nykyhetken kauhistelu”
  2. kädet taskusta ja ohjelmointityökalujen asennus koneeseen
  3. äh, ei se toiminutkaan?!
  4. No nyt saatiin tulosta!
  5. Mitä kannattaa tutkia taitojen parantamiseksi?

Vanhana ohjelmoijana varmaan kaihtaa helposti monimutkaisen näköisiä sovelluskehitysalustoja. Sitä on aikoinaan tottunut ensin kirjoittamaan lähdekoodin pienellä tehokkaalla editorilla, ja perään kääntämään sorsan valmiiksi ohjelmaksi valonnopealla Borlandin kääntäjällä.

En koskaan oikein jaksanut perehtyä Symbianiin tai muihin mobiilialustoihin; Symbianin dokumentteja vilkaisin, mutta muutamien tuntien pähkäilyn jälkeen olin edelleen tuskastuttavasti lähtökuopissa ja silmissäni vilisi käsittääkseni noin 7-8 eri kehitystyökalun pakkopulla… joten jätin sen kesken.

Palm-koodaus oli joskus mielessä, mutta aika ajoi ohi. Omistin ylpeänä Psion Revo taskutietokoneen vuoden 2000 kieppeillä, ja näpyttelin sitä aina bussimatkoilla Otaniemen ja Espoon Piilaakson välillä. 🙂 Nuo PDA-laitteethan eivät (yleensä) olleet vakiona verkoissa, tosin osan niistä sai käyttämään erilaisia kommunikointimuotoja jos jaksoi hikoilla ja jumpata tekniikkaa.

Toki 1990-luvun omat projektit tosiaankin olivat aivan erilaisia. Tein suurinpiirtein 400-500 ohjelmaa huvikseni tietokoneille. Alustoina olivat pienet kotitietokoneet ja PC; yleensä kielivalintana Pascal + assembler. Ohjelmat löytyvät vieläkin kovalevyltä, ja niihin on joskus tosi kiehtovaa palata – katsomaan, miten silloin ajatteli, miten koodasi, ja erityisesti myös: miten suuri merkitys oli tiimiytymisellä, ideoiden jakamisella kavereiden kesken ja yhteisillä koodisessioilla.

Olimme tavallaan “agile” jo silloin 1990-luvun alkupuolella, 13-15 -kesäisinä teineinä. Juomat olivat tutut: kahvi, Cokis ja vesi.

Välillä mentiin konekieleen, tai pamauteltiin suoraan muistipaikkoihin bittejä heksaeditorilla. Joskus käyttöjärjestelmä loogisesti näytti ohjelmoijakokelaalle, mitä tapahtuu kun annetaan vääriin kohtiin sähköshokkeja – sehän kaatui suorilta jaloilta. Ei muuta kuin bootti, ja takaisin kokeilemaan.

Androidissa olen huomannut yhden merkittävän piirteen: ohjelmien ajonaikainen koodi+muistinkäyttö on yllättävän pientä. Osa ohjelmista on vain muutaman 10 Kilotavun, joka on todella pientä tämäntyyppisessä maailmassa. Tietenkin isoimmat ovat 10 megatavun luokkaa. Yleensä mobiiliohjelmia on nimenomaan vaivannut se paradoksi, että ne ovat kuin elefantit syrjäkylän antiikkiliikkeessä. Kun rajoitteet ovat olleet pahimmat, koodi on ollut aika bloattia.

Tuonaikaisten PC:eiden käynnistymisaika oli kovalevyjen markkinoilletulon jälkeen erittäin hyvä – sitten myöhemmin graafisten käyttöjärjestelmien kompleksisuuden myötä ajat venyivät; ja kohta ne taas trimmautuvat, kun Googlen käyttöjärjestelmää alkaa olla saatavilla kera SSD-muistin.

Jokaisen mobiilialustan periaatteet ovat oikeastaan aika samanlaiset. Tosin iPhone:n IOS:stä en ole saanut kokemusta. Mutta olettaisin että seuraavanlaista sielläkin on:

  • rauta = sensorit (kamera, kiihtyvyys), prosessori, muisti
  • mahdollisesti eriytetty kriittisten prosessien käyttöjärjestelmä
  • varsinainen käyttäjätason “vapaa” käyttöjärjestelmä, jossa saa melskata ja kirjoitella jätkänshakkiohjelmia
Koska käyttöjärjestelmä on nykypuhelimissa jo varsin kehittynyt ja vapaasti ohjelmoitava, kannattaa huomata, että sitä myös vaivaavat klassisten käyttöjärjestelmien tietoturvaongelmat – ja tukku uusia, jotka liittyvät lähinnä hieman arvaamattomampien tilanteiden esiintymiseen (puhelin kulkee taskussa mukana tuntemattomiin ympäristöihin) ja mm. siihen, että hankala haittaohjelma voi tuottaa päänsäryn lisäksi isoja puhelinlaskuja.

Kuten tietokone, myös puhelin on käytännössä arkkitehtuuriltaan kuin pieni tietokone. Eikä enää niin pienikään. Nykyisissä älypuhelimissa pörrää jo lähelle 1 GHz:n nopeuksiset prosessorit. Androidissani (ZTE Blade Android2.2) on 700 MHz prossu. Se tuntuu toimivan yllättävän hyvin, ja kaikkialla käyttöliittymä on siedettävän jouhea.

Mobiilikäyttöjärjestelmiä on itse asiassa kymmeniä, mutta joudun keskittymään artikkelissa periaatteessa Google Androidiin ja hitusen pystyn avaamaan myös Symbianin historiaa.

Puhelimissa on niinikään PC-maailmaa mallintaen myös esimerkiksi näytönohjain, eli pääprosessorilta otetaan grafiikan luomisen ja päivityksen taakka pois ja annetaan erikoistuneen grafiikkaprosessorin hoitaa homma näpsäkästi.

Klassisesti aivan alkuaikojen puhelimet olivat hyvin suljettuja järjestelmiä, joihin pystyi korkeintaan vääntämään muutaman bitin haluamakseen jollain erikoisohjelmalla (esimerkiksi puhelimen ikonit saattoi piirtää pikseli kerrallaan, tai apuohjelmalla pystyi PC:llä luomaan omia soittoääniä). Joka tapauksessa tällöin oltiin vielä kaukana nykyisestä avoimesta arkkitehtuurista.

Puhelimen suunnittelijan kannalta haasteellista itse asiassa on keskeytykset. Keskeytyksiä tapahtuu, kun puhelimen prosessori saa signaalin ulkoisesta tapahtumasta: sisääntuleva soitto, saapuva tekstiviesti, mahdollisesti myös tukiaseman vaihtuminen toiseen; oleellista on, että käyttöjärjestelmän koodi käsittelee keskeytyksen hyvin nopeasti – tai tarkemmin sanottuna, ottaa sen käsittelyyn. Nimittäin jos tämä koppi jää tekemättä, voi esimerkiksi puhelu jäädä kuulematta, tai muuta – eihän se kuolemanvakavaa ole, mutta vastannee nyt kuitenkin suurinpiirtein samaa kuin catwalk-mallin kompastelu maahan.

Perinteisesti keskeytysten käsittelyssä on kaksi strategiaa: se voidaan kokonaan nakittaa ulkopuoliselle raudalle (prosessorille), tai keskeytykset otetaan prioriteettijonoon ja niitä pyöritetään resurssien ja tarpeiden mukaan yhdellä prosessorilla. Joka tapauksessa myös useamman prosessorin mallissa pääprosessorin pitää jollain tapaa tietää mitä ulkomaailmassa tapahtuu, joten kommunikointi on tarpeen.

Keskeytysten yhteydessä voit törmätä termiin IRQ – interrupt request. Nämä ovat “nimitauluja”, itse asiassa vektoreita eli laskeutumisosoitteita. Osoitteen päästä löytyy sopiva rutiini, joka käsittelee kunkin keskeytyksen. En ala sekoittaa tässä yhteydessä kertomalla keskeytysten ketjutuksesta; se on tarpeetonta. Idea siis on: IRQ on osoite koodiin, joka suoritetaan kun kyseisen keskeytyksen tyyppinen tapahtuma laukeaa.

Tukiasemat ovat mobiilikielellä MSS eli Mobile switching station. Sinänsä niissä ei ole mitään mystistä, verrattuna muuhun radiotekniikkaan.

Karkeistaen voidaan sanoa, että MSS on pidemmän kantaman langaton verkko, jonka ylläpitopuolella on hieman järeämpää teknologiaa kuin kodin langattomissa verkoissa.

MSS pitää rekisteriä puhelimien sijainnista, laskutuksista ja muusta tällaisesta operaattorin kannalta olennaisesta. Tukiasemiin liittyy myös mobiilimaailman salaisuus: vain tukiaseman ja puhelimen välinen tietoliikenne on yleensä langatonta; sen jälkeen data viedään ihan normaalisti nopeissa kuituyhteyksissä sinne, missä toisen (vastapuolen) puhelin sijaitsee – ja taas radioteitse puhelimeen. Eli puhelinteknologia yhdistää tietoliikenteessään suvereenisti langatonta ja perinteistä tekniikkaa.