After exhausing the little brainpower I have left, I came to a horrid conclusion: PC's stink, and Windows is even worse, and some of that smell rubs off on PureBasic.
Hehe
That's the hook.
(This is long and rambling, but I think worth a thought. Written on August 27, using PureBasic 4.20, knowing perfectly well that it will be improved in the future. Maybe this little thought experiment can help finding the right path
I'm not saying that PureBasic is to blame! I'm just saying that if PureBasic is not to blame, we have to get smart and find a way around the current limitations.)
Now let's think. Why is it, no, why do *I* find it so hard to write a game in PureBasic? Refresh. And CPU load.
Let's look at the current DirectX 7 / 9 implementation in PB, and some general limitations of developing games on Windows machines.
1. Tear free.
If you want to avoid 'tearing' on your screen, there are three possibilities...
- you only redraw your screen during 'vertical blanks' so the user won't see the updates
- you ramp up the framerate so much the user won't notice, or
- you 'obfuscate' the tearing by interlacing, smoothing edges, and similar tactics
The most logical approach is vsync, updating the image during vertical blanks. It's also (somewhat) implied in DirectX and PB, using the FlipBuffers() command.
2. DirectX and the FlipBuffers() bug.
FLipBuffers() has a few parameters. To go tearfree, we want to wait for vertical sync, so FlipBuffers(#PB_Screen_WaitSynchronization) would be a logical choice. Unfortunately, DirectX makes a mess of it (not PB's fault) and eats up all CPU cycles until it can flip the buffer.
That's a pain. Obvioiusly, it's no good to waste expensive CPU power on something like waiting. We could be processing other messages, prepare for the next level, load images, and even do totally non-game related things in the background.
FlipBuffers() has a variant called FlipBuffers(#PB_Screen_SmartSynchronization) which is supposed to reduce CPU wait time, but unfortunately it appears to be a bit broken. It causes a little jerking and tearing under DirectX7, and doesn't wait for anything with DirectX8.
So, that's a bug in PureBasic, but it's only half the problem.
3. Frame rate vs. Refresh rate.
Refresh rate = the number of times per second your monitor shows you an image.
Frame rate = the number of times per second your program draws a new image.
You DON"T control the refresh rate on the machine you run your game. You may THINK you do, but you don't. Sometimes you can change it, but often you cannot, and there is no guarantee that the physical monitor of the user can handle your requested refresh rate.
If you tie your program to the refresh rate, your program will perform differently on different machines with different settings, ie. on some machines the program will run faster than on others, depending on the refresh rate. Not good.
So, if you tie your program to the refresh rate (which is exactly what you do when using FlipBuffers(#PB_Screen_Waitsynchronization) your program is stuck to whatever the user set as a screen refresh rate, and in this case you can assume framerate = refresh rate.
4. The fractional solution.
Assume a player object should move 'n' pixels per second, then you could deduct how many pixels it should move per frame. Let's say the framerate = refreshrate = 60 / second, then:
speedperframe = speedpersecond / 60
Your engine would thus, each frame, have to calculate the movement of your object, adjusting it's position with speedperframe distance. To avoid fractions / roundings you should store coordinates in floats then, not in ints.
5. The threaded solution.
Another approach would be to spread your logic over multple threads. (A requirement for this is that FlipBuffers() is accurate and does not steal all CPU cycles). You could put your 'graphical' engine in one thread, and your game logic in another, etc.
Ah. All starts to make sense. I need to drink more... where's the bottle?
You can test with linux with more success, I think 