Why do old emulated games still suffer from slowdown and lag when they run on modern computers?
In: 36
I think alot of it just has to do with the back end of the game. The coding essentially. What the game was wrote on was high speed at the time. The technology in your computer didn’t exist yet
Bumping. I’d also love to know why this is the case. I was playing Bloons the other day and sure enough it was lagging. Very interesting. So yeah. Hopefully this doesn’t get deleted by the auto bot.
Instruction Set Translation.
If I ask you to read a letter I wrote in your native language you’ll be able to read it fast and without mistakes. If I write it in a language you don’t know, you’ll need to translate it into your language first, and you might make mistakes.
This is the same process that takes places when emulating games. The language of the original game is written in an instruction set the current CPU cannot understand. The translation from one language to another is expensive. This overhead takes more processing powering and can result in slow downs.
The short of it is that old consoles used specialized hardware for different effects. And they needed to to get playable games with slow clock speeds.
All that stuff happens in parallel in the background, in hardware not depending on the actual console cpu to do stuff. And lots of it happens asynchronously or with wierd timing that needs to be reverse engineered by poking at the hardware.
Like the SNES despite being only 25MHz had something like 5 separate purpose built processors, and some extra coprocessors types that lived on the game cartridge.
On a modern computer though you need to emulate that specialized hardware. Each bit of hardware you try and emulate takes up processing time. Eventually that just adds up and you can’t do it all without a lot of CPU power.
Here’s a good article on the SNES stuff specifically.
http://arstechnica.com/gaming/2021/06/how-snes-emulators-got-a-few-pixels-from-complete-perfection/
Old consoles have CPU running synchronized with video and audio chips. Some games depend on the exact time of code execution to issue commands in the right time. Games can, for ex., change graphics settings in the middle of frame drawing – this can produce visual effects, that the video chip cannot do on its own. Emulator, of course, have to simulate all delays, because they can be meaningful.
Example: Super Mario Bros. has scrolling levels, and a status bar, which does not scroll. But NES’ video chip can only scroll the entire screen. So, the game sets 0 scroll, waits until the last line of status bar is sent on the TV, and then changes the scroll. But for that the program on the CPU must be able to keep the time somehow. NES doesn’t have timers, so the game can only rely on instruction timings for timekeeping.
Games on those systems ran on a pretty tight schedule: process the game, wait for a signal from the graphics processor that frame drawing had finished, and then update the screen graphics while the hardware preps for the next frame to be drawn. Games lag when processing the game took so long that the signal from the graphics processor went unnoticed, and the game waits for the *next* signal before continuing, cutting the game speed in half since only every other signal progresses the game.
Emulators try to simulate the original hardware faithfully. That means the CPU speed is still slow – the NES was about 1.72 MHz, and the SNES was only around 4 MHz on the main CPUs. The signal from the graphics processor may be simulated, but the timing still matches the real hardware and the game code will still wait around for the second signal if it missed the first.
You could raise the CPU speed in the emulator, but you run risks doing that. Multiple chips in the original hardware communicate with each other and their timing may be thrown off by one chip running faster than another, and overclocking more chips may have side-effects like audio being distorted. The hardware can query the graphics processor to see its progress and it might mess up the game logic if the CPU were running faster than expected.
Basically every console in the world was effectively the same specs with only minor regional differences (typically 50 Hz vs 60 Hz). Develops wrote their games assuming this to be true. Changing reality in this way may have unexpected surprises and it’s not the devs’ fault if that happens.
Sometimes it’s because the emulator is just emulating the console accurately, and the console would also slow down at that point.
A lot of older consoles (and especially arcades) had a lot of other chips that did things, so your one-CPU computer has to co-ordinate a half-dozen virtual chips. You ever see an [orrery](https://upload.wikimedia.org/wikipedia/commons/8/88/Orrery_small.jpg)? It’s a model of the solar system, when you turn a handle all the planets and moons move as they do in reality, using a huge series of gears. Now imagine you have one of those, but all the gear teeth are missing. You could still use it, you’d just have to move the handle a teeny bit, then see what the gears *should* have done, and move the planets appropriately. You can imagine how that’s a lot slower.
Because the code is not simply translated. The entire architecture is emulated. So your modern pc is recreating the hardware of the emulated device, so ideally the game should run exactly as on the original device
Old games were written to be ran on different hardware, and different operating system. With consoles specifically, often optimized heavily for that machine/OS.
It’s equivalent to you operating a set of controls labeled in Russian, by following instructions written in French, but you only speak and read English, and only have a couple translation books to go by.
It’s a very inefficient way to work, and there often “missing instructions” because not everything has a good or direct translation.
Latest Answers