In addendum to my previous post - the reason you're getting lighter CPU load at lower framerates is because you're using framelimiting - ie, simple delaying. Delaying is a waste of CPU time. In the time you delay the frame, Blitz could have already rendered the entire next scene (even if its only 0.05 seconds). Sure - in early programming we all start out controlling framerate by delaying - but when you feel suitably advanced enough, you need to switch to deltatiming.
Do a forum search for Delta Time to get a feel for it. Basically, rather than limiting the framerate to control CPU load, you let the program run as fast as it possibly can. Then, each frame, you see how much time has elapsed since the last frame, and update entity movements (or 2d graphics movement, whatever) relative to how far they should move at a given rate. If you want a character to move 50 pixels a second, and a hundredth of a second elapses between frames, then that frame, just move the character half a pixel (it'll sort itself out fluidly while playing). This way you're using the CPU as optimally as possible, and it'll run at the same speed on slow and fast CPUs. If someones computer can only run at half the speed required to move a character 50 pixels a second, then each frame it'll move the character 2 pixels. Get the idea? :) It takes a bit of getting used to and a couple of extra functions to write, but its the most efficient way to time a game.
You can use this timing system not only for player movement, but also for everything else - animations, hud updates, etc. Most modern games use delta timing as opposed to frame limiting. You can see it in use by loading up a 3D game that your CPU can't handle (For your computer, try PainKiller or Doom3 at high res). When you move around, the character doesn't move slower as a result - it "jumps" about, giving the "jerky" effect that occurs when a computer isn't powerful enough to run a game at a minimum speed. Thats because each frame, no matter how long it took between frames, or no matter how short, it updates the player movement/enemy movement/animations/etc at the same constant rate.
+BlackD
Do a forum search for Delta Time to get a feel for it. Basically, rather than limiting the framerate to control CPU load, you let the program run as fast as it possibly can. Then, each frame, you see how much time has elapsed since the last frame, and update entity movements (or 2d graphics movement, whatever) relative to how far they should move at a given rate. If you want a character to move 50 pixels a second, and a hundredth of a second elapses between frames, then that frame, just move the character half a pixel (it'll sort itself out fluidly while playing). This way you're using the CPU as optimally as possible, and it'll run at the same speed on slow and fast CPUs. If someones computer can only run at half the speed required to move a character 50 pixels a second, then each frame it'll move the character 2 pixels. Get the idea? :) It takes a bit of getting used to and a couple of extra functions to write, but its the most efficient way to time a game.
You can use this timing system not only for player movement, but also for everything else - animations, hud updates, etc. Most modern games use delta timing as opposed to frame limiting. You can see it in use by loading up a 3D game that your CPU can't handle (For your computer, try PainKiller or Doom3 at high res). When you move around, the character doesn't move slower as a result - it "jumps" about, giving the "jerky" effect that occurs when a computer isn't powerful enough to run a game at a minimum speed. Thats because each frame, no matter how long it took between frames, or no matter how short, it updates the player movement/enemy movement/animations/etc at the same constant rate.
+BlackD