I run a 100Hz monitor, and after recent work in other bugs, I was a little perplexed as to why in amosball, every other animation frame was ~16ms, then ~4ms. In a very predicatable pattern, it was always 2 frames totalling ~20ms. This makes sense for an average of 10ms per frame, or 100Hz, but the every other frame being non-existent was puzzling me further.
Digging into this a bit more, I found that this is due to the wait vbl command, which is causing this to skip a frame, but then this raises an issue.
On 50Hz displays, your effective FPS would be 25fps (Half PAL)
On 60Hz displays, your effective FPS would be 30fps (Half NTSC)
On 100Hz displays, your effective FPS would be 50fps (Full PAL)
This comes down to a more fundamental question... if we are looking to be backwards compatible with old AMOS programs, which FPS should we target in a wait vbl call? Should this be tunable by the compiler in the manifest? Using the previous times, we should be able to work out if we need to double a frame every now and then (i.e. if we're targetting 50fps, and we're on a 60Hz screen, then we would need to add 10 skipped frames, every 6ms or so). We could use the previous n frames to gauge the current average frame length, and compute whether we need to skip or not.
I'll look to add a patch in the next week to see how this looks, and fire it over to you Francois!