glutTimerFunc vs delta_time

Started by
5 comments, last by Zakwayda 13 years, 2 months ago
hi
i was jus wondering which is better for processing, accuracy, implementation, re usability and such and whatever else ther is
ive tried both and it seems like they can both do the same thing but i only see delta time being used in articles and source code
Advertisement
You can't rely on accurate timing from glutTimerFunc -- it will wait at least the specified amount of time before triggering your callback, but doesn't guarantee how soon after the specified amount of time it will happen.

From the documentation for that function:
[font="Arial, Helvetica, sans-serif"]glutTimerFunc registers the timer callback func to be triggered in at least msecs milliseconds. The value parameter to the timer callback will be the value of the value parameter toglutTimerFunc. Multiple timer callbacks at same or differing times may be registered simultaneously.[/font]
[font="Arial, Helvetica, sans-serif"]The number of milliseconds is a lower bound on the time before the callback is generated. GLUT attempts to deliver the timer callback as soon as possible after the expiration of the callback's time interval.[font="arial, verdana, tahoma, sans-serif"][/quote][/font][/font]

[font="Arial, Helvetica, sans-serif"][font="arial, verdana, tahoma, sans-serif"]So for example, if you call glutTimerFunc with a value of 3 milliseconds for msecs, your callback will not be triggered until at least 3 seconds have passed, but it would be perfectly within the specifications of this function for it also not to trigger until 10 seconds or more have passed. If you need accurate timing this can obviously be a problem you would have to deal with.[/font][/font]
[size=2]

[font="Arial, Helvetica, sans-serif"][font="arial, verdana, tahoma, sans-serif"][/font][/font][size=2]This of course doesn't mean you shouldn't use glutTimerFunc, but it is a limitation you need to be aware of, and it does mean glutTimerFunc is not appropriate in all situations.

[font="Arial, Helvetica, sans-serif"][font="arial, verdana, tahoma, sans-serif"] [/font][/font]

Unless you're talking about a specific function here, delta time is more of a general concept where you track the amount of time since the last update and adjust your calculations accordingly. It can allow you to make sure that movement is still correct if physics updates are irregular for example.

A common solution to make sure your physics calculation behave correctly is to Fix Your Timestep so that your code is called on regular intervals rather than uneven amounts of time.




Hope that helps! smile.gif

- Jason Astle-Adams

so then is it ok for me to put all the functions that use timed events into glutDisplayFunction so they are constantly running
and then just use deltaTime to control speed?
i see thats how they did it in quake3
jus seems weird to me to have all these functions all going all at once
but i guess thats just how runtime environments work
i think this is related
what is ^ thing do?
what is & do?
im not sure how these are in this context

if ( ( ( old + 64 ) ^ ( pm->ps->bobCycle + 64 ) ) & 128 )
i think this is related
what is ^ thing do?
what is & do?
im not sure how these are in this context

if ( ( ( old + 64 ) ^ ( pm->ps->bobCycle + 64 ) ) & 128 ) [/quote]
That's some sort of old-school, semi-obfuscated code that determines when a numerical sequence has crossed a 'boundary'.

'^' in this context is the 'bitwise exclusive or' operator. It compares each bit of the two operands (that is, the two input values), and sets the output bit to 1 when the states of the input bits are opposite, and 0 when they're the same, e.g.:

[0110] ^ [1100] = [1010]

'&' is bitwise and, which sets the output bit to 1 if both of the corresponding input bits are 1:

[0110] & [1100] = [0100]

If you leave out the offset, the above bit of code looks like this:

if ((value1 ^ value2) & 128)

128 corresponds to the 8th bit in an integer. If the value is restricted to the range [0, 255], then any value >= 128 will have that bit set.

The expression '(value1) ^ (value2)) & 128' basically checks whether one of the input values has that bit set and the other doesn't. Or, put another way, whether one of the values is < 128 and the other is >= 128. (The offset makes it a little more complicated, but the idea is the same.)

The end result is that the code detects when the walk cycle has crossed a 'footstep boundary', which means it's time to play a footstep sound.

(Disclaimer: I may not have gotten all the details right above, and I may have missed or glossed over some technical subtleties, but the basic idea should be correct.)
wow that is crazy
i jus managed to do it with simply timer > value i like
and my footsteps come out perfect
so i just moved on
is there a reason they do weird stuff like this
is this for performance or something
why cant i understand everything at first sight damit :o

is there a reason they do weird stuff like this
is this for performance or something

Some of the stuff you'll see in the Q3 code base is for performance reasons (look-up tables and so on), but things have changed a lot since that code was written and a lot of that stuff isn't necessary (or even advantageous) anymore, at least on desktop platforms.

Some of it probably also has to do with determinism for networking purposes, although I'm guessing a bit on that count. And lastly, some of it is just programming style :)

But yeah, unless you have a good reason to do otherwise, it's generally best just to write your code so that it's clear, easy to read, and expressive of your intent (IMO).

This topic is closed to new replies.

Advertisement