It’s really rather simple. The game runs at a fixed logic frame rate
of 60 Hz (which is rather easy as it’s using a VGA Mode-X mode at 60
Hz), and the logger/demo player is inserted right between the input
code and the “player control” interface of the game logic. The
logger/demo player has three modes:
Normal:
Forward input to the game logic.
Record:
Forward input to the game logic, and record
the input state for each frame.
Playback:
Disable input and instead pass the state for
one frame at a time to the game logic.
This still works in a game like Kobo Deluxe, where there is a fixed
logic frame rate, but it does not work for games with variable
logic frame rates, as you cannot get accurate playback without
enforcing the exact logic frame durations as well as the input. (And
then you’ll need interpolation to make demos look good, and then you
may as well use a fixed logic frame rate + motion interpolation, as I
do in Kobo Deluxe.
IIRC, since input in Project Spitfire is nothing but 4 directions
(digital) and two fire buttons, I just store one byte of data per
frame, ie 60 bytes/s. Not very much, as that’s all that’s needed to
fully reproduce a game. (Enemies have no AI, and there are no random
events or interactive game logic; it’s just plain retro style
preprogrammed attack waves.)
//David Olofson - Programmer, Composer, Open Source Advocate
.- Audiality -----------------------------------------------.
| Free/Open Source audio engine for games and multimedia. |
| MIDI, modular synthesis, real time effects, scripting,… |
`-----------------------------------> http://audiality.org -’
— http://olofson.net — http://www.reologica.se —On Monday 29 September 2003 23.16, Dominique Louis wrote:
Hi David,
From your reply I could not work out which technique you did end
up using in the SpitFire.