HerzAusGold wrote:Is there no implicit value for this available?
e.g Framerate?
No and Yes.
If Frametime is set, this implies a constant speed in real time. Such a cave is not designed on a C64 Boulder Dash engine. This attribute is meant for newly developed caves/engines.
If Cavedelay is set, it is what the C64 engine used, ie. no constant speed but depending on the elements in the cave, as elements need different amount of CPU time. In this case, there is no multiplier implied. So we need another attribute for this.
Frametime can be specified along with Cavedelay, so BDCFF capable engines which don't support Cavedelay can fall back to a reasonable value which should reflect the average speed.
For documentation this should be set to the value the author intended.
Which is 1.2 for any game designed on a PAL machine, if specified as a multiplier .
A clone should have values to adjust timers by a multipikator.
A cycle exact clone is very difficult, and new levels should be designed without needed cycle exact timing for movement.
Exactly.
This multiplier only makes sense for a game which was made on a TV system based machine. Any newly developed game should be realtime, to avoid confusion, I think.
So the new attribute might look like this then:
TimingFactor=multiplier
multiplier would be 1.2 for PAL games and 1.0 for NTSC games, except for CrLi which is always 1.2.
The question what to use as a default value still remains.
1.2 would reflect 99% of the fanmade games while 1.0 is real time.
Since restricting this to caves using Cavedelay is reasonable, using a default value of 1.2 wouldn't interfere with newly developed cave, which should stay in realtime. Ie. whenever the engine uses Frametime timing, there is no multiplier applied.
Of course, correcting the framerate for this difference alone would not solve the problem as this affects all timers, eg. Magicwall time, Amoeba slow growing, Hatching delay (4 seconds in C64 timing) and Enemy direction change.