Eli5 why is Video Game emulation so difficult? And how do new glitches come about?
In: 54
Video game consoles use specific, purpose-built hardware to run the games. Certain things like very particular CPU, RAM, sound and graphics processors.
A PC lacks that specific hardware, so it has to imitate its function in software. This is seldom perfect, especially since we often don’t have access to the actual full design of the original hardware.
Think about it like this.
A house is built on top of a foundation. And that foundation is built specifically for that spot.
You can’t just pick up the house and place it somewhere else and have everything be fine and dandy.
In order it move said house, a new foundation must laid. Then all the plumbing and electrical will have to be redone in order for it to be a functional house.
Video games are the same. They’re built for the specific architecture (the platform it’s on).
Here’s a few analogies for you:
Game: Hey, I need some bread for this sandwich.
Console: I have the perfect bread right here.
PC: I have tortillas.
Game: I want to take this trail to the mountains.
Console: I have a pair of hiking boots for you.
PC: I have this sports car.
To get emulation to work, the game needs to make a sandwich with tortillas and hike a mountain with a sports car. Totally possible, but some compromises need to be made.
Different developers program in different ways. Let’s look at FPS, Frames Per Second, as an example. This is how many times the game shows you a new picture every second.
Dev 1 might make a game at 30 FPS and tie the physics to that game. This means if the FPS increases the game speed increases.
Dev 2 might make the game have unlimited FPS, meaning that the FPS will go as high as the hardware allows, but since all, say, GameCubes, have the same hardware, the dev knows the FPS will mostly stick at 30.
Now let’s try to emulate each of these games. Let’s say the GameCube emulator lets the game increase FPS to what the hardware allows. The computers people are using to emulate today are generally much better than the GameCube was.
Game 1 stays are 30 FPS and works fine.
Game 2 now has 120 FPS sometimes, but drops to 60 FPS sometimes, or 30 FPS sometimes. Since a PC will have multiple process on-going this will change the frame rate to however much the computer will handle at the time.
So one game works fine, but one has a constantly changing frame rate, which is very annoying. To fix this let’s say the emulator changes it so all games now run at 60 FPS.
Game 1 now runs at 60 FPS, but since the physics were tied to frame rate, the game now runs at double speed.
Game 2 now runs at 60 FPS, and works fine, but some people have good enough computers that were able to constantly run it at 120 FPS, and are now upset the game doesn’t run as smoothly.
All of this is to say that games are software made for a very specific hardware. Every GameCube game was made just for the GameCube. Trying to make that game run on PC, where each user will have slightly different computer, and also want the games to run better than they did originally, leads to plenty of glitches. This is why new emulator glitches come up, because any system wide change will effect some game. Fixes will need to be made on a case-by-case basis, which is very time consuming for people who often aren’t getting paid to make these emulators.
Consoles run operating systems that are made specially for the console’s hardware.
When you’re running an emulator, you’re actually running a clone of that operating system *inside* of your actual operating system.
So now your Windows machine has to be smart enough to be a Windows machine AND another operating system, all while trying to cut down on input lag (which is a big deal for video games).
So it makes sense that the more complex the console system, the more advanced the main operating system computer has to be.
Because you can’t just run the emulator, you have to surpass it, otherwise lag gets in the way.
In addition to everything else that’s been said here, emulators (if they want to be legal anyway) have to *reverse-engineer* all their coding.
You can’t just take the coding language for an N64, plop it in a virtual environment, and viola! N64 emulator! Nintendo will sue you into the goddamn ground. They don’t own the function of “running an N64 game”, but they do own the code the N64 uses to do it.
So you, emulator programmer, have to write your own code, from scratch, and as anyone who’s every done that can tell you, *there will be bugs*.
At its most basic, a computer program (including a game on a computer or gaming console) is a list of very rudimentary instructions. If you have any familiarity with high-level programming, you might be familiar with stuff like this:
10 I = 0
20 WHILE I < 10
30 PRINT I
40 I = I + 1
50 WEND
When this is compiled to a program binary, it might end up with a binary representation which looks essentially like:
1. Create a variable called [I] and set it to the value of 0.
2. Jump to line 6 when the variable [I] is equal to or greater than 10.
3. Output the value of variable [I] to StdOut (the screen)
4. Increment the variable [I] up by 1
5. Jump to line 2
6. [End Program]
Now, these instructions above (in binary form) would normally be sent directly to the CPU, no further processing. Each line takes one to three clock cycles and is super fast.
The problem arises when you find out that the binary representation of these instructions on an Intel x64 processor is completely different than the binary representation of the same instructions on a MOS Technology 6502 (used on the NES). Also, (going back to hypothetical since CPU architecture is out of my wheelhouse) the instructions on line 2 and line 4 have to be rewritten for the Intel x64 due to it having a different instruction set:
* For line 2, the instruction might be something like “Define a loop from lines 2 to 4. Loop while [I] is less than 10.” and line 5 is skipped altogether.
* Line 4, the Increment statement cannot increment by 1 but must specify a second variable to increment by.
(These are just examples)
What an emulator does is it steps through each instruction and, as best as it can, attempts to execute the equivalent instruction. The emulator knows how to handle situations such as line 2.
So why is it slow?
In the most optimized emulator, it first has to read the instruction from the code being emulated which is like 3 cpu instructions. Then figure out what the equivalent cpu instruction should be which may be as few as one instruction and as many as 30, especially is there’s a dynamic rewrite like the example with the loop. Then it has to run the equivalent instruction(s) which very likely requires reading or writing variables from ram, which is also being emulated, so more instructions.
And this is just for the game logic. This doesn’t cover anything about graphics or sound.
It’d be easy if it were simply translating the instructions from one cpu to another, but on a game console, the game assumes it’s the only thing running and that it has complete control over the hardware which is NOT the case on modern computers.
Check out this [three-minute video of this cool adding machine](https://www.youtube.com/watch?v=GcDshWmhF4A) made out of wooden parts!
You don’t need to understand exactly what he’s talking about, but you can see that the parts of the machine are quite simple; they just move like see-saws when marbles hit them. And if you build the machine like he has, then you’ll get a machine that can do addition. Neat!
But what if you want to do addition with it, but don’t have the actual wooden machine?
Well, you could actually just do what it does with pencil and paper. If you draw the machine and then “pretend” to drop the marbles in by drawing the marbles, flipping the see-saws around yourself by erasing and drawing them in their new positions, and then drawing where the marbles end up falling. And if you do a careful enough job, then you’ll get the same result as if you had the actual wooden machine.
But if you make a mistake by accidentally flipping the wrong see-saw, forgetting to do a step, or drawing the machine wrong in the first place, then you won’t get the correct result; your pencil-and-paper machine had a “glitch” in it.
Emulation is the same thing. A video game console has an actual computer board inside with specific chips and wires and doodads in it that your computer doesn’t. So the emulator program has to “pretend” to do what the console computer board does, but with computer code instead.
And if the computer code doesn’t perfectly match what the console’s computer board actually does, then you get a glitch.
That’s why it’s so difficult; it’s really hard to write a computer program that does what a console computer board does perfectly exactly.
In regards to new glitches, I can give a good example.
Say you play Donkey Kong. Mario moves thirty pixels per second when you press forward.
Except he is actually moving every single frame; at thirty frames, he’s actually moving one pixel per frame.
Donkey Kong gets emulated on your brand new gaming PC. They don’t correctly adjust for the fact that this game was built to run on a system considerably slower than the one you have, now.
Instead of being able to produce thirty frames a second, it produces three hundred frames per second.
Old mate continues moving at one pixel per frame, and suddenly moves at 10x the speed they are designed to move at.
Obviously this isn’t normal, by itself. Except, the physics system (what little there was) doesn’t account for this speed. It thinks Mario still moves at 30 pixels a second. Collision breaks. Mario runs through the wall and disappears. Game Over.
Modern game developing accommodates for this particular case quite well, but if the game was not explicitly coded to accommodate changes in processor speed (like if, say, they only ever intended one processor to run it that naturally has the same constant speed), all sorts of stuff breaks.a
1) It’ not that difficult! If it was we wouldn’t have emulators for almost every system that has existed.
2) HLE vs. LLE. People want to play the games ASAP, so many emulator use High Level Emulation, which is less accurate but gives better results on the short run. A better solutiuon is to use Low Level Emulation / cycle accurate. This however means more work and higher system requirements.
3) Some games use clever hardware tricks and undocumented features to achieve what they achieve.
4) Emulators are als oprograms, and therefore have bugs on their own.
Latest Answers