A snapshot of the machine, not just the hero
A normal in-game save usually records selected progress—such as a level, inventory, or checkpoint—and lets the game rebuild the scene when you return. An emulator save state takes a much more literal route: it captures the running game’s working state, including active RAM, the temporary memory the game is using right now.
RAM alone is not enough to resume perfectly. The emulator also needs the virtual processor’s current registers and the state of other hardware the game relies on, such as graphics or sound components. Together, those details describe what the emulated console was doing at that instant.
Why a fall can be undone
Games continually update that state: a character’s position, the speed of a jump, a countdown, and the values that control the next frame. When you load a save state, the emulator puts those values back rather than asking the game to recreate the moment from a checkpoint. The next frame therefore continues from the same precarious position—mid-jump, at the edge of a platform, or just before a mistake.
That is why a save state can preserve moments the game’s own save system was never designed to keep. It can also preserve temporary glitches or a badly timed action; it does not turn the moment into a safer checkpoint.
A snapshot with limits
The file is tied to the emulator’s model of the console and the game’s state. Different emulators—or different versions of one—may store or interpret that information differently, so a state is not necessarily as portable as a conventional save file. But within a compatible setup, the distinction is striking: a regular save remembers what the game chose to record, while a save state remembers the machine in the middle of doing it.
