FPS or Time based??

[LostInTheWoods]

I am currently building a small 3D engine. And i was curious about what to base my engines timing on. The 2 ways i have come up with are these.

First way i thought about was to build 2 seperate pieces of my engine. The first would be JUST the visual things, running as fast as they can, to get the most FPS out of it. And everything else (sounds, collisions, state updates, etc) would be done in a seperate piece, that ONLY fired once every time interval. Problem with this is, I think that requires a fair knowledge of different OSs, and a fair knowledge about threading. I have neither. So doing that would require platform dependent code, and alot more work.

The other way, would to simply base EVERYTHING off of frame rate. Basicaly, i would draw my scene, do sounds, collision detection, input, etc; once per frame, then using glut timmer func, only call a glut post redisplay once every 1/60th of a second. Now I understand that this has 2 problems, first if the fps slow, then the animation will to, and second if the fps draw too fast, then the CPU is just waiting idle for a few milliseconds waiting for its next draw. But i think i could make a much more acurate collision detection, and physics engine doing it this way.

Any suggestions??

[t0y]

Your first suggestion can lead to some loss of precision in sounds, collisions etc.

The second one was used in all Grand Prix games(up to GP3 at least). Maybe it was to get better physics as you suggest, but it seems that it visually the game was a lot slower that it should be (at least in my computer).

From my point of view the most general way is something like (pseudo-pseudo-code)
[CODE]
do{
time=gettime();
animate(time);
draw(time);
} while(!quit)

You take the current time as a basis to generate a new frame. The animate part can take care of input and physics. Of course input information must be "locked" before using it to perform calculations.

[LostInTheWoods]

Thanks for the info. One more quick question. You said it looked too slow to you. Is 60-65 frames per second fast enough? I always thought that that was the *key* frame rate to shoot for.

I think that a fixed frame rate like that would work quite well, expecialy for the physics like you said. Also I think that the CPUs of today will have NO problem doing a frame in less than 1/60 of a second, so slow downs due to processor lag, should be minimal. But do you personaly think that 60-65 frames per second is fast enough? Or should I attempt to base my animations on a higher FPS? Remembering, that if i go TOO high, the animations will slow with CPU lag...

[Korval]

The correct way (or, at least, the way that works very well) to do this is to run your gameloop at the monitor's refresh rate (assuming it doesn't slow down), but each frame get an accurate measure of the time. Make all of your physics, animation, etc calculations based on how much time has elapsed since your last cycle. That way, if your game's framerate drops, the speed of the game will be unaffected (just the responsiveness).

[zed]

neither method, the first is closer
basically u want to run all your physics etc at a fixed time eg 30Hz, rendering is done as fast as possible (dont use another thread or timer 'shudders' ).
method2 is also ok but not as good as the above method

[LostInTheWoods]

Ok, I think i am going to stick with my current method. ONLY because of my collision physics set up right now.

Currently I actualy physicaly move each object that is moving, instead of using the gltranslate, and glrotate, which only moves the image of the item. I do this because, i want the actual verts of the object to test against the walls and such.

Basicaly my setup now is this.
(psydo code)

void render(void)
{
Move Players bounding sphere;

Check player for collisions, move player accordingly to collisions;

Move players eyes, (gl translate, gl rotate);

Move any moving objects;

Check objects for collisions;

Render visable objects;

Waite untill 1/60 of a second has passes since last frame;

Swap buffers;
}

[t0y]

LostInTheWoods:
The game was slow. It allows to choose a fixed frame rate up to near 30 (IIRC) but it was probably slow because of a lack of graphics optimization. At the max value it was very playable (in terms of speed). A good framerate depends on the game.

Zed: I can agree that this is a very good optimization for input/sound, but isn't it a little limited for collision and animation? Complex physics can also benefict from this, but simple collision/acceleration/velocity should (i think ) be animated per-frame for better precision.

[LostInTheWoods]

That was exactly my thought on this. I mean, isnt it ALOT easier, to do things in sequence, simple is better right? So if the animations are based on frames, and the collisions are based on the animations, which are based on frames, and the sound for a collision, is based on the collision, and so on, dosnt it make logical sence to simply set a constant frame rate, and use that as your engine time keeper?

EDIT:

I mean, I have NO idea how an engine like Q3 does collision detecion, being that the frame rate can be up near 150 fps. Seems to me, you could make alot more cool stuff happen with the physics, and such, if you knew the EXACT location of verts in a given frame. Then again, I was NEVER impressed with the Q3 engines implementation of anything exept the visuals.

Take Q3, Alice, Castle Wolfenstien, ALL based on the Q3 engine. And NON of them had basicaly any items you could kick around, any dynamic objects, simply a set of walls, and a set of enimies, (pretty boring, if you ask me, although it was very pretty)

[This message has been edited by LostInTheWoods (edited 09-17-2002).]

[t0y]

Lost:
I've never realy done nothing as complex as that so these are just suggestions .

You should find a way to change your collision detection code, so that you can use gl* calls to move objects around. You're losing on the TnL capabilities. Remember you can always put whatever objects in whatever object's space using matrices (couldn't find better words ).

On the 60hz part. It is convinient in equations and formulas to have a fixed per-frame time (it's the only advantage I can think of). But if a computer can't keep up, the game time streches (1/60 of a second takes longer) and "low spikes" in performance will affect animations. Consider taking a time-based based approach to rendering.

[This message has been edited by t0y (edited 09-17-2002).]

[t0y]

Originally posted by LostInTheWoods:
I mean, I have NO idea how an engine like Q3 does collision detecion, being that the frame rate can be up near 150 fps. Seems to me, you could make alot more cool stuff happen with the physics, and such, if you knew the EXACT location of verts in a given frame.

Now we're posting at the same time .

If you use a "time tag" as a base for animation instead of a "frame tag" you can find that easily. It works basically the same.