Achtergrond - Van stokoude code naar pc-port: zo moderniseren hobbyisten retrogames

In dit artikel:

Retrogaming krijgt nieuwe mogelijkheden door fanprojecten die klassieke consolegames geschikt maken voor moderne pc’s. Dankzij zogenoemde native ports kunnen spellen als Super Mario 64, Mario Kart 64, de Jak and Daxter-trilogie en The Legend of Dragoon draaien met onder meer 4k-resolutie, hoge verversingssnelheden, ultrawidebeeld en modondersteuning.

Voor zo’n port moeten ontwikkelaars eerst de oorspronkelijke programmatuur reconstrueren. Bij een decompilatie analyseren zij de binaire code van het spel functie voor functie en zetten die om in begrijpelijke broncode. Tools zoals Ghidra helpen daarbij, maar veel functies hebben alleen algemene namen. Programmeurs moeten daarom stap voor stap vaststellen welke rol elk onderdeel heeft. Dat kan jaren duren, maar levert code op die diepgaand aanpasbaar is. Zo kunnen ontwikkelaars nieuwe spelmodi, multiplayerfuncties of uitbreidingen voor een andere engine maken.

Een recompilatie werkt sneller. Speciale programma’s vertalen de code van een oude console automatisch naar bijvoorbeeld C of C++. Voor Nintendo 64 bestaan daarvoor onder meer N64Recomp en voor Xbox 360 XenonRecomp en ReXGlue. De resulterende code is minder overzichtelijk en daardoor moeilijker grondig te wijzigen. Verbeteringen aan resolutie en framerate zijn meestal wel mogelijk, terwijl de oorspronkelijke werking van het spel grotendeels behouden blijft.

Een port is het speelbare programma dat uit een van beide processen voortkomt. Een voorbeeld is BattleShip, waarmee het Nintendo 64-spel Super Smash Bros. native beschikbaar kwam voor Windows, macOS en Linux. Ontwikkelaar Jack Rickey gebruikte daarbij de gedecompileerde code en voegde onder meer co-op en drie nieuwe levels toe. Hij zette Claude in als hulpmiddel bij het programmeren, maar bouwde controles in om fouten en ondoorzichtige AI-uitvoer te beperken. Bugfixes werden uitgebreid vastgelegd en voor verschillende soorten gegevens, zoals textures, animaties en aanvallen, ontwierp hij aparte verwerkingssystemen.

Volgens Rickey is goede foutanalyse daarbij belangrijker dan simpelweg opdrachten aan een taalmodel geven. Door eerdere problemen en oplossingen opnieuw te laten bekijken, konden terugkerende fouten worden herkend. Zo bleek een datastructuur bij het compileren met Clang door onjuiste padding een deel van de personagegegevens af te kappen. Zulke gevallen moeten expliciet worden gedocumenteerd, omdat een model anders aannames uit de gedecompileerde code kan volgen die niet kloppen.

Visuele problemen zijn lastiger te onderzoeken dan programmeerfouten. Een ontwikkelaar moet zo veel mogelijk meetbare informatie verzamelen, bijvoorbeeld met logs en vergelijkingen tussen de port en een emulator. Bij geheugenfouten kunnen hulpmiddelen als AddressSanitizer de exacte locatie van een probleem aanwijzen. Audio vergt meer interpretatie: een mixer moet geluidsstromen synchroon verwerken, ruimtelijk positioneren en zonder storingen mengen. Een fout kan leiden tot tikken, ruis, extreem hoge tonen of geluid op slechts één kanaal, zonder dat direct duidelijk is welke code daarvoor verantwoordelijk is.

Rickey beschrijft een geval waarin de audiobalans verkeerd werd berekend. Daardoor kwam geluid uit het midden alleen links terecht en kon geluid aan de linkerzijde een overflow veroorzaken. De oorzaak was uiteindelijk een omgekeerd teken in een eenvoudige berekening. Door dat teken te corrigeren, werd de positionering hersteld.

Voor succesvol debuggen is volgens Rickey inhoudelijke kennis van de consolehardware noodzakelijk, ook wanneer een taalmodel wordt gebruikt. Openbare technische documentatie kan daarbij helpen. Zo moeten ontwikkelaars rekening houden met specifieke beeld- en textureverwerking op de Nintendo 64; zonder die kennis kan software een ongebruikelijke, gecomprimeerde gegevensvorm ten onrechte als het uiteindelijke beeld interpreteren.

Rickey noemt het maken van een port een leerzame ervaring voor programmeurs die meer willen begrijpen van laag-niveauontwikkeling en de werking van games. Wel neemt testen een groot deel van het werk in beslag. Super Smash Bros. was relatief overzichtelijk omdat vrijwel alle spelsituaties snel bereikbaar zijn; langere avonturenspellen zijn daardoor aanzienlijk moeilijker te controleren. Hij adviseert ontwikkelaars om hun werk open te delen, feedback te zoeken en de port zo op te bouwen dat anderen later mods of onlinefuncties kunnen toevoegen.