Note: These are rules from the player perspective.
lists which features are required
by the site maintenance.
page collection. Back to: <<
[1]Bulletproof recording
Players will load states out of order. People mess up; it's going to happen.
That's why it's important to store a complete movie file in each savestate.
(It's also useful for other reasons...)
[2]Resume Recording From Savestate
Since players rarely (if ever) record a movie all in one sitting, emulators
should be able to resume recording of a movie from a savestate.
[3]Savestate Undo (Low priority)
It happens many times that a player will save a state and immediately wish
they hadn't, and desire to recover the state they just overwrote.
An emulator should back up the most recently overwritten savestate to allow
limited undo capabilities.
An emulator should also back up the current state (whether it has been saved
or not) whenever another state is loaded, so that it can be reverted to the
state it was in before the load occurred.
[4]Frame Advance
The ability to pause and advance the emulator by a single frame is essential
for achieving maximum precision. Most people seem to prefer that if you hold
the frame advance key down, the game will advance at the current speed.
[5]Slow Motion
Not everything that is difficult to play in real time requires the precision
of frame advance. Emulators should be able to emulate at 50, 25, 12, 6,
and 3 percent normal speed (and possibly other speeds).
[6]Fast Forward
Lots of games include long periods of time where input from the player is
not allowed, for example, level transitions or cinematic segments that
advance the plot. Emulators should be able to emulate faster than real
time to allow skipping through these portions. This includes having a button dedicated to emulating as fast as possible, and the ability to set the emulation
speed to (for example) 150, 200, 300, 400, or 800 percent normal speed.
[7]Frame Search (Low priority)
Like frame advance, but also tests for which frame to switch button presses
after holding the previous button(s). Simplifies the process of repeatedly
loading a save state to find the minimum number of frames before the game
allows a desired outcome. To support this feature, it is practically required that the emulator also supports rewinding
[16] first.
[8]Key remapping
Most people like to remap game buttons and emulator functions to keys other
than default, or to a gamepad. These include pausing the emulator,
selecting/saving/loading a savestate, frame advance, etc.
Ideally, joypads should be supported in addition to the keyboard, for those
who wish to use them for emulator features without going through an external
mapping program.
[9]Read-only Toggle
In read-only mode, loading a savestate will cause the movie to begin playback
from that savestate. Out of read-only mode, loading a state will resume recording
from that point. Saving a state will create a savestate without changing the
movie file in either mode. Of course, the toggle must work even while the
movie is in the process of playing or recording.
[10]Information Display
The emulator should allow players to display useful information while
playing, such as the frame counter or which buttons are being pressed.
[11]Export To AVI
It helps movies to be published more easily if the emulator can export
to AVI (using a user-selected encoding scheme) during playback.
A frequently-requested feature is for the AVI to be split into multiple files
if it approaches 2 gigabytes, because larger AVI files tend to be corrupted.
[12]Memory Search
When making a movie, it is helpful to be able to search through memory
to find and display values at specific addresses, or to search for a
specific value. This is most useful for
boss fights,
but also for optimizing movements and randomized resource usage.
Preferably it should be possible to watch known relevant values while the game
is running without needing to navigate through a dialog every frame to see the
numbers.
[13]Autofire (Low priority)
It's very convenient if the emulator allows players to set a button to
be pressed every other frame, or every third frame, etc. Preferably the
autofire should take effect on the frame it is activated individually of
other buttons, so that it is possible to set two buttons to alternate,
and it should be possible to autofire any button on any player's controller.
[14]Auto-hold (Low priority)
For games that need a button held down for a long period of time
(such as the "run" button) or for making 2-player runs easier to make,
the ability to simply toggle any button on or off (so that it doesn't
need to be manually held down) is surprisingly helpful.
[15]Combos or macros (Low priority)
The ability to replay a frequently-used key sequence into the movie
currently being recorded. Very few emulators support this although
several people have requested it.
[16]Rewind (Low priority)
An emulator should transparently save a state every 5 seconds or so,
and keep track of the last 20 or so states so that a movie can be rewound,
in effect. This is especially convenient for people watching the movies
who want to reexamine a bit of the action without replaying the whole
movie from the start.
The number of states and frequency of saves should be configurable.
A nice extra feature is for the emulator to use these (or other)
rewind states to allow for (possibly unlimited) single-frame rewinding.
See also:
required movie file features by this site.
[17]Storing And Loading Emulator Settings And ROM Data
If the emulator lets the player set options that might affect playback,
such as sound frequency or PAL/NTSC, these settings should be saved in
the movie file and automatically loaded during playback.
It is also useful if the movie files stores data such as:
- ROM Name
- ROM Checksum
- Emulator version
- Number of rerecords
- A user-configurable comment (such as the author's name)
And the emulator should alert the user of any possible errors on playback
from these values mismatching, such as playing back the movie using a ROM
that has a different checksum than the movie was recorded with.
Note that the ROM checksum should be written in a way that allows reliably
distinguishing a wrong ROM from a correct one. A CRC32 or MD5sum of the
entire ROM's contents (including possible trainers) would be preferable.
It should not be just a copy of some bytes from the ROM, because that does
not enable reliable detection.
[18]Starting recording from power-on
Possibility to start recording from power-on with no savestates
or RAM or SRAM stored within the movie file, is necessary to provide
a fair, common ground for competitive purposes.
It is also a
requirement on this site.
[19]Recording peripherals (Low priority)
The movie format should support recording of non-standard input that might be important for certain games (gun accessory, motion sensor, light sensor, etc.).
[20]Recording resets
Supports recording of soft resets, or hard resets or power cycles that don't clear SRAM.
[21]Disabling layers
Some games have 'dark' areas that are unplayable until your character
retrieves a certain item, such as a torch or night-vision goggles. If
specific sprite layers can be disabled, these areas may become playable
without the required item.
It can also be used to reveal hidden parts of the level to find hidden
items or better understand the level layout.
[22]Accurate emulation of soft resets (Low priority)
Most emulators don't do this. It would be nice.
- What does this actually mean? How can we find out if an emulator emulates soft resets accurately? What are soft resets, anyway? -Bisqwit
- A soft reset is what happens when the player hits the reset button on the console (as opposed to a hard reset, which is achieved by turning power off and back on). These would more accurately be called warm resets and cold resets, because they are both hardware features. Certain games exhibit different behavior between a warm reset and a cold reset, and at least one Sega Genesis game (X-Men) requires a warm reset in order to complete it. --upthorn