Open GL - glTranslate + Game Timing

Some questions related to opengl, may be related. Right now, I have things on my griddy thing that are being represented by a sets of 3-D vertices. Each object is drawn by doing a thing of glLoadIdentity, glBegin, glVertex3fv's, and then glEnd. When I want to move the thingy around, I add change the quantities of everything in my set of 3-D vertices, instead of using glTranslatef. Is this bad?

Also, the way I percieve time in my game is all funky. I time things and stuff and then every time I call my update routine, it passes it the elapse in time. And then the objects can displace themselves around with velocity * delta time. So, their position is never like in some definite spot aligned to a grid, and they make just little sporadic jumps around the place that are really really small and are percieved as smooth movement. So:

1) Is that a good system? What if the system hangs, and the next update is a really big interval, and things make big jumps?

2) This makes collision detection kind of wierd, and (non-nerdy) people I've talked to say that this is just a bad way of doing things because I don't really know where things are. Like, the example right now, is that I'm doing pong, and really I should be able to check if a face of the pong ball hits a face of the paddle.

But, the lines which make their borders will never really be exactly the same, because of the timing, so I can't just check for that. So, Right now, I'm checking if the rectangles intersect, and if they do, it reverses directions. 2 problems with that

(-) If it hits the top of the paddle, it still chenges directions (not logical) and

(-) Sometimes, the ball can get 'stuck' in the paddle, and will change it's direction thousands of times before exiting the paddle, because it doesn't just reverse its direction and leave. Thus, it can hit the paddle, and then still go past it getting a goal.

So, that's wierd, and requires odd workarounds. Is there a better system, or shoul I just use wierd workarounds?

glTranslate() is probably faster, and it'll be easier to manage in the long-term.

1) Don't make your time intervals frame-based.

2) Just keep track of the position? Every interval, get the current X and Y coordinates, and update the ball class or struct.

Okay I can wrap my brain around dealing with glTranslatef.

1) But what do you mean frame-based? Um, I mean, I just have it so that it repaints the screen every 40 times the game loop is run but recalculates position, velocity vectors every time the game loop is run.

2) Well, I do know what position they're at in x and y coordinates, it's just that where they are corresponds to wierd coordinates like -0.6785453, 0.532528, -0.1 or whatever. It's position would be recalculated after 0.0034567 seconds have passed and it would move to some wierd position at blah blah blah blah. And, because of how they jump around, they may never actually have the exact same x coordinates. I could maybe use a really big sort of epsilon for the floating point comparisons, but that seems a little bit wierd.

By frame-based, I mean you're calculating your time step based on machine cycles, which would cause it to get jerky on a slower machine, or if the system slows for any reason. If you make sure that you calculate on real time intervals (by the second for example), everything will move at the same rate, independant of the system cycles. You may want to look into some of the Windows timer functions, like QueryPerformanceCounter().

I don't see what difference having floating-point positions will make. Although if you really want 'clean' numbers, you could implement some sort of 'grid-snap' mechinism.

I am using queryperformacecounter/queryperformancefrequency, the time elapsed is equal to (previousTime - currentTime) / frequency which is equal to some small fraction of a second. Then I pass that elapsed time and recalculate the position of my things based on what their velocity is and how much time has elapsed. I just don't really know how to find when this object A (which for simplicity could be a rectangle in 2-D) is going to collide with object B (same characteristics as A).

I have tried been calculating when they intersect and then making them bounce backwards by just changing the x-direction of their velocities. But the problem with them getting stuck occured, as described in my original post. I remedied this by saying they can't intersect within a period of 0.1 seconds, and it seemed to work alright, but it seemed an odd workaround (and also, sometimes the collision condition never evaluated at all, something I haven't debugged yet). It seems like a wierd way to do it, and the behavior is the same for whether it hits the top or the side of the rectangle.

I could divide the rectangle into regions I suppose. And to fix the getting stuck problem I could just move the ball out of the paddle region and then change the velocity to whatever. I guess that's a reasonable solution, and I guess I may do that. Opinions are welcome.

Quote:

---

Originally Posted by Tonto

1) Is that a good system? What if the system hangs, and the next update is a really big interval, and things make big jumps?

---

Then you need to find out why your system hung and make sure it doesn't happen again.
Such games are real-time systems. In the end, it is more important to keep the elapsed time constant than it is to update the screen.

Quote:

---

Originally Posted by Tonto

I have tried been calculating when they intersect and then making them bounce backwards by just changing the x-direction of their velocities. But the problem with them getting stuck occured, as described in my original post. I remedied this by saying they can't intersect within a period of 0.1 seconds, and it seemed to work alright, but it seemed an odd workaround (and also, sometimes the collision condition never evaluated at all, something I haven't debugged yet). It seems like a wierd way to do it, and the behavior is the same for whether it hits the top or the side of the rectangle.

---

Don't detect when they collide, detect before they collide.
Hint: displacement

While the object is colliding keep subtracting its velocity untill it isn't colliding. Once it's done colliding if it reflects its bounciness should be above 0, it it stops its bounciness should be 0. (If the wall is curved or not horizontal or verticle then you'll have to do some more math on your own.) Don't draw it untill after all the collision stuff is done.

I think this is right. I have only programed a 2D sidescroller using this technique and not anything fancy or 3D.

Code:

---

if (object.collision())
{
    while(object.collision())
    {
        object.pos.x -= object.velocity.x;
        object.pos.y -= object.velocity.y;
    }
   
    object.velocity.x = -object.velocity.x*object.bounciness;
    object.velocity.y = -object.velocity.y*object.bounciness;
}

DrawStuffLater();

---

>> Then you need to find out why your system hung and make sure it doesn't happen again.
>> Such games are real-time systems. In the end, it is more important to keep the elapsed
>> time constant than it is to update the screen.

I realized I could cap the change in time to some small value. Is this reasonable? This seems like it could cause problems if I were to try to keep time over a network.

>> Don't detect when they collide, detect before they collide.
>> Hint: displacement

Aaa. That seems like a pretty good solution. I will try to implement that and glTranslatef. I might use the solution posted above if my collisions were more elastic. Both of these seem like they could have problems if the object was moving incredibly fast. This isn't a condition which should really arise in my program, I just like procrastinating by daydreaming about all the problems that could come up and never fixing any of them.

A network is a completely different beast. And yes, capping time would be a major issue in a network: you'd immediately be out of sync.