Door Imre Himmelbauer

Redacteur

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

21-09-2026 • 06:00

45

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

Zin in een klassieke game? Je bent niet de enige. Retrogaming is de laatste jaren in opmars. Dat is te zien aan de wildgroei aan retroconsoles, maar ook aan het groeiende aantal decompilaties, recompilaties en ports van klassieke games. Daardoor is het mogelijk om verschillende retrogames native op de pc te draaien. Vaak ondersteunen de ports ook native 4k-resolutie, hoge refreshrates, ultrawideaspectratio's en mods. Hoe krijgen de hobbyisten achter de projecten dat voor elkaar?

Het is fans van verschillende grote retrogames de afgelopen jaren op verschillende manieren gelukt om de gecompileerde code van games om te zetten in door mensen leesbare code. Daardoor hebben onder meer Mario Kart 64, Super Mario 64, de Jak and Daxter-trilogie en The Legend of Dragoon al native ports voor de pc.

Die ports kunnen ontwikkelaars maken aan de hand van een decompilatie of een recompilatie. Bij een decompilatie reverse-engineeren programmeurs de gehele game. Uiteindelijk is door mensen leesbare broncode van het spel het resultaat.

Ontwikkelaars gebruiken vaak reverse-engineeringtools als Ghidra om de gecompileerde code te decompileren en het resultaat ervan te analyseren. Vervolgens pluizen zij het resultaat functie voor functie uit om te kijken wat elke functie doet. Veel functies hebben namelijk geen logische, maar generieke namen. Daardoor moeten de ontwikkelaars stukje bij beetje uitzoeken wat elke functie doet.

Onder meer voor spellen voor de Nintendo 64 zijn pc-ports uitgekomen.
Onder meer voor spellen voor de Nintendo 64 zijn pc-ports uitgekomen.

Dit proces is natuurlijk zeer arbeidsintensief en tijdrovend. Ontwikkelaars zijn vaak jaren bezig om de code helemaal om te zetten. Het grote voordeel is dat de broncode hierdoor schoon en begrijpelijk is. Dat maakt het mogelijk om spellen tot in de kern aan te passen. Denk bijvoorbeeld aan diepgaande mods, multiplayer toevoegen of de game overzetten naar een nieuwe engine.

Recompilaties: minder tijdrovend en minder aanpasbaar

Een recompilatie kost een stuk minder tijd. Bij dit proces gebruiken programmeurs speciale tools, zogenoemde recompilers, om de programmeertaal van een oude console om te zetten in een moderne taal als C of C++. Zulke tools bestaan al voor Nintendo 64-games (N64Recomp) en XBOX 360-spellen (XenonRecomp en ReXGlue).

Het voordeel van een recompilatie is dat die veel sneller en eenvoudiger is dan een decompilatie. Wanneer een recompiler beschikbaar is, kunnen gebruikers snel broncode van een oud spel omzetten naar een taal voor moderne hardware. Het nadeel is dat die code voor mensen moeilijk leesbaar is. Daardoor is de game lastig diepgaand aan te passen. Het is vaak wel mogelijk om ondersteuning voor hoge framerates en een hogere resolutie toe te voegen, maar het spel blijft in de basis functioneren zoals het altijd deed.

Ports: uitvoerbare versies van re- en decompilaties

Een port is een speelbaar eindresultaat van decompilaties en recompilaties. Het is een uitvoerbaar programma dat native draait op moderne hardware. Een voorbeeld van zo'n port is BattleShip, dat het Nintendo 64-spel Super Smash Bros. native op pc speelbaar maakt. De maker van die port is Jack Rickey, die met hulp van Claude de gedecompileerde code van Super Smash Bros. omzette in een werkende port voor Windows, macOS en Linux. Mede doordat de port is gebaseerd op een decompilatie, heeft hij ook verschillende zaken aan het spel kunnen toevoegen, zoals een co-opmodus en drie extra levels.

Battleship

Hij vertelde eerder aan Linux Gaming Central dat hij verschillende maatregelen nam om ervoor te zorgen dat de port geen typische AI-slop zou worden. Zo liet hij Claude elke bugoplossing uitgebreid documenteren. Uiteindelijk zag hij dat elk soort data, zoals textures, personageanimaties en de aanvallen van de verschillende personages, op een andere manier moest worden verwerkt. Hij ontwierp voor elk gegevenstype een hulpsysteem om de gegevens correct te verwerken.

Buganalyses

Tegenover Tweakers geeft Rickey meer uitleg over hoe hij die systemen heeft vormgegeven: "Telkens wanneer ik een bug onderzocht, liet ik de agent de eerdere bugs en probleemoplossingen opnieuw doorlezen. Als die tot dezelfde 'bugfamilie' behoorde, was het makkelijk om dezelfde oplossing te volgen of de construct die ik gebruikte aan te scherpen. Dit helpt ook om een werkgeheugen op te bouwen. Ik had bijvoorbeeld een bug waarbij een struct uit de decompilatie, indien gecompileerd met Clang, een deel van de personagedata afkapte vanwege padding. Door zo'n buganalyse op te slaan leren agents om structs niet blindelings te vertrouwen."

Jack Rickey, de ontwikkelaar van Battleship.
Jack Rickey, de ontwikkelaar
van Battleship

Dat betekent niet dat het debuggingproces meteen perfect verloopt. Rickey: "Er waren genoeg momenten waarop ik lastige bugs tegenkwam. Visuele bugs zijn lastig, omdat veel van wat je beschrijft moeilijk over te brengen is op een large language model (llm). Daarnaast zijn de ingebouwde visuele modellen in Claude of ChatGPT eerlijk gezegd niet zo geschikt om kleine problemen met de visuele kwaliteit te debuggen. De manier om dit op te lossen is volhouden en zoveel mogelijk informatie omzetten in iets dat het model kan verwerken. Dat betekent veel logs toevoegen.

"Het helpt ook om te vergelijken met andere dingen. Je zou bijvoorbeeld het spel op een emulator kunnen draaien en displaylists (de N64-tekeninstructiecode die naar de rsp wordt gestuurd) kunnen dumpen en vergelijken met je eigen resultaten. Leren van dit soort technieken is erg belangrijk. Als je vastloopt en niet weet wat je moet doen, heeft het geen zin om tegen je model te zeggen: 'Het is weer kapot en werkt niet, repareer het' en te verwachten dat het dan werkt. Je kunt vragen stellen als: 'Wat zou een professional in deze situatie doen?', 'Welke andere informatie heb je nodig?' en 'Welke referenties of betrouwbare bronnen zouden hier nuttig zijn om dit te bevestigen?'"

Audioproblemen zorgen voor de meeste kopzorgen

Uiteindelijk bleken de audiobugs het hardnekkigst: "Stabiliteitsproblemen zijn frustrerend, maar met de juiste tools eenvoudig te diagnosticeren en op te lossen. De kern van vrijwel elk stabiliteitsprobleem is een fout in het geheugen. Meestal gaat het om een poging om geheugen te gebruiken dat al was vrijgegeven, of een pointer die verwijst naar geheugen dat buiten het voor het programma toegestane bereik valt.

"Deze fouten zijn in de meeste gevallen deterministisch en reproduceerbaar, dus spoor je ze op met speciale tools zoals AddressSanitizer (ASan)", legt Rickey uit. "Met deze tools kun je de build compileren met zogeheten red zones tussen geheugenallocaties. Simpel gezegd doen deze dienst als bufferzones, die het programma nauwlettend in de gaten houdt. Als een teller verder oploopt dan de bedoeling is, komt deze in zo'n red zone terecht. ASan legt het programma dan direct stil en geeft aan welke functie het probleem veroorzaakte.

Super Smash Bros. draait door Rickeys port native op de pc.
Super Smash Bros. draait door Rickeys port native op de pc.

"Ik haal dit allemaal aan om uit te leggen wat opsporen van het ene type probleem inhoudt in vergelijking met een ander type probleem. In dit voorbeeld heb je een deterministische compilerhulp die je de exacte locatie van de bug geeft. Zodra je weet waar de fout zit, is het vrij eenvoudig om de bug in de code te zien en te repareren."

"Audio daarentegen is veel moeilijker. Mixers moeten audiostreams verwerken, ze synchroon houden met het verloop van de game en netjes mixen en faden", legt Rickey uit. "Wanneer audio uit de pas loopt met de gamelogica, krijg je tikken en ruis. Wanneer de mixer een bug bevat, kan de audio ontaarden in hoge pieptonen op hoog volume, of hoor je het geluid nog maar via één kanaal. Aan het geluid kun je horen dat er iets mis is, maar het is lastig vast te stellen wat precies."

Ook gedumpte WAV-bestanden helpen daarbij niet: die tonen aan dat er een probleem met de audio is, maar laten niet zien welke fout in de software dat probleem veroorzaakt.

Audio op de verkeerde plek

Rickey noemt als voorbeeld een bug waarbij het 'centrum' van de audio naar links was verschoven. "Dit leidde ertoe dat audio die vanuit het midden van het scherm kwam, alleen op het linkerkanaal werd afgespeeld. Audio die vanaf de linkerkant van het scherm kwam, veroorzaakte een integer overflow. Dat resulteerde in een hard, krakend geluid."

Die bug was hardnekkig, maar de oplossing bleek kinderlijk eenvoudig. Rickey: "Het was zo simpel dat het grappig is. In de decompilatie stond balance = 64 - balance. Dit keerde de x-positie om. Een personage aan de rechterkant werd naar links geprojecteerd. De code behandelde 0 dus als links en 127 als rechts. Als het personage helemaal links op het scherm stond, veroorzaakte dat een integer overflow in de audiomixer. De oplossing was om het minteken in de decompilatiecode te veranderen in een plusteken: balance = 64 + balance."

Om goed te debuggen is uiteindelijk 'gewoon' kennis nodig, ook met hulp van llm's, zegt Rickey: "Jij en het model moeten uitstekend begrijpen hoe deze systemen werken om effectief te kunnen debuggen. Gelukkig is er veel zeer goede openbare documentatie over de hardwarespecificaties van de Nintendo 64, evenals van alle andere consoles."

Hij noemt als voorbeeld onder meer de compressie van textures op de Nintendo 64. Omdat het werkgeheugen op de console zo beperkt was, comprimeerde het systeem alle textures in een soort kronkelig patroon.

"Dat is een goed voorbeeld, omdat bijna niemand dit ooit in het openbaar te zien krijgt. Dit is hoe de ruwe sprite eruitziet als je hem van de cartridge dumpt. Als het model niet begrijpt dat er op hardwareniveau iets hoort te gebeuren om dit er normaal uit te laten zien, denkt het gewoon dat dit is hoe de sprite eruit hoort te zien."

Zo zien ruwe sprites van de Nintendo 64 eruit
Zo zien ruwe sprites van de Nintendo 64 eruit.

Geweldige leerervaring

Mensen die nu zelf zin krijgen om een port te maken, doen er volgens Rickey goed aan om een sprong in het diepe te wagen: "Ik zou andere ontwikkelaars absoluut aanraden om een ​​game te porten. Je leert veel over N64-hardware, functioneel programmeren op laag niveau en de manier waarop games daadwerkelijk op een computer werken."

"Ik wil er wel bij zeggen dat de game testen een groot deel van het werk uitmaakt", waarschuwt de ontwikkelaar. "Dat vormt waarschijnlijk het grootste knelpunt. Super Smash Bros. was relatief makkelijk te testen, omdat het een erg korte game is, waarbij bijna alle speltoestanden binnen 15 minuten spelen toegankelijk zijn. Voor langere singleplayergames is dat misschien niet het geval."

"Mensen die dit soort werk willen doen, zou ik aanmoedigen om er open over te zijn en anderen erbij te betrekken. Je wilt dat je port een goede basis vormt voor anderen om aan te werken, bijvoorbeeld voor mods en online spelen. Feedback van mensen met meer ervaring in de scene is altijd nuttig."

"Ik heb er enorm veel plezier aan beleefd", onderstreept Rickey. "Het is een zeer bevredigende ervaring om een ​​hoop gedecompileerde gamecode om te zetten in iets dat mensen daadwerkelijk kunnen spelen. Zodra de game stabiel is, is het fantastisch om nieuwe functies toe te voegen, zoals 16:9-breedbeeld, om de game vanuit een compleet nieuw perspectief te bekijken. Ik ben erg trots op wat ik en vooral de andere ontwikkelaars voor het project hebben gedaan."

Redactie: Imre Himmelbauer • Eindredactie: Marger Verschuur

Reacties (45)

Sorteer op:

Weergave:

Ik heb onlangs RetroPie op een oude Raspberry Pi geïnstalleerd. Super leuk project om te doen. Nog even overwogen om er gelijk een arcadekast van te maken, maar blij dat ik dat niet heb gedaan. Dat kost al snel 500,- tot 1.000,- en dat is het waard als het veel gebruikt wordt, maar na 2 dagen werd er hier al niet meer op gespeeld. En dat is wat mij betreft ook gelijk het probleem met retro gaming. Super leuk vanwege nostalgie, maar uiteindelijk is het niet voor niets ouderwets geworden. De games kunnen niet op tegen hedendaagse verwachtingen. Dus doe het vooral wel, leuk om mee bezig te zijn, maar de reis blijkt ook hier belangrijker dan de bestemming.
Spreek voor jezelf🙂 Er is een levendige retro-game community en persoonlijk speel ik ook veel liever retro games dan die moderne drukke overgeproduceerde games. Natuurlijk zijn er voor mij ook met nieuwe games pareltjes bij. Maar er is ook een reden dat er behoorlijk veel indie-games in 8- en 16-bit stijl worden gemaakt de laatste jaren.

Ik heb een reteogame hoek met allerlei oude consoles en een aantal CRT's met toffe echte scanlines, en daar haal ik meer lol uit dan uit moderne consoles. Oh, en ik héb zelf de games in handen, ook wel een verhitte discussie de laatste maanden.

[Reactie gewijzigd door Rataplan_ op 21 september 2026 07:49]

Er zijn natuurlijk ook moderne games in een retro jasje. Niet alles is overgeproduceerd. Onlangs nog de game Secrets of Grindea gespeeld. Enorm veel lol aan beleefd. Vol humor, leuke stadjes en NPCs, ruime keuze aan upgrade keuzes en builds, en zeer uitdagende bosses.

Qua echte retro games komt Lufia 2 naar Steam. Kijk ik enorm naar uit. Heb ik al wel 10x uitgespeeld op de SNES.

En ben nu op de SNES bezig met Plok. Een game waar je je ledematen schiet als kogels, wat daarna je bewegingen beperkt, want je bent je armen en/of benen ff kwijt. Gvd lastige platformer!
Omg, meteen gekocht die Secrets of Grindea!

Ik ben enorm fan van action based RPG in 16bits stijl zoals Alttp, Illusions of Time en deze lijkt me echt heel erg vet!

Thanks voor de link :)
Ocean's Heart was ook erg leuk. Er zijn er volgens mij echt ontelbaar in deze stijl, maar soms lastig te vinden.
Idd, vooral het laatste, je hebt een fysiek 'iets' waar het spel opstaat (nog steeds een licentie, maar wel een fysieke) en kan deze gebruiken of doorverkopen.
Het ene deel van de bevolking heeft duidelijk geen idee waar het andere deel van de bevolking mee bezig is. Ja, nostalgie is beslist een reden waarom retrospellen gespeeld worden, maar die jongeren die we welkom heten op retrocomputerforums zijn echt niet in de nostalgie geïnteresseerd. Ik zou zeggen dat de volgende factoren een rol spelen:
  • Afkeer van moderne bedrijfsmodellen waarbij je abonnementen neemt i.p.v. spellen koopt en er verdienmodellen in spellen zitten
  • De ontdekking dat niet alles beter is aan moderne computers, we zijn ook dingen kwijtgeraakt.
  • De ontdekking van spelgenres die door moderne spellen niet bediend worden.
  • Nostalgie.
Retrocomputing aan het exploderen, iedere keer als ik denk dat we nu toch wel op het hoogtepunt moeten zitten, wordt het nog groter. Het onderwerp van dit artikel is weer een vertakking van de retrowereld waar ik totaal niet in zit, maar ook gewoon weer een volop levende hoek.
Dit inderdaad. Ook vermeldenswaard is het MiSTer FPGA-project dat zowat elke denkbare gameconsole en homecomputer weer tot leven brengt. Onlangs nog werd de core van de slechtst verkopende gameconsole aller tijden toegevoegd: de Super A'Can. De console was capabel, maar was zo'n commerciële flop dat er slechts 12 games voor zijn ontwikkeld. Nu deze console beschikbaar is in MiSTer vermoed ik dat het niet lang gaat duren voor een ontwikkelaar erop springt en hiervoor homebrew games gaat maken.

Een bekende op dit gebied is de Japanse Inufuto, die om de zoveel tijd een game maakt en die port naar meer dan 120 (!) verschillende antieke consoles en computers, waarvan sommige zo obscuur zijn dat je er nog nooit van gehoord hebt.
Je vergeet nog dat vroeger veel mensen een snelle pc hadden, goed voor games.
Later bleef dat hetzelfde, maar werd een 3D kaart noodzakelijk.
Vandaag is een snelle pc (en al zeker een 3D kaart) geen noodzaak meer voor gewoon computerwerk. Zeker jongeren hebben vaak maar een 'gewone' computer waar de nieuwe AAA games gewoon niet op draaien. Veel oudere games zijn even leuk (of zelf leuker) en draaien perfect op oudere/tragere hardware.
Zelf zie ik ook weinig reden meer om een snelle pc te kopen.

Een tweede punt is dat oudere games vaak zeer goedkoop zijn (of zelf gratis).

[Reactie gewijzigd door catfish op 21 september 2026 11:32]

. Nog even overwogen om er gelijk een arcadekast van te maken, maar blij dat ik dat niet heb gedaan. Dat kost al snel 500,- tot 1.000,- en dat is het waard als het veel gebruikt wordt, maar na 2 dagen werd er hier al niet meer op gespeeld.
Bij mij was het bouwen en het zorgen dat het perfect werkt het doel; het spelen een stuk minder. Het budget overschat je denk ik; het lijkt er op dat hout tegenwoordig eigenlijk het duurste is...
(En daar kun je nog op beknibbelen door een table-top te maken; scheelt veel MDF.)

Kosten van overige componenten valt echt heel erg mee; met een beetje creatief shoppen kom je echt heel ver, en ook dat was voor mij een deel van de hobby. Ik denk niet dat ik de €300 heb overschreden* inclusief op maat gemaakte glazen plaat, 'echte' plastic afwerkstrip (T-band), glitterfolie voor de afwerking en een custom arcade banner voor de bovenkant.
Beeldschermen die niet-breedbeeld zijn kosten geen drol op MP of bij de kringloop. Geen HDMI is geen probleem; verloopkabels zijn een paar euro.

Tijdje in de werkruimte gestaan als eye-catcher en toen weer verkocht. Als je het opstarten fool-proof maakt is hij dus ook voor iedereen geschikt. Het ding heeft mij letterlijk niets gekost en een hoop plezier opgeleverd.

M.a.w.: laat je alleen tegenhouden als je het écht financieel niet tijdelijk kunt missen, maar in alle andere gevallen: laat je er niet door afschrikken.

*(Enige kanttekening: je hebt natuurlijk wel wat gereedschap nodig; soldeerbout, freesje, dikke-peerzaag, boormachine, gatenzaag, lijmklemmen.)
Dit inderdaad. Hier hangt ook een zelfgemaakte arcadekast aan de muur in onze gameroom. En gebouwd op de manier zoals jij beschrijft, + verlichte knoppen van ome Ali. Voor mij geen gladgestreken hi-res shiny retro games. Zoals hierboven al beschreven wil ik het gevoel van vroeger kunnen benaderen. Dus lage resolutie en scanlines! Dan is space invaders misschien voor 2 minuten leuk, maar dat is ook perfect voor de energyboost die het mij geeft op de momentjes dat je even ergens op moet wachten. Je hoeft niet iets uit te spelen, en het is ook niet erg als je weer moet stoppen met spelen. Geen levels die 15 minuten duren waarbij het jammer is van je tijd als je eerder moet stoppen en je level niet uit kunt spelen.
Retro gaming is zeker niet ouderwets geworden.
Zie de toename aan retro consoles, handhelds en tweede hands markten.
Retro gaming is hard aan het groeien.

Veel gamers gaan juist meer retro gamen door de negatieve moderne aspecten van games zoals eindeloos betalen voor games, bugs, gokken, reclame, online only, DLC's en AI slop.
Niet enkel dat, vanuit nostalgie ga je ook weer oude games spelen die je vroeger deed.
Je ziet het ook aan het feit dat er (eindelijk) steeds meer mobiele game launchers verschijnen op iOS / iPadOS waarbij je de combinatie hebt van deeplinks naar games (waar ondersteund: Delta, PPSSPP, Manic Emu, Provenance, Joy Emulator, Gamma, LunaDS) in geïnstalleerde emulators, iOS games, cloud en web games. Enkele opties: LudiHub, Ohsnap Mcon, Sumee!, Gamesphere (in TestFlight). Samen met een controller (Backbone One, Razer Kishi, Mcon, Abxylute S9, GameSir, Elo Vagabond) heb je een prima (retro) handheld voor je iPhone / iOS.

[Reactie gewijzigd door funrider op 21 september 2026 09:47]

n=1 neem ik aan. Er zijn hele communities die echt niks anders willen dan retrogaming, en dit al jarenlang. Ze spelen de games, ze ontwikkelen aan de lopende band nieuwe, ze porten games naar oude en obscure systemen, maken nieuwe hardware-uitbreidingen, ze zetten nieuwe softwarehuizen op, verkopen hun games en verdienen daar flink aan. "Modern gaming" laten ze helemaal links liggen. Retrogaming is voor de echte fan zeker geen geval van "na twee dagen is de lol er wel van af", integendeel, de groei zit er nog steeds in.
In mijn beleving zijn retro games leuker*, maar missen ze de quality-of-life aspecten van 30 jaar game ontwikkeling. Niet kunnen saven, onbegrijpelijke user-Interfaces, niet ergonomische handelingen, inconsequent tempo, domme game mechanics etc.

*) Leuker is natuurlijk een bias: er is ook zo ontzettend veel om te kiezen dat enkel de goede wellicht overblijven in de overlevering. Laatst nog een ROM collectie 'gevonden' en ik kan je zeggen dat van de 10 spellen, er 11 echt ruk waren. Ook brachten retro games als eerste nieuwe concepten, zodat er tegenwoordig moeilijker iets is te maken dat daarop niet voortborduurt.
Ik heb mijn zelfgebouwde arcade kast weer verkocht, niet omdat ik er niet meer op speelde, maar meer omdat het een "sta in de weg" begon te worden. Ik woon er niet alleen :)

Mijn oplossing was: een X-Arcade controller.
Van de week een oude Raspberry Pi 3B+ afgestoft en Batocera erop gezet. Icm een controller van de Action werkt het prima :9

Met chatgpt een Tetris game gemaakt voor snes, werkt perfect op de emulator.
Leuk om te lezen. Laat iedereen maar lekker rommelen, dan zijn de LLM's dit truukje ook binnenkort meester. Kunnen we 1 prompt geven :)

Mijn kids vinden Snes rpg's leuk, dus ik heb de heavy hitters vertaald naar NL. Het verbaast mij hoe makkelijk die tegenwoordig vertaalbaar zijn door AI, ook MSU1- achtige mods zijn fluitje van een cent geworden.
Mijn kids vinden Snes rpg's leuk, dus ik heb de heavy hitters vertaald naar NL. Het verbaast mij hoe makkelijk die tegenwoordig vertaalbaar zijn door AI, ook MSU1- achtige mods zijn fluitje van een cent geworden.
Ik leerde juist in mijn jongere jaren Engels door (o.a.) op de eerste fatsoenlijke SNES emulators deze spellen gewoon in het Engels te spelen. Des te jonger, des te makkelijker het is om andere talen te leren.

Je kan overigens Lufia II (hier verkocht als Lufia) in het Nederlands krijgen. Er is een officiële vertaling.

[Reactie gewijzigd door The Zep Man op 21 september 2026 08:33]

De remaster die er aan komt van Lufia 2 lijkt dan weer niet Nederlands te hebben.

Toch, het hebben van meer talen in games kan ook een reden zijn dat meer mensen nu überhaupt gamen. Het is geen slecht idee om kinderen te motiveren meer talen te leren, maar als ze daardoor helemaal niet meer willen gamen schiet je er ook weinig mee op.
En we moeten Ghidra niet vergeten: zonder tools als Ghidra was dit veel lastiger, zelfs met LLM’s!

Het allermooiste is natuurlijk dat je de originele gamecode grotendeels kunt behouden en vooral de platformlaag abstraheert, bijvoorbeeld de renderer naar SDL3 (en Vulkan). Zo blijft de game intact, maar draait hij native op moderne systemen.

Zelf hoop ik vooral op een native Linux/PC-port van GoldenEye 007 (de OG N64 versie, niet die van XBLA die volgens mij al werkt). Maar Killzone (PS2) en vooral Killzone 2 (PS3) native op PC zouden voor mij helemaal de droom zijn, maar dat zal nog wel even op zich laten wachten... :9
Nope, wat je hebt is een binaire blob met data. Maar als je weet voor welke processor het is en waar in de blob de CPU start met uitvoeren, kan je de data omzetten in voor mensen leesbaare assembler instructies.
voor mensen leesbaare assembler instructies
Als good 'ole boomer coder durf ik rustig te stellen dat deze zin in de basis niet klopt 🤪

Datzelfde geldt overigens voor:
Vervolgens pluizen zij de binaire code functie voor functie uit om te kijken wat elke functie doet. Veel functies in de binaire code hebben namelijk geen logische, maar generieke namen
Binaire code kent geen functies en al helemaal geen functienamen. Het kent hooguit adressen waar een functie gemapped is maar de naam is alleen in documentatie terug te vinden.

[Reactie gewijzigd door Croga op 21 september 2026 06:53]

[...]

Als good 'ole boomer coder durf ik rustig te stellen dat deze zin in de basis niet klopt 🤪
Waarom denk je dat? Assembly wordt gewoon beschouwd als leesbaar voor mensen.
[...]

Binaire code kent geen functies en al helemaal geen functienamen. Het kent hooguit adressen waar een functie gemapped is maar de naam is alleen in documentatie terug te vinden.
Assembly heeft labels die je met wat goede wil als startpunt van een functie kunt zien. De naam is natuurlijk gegenereerd aangezien je die niet in de binary vindt.
Waarom denk je dat? Assembly wordt gewoon beschouwd als leesbaar voor mensen.
Er is leesbaar en leesbaar..... heb jij wel eens assembler code gezien? En begreep je dan ook wat die precies doet? Ik heb het geschreven en zonder een paar boeken aan referenties er bij zegt de code helemaal niets.
Assembly heeft labels die je met wat goede wil als startpunt van een functie kunt zien. De naam is natuurlijk gegenereerd aangezien je die niet in de binary vindt.
Exact...... Assembler heeft een berg adres referenties. Dat noem ik geen functienamen. En als dat referenties zijn naar CPU of virtualisatieplatform functies dan is er een functienaam op te zoeken maar als het een referentie is naar een routine van de software zelf dan is er helemaal niets. Bottomline is nogsteeds dat de "binaire code" geen functienamen heeft.
[...]

Er is leesbaar en leesbaar..... heb jij wel eens assembler code gezien? En begreep je dan ook wat die precies doet?
In mijn jeugd wel wat Z80 assembly geschreven. Niet veel, ik heb dat geduld niet, maar ik ken de basis. Als het niet leesbaar is dan komt dat door de complexiteit van hedendaagse CPU’s. Maar als dat het criterium is dan is menige hogere programmeertaal ook niet leesbaar voor mensen.
Ik op de 6502 en daar best leuke dingen gemaat. Hoewel elke regel prima te herleiden is tot wat het doet en er best veel commando's zijn met een logische naam is het naar mijn mening toch heel erg lastig om (zonder externe documentatie) aan de enorme bak commando's op rij te zien wat er precies gebeurt; het is gewoon te veel.
Als iemand die nog nooit in een assemblytaal geprogrammeert heeft, maar wel leest, is het altijd wel een dingetje om te begrijpen wat er gebeurt. En ook altijd met de documentatie ernaast.

Maar handgeschreven z80 is dan weer wat anders dan gegenereerde x86 (vanuit C#).
Overdrijven is ook een kunst. Assembleertaal is op het oog wat minder doorzichtig dan hogere talen, maar of dat een probleem om te weten wat die code precies doet? Ik denk in het geheel niet, je moet er simpelweg iets langer naar kijken.
Overdrijven is ook een kunst. Assembleertaal is op het oog wat minder doorzichtig dan hogere talen, maar of dat een probleem om te weten wat die code precies doet? Ik denk in het geheel niet, je moet er simpelweg iets langer naar kijken.
Dat is niet hoe het werkt....
Aangezien assembler bestaat uit het aanroepen van adressen zul je moeten weten wat er op die adressen gebeurt. Weet je dat niet dan kom je nergens. En dat is niet (volledig) uit de code op te maken. Assembler an sich is dus defacto niet te lezen. Het is alleen te lezen door er een naslagwerk van de CPU of CPU-virtualisatie naast te leggen. En op een oude Z80 was dat nog redelijk te doen maar op x86 is dat echt een heel ander verhaal....
Bekijk eens even een project van me... ik heb mijn port assembleertaal wel gehad. In dit geval 6502, want onderwerp is hier retro, maar ook x86 heb denk ik meer regels assembleertaal geschreven dan de meesten hier. Adressen geef je een symbolische naam, daardoor wordt het leesbaar.
Binaire code kent geen functies en al helemaal geen functienamen.
Functies uit de standaard library worden soms herkend en hebben dan wel namen.
Als je alleen de gecompileerde code hebt dan zijn er geen libraries.... Er is dan alleen de CPU of the virtualisatielaag daar overheen. En ja, daar is documentatie van die wellicht namen weer geeft. Maar er staan zeker geen namen in de code. Dat kan ook niet aangezien de code waar het hier over gaat.... binair is.
Een heel mooi voorbeeld hiervan is het onlangs uitgebrachte Nelumbo (beter bekend als Lotus bloem) van Almost There Games. Het is een remake van in feite alle Lotus versies op de Amiga op de PC. Je moet ook de 'echte' disks (ADF) toevoegen om het spel te laten werken. https://almost-there-games.itch.io/nelumbo Het speelt echt fantastisch.

Hij heeft nog meer van dat soort conversies gemaakt. Zoals SuperFrog, ook van de Amiga.

[Reactie gewijzigd door XL79 op 21 september 2026 07:22]

Het stuit me een beetje dat ik die Lotus remake nu voor het eerst zie :X terwijl ik het retro-game nieuws best strak volg. Overigens de recente Outrun en Sonic voor de Amiga (wel beetje beefed up Amiga) zijn ook wel heel toffe prestaties!
Ik meld dit meestal bij Tweakers - zeker dit soort Amiga nieuws. Wordt genegeerd of in ieder geval niet van belang geacht voor de frontpage.

En inderdaad, ook Sonic voor de Amiga viel in die categorie. Ook gekocht trouwens voor een paar Euro. Net zoals deze Lotus remake.

[Reactie gewijzigd door XL79 op 21 september 2026 08:15]

Binaire code is een vreemde naam. Je hebt (mag ik aannemen) minimaal de assembly code als je weet voor wat voor processor architectuur de game geschreven was. Tenzij natuurlijk de executable encrypted of gecomprimeerd is.
Je hebt (mag ik aannemen) minimaal de assembly code
Je hebt machine code. Dat is relatief makkelijk om te zetten naar assembly code, maar zelfs als iets oorspronkelijk in assembly is geschreven is dat niet de originele code.

Wikipedia: Machine code
Ik vind het geweldig dat mensen dit maken. Heb zelf ook veel lol gehad met een paar oude ps2 games opnieuw spelen in hogere resolutie (dit was met een emulator maar goed), en ik speel een 2004 server van Runescape (Lost City project) waar de game wel helemaal nagemaakt wordt. Mario 64 port, wist ik niet! Ga ik absoluut bekijken, blijft 1 van de meest imposante games ooit gemaakt.
Voor mensen die geïnteresseerd zijn in wat er allemaal bij komt kijken. Hierbij een video serie over specifiek Lego Island.
Supergave tip, dankjewel!
Vooral mooi om terug te lezen hoe AI op een goede manier een ontwikkelaar kan helpen in zijn werk! Niet vibe coded prompts schrijven die om die pastabrei aan oude code te ontvlechten maar wel:
  • Een gevonden bug te checken met de lijst met bestaande & opgeloste bugs om deze sneller te categoriseren en daarmee op te lossen
  • Controle of de documentatie volledig is en waar nodig aanvullen met menselijke controle
  • Probleemanalyses zo opzetten (zie vb van de structs) waarin het zichzelf niet blindelings over neemt
Ook mooi om te lezen waar de beperkingen zitten in het gebruik van een LLM in dit soort processen. Zeker niet dat ik anti-AI ben maar een artikel als dit geeft denk ik een veel meer realistisch beeld wat we wel en niet kunnen verwachten van AI-ondersteund ontwikkelen
Als iemand die wat ervaring heeft met klassieke console ontwikkeling gaan er toch behoorlijk wat alarmbellen af. De oplossing voor de audiobug klinkt als een dubbele fout die goed uit pakt (waarschijnlijk een processor flag). Het verhaal over structs klinkt in mijn oren als een iemand die niet begrijpt hoe padding en alignement op processors werkt. Ook het verhaal over geheugen allocaties vind ik ontzettend verdacht. Waarschijnlijk betreft dit ook geen bug maar een truc.

Hmm... Na het lezen van de Github repository en het stuk van linuxgamingcentral wordt het mij duidelijk dat dit om retargeting framework gaat en niet een emulator/recompiler/decompiler.

Hij gebruikt een andere project voor decompilatie en verbind dan zijn code met dat van de decompilatie zodat het op andere platformen werkt en er dingen toegevoegd kan worden.

Pff... Geen wonder dat er alarmbellen af ging en waarom ik zoveel twijfels had.
En sommige features van de ports veranderen de ervaring echt wel fundamenteel.

Zo kun je Mario oppakken, en laten rondrennen in je eigen woonkamer .

Om te kunnen reageren moet je ingelogd zijn