Frame rate / limiting -- what is a 'frame'?

[Kroc]

Original Elite has no real concept of frame limiting, the main loop just goes as fast as it can and the physics/A.I. and rendering all run one after the other.

Elite 128 by Uz has an imperfect frame-limiter, but given that we have a complete disassembly with the freedom to modifying code drastically, we should look at what would be an ideal frame strategy.

My own vague opinion is that the physics & A.I. should be run on interrupts (probably throttled to 15fps), and have the 'main loop' running the screen rendering permanently. This should allow the rendering speed to scale smoothly and to extremes. i.e 20 MHz SuperCPU. A potential flaw with this idea is the confusion of a different set of lines to draw being generated whilst the renderer is already half-way through the set. A line buffer would be needed and this may increase memory demand considerably.

[dyme6510]

It is probably much easier to keep alternating between animate and draw, but to allow the physics to

1. 'catch up' to the desired game speed by skipping a draw phase.
2. emulate double or only half a time slice when drawing was fast.

So e.g enable the physics to run 50/25/10 fps and count the screen cycles, choosing the right emulation and repeat if still not up to game speed.

[mrdudz]

is there even "physics"? iirc its all pretty linear and simple, so making it run at smaller steps (on a faster cpu) shouldnt be too hard

[Kroc]

Actually, if we can run at 50/60fps (e.g. with SuperCPU or emulator turbo), then we should be aiming to run the logic at 50/60fps and scale the logic according to frames missed; but, this does raise the question of what should / shouldn't be scaled to full-speed -- A.I. decisions for example should probably be kept to 15fps to retain the feel of the original game.

[Kroc]

A note that Uz's Elite 128 2.0 has been released https://csdb.dk/release/?id=185931 and this adds support for various accelerators and a frame-rate limit of 12.5fps (PAL) / 15fps (NTSC)