Ristinolla-kilpailun aikoihin, kun aioin kääntää QB-tekoälyni Exeksi, huomasin, että käännetty ohjelma toimi aivan toisin kuin QBasicin koodieditorilla ajettuna, ja aiheutti lopulta omituisia virheitä. Tästä seurasi, että jouduin porttaamaan tekoälyni VB:lle. Se onnistui hyvin, ja sen takia unohdin kaikki QB:n ongelmat.
Nyt ongelma tuli kuitenkin uudelleen vastaan, kun aloin tehdä 2d-tasohyppely-räiskintä -tyyppistä peliä. Nyt minua kiinnostaisi ihan tietää, että onko vika yleisesti QB:n 4.5 ja 7.1 kääntäjissä, vai onko vika kenties omassa koneessani, tai jostain muusta syystä yksin minulla.
Jotkut eivät muistaakseni oikein voineet uskoa, että kääntäjä voisi tehdä virheellisiä tiedostoja, joten jos asia kiinnostaa niin lataa tämä lähdekoodi ja kokeile onnistutko kääntämään sen QBasicilla niin, että se toimisi samalla tavalla kuin koodikin.
Pistettä pelissä ohjataan nuolinäppäimillä ja hyppääminen tapahtuu Enteristä. Jos kaikki toimii niin kuin pitää, pisteellä ei pitäisi olla mahdollista päästä punaiseen läikkään, mutta kuinka mahtaa käydä käännetyssä Exe:ssä?
Ilmoittakaa, jos havaitsette muita eroavaisuuksia koodin ja Exen välillä, tai joitain ratkaisuja, joilla ongelma katoaisi. olen nimittäin käynyt läpi luullakseni kaikki mahdolliset vaihtoehdot Exe-käännön asetuksista, ja ongelma pysyy yhä samana.
Testasin tuon lähdekoodina & exenä, ja kyllä niissä eroja on. Exessä enterin painaminen monta kertaa aiheuttaa korkeamman hypyn. Ongelma saattaisi ratketa jos onnistuisit jotenkin tekemään tarkistuksen tyyliin "onko piste maassa vai ei?" jos on, voi hypätä uudestaan, jos ei, on hyppääminen estetty.
No siinä koodissahan nimenomaan on sellainen tarkistus :)
Kokeile ajaa koodi QB:n editorilla, niin huomaat sen. Ja minulla muuten riittää, kun painan vain yhden kerran Enteriä Exessä, niin hypystä tulee silti korkeampi kuin QB:n editorilla ajettuna. Kaikki virheet viittaavat minusta ongelmiin muuttujien käsittelyssä. Jostain syystä muuttuja, joka määrää kuinka nopeasti piste liikkuu ylöspäin vähenee liian vähän, vaikka sen pitäisi vähentyä ihan yhtä nopeasti kuin koodissa.
Juu... Näyttääse editorilla hyppäävän matalammalle kuin exessä.
QB:n kääntäjässä voi hyvinkin olla virheitä; onhan sekin vain ihmisen tekemä. Muistan myös VB:n kolmosversiossa törmänneeni vähän samantapaiseen ongelmaan, jossa muuttujan arvo muuttui itsekseen, eikä auttanut muu kuin kirjoittaa koodi uudestaan hieman toisella tavalla.
Testasin koodia kahdella koneella, ja molemmilla tulos oli sama kuin kuvailemasi. Tutkin myös koodia jonkun aikaa, mutta en tullut juuri hullua hurskaammaksi. Outoa on myös se, että EXEssä pallo pystyy hyppäämään ilmassa uudelleen - ja näin sen minusta koodin perusteella kuuluukin mennä. Eihän hypyn alkaessa tarkisteta, että hyppy ei ole jo meneillään.
Valitettavasti en pystynyt auttamaan kunnolla ongelmassa. Mutta jos jaksat tarpeeksi huolellisesti testata ohjelman eri osien toimintaa, löydät varmaan ainakin kohdan, joka käyttäytyy eri tavalla tulkattuna ja käännettynä.
en tässä kiireessä nyt ehdi tarkistaa koodia, mutta oletkos heittänyt esim jonkun boolean määrityksen hyppyyn? siis meinaan että kun ei hypitä niin esim hyppy = false
mutta kun painetaan jotain ja hypätään, niin laitetaas samalla hyppy = true
if hyppy = false then voimme käynnistää hypyn jos painetaan jotain hyppynappia else muussa tapauksessa emme ala hyppimään... endiä
sori, en varmaa osannut auttaa ongelmassasi, täytynee repiä aikaa ja kattoo toi koodisi läpi niinkuin exekin...
Nomic, ei ongelma ole siinä, etten osaa koodata tuota peliä, eli en sinänsä tarvitse neuvoja siitä, miten tuo hyppysysteemi oli parasta toteuttaa. Sen osaan kyllä tehdä itse. Ongelma on siinä, että Exe ei toimi niin kuin pitäisi.
Antti Laaksonen kirjoitti:
Eihän hypyn alkaessa tarkisteta, että hyppy ei ole jo meneillään.
Kyllähän tuossa semmoinen tarkistus on. Se on vain ehkä vaikea huomata, ellei ole itse tehnyt.
IF Man(i).AboutTo.Jump THEN IF Solid(Man(i).x, Man(i).y + 1) THEN Man(i).ym = -3 Man(i).AboutTo.Jump = Man(i).AboutTo.Jump - 1 END IF
Eli selkokielellä:
Jos ukko.on.aikeissa.hypätä (eli on painettu hyppäys-näppäintä) THEN
Jos ukon alkapuolella on kiinteää (huomaa Solid-funktio, ja sen argumentit) THEN ukon.ylöpäin_liikkuminen on -3.
Aihe on jo aika vanha, joten et voi enää vastata siihen.