3 ms·
Funny that these things are mostly referred to as 'emulator bugs'. It would be more accurate to call them bugs in the game. It's a bit like the situation with
by kutkloon7 9y ago
Funny that these things are mostly referred to as 'emulator bugs'. It would be more accurate to call them bugs in the game.
It's a bit like the situation with C, where some code depends on a specific outcome of undefined behavior.
With this, I don't mean that the programmer of the game is to blame. If you are developing for a single system, it is reasonable to use some of the properties of this system. In this specific situation, it might even be of interest for Nintendo, since it makes it harder to pirate games.
If one would like to avoid a situation like this, it seems best to develop for an emulator with unreliable properties (the principle of fail-fast: crash and let the developer know that he makes an assumption that is not guaranteed to hold), but which implements the ISA faithfully.
- digi_owl 9y agoNah. These are emulators built not to just run the games, but to be have as closely as possible to the real hardware companies were shipping for years. This means that if a game that worked on actual hardware is not working in emulation, the emulator is no behaving accurately enough compared to the hardware.
- eropple 9y ago> Funny that these things are mostly referred to as 'emulator bugs'. It would be more accurate to call them bugs in the game. You are missing the point of an emulator: to correctly emulate hardware. Off-label use of the hardware was standard in that era of game development. Failure to support it is an emulator bug. > it seems best to develop for an emulator with unreliable properties Those emulators generally did not exist during the commercial lifespan of the system, at least not in any real quantity, and mean giving up on the advantages of the actual behavior of the hardware. Correctness is not as important as performance and fluidity in a console game.