Bringing button responses forward with run-ahead
A game draws the result of a button press a frame or more after reading it. Run-ahead runs those frames in advance to bring the response forward, and uses more battery for the extra work.
A game draws the result of a press a frame or more after reading the button. In an emulator the delays of display and input handling are added on top, so the response can feel late.
Run-ahead runs in advance the frames a game would draw late. For every frame shown, the game advances one frame and that state is kept. It then runs the chosen number of frames further, shows that later picture, and returns to the kept state. A press shows up that much sooner, while the game still moves forward one frame at a time.
Only the sound and rumble of the final, displayed frame are used; those of hidden frames are discarded. To keep the predicted progress out of in-game saves, mGBA also copies the cartridge save memory omitted from its save state and restores it with the rest. Rewind history and save states contain only the state kept before running ahead.
The cost is computation. Every frame shown runs one frame more than the chosen number, plus a save and a load of the state each time. So it is off by default and works only at 1×; during fast-forward there is no reason to bring responses forward.
How many frames can be run ahead is set per system. Most allow two; Super Famicom and Mega Drive are held to one until the cost has been measured on a real device. Nintendo DS and PSP are left out: their save states run from several to tens of MiB, and the PSP core needs its graphics processing even for a frame run in advance.
Another problem turned up along the way. The six systems run on ares sometimes advanced two frames at once when the picture arrived late. Run-ahead only works when each step is one frame, so the app now waits for the picture to arrive, and the occasional double step in ordinary play is gone as well.
How much frame time and battery use change on a real device has not been measured yet.
Related development stories
- Development storiesv1.2.0Closed beta testing
Write in-game saves while playing
In-game saves used to reach their file only when the app went to the background or the game closed. From 1.2.0, the data is written after it stays unchanged for a second.
- Development storiesv1.2.0Closed beta testing
Reduce repeated work on paused screens
A still picture can keep the renderer busy. Version 1.2.0 distinguishes when another draw is needed and lets you try settings before saving.