# Game logic/renderer timing with PhysX

## Recommended Posts

I trying to create a simple game engine. I currently use a single thread for everything and a main loop who simply calculate the delta time between each frame using QueryPerformanceCounter and use it and the inputs to update the game logic, then do a rendering pass. This way, the game have the same results even if it's running at 10fps or 200fps. I'm currently trying to add PhysX support, from what it seems, I should use a fixed timestep of like 60fps to run the simulation. So instead of simply passing my delta time I calculate between each frame, I need to block my rendering and game logic to 60fps so the simulation get in synch. That don't seems right because usually every application I see can get under or above a fixed framerate without problem. I've searched around a bit and didn't find a clear answer. What is usually used? 1. Variable timestep using my first idea (which bring inconsistencies) 2. Passing a fixed constant in simulate() even if the function is called at a different speed which would probably result in different speedy strangeness. 3. Use another thread which run at fixed time for physx and the main one who run at full speed as usual and find a way to pass all objects and collisions info between threads (I would need a guide for this). 4. I've ended up on the word "accumulator" 2 times, what is it and can it help me? A small pseudo code would be nice. Thx

##### Share on other sites
I think you might have forgotten one solution.
Using a single thread running updating a constant 60 times a second (possible updating several times for each rendering-frame, since updating will take place before rendering) and rendering as fast as possible while interpolation between the two latest update frames/samples to get average/plausible physics data for the rendering.
This way, updating will always take place (assuming 60 fps) at "virtual" time (the time you pass PhysX) 0 ms, 16.67 ms, 33.33 ms, etc. with the rendering taking place after the necessary updating has been performed.
You should be aware of timestamping input data and other time-sensitive data, so that input and the rest of the time-sensitive will be triggered/"discovered" in the right update (because multiple updates might happen before rendering).

This article also explains it, although it might not be exactly the same method (long time since I read it): Fix Your Timestep.

##### Share on other sites
Thx for the help. I actually ended up on this page before writing the post, but tough it was another crappy one and I got confused with the "integrate" function, which actually seems to be the "update". Reading it trough actually helped and it takes in account every situations. This adds up something new, I need to save old physics states for each object between updates to interpolate. This include position and rotation, anything else?

##### Share on other sites
There's no nead to make it complicated. I've integrated physx a year ago now and I can run it with a variable timstep:

NxReal CPhysX::UpdateTime(){	NxReal deltaTime;	static __int64 gTime, gLastTime;	__int64 freq;	QueryPerformanceCounter( ( LARGE_INTEGER * )&gTime );   // Get current count	QueryPerformanceFrequency( ( LARGE_INTEGER * )&freq );  // Get processor freq	deltaTime = ( NxReal )( gTime - gLastTime ) / ( NxReal )freq;	gLastTime = gTime;	return deltaTime;}m_pScene->setTiming( 1.0f / 60, 8, NX_TIMESTEP_VARIABLE);m_pScene->simulate( UpdateTime() );m_pScene->flushStream();m_pScene->fetchResults( NX_RIGID_BODY_FINISHED, true );

The devs told me this will work and it does work like a charm. I've never had problems with it. Physx already runs at a seperate thread and the scene does all the wrapping for you, there's no need to reinvent it twice, it will just cause more trouble.

##### Share on other sites
It cause more trouble, but it stay fixed. From the documentation and some forum posts, using your method (what I was thinking of using) will bring different results on some computers..

##### Share on other sites
Firstly, there should be no need to run faster than 60fps, since that is about the highest framerate you can realistically display. Any higher and you're just wasting time.

If you are running below 60fps, you can run multiple 1/60 sec physics updates each frame and interpolate the remainder from the last update.

## Create an account

Register a new account

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627665
• Total Posts
2978531

• 10
• 10
• 12
• 22
• 13