Hi (and sorry for bad English in advance), Let''s assume that I have a 3D game. What''s the correct way to update the world and render it''s current state and to be frame rate independent ? ( For example, I had a simple engine several years ago under DOS. /I used a 486DX2 that time :-)/ I tried it on (even) slower machines, and/or in higher resolutions, and although I measured the time between frames and the player''s speed was exactly the same, it wasn''t enough; sometimes the collision detection didn''t worked: Player in frame N: | | X | | WALL | | Player in frame N + 1: | | | | WALL X | | Because the frame rate was so low (the time between frames was long = distance was big) that the player simply jumped over the wall :-) So how should I do it correcly ? The game runs at a specified rate, and the renderer makes ''snapshots'' ? If yes, how should I implement it ? Threads ? Or just measure the time between frames, and use that information to update the world ? Thanks, ferceg

OK, the ASCII graphix are wrong, but you get the idea (I hope :-)

ferceg

Hope I understood your problem

Generally every movement or anything else what doesn''t happen in a short time (e.g. set player to a point) is framerate-dependant (e.g. move the player) and as far as I know the measurement of the frame time is the usual way to solve every problem like yours.

Imagine a car moving with 8 meter/second.
So, you can''t say that your car moves 8 meters right/left every _frame_; it moves 8 meter per _second_.
If you got 10 fps, your car will move 0,8 m/s.


I think this technique will always work.

I don''t know exactly, but as far as I heard, keep away from threads! (I think it''s the problem of syncronisation)


Hope this helps


Have a look at our game "Crashday" at www.moonbyte.de

Oh, me once again, got a new idea

I currently remember your collision detection problem.
You should check the _line_ from your player point A (last frame) to your player point B (current frame) against collisions with the wall. No matter how bad your fps are, you shouldnt miss the collision this way.



Have a look at our game "Crashday" at www.moonbyte.de

Thank you for your answer !
Yes, the collision problem... :-)
And what about other events ? The movement of objects (enemies, whatever).
For example an enemy catches sight of my player.
I want it to wait 1 second, then make a sound and attack my
player. How to handle this ? Let''s assume that 2 seconds elapsed
since the last frame. How to keep track of what
should have happened ?
Maybe I''m not too clever :-) but I can''t imagine how to do this kind of things by just measuring the frametime.

Thank you for your answer again !!!

ferceg
(how can i include those :-) pics ???)

Despite what MothaBrain said I would go with two separate threads. It is possible to sychronize the two threads, but you don''t even need to. Just make the game AI, collision detection, the user input, networking, and stuff like that the main thread, and then use another thread for the graphics part. Then make sure your main thread works at whatever speed it needs to (30Hz, 60Hz, 100, 200?? whatever works for you) and then don''t even bother to sychronize the graphics thread, just have it update as fast as it can, that way the gameplay is never interupted even when the frame rate drops. This has another subtle advantage. Imagine what happens if you only calculate the game engine every frame, and the frame rate drops to say 1 frame a second. Then you''re only recieving user input 1 frame a second, so even if you''re game engine takes into account frame rate and compensates as MothaBrain suggested, you still couldn''t control the action.

Sorry MothaBrain, not trying to dis you anything ; )

You still have the problem of collision detection, but all the rest of your problems will be solved. Just make sure when you do collision detection remember to take into account that the objects are moving between frames (ie. use lines not points), just as MotherBrain said (see ; )

Hope that helps.

Thanks to both of you for your answers. I think I will try the threads. I''m just wondering how it''s done in commercial games.

ferceg

Dont use threads! I think...

Ok, I''ve just checked the Q-Source quickly for threads
(just searched for "thread") but I didnt find anything about threads in Quake.
I suppose ID Software didn''t use them (oh, I''m stupid, it''s DOS )

Here''s my way to solve your enemie problem:

// class variablesBOOL HasSeen = 0; // True, if monster has seen the playerBOOL Attack = 0; // True, if monster is attackingTIME LeftRestTime = 1; // Time, until monster will attack (1sec)// Monster''s update function called each framevoid Monster::Update( TIME delta ){ // Is Player visible? if( HasSeen == 0 && CanSeePlayer() == 1 ) { HasSeen = 1; } // Wait 1 Second if( HasSeen == 1 ) { LeftRestTime -= delta; // This time passed if( LeftRestTime <= 0 ) // It''s time to attack { Attack = 1; PlaySound( MONSTER_ATTACK ); } } // Keep on attacking if state is set if( Attack == 1 ) { DoPlayerAttack(); }}

Hope this was comprehensible. So you see, even if delta is 2 seconds the test will tell you to attack, since the LeftRestTime has passed.

If you like, have a look at the source code links on our site
Bye and good luck!

(The picture is done by HTML)


Have a look at our game "Crashday" at www.moonbyte.de

Yes, it seems OK.
To tell you the truth, I''m in the early experimental phase.
So first I need a simple, working engine to test these problems.
Nevertheless I''m thankful for the help.
(Maybe I will share my experiences later...)

ferceg