PocketMatrix

I might be missing something, but... how are you guys doing (assuming you are) frame rate limiting?

Specifically, when developing on the desktop I don't want my app running as fast as possible, I want some known maximum. This would also be true in many cases on a PPC, but on the desktop for sure.

Any comments? Thanks!

This subject has been covered a countless number of times in these forums. Just do a search?

Ok, you officially have permission to slap the crap out of me... I DID do a search originally, but for whatever reason didn't find a suitable thread. I just tried after seeing this and guess what?? FOUND A THREAD!

Worse...

ONE I STARTED!!

Argh.

My suspicion is that the power savings wouldn't be noticeable. Especially when your frame render times are close to the limit anyway, there's not going to be a difference big enough to matter.

Though, I could be wrong I'm not certain how much CPU time really matters on modern devices... I'd be willing to bet though that the vast majority of power usage still comes from the things it always has... screen, memory cards, etc. I'd bet the CPU accounts for such a small percentage that it wouldn't make any tangible difference.

But, I can't think of a BAD side to the sleep, and if no one else can either then I'd say cool why not do it and get whatever benefit there might be, regardless of how minor it may or may not be?

The only reason to limit FPS is to save battery power. If you're not saving battery power with your implementation of FPS limiting, then it's pointless.

If you're using FPS limiting for time based animation and movement, then you need to rework your design. Even if you limit the FPS, slower deviced may run your game at a lower FPS, especially if the user has other things running in the background.

So in short, use a FPS limiting implemention that'll save battery power. Just my 2 cents on that subject.

I don't agree with that. This discussion has been done to death frankly, but still...

The one true benefit of a frame-limiting solution is that you know that your game will run the same on all devices. There is nothing I hate more than a game that runs smooth as silk on one device but runs like a pile of shit on another. Sure, the SPEED is identical, all the TIMING is the same, but the SMOOTHNESS is not. Any time I see a game that gets choppy I walk away from it in a hurry. Frame limiting, WHEN DONE RIGHT, avoids this.

I'd much rather determine the minimum frame rate my game needs, and in fact DESIGN the game to run at some tiven rate on ANY device, and go from there. The trick is to pick a baseline device that no device you will support will perform worse than, and use that as your guide.

I always use my trusty E-125 for that. For those that haven't been around as long, that's a 150MHz MIPS device running the original PocketPC OS. Slow as balls compared to ANY modern device. So, if my game runs consistently at 30FPS on that, I know I'm golden.

Of course, there will always be situations you can't design for... Someone that underclocks their 600MHz PocketPC to 200MHz to save battery is going to make life difficult for any game. I contend you shouldn't be designing for such situations. But, if you target an E-125, or even an original 200MHz iPaq would be safe these days, you will be fine.

Now, to be fair, some games you just CAN'T do this with. I would NEVER use this technique on a 3D first-person shooter. Just wouldn't work right. Many other types of games probably wouldn't work well either. But I dare say that most 2D games probably would be fine.

Aside from the smoothness benefit, you also greatly simplify your code. Well, maybe not *greatly*, but somewhat anyway.

As with most things in development, to say one thing is good or bad, right or wrong in absolute terms is usually a bad thing to do. If you understand the implications and make your decisions accordingly, even the "bad" architectural decisions can be good ones in some cases. Frame limiting is one example of this.

One thing about not sleeping... On the x30 I've got - the button presses tend to be sluggish if you don't sleep a little.

I use a combination of frame limiting with time correction - since even with limiting, the frametime is not exactly the target. Plus, if the framerate drops below the target - the game doesn't slow down.