Olen taas 20 vuotta jäljessä pelien nykykehityksestä, kuten yleensä ja päätin ruveta tekemään Wolfenstein 3D:n kaltaista raycasteria.
Tämän hetkinen versio on kirjoitettu Hollywoodilla ja on vielä helskutin hidas, mutta muuten toimiva.
Toteutettuna on teksturoidut seinät, lattia ja katto. Lisäsin mukaan vielä jonkunlaisen distance shading toteutuksen, jotta kauempana olevat seinät, lattia ja katto näyttävät tummemmilta, kuin lähellä olevat. Sprite tuki on vielä työn alla.
Painamalla: Alt + Enter: täyteen ruutuun, 1: tekstuurit seiniin, 2: tekstuurit lattiaan, 3: tekstuurit kattoon
Seinä tekstuurit täytyy olla päällä, jotta lattia ja katto tekstuurit saa päälle.
Tuolta se nyt näyttääpi: http://img840.imageshack.us/img840/1866/
Onko täällä kukaan toteuttanut Wolfenstein 3D:n tyylistä raycasteria? Minkälaisia nopeuksia saitte ohjelman piirrosta irti?
Oma tämän hetkinen toteutukseni on kirjoitettu Hollywoodilla ja samaisesta syystä erittäin hidas, koska Hollywood tekee kaiken piirtämisen softalla. Ajatuksena olisi kuitenkin kirjoitella raycaster uudelleen BlitzMax:illa, jolloin nopeutta pitäisi tulla kohtalaisesti lisää, vai tuleeko?
Kokeilkaa ja kertokaa mitä mieltä olette
Numeronäppäimillä 1-7 voi muuttaa piirtotilaa. Tuosta näkee myös hyvin, että mitä enemmän ruudulle pitää tavaraa saada pikseli kerrallaan, niin nopeus putoaa aika rajusti.
jalski kirjoitti:
Kokeilkaa ja kertokaa mitä mieltä olette
Olen sitä mieltä, että koodissasi on aika paljon optimoimisen varaa. Wolfenstein 3D toimii 286:lla nopeammin, kuin mitä tuo sinun demosi 6-tilassa Athlon 64 6400:lla Winen päällä.
Samaa mieltä olen: ei kieltä voi syyttää noin mahdottomasta hitaudesta, eikä myöskään softarenderöinti käy syyksi, koska eihän W3D:n aikaan edes ollut saatavilla rautatukea. Sitä paitsi jopa 2000-luvun alkupuolen pelit toimivat nykykoneilla softarenderöinnillä ihan hyvin, vaikka niissä käytetään raskaampaa rasterointia eikä pelimaailmoista voi tehdä samanlaisia oletuksia kuin W3D:stä (yksi taso, pystysuorat seinät jne.).
-tossu- kirjoitti:
Olen sitä mieltä, että koodissasi on aika paljon optimoimisen varaa. Wolfenstein 3D toimii 286:lla nopeammin, kuin mitä tuo sinun demosi 6-tilassa Athlon 64 6400:lla Winen päällä.
Wolfenstein 3D:hen verrattaessa oikea demon tila on muuten 4. Wolfenstein 3D:ssä ei nimittäin ole teksturoitua lattiaa, eikä kattoa.
Ja mitä optimointeihin tulee, niin se ei ole tässä hirveän helppoa: Hollywood on käytännössä skriptikieli, mikä käyttää Lua:n kerneliä virtuaalikoneenaan. Se ei siis käännä ohjelmaa konekielelle, vaan käytännössä linkittää playerin ja skriptin exe-tiedostoon. Se ei myöskään tarjoa numeroita varten kuin yhden 64-bittisen tietotyypin.
Metabolix kirjoitti:
Samaa mieltä olen: ei kieltä voi syyttää noin mahdottomasta hitaudesta.
Kuten yllä kerroin, Hollywood ei tarjoa erillisiä tietotyyppejä kokonais -ja liukuluvuille. Ennen paljon käytetty optimointi tapa laskea kokonaisluvuilla fixed-point muodossa ei ole käyttökelpoinen. Piirtämisen optimointikaan ei ole kovin helppoa, kun näytönkäsittelyyn käytössä on vain Hollywoodin tarjoamat peruspiirtofunktiot.
Kyllähän tuosta nopean saisin 386-koneellakin, kun kirjoittaisin ohjelman assemblerilla, käyttäisin fixed-point laskentaa. Korvaisin sinin ja kosinin laskennan taulukkototeutuksella. Neliöjuurenkin laskennan voisin korvata nopeutta varten optimoidulla riittävän likiarvon tuottavalla versiolla. Piirtämistä varten valitsisin lineaarisen näyttötilan, tekisin piirtämisen ja täytöt aina 4-pikseliä kerrallaan, kun se olisi mahdollista.
jalski kirjoitti:
Kuten yllä kerroin, Hollywood ei tarjoa erillisiä tietotyyppejä kokonais -ja liukuluvuille. Ennen paljon käytetty optimointi tapa laskea kokonaisluvuilla fixed-point muodossa ei ole käyttökelpoinen.
Missä on suhteellisuudentajusi? Nykykone laskee liukulukujakin kymmeniä kertoja nopeammin kuin W3D:n aikaiset koneet kokonaislukuja, ja muutenkaan liukuluvut eivät enää ole dramaattisesti hitaampia kuin kokonaisluvut.
Tein ihan demona tässä raycasterin JavaScriptilla HTML5:n canvas-elementille. Tuskin voit väittää, että tämä menetelmä olisi Hollywoodia tehokkaampi, ja ainakaan koodia ei ole tippaakaan optimoitu. Lopputulos on kuitenkin ainakin Chromiumilla ja Operalla aika hyvä, ensin mainitulla FPS useita kymmeniä ihan tapotavallisella halpiskoneella. Epäilemättä jollain "oikealla" peliohjelmointikielellä tuon saisi melko pienellä vaivalla nopeutettua vielä moninkertaiseksi.
Kattoa ja lattiaa en jaksanut teksturoida.
Edit: Tässä muuten nähdään aika kivasti Firefoxin ja Chromiumin nopeusero. Myös Opera pesee Firefoxin mennen tullen. Nelosversiota odotellessa...
Metabolix kirjoitti:
Tein ihan demona tässä raycasterin JavaScriptilla HTML5:n canvas-elementille. Tuskin voit väittää, että tämä menetelmä olisi Hollywoodia tehokkaampi, ja ainakaan koodia ei ole tippaakaan optimoitu. Lopputulos on kuitenkin ainakin Chromiumilla ja Operalla aika hyvä, ensin mainitulla FPS useita kymmeniä ihan tapotavallisella halpiskoneella. Epäilemättä jollain "oikealla" peliohjelmointikielellä tuon saisi melko pienellä vaivalla nopeutettua vielä moninkertaiseksi.
Kattoa ja lattiaa en jaksanut teksturoida.
No, eipä tuo sinunkaan toteutuksesi omalla vanhalla Windows-koneellani paljoa nopeudella juhli. Pelkät seinätekstuurit päällä ja ruudun koko pienempi, kuin omassa versiossani, ohjelmasi saavuttaa huiman 5 FPS nopeuden! ;-)
Oma pointtini oli, että piirtäminen pikseli kerrallaan on Hollywoodilla hidasta! HTML5:n canvas elementin toteutuksesta en tiedä, mutta epäilen sen olevan kuitenkin nopeampi ja käyttävän apuna kiihdytyksiä, ainakin skaalauksen pehmennyksistä päätellen ja siitä, että piirtonopeus oli sama tekstuurien kanssa ja ilman.
Et voi tosissasi väittää, että Wolfenstein 3D:n aikaan piirtorutiinien optimointi ei olisi ollut helpompaa toteuttaa lineaarisella 8-bittisellä 256-värin näyttötilalla, missä yksi tavu vastaa yhtä pikseliä nykyisen 32-bittisen alpha-kanavallisen näyttötilan sijaan.
jalski kirjoitti:
Oma pointtini oli, että piirtäminen pikseli kerrallaan on Hollywoodilla hidasta!
Vähän epäilen että tuossa tehdään aika reippaasti turhaa laskentaa. Vaikka sen saisikin optimoitua, niin silti ihmetyttää miksi ohjelman tekoon on valittu työkalu, jonka jo alunperin tiedetään olevan huono valinta? Ei kai kukaan valitse sahaa, jos täytyy naulata nauloja?
Torgo kirjoitti:
Vähän epäilen että tuossa tehdään aika reippaasti turhaa laskentaa. Vaikka sen saisikin optimoitua, niin silti ihmetyttää miksi ohjelman tekoon on valittu työkalu, jonka jo alunperin tiedetään olevan huono valinta? Ei kai kukaan valitse sahaa, jos täytyy naulata nauloja?
Tehdäänhän tuossa turhaa laskentaa, jonka voisi laskea valmiiksi esim. tummennan y-puolen seinien piirrossa jokaisen pikselin jakamalla sen RGB-arvon kahdella (ja pikseleitähän blitataan kohtuullisen paljon per frame).
Mitä tulee työkalun valintaan, niin Hollywood on oiva työkalu ideoiden toimivuuden testaamiseen. En lähtenytkään ensimmäiseksi toteuttamaan nopeinta mahdollista toteutusta, vaan toimivan. Tähän tarkoitukseen Hollywood on kyllä paras tietämäni työkalu.
jalski kirjoitti:
ohjelmasi saavuttaa huiman 5 FPS nopeuden! ;-)
Taisit siis testata Firefoxilla, vaikka ihan erikseen mainitsin, että se on hidas? Jos viitsit kokeilla Chromiumilla tai Safarilla, FPS nousee arviolta 10-kertaiseksi. Minusta olisi omituista, jos natiivikoodiksi käännettävällä kielellä (kuten Hollywood käsittääkseni on) ei pääsisi yhtä hyvään tulokseen.
jalski kirjoitti:
HTML5:n canvas elementin toteutuksesta en tiedä, mutta epäilen sen olevan kuitenkin nopeampi ja käyttävän apuna kiihdytyksiä
Ei voi käyttää: FPS muuttuu lineaarisesti mukana, kun säädän prosessorin nopeutta. Mainitsemasi lineaarinen pehmennys ei vaadi kovin huimaa laskentatehoa.
jalski kirjoitti:
Et voi tosissasi väittää, että Wolfenstein 3D:n aikaan piirtorutiinien optimointi ei olisi ollut helpompaa toteuttaa ...
En ole näin väittänytkään, vaikka eipä tuo näyttötila olennaisesti asiaa mutkista. Pointtini kuitenkin on, että nykykone pystyisi ajamaan W3D:tä vaikka täydellisen x86-emulaation alla, joten jopa melko huonolla kielellä ja ohjelmointiympäristöllä pitäisi saada aikaan yhtä nopeasti toimiva systeemi. Et voi tosissasi väittää, että yhden nykyaikaisen pikselin kopiointi veisi enemmän aikaa kuin vanhanaikaisen pikselin kopiointiin tarvittavien 286-komentojen emulointi yksitellen.
Veikkaan, että toteutuksessasi on jokin olennainen virhe, joka hidastaa ohjelmaa tuntuvasti. Lähdekoodista sen ehkä voisi bongata, tai sitten kyseessä on jokin seikka, joka Hollywoodista pitäisi vain tietää (itse toteutettava kaksoispuskurointi tms.).
Oma tuotokseni oli siis vielä täysin optimoimaton. Itse asiassa tulin jo maininneeksi suurimman tällä hetkellä omaa toteutustani hidastaneen tekijän.
Teksturoimattomana nopeus on kuitenkin tällä hetkellä helposti asetetut 50 framea sekunnissa. Piirsin aiemmin aina y-puolen seinien tekstuurit tummempina yksinkertaisesti jakamalla tekstuurista haetun värin RGB-arvon kahdella. Vaihdoin tämän nyt siten, että x -ja y-puolen seinille on molemmille omat tekstuurinsa, toinen vaaleampi ja toinen tummempi. Tällä eliminoitui pois kohtuullisen moni jakolasku teksturointi silmukassa.
Toinen asia, mikä nopeuttaisi asioita huomattavasti olisi se, että lattian ja katon teksturoinnissa käytettävät etäisyyslaskut voisi kaikki laskea valmiiksi taulukkoon. Tällä eliminoituisi lisää huomattava määrä laskentaa lattia -ja kattotekstuurin pikselien piirrossa.
Heh, Pienellä helpillä BlitzMax foorumilta!
Pelkät teksturoidut seinät käsittävä BlitzMax-toteutus pääsee 800x600 resoluutiolla n. 300-400 FPS lukemiin. Mielenkiintoista nähdä, mihin pääsee, kun lisäilen tuohon vielä kaikki mitä Hollywood-toteutuksessakin on mukana.
Oisko mahdollista saada lähdekoodi sellasessa muodossa että osais muuttaa sen SDL:älle?
Haluisin kokeilla fullscreenillä tota hommaa.
Ihan mielenkiinnosta.
:)
DumTom kirjoitti:
Oisko mahdollista saada lähdekoodi sellasessa muodossa että osais muuttaa sen SDL:älle?
Käytin lähtökohtana tätä tutoriaalia.
Samaisen linkin takaa löydät myös valmiin C-toteutuksen. Tutoriaalissa on selitetty hyvin kaikki tarvittava lähdekoodin toiminnan ymmärtämiseksi. Tuosta se on myös helppo kääntää mille tahansa muulle ohjelmointikielelle ja tehdä myös omia lisäyksiä ja parannuksia.
Hollywood-versiota siis hidasti se, että kaikki piirrettiin pikseli kerrallaan ja jokaista pikselipiirtoa varten jouduttiin kutsumaan funktiota, ja noita funktio-kutsujahan tuli kohtuullisen paljon raycasting-silmukassa. Myöhemmin havaitsin, että DisplayBrushPart() - funktio pystyi myös skaalaamaan Hollywoodin standardi tagien avulla. Homma nopeutui aika saakelisti, kun teksturoitu pystysuora seinäviipale saatiin nyt piirrettyä aina pelkästään yhdellä funktiokutsulla.
Mitä tulee BlitzMax-toteutukseen, niin tuo aiemmin kertomani n. 300-400 fps lukema oli hiukan alakanttiin. Tuo oli siis debug-buildin arvo ja release buildilla päästiinkin jo n. 1200 fps lukemiin.
Aihe on jo aika vanha, joten et voi enää vastata siihen.
