Quaken porttaus alustalle jolla ei käyttöjärjestelmää

[hkultala]

Onko kellään kokemuksia Quaken lähdekoodin kanssa leikkimisestä/quaken porttaamisesta eksoottisille alustoille?

Tekisi mieli portata Quake eräälle alustalle, jolle ei ole ollenkaan käyttöjärjestelmää.

Kun pikaisesti katselin niin Quaken lähdekoodista on vaikka kuinka monta eri haaraa. Itse siis tarvisin mahdollisimman minimaalista versiota, joka vaan softarendaa framepuskuriin ja sisältää minimaalisen määrän IO-/käyttöjärjestelmäkutsuja. Mikä olisi hyvä haara minkä pohjalta alkaa väsäämään?

Pelin resurssit pitäisi myös saada ladattua ilman tiedostojärjestelmää - ilmeisesti Quakessa on joku oma resurssitiedostomekanisminsa jossa kaikki pelin resurssit on käytännössä yhden ison tiedoston sisässä mikä helpottaa tätä, pitää vaan saada toteutettua IO jolla tämän yhden tiedoston sisältö saadaan ladattua muistiin?

 

[Zener]

Olisiko helpompaa tuolle alustalle sovittaa jokin käyttöjärjestelmä, joka pyörittää Quakea?

 

[hkultala]

Olisiko helpompaa tuolle alustalle sovittaa jokin käyttöjärjestelmä, joka pyörittää Quakea?

Luulisin, että ei; Alusta on sen verran outo ja joillain tavoilla rajoittunut, että kaikki yleiset käyttikset on poissa laskuista, lähinnä mahdollisia voisi olla jotkut pienet yksinkertaiset RTOS:t, mutta niilläkään ei varmaan quake heittämällä toimi.

Alustalla kuitenkin on raudalla se kriittinen toiminnallisuus ja suorituskyky jota quake oikeasti tarvii.

Realistisena optiona olisi joku valmis minimalistinen tiedostojärjestelmäkirjasto yms., mutta sitäkään ei tosiaan välttämättä tarvi jos kaikki pelin resurssit on yhdessä tiedostossa jonka voi dumpata suoraan imagena muistitikulle ilman mitään tiedostojärjestelmää.

 

[hsalonen]

Miksi softarenderöinti? Vai eikö alusta tue 3d:tä?

Alkuperäisessä koodissa on x86 ASM:iä, niin täytyisi sekin portata, jos sitä käytät:

GitHub - id-Software/Quake: Quake GPL Source Release

Quake GPL Source Release. Contribute to id-Software/Quake development by creating an account on GitHub.

github.com

En kyllä vieläkään ymmärrä softarenderöijän käyttöä. Ihan mikä vaan 3d-toteutus tuntuisi menevän tästä ohi ja tuossa saadaan myös suurempi resoluutioriippuvuus nopeuteen.

 

[hkultala]

Miksi softarenderöinti? Vai eikö alusta tue 3d:tä?

Alkuperäisessä koodissa on x86 ASM:iä, niin täytyisi sekin portata, jos sitä käytät:

GitHub - id-Software/Quake: Quake GPL Source Release

Quake GPL Source Release. Contribute to id-Software/Quake development by creating an account on GitHub.

github.com

En kyllä vieläkään ymmärrä softarenderöijän käyttöä. Ihan mikä vaan 3d-toteutus tuntuisi menevän tästä ohi ja tuossa saadaan myös suurempi resoluutioriippuvuus nopeuteen.

Alustalla ei ole mitään 3d-kiihdytintä.

Toki homman voisi jakaa kahteen osaan siten, että ottaisi Quakesta jonkun OpenGL-version, ja sitten porttaisi jonkun softa-openGL-toteutuksen(MesaGL?) tuolle samalle prossulle. Tällöin homma olisi toki edelleen softarendattua, mutta mikäli quaken softarendauskoodista on vain x86-versio, MesaGL:n koodin voisi ehkä saada tuolle prossulle helpommin portattua ja erityisesti optimoitua kuin Quaken softarendauskoodin.

Toisaalta pelottaa, että siinä OpenCL-versiossa tulee kuitenkin liikaa kaikkea boilerplate-koodia sen OpenGLn alustamiseen yms. ja sen boiletplate-koodin porttaaminen/oman GLUT-toteutuksen yms. tekeminen on myös työlästä.

Alkuperäisen DOS-extenderiä ja VESA-framepuskuria käyttävän softarendauskoodin taas ei pitäisi tarvia käytännössä graffa-IOlta mitään muuta rajapintaa kuin framepuskurin osoitteen (ja ehkä tiedon, koska ruutu refreshataan), mutta jos sitä tosiaan ei ole C-kielellä saatavilla vaan vain x86-asmina, sitten se on ongelmallinen.

Tosin, näköjään tuolla lukee:

"
It is possible to change a #define and
build with only C code, but the software rendering versions lose almost half
its speed.
"

Eli koko softarendaustoteutus pitäisi olla (hitaana) C-koodina. Tuo hitaus ei kuitenkaan ole minulle ongelma.

Tosin hämää se, että noissa hakemistoissa puhutaan "winquakesta". Luulisin, että alkuperäinen dos-versio olisi helpompi portata koska vähemmän alustetttavia asioita esim. ruutu-IOn suhteen, ja windows-ohjelmointi on keskimäärin kamalaa.

 

[hsalonen]

Alustalla ei ole mitään 3d-kiihdytintä.

Toki homman voisi jakaa kahteen osaan siten, että ottaisi Quakesta jonkun OpenGL-version, ja sitten porttaisi jonkun softa-openGL-toteutuksen(MesaGL?) tuolle samalle prossulle. Tällöin homma olisi toki edelleen softarendattua, mutta mikäli quaken softarendauskoodista on vain x86-versio, MesaGL:n koodin voisi ehkä saada tuolle prossulle helpommin portattua ja erityisesti optimoitua kuin Quaken softarendauskoodin.

Toisaalta pelottaa, että siinä OpenCL-versiossa tulee kuitenkin liikaa kaikkea boilerplate-koodia sen OpenGLn alustamiseen yms. jonka porttaaminen on myös työlästä.

Itse porttaisin vaan sen alkup. koodin softarenderöijän assemblerista toiselle. Tai sitten tekisin siitä C:tä, niin muutkin pääsisivät hyötymään. IMHO projektisi olisi paljon parempi, jos se sisältäisi korkeammalla tasolla kirjoitetun renderöijän. Tämä pikaisella 5min googletuksella, jossa etsin noita Quake-portteja.

Itse olen sitä ikäluokkaa , että korkeakoulun koneilta fingeröin Carmackkia Kun tämä koodi tuli saataville, latasin sen omalle koneelle ja tutkin sitä, tarkoituksena tehdä oma vastaava peli. Siitä ei tullut yhtään mitään, mutta takataskussa on yksi seminaariesitelmä, jonka pidin radiositeetista (tapa, jolla valaistus on toteutettu tuossa ja suuressa osassa muitakin pelejä) ja oma, OpenGL-pohjainen radiositeettilaskija, jossa on muistivuoto

Eli omat tiedot tästä on 20v vanhoja, mutta silloin käytin tähän jonkun verran aikaa.

--

Lisäksi, jo puoliksi offtopicin puolella: näitä softarenderöintitoteuksia löytyy sitten Doomista paljon enemmän. Käytännössä, kun piirretään kuitenkin vaan skaalattuja viivoja, niin on paljon helpompaa.

 

[hkultala]

Lisäksi, jo puoliksi offtopicin puolella: näitä softarenderöintitoteuksia löytyy sitten Doomista paljon enemmän. Käytännössä, kun piirretään kuitenkin vaan skaalattuja viivoja, niin on paljon helpompaa.

Kun suorituskyky ja raudan ominaisuudet riittää quakeen, haluan mennä suoraan quakeen asti. Maailmassa on jo ihan tarpeeksi doomeja oudoilla alustoilla, Quake on se seuraava askel.

Ja tosiaan tämän kannalta ne ongelmat/hankalat asiat ovat IO-puolella, ei rendausalgoritmin raskaudessa.

 

[finWeazel]

Quakesta taitaa olla gameboy/gameboy advanced versio open sourcessa olemassa. Gameboy advance voisi olla hyvä lähtökohta. Ei ole kattavaa käyttäjärjestelmää, ei muistaakseni 3d kiihdytystä ja arm cpu käytössä.

Toinen vaihtoehto vois olla joku amiga quake porttaus. Amigassa tosin jonkinlainen käyttis ja väärä cpu(motorola 680x0).

 

[hsalonen]

Quakesta taitaa olla gameboy/gameboy advanced versio open sourcessa olemassa. Gameboy advance voisi olla hyvä lähtökohta. Ei ole kattavaa käyttäjärjestelmää, ei muistaakseni 3d kiihdytystä ja arm cpu käytössä.

Toinen vaihtoehto vois olla joku amiga quake porttaus. Amigassa tosin jonkinlainen käyttis ja väärä cpu(motorola 680x0).

Idea varmaan lienee, että niitä käyttöjärjestelmäkutsuja on loppupeleissä vähän. Ne korvaa omalla koodilla, ja on porttaus tehty. Kovasti yksinkertaistaen.

Kuitenkin alkuperäinen Quake oli aikansa tuote ja ei ollut edes 3d-kiihdytystä. Softarenderöinti kirjoitettiin x86-konekielellä, että saatiin tarpeeksi nopeaksi. Koska kohdejärjestelmä ei ole x86, niin nämäkin pitää kirjoittaa uusiksi. Mutta sen on joku todennäköisesti jo tehnyt.. Ehkä osana 3d-kiihdytyksen lisäämistä, ehkä vaikka toiselle järjestelmälle porttausta. Ja eiköhän tämä ole se työläin osuus, niin mieluiten tämä portattuna. Lisäksi, jos tekee softarenderöinnistä softarenderöinnin, niin välttyy turhalta boilerplatelta ja mahdollisten kirjastojen konversiolta.

Valitan sivusta huutelua. Ja voin (ajan salliessa) kyllä vääntää x86 ASM -> korkeamman tason kieli, jos tarvitaan siihen apuja.

 

[finWeazel]

Idea varmaan lienee, että niitä käyttöjärjestelmäkutsuja on loppupeleissä vähän. Ne korvaa omalla koodilla, ja on porttaus tehty. Kovasti yksinkertaistaen.

En tuon kanssa jäisi pohtimaan. Koodia kääntämään. Stubittaa kaiken pois mitä ei löydy alustalta. Kun kääntyy stubia vastaan niin tietää puuttuvat asiat. Gameboy advance portista saa jotain irti olettaen että AP:n alusta on arm-pohjainen.

 

[hkultala]

Nyt tuli vastaan tällainen, tämä auttaa minua paljon, toisaalta nyt tulee vähän sellainen "joku ehti jo ensin".

mbitsnbites / mc1-quake · GitLab

Quake - ported to the MC1/MRISC32 architecture

gitlab.com