Trouble with Time and GLUT looping mechanisms

Jones
Unregistered
 
Post: #1
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. Wink

Here is the code (in my display loop):

Code:
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!
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #2
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

Code:
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.

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Jones
Unregistered
 
Post: #3
unknown Wrote: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

Code:
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
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #4
use glutIdleFunc for animation then
http://www.opengl.org/documentation/spec...0000000000

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Jones
Unregistered
 
Post: #5
unknown Wrote:use glutIdleFunc for animation then
http://www.opengl.org/documentation/spec...0000000000

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.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #6
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.
Quote this message in a reply
Jones
Unregistered
 
Post: #7
ThemsAllTook Wrote: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.
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #8
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?
Quote this message in a reply
Jones
Unregistered
 
Post: #9
ThemsAllTook Wrote: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.
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #10
random example of an animate function:

Code:
animate(dt) { // dt is time in seconds
   game_timer += dt;
  
   spaceship_position += spaceship_velocity * dt;
   // spaceship_velocity is a speed in pixels per second
}

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Jones
Unregistered
 
Post: #11
unknown Wrote:random example of an animate function:

Code:
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?
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #12
infact heres a better example:

Code:
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
}

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Moderator
Posts: 1,560
Joined: 2003.10
Post: #13
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/...tion.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. Smile

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?
Quote this message in a reply
Jones
Unregistered
 
Post: #14
ThemsAllTook Wrote: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/...tion.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. Smile

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.
Quote this message in a reply
Sage
Posts: 1,403
Joined: 2005.07
Post: #15
ThemsAllTook Wrote: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..

Sir, e^iπ + 1 = 0, hence God exists; reply!
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  Trouble writing a GLUT-like API TomorrowPlusX 2 2,527 Jun 2, 2009 03:47 AM
Last Post: TomorrowPlusX
  Looping Sound in Cocoa RigelPrime 11 5,168 Jan 7, 2003 04:02 AM
Last Post: OneSadCookie