Tuodaan nyt c++ edustetuksi tuohon pelintekohupailuun.
Lunar lander on innoittajana. Pelissä ohjaat hienointa X-Space firman rakettia; Bacon 9. Tarkoitus on saattaa raketti onnistuneesti maahan, mieluiten ilman naarmuja.
esikäännetty versio - win & linux binäärit mukana.
Koodit löytyy githubista: https://github.com/Apodus/putka-game-2020
Voit käyttää koodia kuten parhaaksi näet. En kuitenkaan ota vastuuta itse koodin toimivuudesta tai sopivuudesta tarkoituksiisi, enkä mistään mihin sitä käytät.
Hieno. Teki heti mieli yrittää päihittää peli. Välillä tuntui tulevan joku outo lagi, missä alus yhtäkkiä syöksyy maahan (ks. 0:15 eteenpäin).
vesikuusi kirjoitti:
Hieno. Teki heti mieli yrittää päihittää peli. Välillä tuntui tulevan joku outo lagi, missä alus yhtäkkiä syöksyy maahan (ks. 0:15 eteenpäin).
Jännittävää! Mimmosella raudalla ajoit ohjelmaa ja millä käyttöjärjestelmällä? En ole kohdannut tuota käytöstä, mutta näitten schedulointijuttujen kanssa on kyllä väännetty kättä ennenkin.
Jos olit liikkeellä windowsin kanssa niin tässä olis vaihtoehtoinen exe, jos voit tuolla ajaa ja heti tuommoisen lagailun jälkeen painaa vasemmasta alakulmasta löytyvää "Log Profile" nappia, ja välittää sen tuottaman jsonin takaisin minulle niin voin katsoa mitä siellä oikein tapahtuu (tai voit itsekin sitä ihmetellä esim. chromella osoitteessa chrome://tracing)
Apodus kirjoitti:
vesikuusi kirjoitti:
Hieno. Teki heti mieli yrittää päihittää peli. Välillä tuntui tulevan joku outo lagi, missä alus yhtäkkiä syöksyy maahan (ks. 0:15 eteenpäin).
Jännittävää! Mimmosella raudalla ajoit ohjelmaa ja millä käyttöjärjestelmällä?
NVIDIA GeForce GTX 1060 6GB
Intel Core i5-7600K
16 GB (4+4+4+4) DDR4 SDRAM
Microsoft Windows 10 Home (x64)
Tsekkaan tuon exen ja tracet ja pistän sitten lisätietoa.
Taisin tajuta miten saan bugin toistumaan. Lähes aina kun rakettimoottorit starttaa, tai tulee tuo ns. räjähdysmäinen startti kun on painanut W-näppäintä hetken niin alus hyppää tuollatavoin alaspäin. Toistuu siis jos annan aluksen pudota hetken, sitten painan W kunnes starttaa. Taisin videon skenaariossa tehdä aluksi niin, että painelin W kevyesti ilman että tuli se kunnon startti ja sitten kun näin maata niin pidin pohjassa.
Okei, tracejen perusteella ei näy ainakaan mitään ylipitkiä frameja, näyttäisi olevan ihan stabiili 500fps.
Tulkitsin tosta videosta aiemmin että moottorinappi olisi pohjassa ja jostain syystä partikkelit ei näkyisi ja meno olisi slowmotionia kunnes lopulta aika lähtee liikkumaan normaalisti ja paukahdetaan maahan, mutta ilmeisesti siinä onkin tosiaan näpytelty kaasua hissukseen.
Pelissä moottorit ei käynnisty välittömästi, vaan vaativat hetken kaasun pohjassa pitämistä. Laskeutumissiivekkeiden ohjausmoottorit käynnistyvät nopeammin mutta eivät ole kovin voimakkaita - keskimoottori on selvästi voimakkaampi, mutta käynnistyy hitaasti ja on myös se joka tuottaa käynnistyessään paukahduksen.
Eli tässä nyt varmaankin käy niin ettei moottorit varsinaisesti ehdi käynnistyä missään vaiheessa ennenkuin maata tulee näkyviin, jolloin onkin ehditty kerätä jo niin paljon vauhtia painovoiman avustuksella että alkaa olla myöhäistä reagoida.
Ongelmaa varmasti voimistaa nyt se ettei pelaajalla ole mitään referenssipisteitä ilmassa joista arvioida omaa nopeutta, kunnes maata tulee näkyviin.
En saa peliä käynnistettyä. Windowsissa tulee ilmoitus puuttuvista tiedostoista MSVCP140.dll, VCRUNTIME140_1.dll ja VCRUNTIME140.dll, joten pakettiin olisi varmaan syytä laittaa vähintäänkin ohje, mistä nämä helpoiten löytyvät. Winellä tuli jokin page fault. Linuxissa esikäännetyn version GLEW-kirjastoversio ei täsmännyt, ja itse käännetyssä tulee "Failed to create GLFW window". Katsoin virheen vielä glfwSetErrorCallback-funktiolla, ja virheenä on "GLX: Failed to create context: GLXBadFBConfig". Kone on aika vanha, voiko kyse olla esimerkiksi liian vanhasta OpenGL-versiosta tai muuten puuttuvista ominaisuuksista? Voisiko ominaisuudet tarkastaa alussa ja antaa selvemmän virheilmoituksen? Tarkempaa arviota varten glxinfo.
Visual C runtimet saa ladattua tuolta
https://support.microsoft.com/en-us/help/2977003/the-latest-supported-visual-c-downloads
140 on siis 14.0 eli viimeisimmät.
Oraclekin jakelee asennuspaketteja jotka kaatuvat noiden puuttumiseen.
Metabolix, glxinfoa vilkaisten:
Max core profile version: 3.3
Peli pyytää OpenGL 4.3.
Uudemmalla koneella tosiaan toimii. Ehkä tuosta kannattaa laittaa selvempi ilmoitus.
Pelin tavoite jää epäselväksi. Ok, täällä keskustelussa lukee, että pitää laskeutua onnistuneesti. Onko tähän jokin tietty paikka ja nopeus? Itse yritin muutaman kerran, ja mielestäni varsin hitaassakin laskussa alus räjähti. Pelistä tulee mieleen kuuluisa juoksupeli QWOP.
Partikkeligrafiikka on kyllä hienoa.
Saa laskeutua itse parhaaksi katsomaansa paikkaan. Ainoa rajoite on ettei aluksen osiin saa kohdistua liian suuria hetkellisiä voimia. Tyylipisteitä ei jaeta, kertaalleen laskeuduin mm. jyrkänteeltä kaatuen ylösalaisin ojan pohjalle (ohjausmoottoreilla kaatumista hidastaen). Jos jostain löytyy suurinpiirtein tasaista maata niin siihen kohti lienee helpompi laskeutua kuin muualle.
Peli todella ei anna paljoa anteeksi, ja voi tuntua etenkin aluksi perin hankalalta.
Itse saan noin 50% laskeutumisista onnistumaan koneella jossa peli pyörii noin 500fps, mutta sitä tulikin harjoiteltua joitain kertoja koodirivejä naputellessa.
Jos frametime kipuaa kovin suureksi niin laskeutumisesta tulee kyllä hankalampaa (kokeilin myös läppärillä jossa vain integroitu gpu).
Voi rähmä! Yritin käynnistää ohjelman, mutta ei onnistunut. Minulla on ikiwanha win7 -läppäri ja ei käynnisty.
Saisiko tätä jotenkin sellaiseen kuosiin, että Viitasaaren mummokin voisi pelata?
TapaniS kirjoitti:
Saisiko tätä jotenkin sellaiseen kuosiin, että Viitasaaren mummokin voisi pelata?
Olisi toki hauskaa, jos peli toimisi myös vanhemmalla koneella. Toisaalta OpenGL 4.3 on vuodelta 2012 eli sen verran vanha, että vaatimusta ei voi ehkä pitää kohtuuttomana. Päätinkin tilata vihdoin uuden läppärin. :D
Apodus kirjoitti:
Jos frametime kipuaa kovin suureksi niin laskeutumisesta tulee kyllä hankalampaa
Näppäimistön käytön tarkkuus (myös pelaajan osalta) kuitenkin lienee pikemmin 50 fps kuin 500 fps, ja ainahan voi laittaa piirtämisen eri säikeeseen kuin itse pelilogiikan, jotta ohjaus ei häiriinny hitaasta näytönohjaimesta. Vai onko pelilogiikka jotenkin muuten fps:stä riippuvainen? Jos on, niin miksi?
Näppäimistön käytön tarkkuus on aika lailla niin tarkka kuin pelaaja itse kykenee. USB antaa kuitenkin 1ms tarkkuudella. Esittäisin esim. rytmipeleihin perustuen, että ihmisen tarkkuus voi kuitenkin olla yli 50Hz. Lisäksi täytyy huomata että mikäli peli & ihmisen input molemmat toimivat noin 50Hz taajuudella, niin worst case on se että painat nappia juuri sen jälkeen kun logiikkaframen inputit on luettu, jolloin saat syötteet perille ikäänkuin 25Hz taajuudella. Ja average on siinä puolivälissä.
Tuossa frametime asiassahan on pari eri lähestymistapaa. Voit joko valita vakiokokoisen aika-askeleen pelille ja todeta että mikäli kone ei tähän yllä niin et voi pelata. Ja mikäli koneessasi on ylimääräistä tehoa niin et hyödy niistä mitään, koska kaikki laitetaan menemään alhaisimman speksin mukaan.
Toinen vaihtoehto on pitää dynaamista aika-askeleen kokoa. Paremmalla raudalla pelaava saa kaiken irti laitteestaan ja tarkemman simulaation. Perin heikolla raudalla pelaava taas näkee simulaation laadun kärsivän, mutta ei saa suoraan ilmoitusta että no can do, osta parempi kone. Ainakin periaatteessa näin.
Molemmissa lähestymisissä on omat vahvuutensa ja heikkoutensa, mutta tässä projektissa olen mennyt jälkimmäisellä tavalla. Toki tämmösessä fysiikkaan pohjautuvassa pelilogiikassa jälkimmäinen vaihtoehto asettaa pelaajat eriarvoiseen asemaan, kun yllättäen vähemmän tarkassa simulaatiossa on helpompi saada aikaan väkivaltaisempia törmäyksiä.
Piirtämisen täytyy olla jollain tapaa synkronoitu pelilogiikan kanssa, samaan aikaan ei voi lukea pelidataa piirrettäväksi ja luoda/poistaa pelimaailman kamaa. Tässä toki voisin hoitaa asioita tehokkaammin, mutta se ei ole juuri nyt omassa tärkeyslistassani ykkösenä. Asian tekeminen paremmin vaatisi merkittäviä muutoksia scheduleriin (main threadin käsite pitäisi erotella muista, koska opengl kutsuja saa tehdä vain yhdestä threadistä), enkä koe että se olisi juuri nyt vaivan arvoista.
Apodus kirjoitti:
Esittäisin esim. rytmipeleihin perustuen, että ihmisen tarkkuus voi kuitenkin olla yli 50Hz.
Toisaalta rytmipelit ovat ennustettavia; reaktioaikaa koskevista tutkimuksista tiedetään, että ihmisen reaktioaika ärsykkeeseen on yleensä pitkälti yli 100 millisekuntia (eli tarkkuus alle 10 Hz). Tämä peli asettuu varmaan jonnekin tälle välille. Mutta kukin tavallaan.
Oletan, että tämäkin peli oli (aloitusviestin mukaisesti) tulossa kisaan mukaan. Laittaisitko vielä tiedot haluamallasi tavalla vaikka ilmoittautumislomakkeen kautta?
Aihe on jo aika vanha, joten et voi enää vastata siihen.