Hello guys.

I have been trying to figure out if I should cap the max. number of frames there bust be each second in my SDL game. All my animations is moves according to delta, and is not effected by the number of frames each second.

I would cap the FPS with SDL_Delay, I tested by looking at the windows 7 task manager how much CPU my game would use under different circumstances:

I first tested to see if indeed SDL_Delay also spared the CPU, by setting it to SDL_Delay(20000), and the CPU under "Processes" showed: 01.

With a cap on 60 FPS, the CPU showed around: 25.

With no cap the CPU showed around: 50.

I wonder if it is important to cap FPS. Gamers around the world brag about how many FPS there games play with, so I guess there isn't a CAP on those games.

So would you cap it? or let it run as many times as you would like?

a little extra curiosity question:
I noticed a game I made in SDL used 250.000K memory when running under winXP32bit, but when I switched to win7 it used 150.000k. I had a lot of images. But anyone know why the different on the to OS?

I would put it as an option for laptop users to save power (potentially allowing it to switch power save mode automatically when the machine switches to battery power), most users would probably prefer to have it run at max speed though.

It's useful to save power for sure, but that should be your only motivation for doing it, and it should be optional and off by default. SDL_Delay uses standard Windows API Sleep calls behind the scenes, and Sleep has the interesting "feature" that the amount of time specified is only a guaranteed minimum sleep time - your program may in fact sleep for any arbitrary amount of time higher than that. I'm sure there was a good reason for that when it was designed, but it makes it completely inappropriate for this use case. FPS capping using Sleep (i.e. SDL_Delay) calls also has the effect that you're limiting extra CPU availability for transient conditions that may need it. Finally, you're only sleeping on the current thread; if your program (or any library or other DLL it uses - most of which will be OS-provided or from hardware vendors) spawns extra threads, and if those threads are consuming CPU time, then you're going to achieve absolutely nothing for them.

My personal preference, if you really want to limit FPS, is to do so using vsync.

(Exceptions: if your program can reliably detect when it goes idle, for example by checking time since the last input (may not be suitable for all cases), then sleeping a bit under that condition might be appropriate. It's also appropriate to sleep when the player Alt-Tabs away.)

I'm sure there was a good reason for that when it was designed, but it makes it completely inappropriate for this use case. FPS capping using Sleep (i.e. SDL_Delay) calls also has the effect that you're limiting extra CPU availability for transient conditions that may need it.

The code for the OS scheduler has to actually run for the system to be able to switch process and this can only be done using hardware interrupts or by the currently running process requesting it, Fixed sleep durations for high priority processes can only reliably be achieved by setting the timer interrupt to trigger when it is time for the high priority process to resume (Which means changing the timer frequency each time the scheduler run), by setting it to trigger at a very high rate or by the OS inserting its own instructions into the code that is scheduled to run, All solutions will result in the CPU spending more time switching between processes and running the scheduler and less time performing real work thus reducing overall system performance. (As CPU speeds increase it becomes viable to run the scheduler more frequently as you'd still get a significant number of cycles in between switches but you always lose performance by doing so.)

So yes, sleep should never be used to cap framerates, it should only be used to reduce a process cpu usage, (to allow other processes to run faster or the system to save power), If sleeping is used to save power Sleep(1) is appropriate, if used to allow other processes to run more Sleep(0) can be used instead (With sleep(0) the scheduler will hand control back to the calling process immediatly if no equal or higher process is ready to run), higher sleep durations only really make sense for background services)