0

Possible Duplicate:
What's the usual way of controlling frame rate?

I'm an amateur when it comes to programming, but I wanna ask if this is an efficient way of handling things.

Right now, my program currently updates itself with every step, but I am looking to divide the program up into a smaller frame rate. My current idea is to set a clock in main, where with every 30 ticks or so (for example), the game will update itself. However, I am looking to update the different parts of the program separately within that slot of time (for instance, every 10 seconds) with the program updating the screen at the end of that period. I figured that this will help to alleviate some of the "pressure" (assuming that there is any).

Community
  • 1
  • 1
user1703993
  • 61
  • 1
  • 5

1 Answers1

2

I wouldn't go that way. It's going to be much better/easier/cleaner, especially when starting, to update the game/screen as often as possible (e.g. put it in a while(true) loop). Then each iteration, figure out the elapsed time and use that accordingly. (e.g. Move an object 1 pixel for every elapsed 20ms) or something

The reason that this is a better starting point, is you'll be hard-pressed to guarantee exactly 30fps and the game will behave weirdly (e.g. if a slow computer can only pull 15fps, you don't want objects going twice the speed) and not to mention drift/individual slow frames etc.

Heptic
  • 3,076
  • 4
  • 30
  • 51
  • But I am just altering the main update loop. Since my entire program revolves around that loop, simply declaring that the system should update itself every 20 ms is easy. But I am going one step further. I want to update one particular subset of the system during those 20 ms, then update the screen in the end. – user1703993 Oct 07 '12 at 00:32
  • You're probably over-thinking it. Especially when starting, just do the simplest thing. e.g. Put physics in the same loop as updating frames – Heptic Oct 07 '12 at 00:36
  • The only down side to this is you might be in a tight-loop burning cpu. – andre Oct 07 '12 at 00:37
  • My program is going to be pretty huge, so I think such forethought is necessary. I have already separated the parts of my code into different groups, all of which are updated at once every step. – user1703993 Oct 07 '12 at 00:43
  • So what's the problem? At each step, call each different 'group'. I've done this sort of stuff to know, the only way you're going to figure out what works is through experience. Totally screwing up, and having to refactor the crap out of it isn't a bad thing, it's an essential part of getting experience. – Heptic Oct 07 '12 at 04:11