Peliohjelmointi

Sen kyllä tiedän ettei uutta ohjelmointikieltä hetkessä opita. Enkä ajatellut peliä parissa tunnissa vasemmalla kädellä koodailla. Jos joku tietää hyvän ohjelman/kirjan josta olisi apua peliohjelmmoinnin aloittelijalle niin kertokaa!

noob kirjoitti:

Sen kyllä tiedän ettei uutta ohjelmointikieltä hetkessä opita. Enkä ajatellut peliä parissa tunnissa vasemmalla kädellä koodailla. Jos joku tietää hyvän ohjelman/kirjan josta olisi apua peliohjelmmoinnin aloittelijalle niin kertokaa!

Lue lisää

Alkuun pääsee jo lapsikin (itse olen tätä kirjoittaessani 13v poika...)! Niin että siis HYVIN yksinkertaisia pelejä voi kyllä tehdä HYVIN VÄHÄLLÄ opettelulla. Kannattaa lähteä tästä: Kirjasto>>>Lainaa JavaScript - kirja>>>>>Opettele! Se on hyvin yksinkertainen kieli>>>>Tee peli. Mutta muista: tällä kielellä ei saa toteutettua kovin graafisia pelejä. Käy kattomassa mun kotisivut js.w2.fi. jos ei toimi, ni koita remix.suntuubi.com. Siel on jotai...

katsoin tuossa äskein tuota java linkkiä
http://www.cs.joensuu.fi/~mwolff/dokumentointi/index.html

ja huomasin ,että java ja c ovat melkein samanlaisia.

nyt kysyisinkin ,että mitä eroa on c ohjelmointikielessä verrattuna java ohjelmointikieleen?

Javalla on kuitenkin yksi valtti Flashiin verrattuna: suoritusnopeus. JVM kun revittelee lähellä natiivin C :n nopeutta. Säikeitä saanee (en ole täysin varma saiko appleteissa) monta tarvittaessa, yksi voi hoitaa grafiikkaa, toinen pelin logiikkaa yms.

Javan käyttöliittymänopeus on tietysti hidas, mutta piirtää suoraan int-taulukkoon ja sieltä graffat suoraan näytölle. Quake3:n tasoinen räiskintä on täysin mahdollinen. Nopeilla 4 ytimellä ehkäpä Doom3-tasoinen 640x480 koossa. Tosin grafiikkakiihdytystä ei voi käyttää normaalisti, kaikki grafiikka on tehtävä laskemalla - koodaaminen on siis vaikeaa. Nopeuden vuoksi on hyvä idea käyttää kokonaislukuja mahdollisimman paljon, laskea kaikki mahdollinen sisimmän loopin ulkopuolella etukäteen ja välttää luomasta objekteja ajon aikana, jottei garbage collection käynnisty.

Pelin reaaliaikaiseksi tekstikonsoliksi voisi napata minkä tahansa Javalla toteutetun skriptakielen. Kaikkea löytyy, vaikkapa Python, Ruby tai Javascript. Tai sitten voi ohjata Java-applettia selaimen javascript-tulkin kautta.

Jos joku epäilee nopeutta, mainittakoon että Java-pohjaisella x86 PC-emulaattorilla Doom3D on pelattava!

.. kirjoitti:

Javalla on kuitenkin yksi valtti Flashiin verrattuna: suoritusnopeus. JVM kun revittelee lähellä natiivin C :n nopeutta. Säikeitä saanee (en ole täysin varma saiko appleteissa) monta tarvittaessa, yksi voi hoitaa grafiikkaa, toinen pelin logiikkaa yms.

Javan käyttöliittymänopeus on tietysti hidas, mutta piirtää suoraan int-taulukkoon ja sieltä graffat suoraan näytölle. Quake3:n tasoinen räiskintä on täysin mahdollinen. Nopeilla 4 ytimellä ehkäpä Doom3-tasoinen 640x480 koossa. Tosin grafiikkakiihdytystä ei voi käyttää normaalisti, kaikki grafiikka on tehtävä laskemalla - koodaaminen on siis vaikeaa. Nopeuden vuoksi on hyvä idea käyttää kokonaislukuja mahdollisimman paljon, laskea kaikki mahdollinen sisimmän loopin ulkopuolella etukäteen ja välttää luomasta objekteja ajon aikana, jottei garbage collection käynnisty.

Pelin reaaliaikaiseksi tekstikonsoliksi voisi napata minkä tahansa Javalla toteutetun skriptakielen. Kaikkea löytyy, vaikkapa Python, Ruby tai Javascript. Tai sitten voi ohjata Java-applettia selaimen javascript-tulkin kautta.

Jos joku epäilee nopeutta, mainittakoon että Java-pohjaisella x86 PC-emulaattorilla Doom3D on pelattava!

Lue lisää

Tässä linkki Javalla toteutettuun PC-emulaattorin snapshottiin, jossa pyörii Doom. Tuohon voi asentaa vaikka Linuxin, ehkä myös Windows onnistuu...

Melko nopea, varsinkin kun pitää mielessä, että x86 on melko paha emuloitavaksi Javalla, mm. koska x86 on little endian (vähiten merkitsevä tavu ensiksi) ja Java on big endian (eniten merkitsevä tavu ekana).

http://www-jpc.physics.ox.ac.uk/doom.html

Flashi on kieltämättä aika hyvä jos haluaa tehä pelejä jotka toimii varmasti yli puolissa työasemissa joissa on nettiselain. Tai toimii ainakin sellaset kolmesta viiteen vuotta. Flashilla on kiva tehä sikälikin, että sillä tehdessä on mahollisuus saada peli myyntiin vaikka ompun äiföyniin.

Toinen tietty on sitten Java jolla on kaks tapaa tehä eli se mopiili tai tavallinen. Tiijän tosin yhen tyypin joka teki pelin sillä kolmannella eli J2EE:llä mutta hullut erikseen. :)

Oikeestaan kantsis miettiä eka se, mille haluaa tehä.

Jos kohdealusta on vaikka xbox 360 niin sillon taitaa .NET ja C# olla tavalliselle kooderille se ainoa oikea vaihtoehto kun XNA rulettaa siellä kaikkien muiden ohi. Ompullakin taitaa olla äiföönissä enempi vaihtoehtoja tekemiseen kun xpoksilla. Mutta toisaalta C# ja .NET on loistava ja upea tapa tehä eli ei ongelmaa.

.. kirjoitti:

Tässä linkki Javalla toteutettuun PC-emulaattorin snapshottiin, jossa pyörii Doom. Tuohon voi asentaa vaikka Linuxin, ehkä myös Windows onnistuu...

Melko nopea, varsinkin kun pitää mielessä, että x86 on melko paha emuloitavaksi Javalla, mm. koska x86 on little endian (vähiten merkitsevä tavu ensiksi) ja Java on big endian (eniten merkitsevä tavu ekana).

http://www-jpc.physics.ox.ac.uk/doom.html

Lue lisää

Järjettömän hidas. Tuplaytiminen muutaman kuukauden ikäinen tietotokone pyörittää peliä ehkä vähän hitaammin kuin 25 MHz 486DX tjsp. tai korkeintaan samalla nopeudella kun piirrettävän kuvan kokoa oli jo pinenennetty. Selkeästi nopeammin kuin 25 MHz 386 silloin kun peli tuli.

Jos joku löytäisi jostain prosessorien nopeusvertailutaulukon niin tästä saisi mielenkiintoista tilastoa. Pyöriikö yli 17 vuotta vanha peli tuolla tekniikalla kohtuullisen uudessa koneessa melkein yhtä hyvin kuin 20v vanhassa huippukoneessa. Eli olisiko Javalla emuloitu x86 20 vuotta jäljessä oikeaa rautaa vastaan.

Kukkuu76 kirjoitti:

Järjettömän hidas. Tuplaytiminen muutaman kuukauden ikäinen tietotokone pyörittää peliä ehkä vähän hitaammin kuin 25 MHz 486DX tjsp. tai korkeintaan samalla nopeudella kun piirrettävän kuvan kokoa oli jo pinenennetty. Selkeästi nopeammin kuin 25 MHz 386 silloin kun peli tuli.

Jos joku löytäisi jostain prosessorien nopeusvertailutaulukon niin tästä saisi mielenkiintoista tilastoa. Pyöriikö yli 17 vuotta vanha peli tuolla tekniikalla kohtuullisen uudessa koneessa melkein yhtä hyvin kuin 20v vanhassa huippukoneessa. Eli olisiko Javalla emuloitu x86 20 vuotta jäljessä oikeaa rautaa vastaan.

Lue lisää

... kerro miten muuntaisit tämän hyvin yksinkertaisen x86 esimerkin bytecodeksi:

mov ecx, ykoordinaatti
mov ebx, xkoordinaatti
mov eax, pisteenvari
shl ecx, 6
lea edi, [a0000h 4*ecx ecx]
mov [edi], al

Kun koordinaatit haetaan, muistia luetaan 32-bittisenä. Kun pikseli kirjoitetaan näytölle, se tehdään 8-bittisenä.

Millaisen taulukon tekisit vaikkapa 4 MB muistista? Vaikkapa byte[1024*1024*4]? Miten lukisit ja kirjoittaisit 32-bittisiä lukuja nopeasti silloin?

Näinkö muka?

kirjoita32Bit(byte[] muisti, int osoite, int arvo)
{
muisti[osoite] = (byte)arvo; muisti[osoite 1] = (byte)(arvo≥≥≥8); muisti[osoite 2] = (byte)(arvo≥≥≥16); muisti[osoite 3] = (byte)(arvo≥≥≥24);
}

Reilusti pinonpyöritystä, 4 kirjoitusta muistiin, 4 castia (bytecode i2b convert int to byte), 3 yhteenlaskua, 3 unsigned shift rightia (aritmeettinenkin olisi tosin tässä toiminut). JIT optimoisi pinon käytön ja i2b castit pois, mutta nopeaa tuosta ei tulisi! Onneksi ainakaan ehdollisia lauseita (if) ei ole -- väärin ennustetut ehdolliset hypyt hyydyttävät modernin prosessorin.

Tai määrittelisitkö sen 4 MB muistin int[1024*1024]? Vastaus ei muuten ole suora sijoitus taulukkoon, koska x86 sallii misaligned lukemisen/kirjoituksen. Misaligned tarkoittaa sitä, kun operaation osoite ei ole jaollinen sen koolla, eli vaikkapa 32-bittisenä osoite&3 ei ole 0. Erityisen kivaa asiasta tekee sen, että x86 tallentaa luvun 0x12345678 muodossa 0x78563412. Siinähän shiftailet ja maskailet Javalla! Entä osarekisterit, kuten rax/eax/ax/al/ah. Kun osarekisterin arvo muuttuu, koko rekisteri muuttuu. Ah:n arvon muutos vaikuttaa myös ax, eax ja rax. 32-bittinen luku ladataan vaikkapa eax:ään ja tehdään 8/16-bittistä aritmetiikkaa ax/ah/al:llä, välissä 32-bittistä aritmetiikkaa ja sitten eax kirjoitetaan jonnekin. Maskit vai virtuaaliset rekisterit, jotka tarkastetaan ja koostetaan ennen mov-käskyn suorituksen yhteydessä? Miten toteuttaisit tämän Javan bytecodella, niin että se olisi nopeaa?

Nuo operaatiot ovat tavanomaisen ohjelmiston nopeuden ja toiminnallisuuden kannalta merkityksettömiä, mutta x86-emuloinnin kannalta tappavia. Kun kaiken tämän ottaa huomioon, tuo x86 emulaattori on varsin nopea.

Jepulis Jeep kirjoitti:

Flashi on kieltämättä aika hyvä jos haluaa tehä pelejä jotka toimii varmasti yli puolissa työasemissa joissa on nettiselain. Tai toimii ainakin sellaset kolmesta viiteen vuotta. Flashilla on kiva tehä sikälikin, että sillä tehdessä on mahollisuus saada peli myyntiin vaikka ompun äiföyniin.

Toinen tietty on sitten Java jolla on kaks tapaa tehä eli se mopiili tai tavallinen. Tiijän tosin yhen tyypin joka teki pelin sillä kolmannella eli J2EE:llä mutta hullut erikseen. :)

Oikeestaan kantsis miettiä eka se, mille haluaa tehä.

Jos kohdealusta on vaikka xbox 360 niin sillon taitaa .NET ja C# olla tavalliselle kooderille se ainoa oikea vaihtoehto kun XNA rulettaa siellä kaikkien muiden ohi. Ompullakin taitaa olla äiföönissä enempi vaihtoehtoja tekemiseen kun xpoksilla. Mutta toisaalta C# ja .NET on loistava ja upea tapa tehä eli ei ongelmaa.

Lue lisää

Jos olet yläkoululainen, niin tuossa voisi olla hyvä vaihtoehto

Nuorten peliohjelmointi, viikon mittainen lyhytkurssi Jyväskylän yliopistossa, suunnattu yläkoululaisille

https://www.jyu.fi/it/laitokset/mit/opiskelu/nuortenkurssi