TOLPPA

Tolppa, eli pylväs, ja tässä tapauksessa sellainen roomalainen pylväs joka ilmaisee paljonko matkaa on kuljettu. Suomeksi siis ihan virstanpylväs, joka on nyt saavutettu MERPGissä. Meillä on nyt näyttöluokka, jonka periyttämällä saa melko CB:mäisen käyttötuntuman. Tuo luokka osaa piirtää tekstiä annettuun sijaintiin, ja koska teksti annetaan text()-funktiolle std::string - viittauksena, voi tekstin koota suoraan kutsuun seuraavasti:
Text(0,10,"HiiriX: "+hiiriX()+"   hiiriY:"+hiiriY()); //Tyyli on..... lainattu cb-foorumilta, jos näin ei saisi tehdä, on blogissa vieraskommentointi syystä sallittu
Eli parametriin voi asettaa kaikkia niitä tietotyyppejä, joille on ylikuormitettu + - operaattori std::stringissä. Toiminnallisuus on siis paljon kivempi kuin const char* - teksteissä, jotka eivät tue minkäänlaisia kikkailuja, ja sitäkin huonosti.

Lisäksi näyttöluokka ainakin taipuu samanlaiseen piirtelyyn kuin CB:n piirtelyapi,  jos en ole näitä funktioita jo toteuttanut. Luokan getObject/-Anim/-Map - funktiot taas luovat pyydetyn olion, lisäävät siitä osoittimen näyttöluokan piirtojonoon (joka on oikeasti vektori, mutta kun kerran sille on jono - lempinimen antanut niin se sillä pysyy), ja palauttavat tämän osoittimen käyttäjälle. Piirtojono mahdollistaa sen, että kun DrawScreeniä (kyllä, tämä CB-funktioiden apinointi on ihan tarkoituksenmukaista :D lukekaa loppuun) kutsutaan, se piirtää ensin piirtojonon jäsenet takapuskuriin, ja sitten flippaa puskureita. Eli suomeksisanottuna, käyttäjän ei tarvitse erikseen piirtää jokaista lataamaansa kuvankaltaista näytölle, koska koneen voi laittaa tekemään se automaattisesti.

Koska Text - komento ja objektit aiheuttavat ongelmia jo CB:ssä, toteutin näyttöluokkaan myös DrawGame()n, joka piirtää piirtojonon takapuskuriin, jonka jälkeen käyttäjä voi piirtää tekstinsä pelkäämättä että objektit piirtyisivät niiden päälle. Ilman DrawGamea tilanne olisi se, että ensin pääluupissa käyttäjä piirtää tekstejä innoissaan, ja sitten kutsuu DrawScreeniä, joka piirtää objektit ruudulle - suoraan tekstien päälle.

Piirtojonon-rakenteen huono puoli on siinä että käyttäjä ei voi vaikuttaa piirtojärjestykseen muuten kuin lataamalla mediansa oikeassa järjestyksessä (kuvien pointterit lisätään piirtojonoon latausjärjestyksessä). Jos olisin oikein viisas, vaihtaisin piirtojono - vektorin joksikin muuksi tietorakenteeksi, ehkä listaksi, joka mahdollistaa A) läpi-iteroinnin ja B) karttojen asetuksen piirtojonon ensimmäisiksi piirrettäviksi ja muiden asettamisen jonon (LISTAN!!!) loppuun.


Ja niin, onhan meillä muitakin luokkia. Näyttöluokan sisällä koodaavalle kiinnostavia luokkia ovat MEOBJEKTI, MEMAP ja ärsyttävän epäjohdonmukaisesti nimetty ANIMAATIO. Nuo perivät samoja kantaluokkia, joten niiden käyttö on melko samanlaista. Oikeastaan ANIMAATIO ja MEMAP perivät objektiluokan, joten piirtojono oli johdonmukaista toteuttaa MEOBJEKTI* - tyyppisenä rakenteena. Eli jos osaat käyttää MEOBJEKTIA, eivät animaatio ja kartta ole vaikeita. Mitään näistä ei voi suoraan luoda, vaan näyttöluokka hoitaa luonnin, ja siltä saa pyydettyä getObject/-Anim/-Map - funktioilla pointterit uusiin olioihin. Käyttäjälle saattaisi olla ehkä fiksumpaa tarjota viittaus olioihin, mutta en usko että kukaan luokan käyttäjä on niin tyhmä että menee seuraavaan ansaan:

MEOBJEKTI* objekti = getObject("opjekti.bmp");//tee jotain opjektilleobjekti = jotain_muuta;

Kuka tahansa pelkkää CB:täkin koodaillut tajuaa että tässä menee väärin. Siksi en ala avaamaan miksi tämä on väärin, vaan annan seuraavan CB-koodin:


ukkeli = LoadObject("opjekti.bmp")'tee jotain ihmeellisyyksiä objektille
ukkeli = LoadObject("Anööther opjekti")

Tämä on siis klassinen muistivuoto, objektin osoitin hukataan ja objekti jää ikuisesti seilaamaan halki kartoittamattoman RAM-meren. Tämä on ainoa muistinkäytöllinen asia, josta käyttäjän on huolehdittava näyttöluokan sisällä, sillä näyttöluokka varaa puoliautomaattisesti tarvittavan muistin ja vapauttaa myös.

Esittelen noita luokkia myöhemmin lisää :P nyt lähden kouluun

Sitäpaitsi, jos joku ei vastusta, saatan kirjoittaa Fairandcrueliin tuton siitä, kuinka helppoa näyttöluokan sisällä koodailu on.