   Frame Rate Cap OR Frame Independent Movement?
  What's better? I suppose it doesn't make a difference much when you're just starting out, but in general, is it better to cap the frame rate or have things move in relation to time rather than framerate?Or cap the frame rate AND have them move in relation to time?[Edited by - Sean_Seanston on September 13, 2007 9:35:54 AM]
  Hey, well i'm no expert but here's how i see it.Quote:Or cap the frame rate AND have them move in relation to time?No, because if your frame rate is capped at say 60Hz i.e. 60 times per second, and your updating everything else with relation to time, for example, every 8ms (about 120 times per second) theres no point because the extra update your doing won't be displayed to the user, and so it just eats processing power.Quote:What's better? I suppose it doesn't make a difference much when you're just starting out, but in general, is it better to cap the frame rate or have things move in relation to time rather than framerate?abit of both :) Moving in relation to time is the best (IMO - feel free to argue), so when your program is finished calculating everything it needs to do e.g. collision detection etc. then render the frame with the updated values. But if your program is simple, then your time-based caluclations could be way over your monitor refresh rate e.g. 60Hz, 75Hz, etc so there's no point and your programs too fast cos it might be trying to display at 300Hz, which your monitor won't do and so it's once again a waste of processor power.Usually in my programs i cap the frame rate at 60Hz for the release version using an #ifdef, and in the debug version let it run 'free' and render the frames as fast as they can go (which most get lost because its > 60Hz), but it's still useful for development to see how fast everything is running.Hope this helps, others may have a different take on it.   ;  The best way (as I see it), is to separate the rendering from the updating of the world. The updating of the world would be done with fixed-time steps, i.e. you sum the time between frames and as soon as it reaches something like 30 ms, you do a fixed update. During rendering, you'd interpolate between the old position and the new position.A more simple method, would be indeed to simply use time-based updates. Update according to the time between frames.Capping frame rates should, IMO, only be a way to sync to the monitor rate, and therefore lower CPU-rates a bit, but should never have any impact on the updating of the world. (In jargon: the world MODEL may never be influenced by the world VIEW).   ;Fix Your Timestep!See also this current discussion.   ;  Cool, thanks for the replies. Think I have a good idea of it now...One more thing though:I'm trying to set up my functions for initializing the screen, updating it etc. and since it's bad to make global variables and I need a lot of SDL_Surface*, I put their declarations in the init() function, but then of course update() can't access it.So, would the best way to handle this be to make a class graphics with init(), update() etc. and all the surfaces, then use an object of that class to handle all the graphical aspects of the game? Or is there a better way to make the surfaces not global but accessible to all the functions that need them?EDIT: I tried the class method and the init() function works, but when I call update(), seen below:bool Graphics_Control::update(){if( SDL_Flip( screen ) == -1 ){return false;    }return true;}I get an exception... "Unhandled exception at 0x681298d2 in Breakout.exe: 0xC0000005: Access violation reading location 0xcccccccf.". If I comment out the call to update() it works fine.[Edited by - Sean_Seanston on September 13, 2007 10:06:48 AM];Quote:So, would the best way to handle this be to make a class graphics with init(), update() etc. and all the surfaces, then use an object of that class to handle all the graphical aspects of the game?Yep, that sounds fine, and make your SDL surfaces private members inside that class. So that all the members in the class can access them, but anything outside the class can't.Quote:If I comment out the call to update() it works fine.Ok so the only thing that's happening in update() is a call to SDL_Flip, passing it 'screen' as a parameter. So it must be something to do with that. I'd look at whatever 'screen' is and make sure it's being initalised properly in your init() function or whereever you define it.;Quote:Original post by Sean_SeanstonI get an exception... "Unhandled exception at 0x681298d2 in Breakout.exe: 0xC0000005: Access violation reading location 0xcccccccf.". If I comment out the call to update() it works fine.Quote:Source:Compiler initialisations0xCC, 0xCCCCCCCC - The /GX Microsoft Visual C++ compiler option initialises all local variables not explicitly initialised by the program. It fills all memory used by these variables with 0xCC, 0xCCCCCCCC.;Quote:Original post by supamikeHey, well i'm no expert but here's how i see it.Quote:Or cap the frame rate AND have them move in relation to time?No, because if your frame rate is capped at say 60Hz i.e. 60 times per second, and your updating everything else with relation to time, for example, every 8ms (about 120 times per second) theres no point because the extra update your doing won't be displayed to the user, and so it just eats processing power.Quote:What's better? I suppose it doesn't make a difference much when you're just starting out, but in general, is it better to cap the frame rate or have things move in relation to time rather than framerate?abit of both :) Moving in relation to time is the best (IMO - feel free to argue), so when your program is finished calculating everything it needs to do e.g. collision detection etc. then render the frame with the updated values. But if your program is simple, then your time-based caluclations could be way over your monitor refresh rate e.g. 60Hz, 75Hz, etc so there's no point and your programs too fast cos it might be trying to display at 300Hz, which your monitor won't do and so it's once again a waste of processor power.Usually in my programs i cap the frame rate at 60Hz for the release version using an #ifdef, and in the debug version let it run 'free' and render the frames as fast as they can go (which most get lost because its > 60Hz), but it's still useful for development to see how fast everything is running.Hope this helps, others may have a different take on it.I do the same. For release versions, I cap my FPS at 60, which is the frequency of an LCD screen. Debug versions I allow to run as fast as they can.