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

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.

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?

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