a comment on that site really condescendingly claims this is how he would have handled it and that a script could be written in half a day to do the work.
my understanding is that an emulator effectively recreates the hardware’s different components in software so that from the game’s “perspective” it’s running on a real machine more or less.
This process instead decompiles the game code and recompiles for a new target machine.
I suspect one can’t just pump out a script in an afternoon to do this, but I am curious what is the complexity here?
For graphics, the problem to be solved is that the N64 compiled code is expecting that if it puts value X at memory address Y it will draw a particular pixel in a particular way.
Emulators solve this problem by having a virtual CPU execute the game code (kinda difficult), and then emulator code reads the virtual memory space the game code is interacting with (easy), interprets those values (stupid crazy hard), and replicates the graphical effects using custom code/modern graphics API (kinda difficult).
This program is decompiling the N64 code (easy), searches for known function calls that interact with the N64 GPU (easy), swaps them with known valid modern graphics API calls (easy), then compiles for local machine (easy). Knowing what function signatures to look for and what to replace them with in the general case is basically downright impossible, but because a lot of N64 games used common code, if you go through the laborious process for one game, you get a bunch extra for free or way less effort.
As one of my favorite engineering phrases goes: the devil is in the details
a comment on that site really condescendingly claims this is how he would have handled it and that a script could be written in half a day to do the work.
my understanding is that an emulator effectively recreates the hardware’s different components in software so that from the game’s “perspective” it’s running on a real machine more or less.
This process instead decompiles the game code and recompiles for a new target machine.
I suspect one can’t just pump out a script in an afternoon to do this, but I am curious what is the complexity here?
For graphics, the problem to be solved is that the N64 compiled code is expecting that if it puts value X at memory address Y it will draw a particular pixel in a particular way.
Emulators solve this problem by having a virtual CPU execute the game code (kinda difficult), and then emulator code reads the virtual memory space the game code is interacting with (easy), interprets those values (stupid crazy hard), and replicates the graphical effects using custom code/modern graphics API (kinda difficult).
This program is decompiling the N64 code (easy), searches for known function calls that interact with the N64 GPU (easy), swaps them with known valid modern graphics API calls (easy), then compiles for local machine (easy). Knowing what function signatures to look for and what to replace them with in the general case is basically downright impossible, but because a lot of N64 games used common code, if you go through the laborious process for one game, you get a bunch extra for free or way less effort.
As one of my favorite engineering phrases goes: the devil is in the details