I've been looking at the latest version of the ScummEngine and it looks like the main game world update still uses an integer based delta. With this approach, I don't see how I will ever get more than 10fps out of my game (apart from multi-threading the sucker).
This is how I think it basically works at the moment:
ScummEngine::go {
// Determine how long to wait before the next loop iteration should start
int delta = (VAR_TIMER_NEXT != 0xFF) ? VAR(VAR_TIMER_NEXT) : 4;
// Wait...(Yawn...)
waitForTimer(delta * 1000 / 60 - diff);
ScummEngine::scummLoop(delta);
}
ScummEngine::scummLoop(int delta) {
// Update game-world based on units
}
This is a very strange way of doing it, it's better to use this kind of approach.
void main loop() {
while(!shouldQuit()) {
// Calulate how much time has passed since the last loop.
float delta = (some code).
scummLoop(delta);
renderScreen();
getUserInput();
}
}
ScummEngine::scummLoop(float delta) {
// Update game-world based on units
}
The second approach will ensure that the game runs at a constant speed no matter how fast the machine whereas a slower machine will just display less FPS.
Not all developers read the forums so the right person might not see your post.
Also, contributing a patch (even a work in progress one) would go a long way. Dev time is limited, so implementing such a feature could take a long time or not happen at all unless someone takes interest in working on it (especially since there might be regressions and side-effects and so retesting games would be needed).
NovaCoder, you misunderstand the code. While it doesn't use floats, it still ensures that everything runs at a constant speed, albeit using integer arithmetic. The speed to be used is controlled by the scripts, by the way, and a multiple of 60 Hz (or, as gamers seem to put it, 60 FPS).
It is true that the integer based approach is not quite exact; it may cause the base framerate to be slightly higher/lower than 60Hz (say 59 or 61 Hz), but that shouldn't be perceptible.
It would be possibel to make it "fully" accurate by using an Audio::Timestamp (and its integer based, rounding free approach to counting frames and milliseconds accurately), although I don't think that it would have any perceptible impact.
I am not intimately familiar with the ScummVM code, but I am working on an other project that uses libSDL.
You basically works with a millisecond clock and its use of integers is just fine.
int bla = SDL_GetTicks();
This gives you the amount of milliseconds since the program started running.
SDL_Delay(10);
This makes the program stop for 10 milliseconds.
With some these commands and some math you can make any kind of timer you like. The rounding error of one millisecond is WAAAY to small for a human to detect, so it's not much use for a game to go more precise then that.
Just for completeness, in addition to what's been said: Yes, the rounding error is too small for the human eye to notice, but when syncing audio & video these small differences can make a difference if they accumulate over a long time. 1/3 ms lag per second run over 10 minutes = 600 secs adds up to 200ms lag, which *is* perceptible.
Even when using floats, this accumulative rounding error can strike. Using integral fractions and exact computations (as Audio::Timestamp does), this problem is entierly avoided.
fingolfin wrote:NovaCoder, you misunderstand the code. While it doesn't use floats, it still ensures that everything runs at a constant speed, albeit using integer arithmetic. The speed to be used is controlled by the scripts, by the way, and a multiple of 60 Hz (or, as gamers seem to put it, 60 FPS).
Hiya,
Ok so you are staying that if the inner loop is already running at 60FPS this code will not do anything?
And if the loop is running at less than 60FPS (eg the machine is a bit slow) then delta will be updated to 'skip' the scripts forward to the correct place (to maintain a constant game-world speed)?
(Just for the record, note that most SCUMM games don't run at 60 Hz, but rather at a fraction of that; typically 15 Hz.)
Things are never "skipped ahead". This is impossible to do in a scripting based system.
However, you do have a point in that the engine currently does not handl if a script engine iteration unexpectedly takes very, very long. The next iteration after that will have a delay of 0, but future frames won't delay further.
The engine could try to adapt to that by letting several future delays be 0, instead of just one, until the lag has been caught up with. We don't currently try to do this -- mainly to precisely match the behavior of the original engine, which didn't try to do this either.
I'm a little out of my league here, but wouldn't it be a bad idea to use floating point arithmatic in a game engine as some of the platforms (DS, GP2X) don't have FPU's?
