• Create Account

Need scary sound effects or creepy audio loops for your next horror-themed game? Check out Highscore Vol.3 - The Horror Edition in our marketplace. 50 sounds and 10 loops for only \$9.99!

### #ActualGavin Williams

Posted 15 December 2012 - 10:29 AM

Don't worry about the first 2 to 3 seconds, maybe it's just your average frame time building up, I don't know, but I think that's unimportant. If your rendering reaches 60 fps and sits on that consistently, then that's all you need to worry about at this stage I would say. Depending on your program, there could be a few things going on at start-up that can result in shuddering or unstable frames. If you are really worried about it, you might have to profile your application using a profiling tool or simply time your method calls and start getting some specific information about how long everything is taking. Personally, timing my function calls is the approach I take when my programs start getting bigger and I run into frame-rate issues. I have a clock class (using inter-op to access the high precision timer) which i can use to mark the start and stop of a function (in the clock class) and then spit out durations to an onscreen display or text file for later inspection.

Just in regard to the above code ... does timeGetTime() retrieve fresh information from the clock or does it just return an already retrieved value. I'm guessing that it fetches a fresh measurement, which it shouldn't do, because even though the time between your two calls to timeGetTime() might be trivial here, as your physics (x+=speed*elapsedTime ... etc) gets more complicated, the difference between the two calls will become substantial and you will start losing time which will result in incorrect physics. You should have something like this ..

long timeNow = QueryClock();
elapsedTime = timeNow-timePrev;
timePrev = timeNow;


See the slight difference ! You can even separate your physics from your timing. You can have an update clock stage in your main loop and then an update physics stage, which simply reads the elapsed time.

Edit : If you start recording your frame-times and the times of your function calls you'll start seeing abnormalities such as functions performing on distinct tiers or spikes in function times. These are to be expected for a number of reasons, often to do with the operating system and your hardware. But they are not a problem. The first frame or two may often result in a time-spike. Could be a cache miss, or maybe even .NET or it's gc (but I don't know much about the gc and .NET mechanics). But generally I would say that these things can be ignored, especially if your program settles into a regular 60fps after just a few seconds.

A question to ask about your program is ... Does the character move correctly given the particular frame-times. You can get those numbers (distance, time, speed) and work that out. That way at least you can make sure your timing and physics is correct.

### #1Gavin Williams

Posted 15 December 2012 - 10:00 AM

Don't worry about the first 2 to 3 seconds, maybe it's just your average frame time building up, I don't know, but I think that's unimportant. If your rendering reaches 60 fps and sits on that consistently, then that's all you need to worry about at this stage I would say. Depending on your program, there could be a few things going on at start-up that can result in shuddering or unstable frames. If you are really worried about it, you might have to profile your application using a profiling tool or simply time your method calls and start getting some specific information about how long everything is taking. Personally, timing my function calls is the approach I take when my programs start getting bigger and I run into frame-rate issues. I have a clock class (using inter-op to access the high precision timer) which i can use to mark the start and stop of a function (in the clock class) and then spit out durations to an onscreen display or text file for later inspection.

Just in regard to the above code ... does timeGetTime() retrieve fresh information from the clock or does it just return an already retrieved value. I'm guessing that it fetches a fresh measurement, which it shouldn't do, because even though the time between your two calls to timeGetTime() might be trivial here, as your physics (x+=speed*elapsedTime ... etc) gets more complicated, the difference between the two calls will become substantial and you will start losing time which will result in incorrect physics. You should have something like this ..

long timeNow = QueryClock();
elapsedTime = timeNow-timePrev;
timePrev = timeNow;


See the slight difference ! You can even separate your physics from your timing. You can have an update clock stage in your main loop and then an update physics stage, which simply reads the elapsed time.

PARTNERS