Historien om den umulige havnen: Hvordan Quake ble overført til Game Boy Advance

Game Boy Advance er en håndholdt spillkonsoll laget av Nintendo. Den ble utgitt i Japan i 2001 og fungerte som etterfølgeren til Game Boy Color. Den hadde en ARM7TDMI klokket til 16,78 MHz, 32kb intern arbeids-RAM, 256kb ekstern RAM og 96kb VRAM. Det er ikke den kraftigste maskinen, men det er nok av spill for håndholdte som mange holder i godt minne. Et spill som aldri så dagens lys for enheten var en prototypeport av Quake, et spill utviklet av id Software som bidro til å definere førstepersons skytespillsjangeren som vi kjenner i dag.

Quake er et utrolig detaljert spill med et fantastisk lydspor og vanedannende spilling, og akkurat som DOOM har det blitt portert til praktisk talt hver eneste enhet du kan tenke deg. Porten til Game Boy Advance er spesielt utrolig ettersom den ikke støtter 3D-grafikk, og Nintendo markedsførte spesifikt den håndholdte som en todimensjonal spillopplevelse. Det stoppet ikke Randy Linden fra å utvikle sin egen havn.

Hvis du ikke er kjent med Linden, er han mest kjent for å være utvikleren av begge bleem! (en PlayStation-emulator) og SNES-porten til DOOM, en prestasjon som John Romero, medgründer av id Software, en gang sa i et intervju med Shacknews han trodde ikke var mulig. Lindens utviklingskompetanse beviste at hvis noen skulle klare å gjøre Quake på Game Boy Advance til en realitet, så var det sannsynligvis ham.

Denne porten har kommet frem i lyset takket være Lindens egen utgivelse av den gjennom Forest of Illusion-prosjektet. Forest of Illusion er et prosjekt som tar sikte på å bevare historien til Nintendos spill, og Linden nådde ut for å distribuere kopien av Quake-porten han fant på et 256 MB flash-kort i sin besittelse.

Vi vil gjerne takke Randy Linden for å ha brukt tid på å svare på spørsmålene våre og sikre den tekniske nøyaktigheten til denne artikkelen. Vi vil også takke Moderne vintage gamer for å tillate oss å bruke stillbilder fra videoen hans som var nødvendig. Denne porten har ingen offisiell relasjon til id Software eller ZeniMax og ble utviklet som et soloprosjekt av Linden.

Quake's Game Boy Advance-port

Teknisk sett er det et vidunder at Quake til og med kan løpe til det nivået det gjør på Game Boy Advance. Det kjører med en god bildefrekvens og opprettholder den korrekte lyssettingen og fargepaletten til det originale Quake-spillet. Alt er 3D, inkludert våpen og monstre. Spill på Game Boy Advance oppnådde 3D-grafikk vanligvis gjennom sprites, men dette var den virkelige avtalen. Den bruker ikke strålekasting på samme måte som andre 3D-spill gjorde på den håndholdte, og den oppnår til og med poeng lyseffekter på forhåndsrenderte objekter via et palleskiftende triks for å oppnå en illusjon av dynamisk belysning.

For å være klar, er ikke denne porten hele spillet, og det er en prototype som Linden hadde til hensikt å ta til id Software når den ble fullført for å bli laget for utgivelse. Game Boy Advances popularitet begynte imidlertid å avta, og i stedet ble den tilpassede motoren skrevet av Linden senere motoren til et annet spill utviklet av Linden fullstendig - Cyboid. Linden forteller oss at en "stor del av koden" fortsatt er den originale ARM-koden fra Game Boy Advance-versjonen. Hvis du vil prøve Cyboid, er en eldre versjon tilgjengelig i Google Play Store, men den offisielle APK-en er nå distribuert på Amazon App Store siden spillet har mye 32-bits kode på lavt nivå.

Linden delte også med oss ​​en video av koden hans som kjører på iPod Video, som fungerte som en av de tidligste versjonene av Cyboid. Den ble bygget på den samme motorkoden som ble brukt for Quake-porten hans til Game Boy Advance.

Game Boy Advance-porten til Quake inneholder ingen av spillets offisielle eiendeler, ettersom Linden ikke har kontaktet enten id Software eller ZeniMax om distribusjon av E1M1-versjonen som inneholder offisielle Quake eiendeler.

Spillet som distribueres for øyeblikket er også en feilsøkingsbygg. Holder du R-tasten ved oppstart vil spilleren bringes rett til det andre kartet i spillet, og å holde venstre på D-paden vil bringe dem til det tredje. Kartbytte kan også nås når spilleren dør, og monstre vil ikke angripe spilleren før spilleren skyter på dem først.

Når det gjelder musikk, bruker demoen offentlige .S3M-filer og lydmikseren håndterer både stereomusikk og lydeffekter.

Tekniske grenser

Det var en rekke grenser når det kom til Game Boy Advance som gjorde dette til en vanskelig havn. Noen av de største hindringene var den lave klokkehastigheten, mangelen på 3D-grafikkfunksjoner til den håndholdte enheten, og mangelen på en flytende punktenhet (FPU). Det var mange andre underveis, men dette var spesielle smertepunkter som Linden skisserte for meg som problematiske. Før vi går inn i det, er det viktig å forstå utformingen av Game Boy Advance.

Game Boy Advance har tre sett med RAM - ett er internt arbeids-RAM (IWRAM), et annet er eksternt arbeids-RAM (EWRAM), og det tredje er video-RAM (VRAM). De 32 kb med IWRAM brukes til å lagre ARM-instruksjoner for rask utførelse, mens 256 kb med EWRAM er optimal for lagring av instruksjoner som bare er tommelen og mindre databiter. Som Rodrigo Copetti bemerker, EWRAM kan være opptil seks ganger tregere å få tilgang til enn IWRAM. Størstedelen av minnet i form av EWRAM er kun tilgjengelig via en 16-bits buss, til tross for at Game Boy Advance markedsføres som en 32-bits håndholdt. IWRAM kunne nås via en 32-bits buss. VRAM på Game Boy Advance kommer inn på 96kb, og selv om det først og fremst er for lagring av grafikkdata, finnes det i CPUens minnekart og kan også brukes som vanlig minnelagring.

Tommelinstruksjoner er et undersett av 32-biters ARM-instruksjoner, og er et sett med instruksjoner kodet inn i 16-biters ord. De har alle fordelene med 32-bits instruksjoner uten å ta så mye plass, noe som gjør dem effektive for optimalisert utvikling. Dette betyr at selv om EWRAM er tregere å få tilgang til, kan tommelen-instruksjoner som er effektive ofte fortsatt ende opp like raskt som ARM-instruksjoner lagret i IWRAM, selv om ulempen med Thumb-instruksjoner er at noen ganger er det ikke helt Thumb-ekvivalenten til en ARM-instruksjon du vil henrette. EWRAM ble brukt til å lagre utdata fra 3D-matematikktransformasjonslogikken, som i utgangspunktet var listen over polygonkanter som deretter ble sporet ut skanningslinje for skanningslinje av rasteriseringskoden.

Som Linden forteller meg, var den mest komplekse og vanskelige delen av hele porten skanningslinjegjengivelsen. Den består av over 10 000 linjer med svært optimalisert ARM-monteringskode som er designet for å tegne et sett med piksler til VRAM. Scanline-gjengiveren brukte mesteparten av 32kb IWRAM. Kantene nærmest kameraet er aktive og gjengitt, og det er egentlig et stort binært rompartisjonstre (BSP). VRAM ble brukt til å lagre resultatene av polygonal transformasjonsutdata i kanttabeller fordi det ikke var nok IWRAM, men VRAM på Game Boy Advance er fortsatt raskere enn EWRAM. Grafikken ble også lagret og vist her.

Han brukte mye tid på å fokusere på optimaliseringer for å sikre at det var i stand til å oppnå raskest mulig utførelsestid. Tre ting han gjorde for å fremskynde henrettelsestiden inkluderte følgende:

• Selvmodifiserte koden før den ble utført, så færre instruksjoner var nødvendig
• Brukte en serie oppslagstabeller for ting som resiprok, sinus, cosinus, tangens osv.
• Byttet CPU "modus" for å få tilgang til flere registre (som er som "variabler") uten å måtte lagre og gjenopprette registrenes verdier.

Å bytte CPU-modus for å få flere registre er en utrolig smart manøver som gir rask tilgang til verdier nær CPUen slik at de kan hentes i en enkelt klokkesyklus. Som Linden forteller meg, var det mulig å bytte register og hente en verdi i en klokkesyklus, i motsetning til å lagre en verdi i RAM-en til Game Boy Advance, som tar lengre tid. Selve CPUen er en 16,78 MHz prosessor, noe som betyr at den kan fullføre 16780000 sykluser per sekund. Det høres mye ut, men når du trenger å beregne og tegne hver piksel på skjermen, blir de raskt sammenlagt, og det blir viktig å barbere så mange operasjoner som mulig.

Ovenstående er listen over generelle registre for ARM7TDMI-brikkesettet som er inne i Game Boy Advance. Vanligvis vil utviklere bare noen gang få tilgang til registrene i "System og bruker"-modus og ty til å bruke normale variabler utenom det. Imidlertid brukte han registre i alle de syv modusene i brikkesettet, og det beste med det er det byttemoduser beholder fortsatt verdiene i registrene til de andre modusene, slik at han kunne bytte mellom dem.

Artig nok nevnte Linden også hvordan metoden hans for bankbytte avdekket en feil i Nanoboy Advance-emulatoren. Som det viste seg, støttet ikke den emulatoren bruk av de andre modusene til CPU for å lagre i registre og bytte, og Quake-demoen hans var det første kjente spillet som faktisk gjorde det.

Linden delte et bilde med oss ​​av noen av notatene han laget og forklarte hvordan han optimaliserte flytepunktberegningene sine i fravær av en skikkelig FPU.

Bildet ovenfor er et som Linden delte med oss ​​fra notatene sine, og det som er spesielt interessant er "diverse ARM-syklusinstruksjoner". Han utviklet en måte å optimalisere syklusene for beregninger slik at han kunne redusere antall klokkesykluser for en beregning. Slik han beskrev det for meg, kan et 8-bits tall multipliseres i én klokkesyklus, et 16-biters tall i to klokkesykluser, et 32-biters tall i tre klokkesykluser og et 64-biters tall i fire klokkesykluser .

"Det var to eller tre stadier av utførelse [i ARM-prosessoren]. Si for eksempel at jeg multipliserer register en med register to og setter resultatet inn i register tre. Hvis jeg visste at register to var et 16-bits tall i stedet for å si multiplisere register en med register to, jeg ville snu den og jeg vil si multiplisere register to med register en fordi det ville spare meg for en klokke syklus."

Han fortalte meg at grunnen til at han gjorde dette var for å presse hver eneste bit av ytelsen ut av Game Boy Advance, som en klokkesyklus som er lagret her og der, går virkelig opp når mange beregninger utføres utført. Når det gjelder den selvmodifiserende koden, ba jeg Linden forklare den.

"Programmet kommer fra [lagring], det overfører en stor blokk av programmet til intern RAM for kjøring fordi det er raskere. Hver RAM-tilgang er mye, mye tregere, så jeg gjør en DMA [Direct Memory Access] av en stor blokk fra ROM til RAM, og så endrer jeg selve programkoden. For eksempel har ARM muligheten til å skifte operander til venstre eller høyre, eller den kan maskere visse biter som en del av instruksjonssettet. Instruksjonen spesifiserer hvilke biter du skal maskere eller hvor mange biter du skal skifte etter. Så jeg ville generere kode som ville endre det som akkurat skulle kjøres basert på hvor mange biter jeg trengte å skifte. Et annet eksempel er med hensyn til 3D-matrisemultiplikasjon. Det er en hel haug med multiplikasjoner involvert der. Jeg ville generere de faktiske instruksjonene som gjør multiplikasjonene i den interne RAM-en og deretter utføre dem slik at koden på en måte bygget deler av seg selv mens den kjørte."

Selvmodifiserende kode har sine egne ulemper, spesielt når det gjelder feilsøking. Det fjerner også behovet for greninstruksjoner, der koden vil hoppe til en annen utførelsessekvens og kan frata hovedtråden dyrebar beregningstid. Linden fortalte oss også at oppslagstabellene er perfekt justert i ROM-en slik at de er et perfekt multiplum av en åtte-bits verdi forskjøvet til venstre. Størrelsen på oppslagstabellen er enorm og passer ikke inn i RAM, og justeringen unngår også behovet for en ekstra lasteinstruksjon for å få tabellens baseadresse.

Alt i alt ble den endelige prototypen utviklet over nesten to år.

Fremtiden til Randy Lindens Quake-havn

Jeg spurte Linden hva som ville skje med fremtiden til Quake-havnen, og han fortalte meg at han satte vurdere å spørre ZeniMax og id Software om å gi ut versjonen med offisielle Quake eiendeler. Han fortalte meg også på et tidspunkt at han vil gi ut kildekoden, men for øyeblikket bygges den ikke ettersom den krever en eldre datamaskin.

Jeg spurte Linden hvorfor han valgte Quake, og han fortalte meg at han elsket spillet og han elsket utfordringen med å være det "umulige prosjektet", siden det var på baksiden av hans DOOM for SNES port. Han nevnte også at selv om han ikke tror at hele spillet kunne ha blitt portert på grunn av plassbegrensninger, kunne det store flertallet av spillet ha vært i samme motor.

Hvis du er interessert i å sjekke ut Quake for Game Boy Advance, sørg for å sjekke utgivelsen av den på Forest of Illusion, som du kan sjekke ut nedenfor.

---

Last ned fra Forest of Illusion