Trouble with Time and GLUT looping mechanisms

[Jones]

I used SacredSoftware's tutorial about Time interval animation, and then integrated the sample code into a sample project with some of my own, to see if it would work.

The code in question draws an MD2 on the screen. (Yes it works now, special thanks to Fenris and Zip!)

However, the code has not helped slow down my test model's amazingly quick dance moves. ;)

Here is the code (in my display loop):


void display(void)
{
glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
glColor3f(1.0, 1.0, 1.0);
glLoadIdentity();

currentTime = glutGet(GLUT_ELAPSED_TIME) / 60;
updateIterations = ((currentTime - lastFrameTime) + cyclesLeftOver);
if (updateIterations > (MAX_CYCLES_PER_FRAME * UPDATE_INTERVAL)) {
updateIterations = (MAX_CYCLES_PER_FRAME * UPDATE_INTERVAL);
}

while (updateIterations > UPDATE_INTERVAL) {
updateIterations -= UPDATE_INTERVAL;

// Update junk.
}

cyclesLeftOver = updateIterations;
lastFrameTime = currentTime;

// Draw!
drawModel();

if (myFrame == 100) {
myFrame = 0;
}
myFrame++;

glutPostRedisplay();
glutSwapBuffers();
}

The original time is aquired by getting the time right after I tell glut to use display() as my display loop.

drawModel does all transformations and then draws.

Why has nothing slowed down?

Thanks!

[unknown]

first of I would recommend you remove all time based things from the draw function so for example calling draw 100 times would not affect the state of the game.
Secondly, create an animate or update function that takes a float parameter which will have the value time since update was last called,
Your gameloop would then contain all the timing functions and look somthing like


dt = time();
while(1) {
dt = time()-dt;
animate(dt);
display();
}


once the structure of your animation code makes sense it will be a lot easier to debug the individual parts of it so you can figure out whats wrong,

also, if were to change animate(dt); to animate(dt*0.5); everything would run at half speed.

[Jones]

first of I would recommend you remove all time based things from the draw function so for example calling draw 100 times would not affect the state of the game.
Secondly, create an animate or update function that takes a float parameter which will have the value time since update was last called,
Your gameloop would then contain all the timing functions and look somthing like


dt = time();
while(1) {
dt = time()-dt;
animate(dt);
display();
}


once the structure of your animation code makes sense it will be a lot easier to debug the individual parts of it so you can figure out whats wrong,

also, if were to change animate(dt); to animate(dt*0.5); everything would run at half speed.

Ah, but <problem>! All looping is handled by GLUT. I chose GLUT over an API that would let me control the loops because I liked the very organization that is destroying me right now.

I'm not sure I understand what you're saying, are you proposing a different system, or the same system but organized differently?

If I made function that automatically moved everything/updated everything, then everything would be dependant upon it.

Thanks for the help!

Jones

[unknown]

use glutIdleFunc for animation then
http://www.opengl.org/documentation/specs/glut/spec3/node63.html#SECTION0008180000000000000000000000000 00000000000000000000000000000000000000000000000000 00000000000000000000000000000000000000000000000000 000000000

[Jones]

use glutIdleFunc for animation then
http://www.opengl.org/documentation/specs/glut/spec3/node63.html#SECTION000818000000000000000

I thought idle only did stuff when the program was actually idle, in a sense that no keyboard detection or mouse reading was taking place...

Guess not.

[ThemsAllTook]

The only problem I see is that you're dividing the result of glutGet(GLUT_ELAPSED_TIME) by 60. GLUT_ELAPSED_TIME is in milleseconds, not ticks, so you'll want to divide by 1000... Or rather, 1000.0f, since you want floating point division.

Other than that, I'd want to see what data types you're using for your variables. If you're using an int where a float is needed, that could potentially cause things to run faster than you expect.

[Jones]

The only problem I see is that you're dividing the result of glutGet(GLUT_ELAPSED_TIME) by 60. GLUT_ELAPSED_TIME is in milleseconds, not ticks, so you'll want to divide by 1000... Or rather, 1000.0f, since you want floating point division.

Other than that, I'd want to see what data types you're using for your variables. If you're using an int where a float is needed, that could potentially cause things to run faster than you expect.

Ah, you measure it in ticks. Woops. I was stuck thinking seconds. :wacko: I'll see if that helps.

In the meantime, Unknown, could you give me an example of what you mean for an "animate" function?

EDIT:

I chucked the time delay into my idle func, and devided the time by 1000.0, but no luck, the model still goes insanely fast.

I'm going to try and switch to SDL. Maybe I'll be able to make easier sense of things, but I'll miss the great reshape system and easy non-event based input detection.

[ThemsAllTook]

Hmm...

Just to be sure, the "// Update junk" comment in the code you pasted above is stuff you snipped out when you pasted it, right? I assume there's real updating going on in the actual code?

[Jones]

Hmm...

Just to be sure, the "// Update junk" comment in the code you pasted above is stuff you snipped out when you pasted it, right? I assume there's real updating going on in the actual code?

No, I actually took it out to get this to work. I've tried adding my frame++ calls in the update block, but to no avail.

I don't suppose it's possible to set up a reshape callback with SDL? I really liked that feature of GLUT, that and the fact it was easier to setup and go with.

[unknown]

random example of an animate function:


animate(dt) { // dt is time in seconds
game_timer += dt;

spaceship_position += spaceship_velocity * dt;
// spaceship_velocity is a speed in pixels per second
}

[Jones]

random example of an animate function:


animate(dt) { // dt is time in seconds
game_timer += dt;

spaceship_position += spaceship_velocity * dt;
// spaceship_velocity is a speed in pixels per second
}


Spaceship velocity is also representative of the spaceship trajectory also, in that example, correct?

[unknown]

infact heres a better example:


animate(dt) { // dt is time in seconds
game_timer += dt;

if(up_key && !down_key) {
spaceship_velocity += forward_thrust * dt;
}
else if(down_key && !up_key) {
spaceship_velocity -= forward_thrust * dt;
}

spaceship_position += spaceship_velocity * dt;
// spaceship_velocity is a speed in pixels per second
}

[ThemsAllTook]

Ed: Your approach has a few problems. It can be made to work, but has been far more trouble than it's worth in my experience. I explain this in my tutorial. See the "Variable interval time-based animation" section:

http://www.sacredsoftware.net/tutorials/Animation/TimeBasedAnimation.xhtml

Also, the character limit exists for a reason. Please elaborate on your post rather than putting filler text in to circumvent it. Edit: Never mind, I see you did already. :)

Jones: The idea is to do all state updates within the update block, and all drawing outside it. Otherwise, the fixed-interval system doesn't work at all. What went wrong when you put the myFrame++ stuff inside it?

[Jones]

Ed: Your approach has a few problems. It can be made to work, but has been far more trouble than it's worth in my experience. I explain this in my tutorial. See the "Variable interval time-based animation" section:

http://www.sacredsoftware.net/tutorials/Animation/TimeBasedAnimation.xhtml

Also, the character limit exists for a reason. Please elaborate on your post rather than putting filler text in to circumvent it. Edit: Never mind, I see you did already. :)

Jones: The idea is to do all state updates within the update block, and all drawing outside it. Otherwise, the fixed-interval system doesn't work at all. What went wrong when you put the myFrame++ stuff inside it?

Nothing, it just kept going fast, if I remember correctly.

[unknown]

Your approach has a few problems
It's actually a better method to use a variable timestep than a fixed timestep in terms of stability and realism, although it doesn't come without a cost. It generally requires slightly more programming to get correct results, like intersecting moving objects instead of static objects. fixed time step is easier because its more predictable so you more likley will be able to get away with short cuts like I mentioned.
I know that a high quality engine like newton works like I suggest, so I am just trying to get into good habits before I move on to program somthing harder..

[Jones]

It's actually a better method to use a variable timestep than a fixed timestep in terms of stability and realism, although it doesn't come without a cost. It generally requires slightly more programming to get correct results, like intersecting moving objects instead of static objects. fixed time step is easier because its more predictable so you more likley will be able to get away with short cuts like I mentioned.
I know that a high quality engine like newton works like I suggest, so I am just trying to get into good habits before I move on to program somthing harder..

Sounds more complicated. You were showing a variable system, weren't you...

Ah, I think I'm beginning to see the difference...

[unknown]

It would require the same effort to code a good variable timestep system and a good fixed timestep system, using a fixed timestep gives you somthing you can take advantage of in your calculations and 'fudge' things to just work.
Whether you choose fixed or variable im sure everyone would agree that you would want to seperate all your graphics code (GPU) from your animation code (CPU).

[ThemsAllTook]

It's actually a better method to use a variable timestep than a fixed timestep in terms of stability and realism, although it doesn't come without a cost. It generally requires slightly more programming to get correct results, like intersecting moving objects instead of static objects. fixed time step is easier because its more predictable so you more likley will be able to get away with short cuts like I mentioned.
I know that a high quality engine like newton works like I suggest, so I am just trying to get into good habits before I move on to program somthing harder..
Ah, OK, I understand your viewpoint a bit better now. You can't actually get more stability from a variable interval system since a fixed interval system gives you identical results no matter what, but theoretically you could get as much stability with greater realism and speed. It just takes a lot more effort to get there, and debugging edge cases in a variable interval system is pretty difficult.

But yes, essentially, the only advantage of fixed interval is that it lets you get away with shortcuts. If you have the skillz to implement a solid variable interval system, that's definitely the way to go. I just don't like dealing with all the not-immediately-visible problems a variable interval system brings.

Jones: Can I get you on AIM or IRC or something? I'd be happy to help debug this with you, but it's pretty difficult over the forum. Alternatively, if you could send me the project over e-mail, that would work too.

[OneSadCookie]

I have to say, my impression is that variable-interval is *way* more trouble than it's worth. Yes, if you want super-realism, with small objects moving fast or something like that, then you'll need to do it. For most games, though, you won't need anything nearly as complex.

Even then, there's a difference between "variable rate" in terms of "run one physics step each frame, passing the elapsed time" (which doesn't work, see alex's tutorial) and "run as many physics steps as you need to to get things accurate" (which is what something like newton will do)

[Jones]

Jones: Can I get you on AIM or IRC or something? I'd be happy to help debug this with you, but it's pretty difficult over the forum. Alternatively, if you could send me the project over e-mail, that would work too.

Thanks for the offer, I'd love (and need) the extra help.

I'll just add you to my contacts...

*done* :)

In case you're wondering who the crazy person rambling to you about programming problems is, it's me Gareth. :p

And in the meantime, I'll try implementing your system in a SDL context. Hopefully the less strict looping system will make it easier, and maybe even work, but knowing my code it's not good to be hopeful. ;)

[unknown]

(moving to SDL is a very good idea, although SDL is absolutly awful its way way better than glut)

[ermitgilsukaru]

Hey Jones.

I've got a really simple GLUT application class that I made with a update(float deltaTima) function.

If you're intererested I can e-mail it to you. (I can't say that it's brillian code, but I illustrates the concept pretty well)

[ermitgilsukaru]

By the way unknown, why do you think SDL is awful?