55.6 frames per second

[TerryRitchie]

Thanks for the replies, I really do appreciate the help.

@bplus, good thinking on adjusting the _Limit duration at program run. I can't seem to find a sweet spot however.

It feels like there is something lurking beneath that has to do with _Display having a high variability (10~20 ms) in when the actual memory copy occurs.
I realize _Display needs to call a graphics copy function at the OS level, but it's actually waiting for something too? What would that be?

As for 55.6 fps, is the wait &h3da, 8 command unsupported at this point? I know from original QB that this waited for vsync (vertical refresh) back in the VGA compatible days.

The process on Old QBASIC was draw to the working screen page, wait until vsync, flip the screen page, clear the new working screen page, wait until not in vsync, repeat.

For QB64, I wish there was a command to essentially wait for vsync and copy over the image buffer to the OS at that point and return. And then if it was called again while in the same vsync period, it would actually just wait until the next vsync to do the copy.

thanks

Are you working on something that requires less than 20ms accuracy for screen updates? I've been writing games in QB64 since 2010 and have never once run into an issue where screen updates have hiccuped in the slightest using _DISPLAY and _LIMIT together.

I ran your example code with the changes I suggested for a good 5 minutes. It locked onto to 60FPS and stayed there. I watched intensely for any frame skipping and never saw one. It may boil down to the combination of CPU, GPU, RAM, and OS causing these issues.

Has anyone else run the example code with the changes I suggested and noticed any frame skipping?

My system specs are old but considered pretty good when new.

i7 6700K @ 4GHz, 32GB dual channel RAM @ 1GHz, nVidia GeForce GTX 960 4GB, Windows 7 Pro 64bit.

Update: DSMan posted while I was writing this. So there is an issue with QB64? Why am I getting a rock solid 60FPS then?