While we're at it, I have a question.
In the physics API I am using (Bullet, FYI) there's no chance to mess this up too much.
The physics will always tick at 30 fps, smaller timesteps will be interpolated.
By this point of view, there's nothing like an updating timestep nor interpolation. From code point of view, nothing is changed.
What kind of approach is that?
There's a very subtle difference between update by interpolation and update by simulation.
If that's not hijacking the thread, I also have another question.
I have scripts pretty much everywhere. I originally planned to give scripting logic 10 ticks per second. However, this caused some issues in many routines which were really supposed to run per-frame. For the time being, I'm ticking the scripts each frame. Any suggestions on separating those to run at a constant update rate?
Ideal Gameloop Implementation
I have never used Bullet, Squirrel, PhysX, Box2D etc. I don’t know what they are doing, but from a conceptual standpoint it doesn’t seem reliable, specifically from the point I mentioned about not getting the real current time more than once per frame.
I am guessing they want to prevent that tragedy by getting the real current time themselves only “once per frame” and dealing with physics that way, in order to guarantee stability, but for competent developers that would actually decrease stability when they are already getting the current time only once per frame. The value passed to the physics simulation should be trusted, unless your goal is to target only beginner developers who might fall into one of the nuances I mentioned. In that case you would say to yourself, “The guy or girl using my physics engine is probably a newbie and doesn’t know all the nuances of timing. I should keep track of time myself to make sure.”
Hence I feel many physics engines are doing this, and as a result provide unstable results (even though the instabilities are extremely minor and probably only conceptual in practice).
But if you want to tick scripts in a similar manner, the concept for fixed time steps has not changed. It fully applies to ticking (updating) script as well. Scripts are only a subset of the whole engine. If the whole engine can wait 33.3 milliseconds until the next logical update, everything else can too. Except graphics.
L. Spiro
I am guessing they want to prevent that tragedy by getting the real current time themselves only “once per frame” and dealing with physics that way, in order to guarantee stability, but for competent developers that would actually decrease stability when they are already getting the current time only once per frame. The value passed to the physics simulation should be trusted, unless your goal is to target only beginner developers who might fall into one of the nuances I mentioned. In that case you would say to yourself, “The guy or girl using my physics engine is probably a newbie and doesn’t know all the nuances of timing. I should keep track of time myself to make sure.”
Hence I feel many physics engines are doing this, and as a result provide unstable results (even though the instabilities are extremely minor and probably only conceptual in practice).
But if you want to tick scripts in a similar manner, the concept for fixed time steps has not changed. It fully applies to ticking (updating) script as well. Scripts are only a subset of the whole engine. If the whole engine can wait 33.3 milliseconds until the next logical update, everything else can too. Except graphics.
L. Spiro
I apologize for the late reply.
Bullet - I don't know other engines - work like this (at the simplest).
It is my understanding Bullet does not probe elapsed times internally - if not for profiling - and uses a constant tick internally. If the elapsed time since last tick is smaller than 1/30, results are produced by interpolation (extrapolation?) rather than simulation.
However, at an higher level of abstraction, this difference is not visible. As far as I understand, the time increment value is completely trusted. It is my understanding invariance is guaranteed.
From this, my original question: what kind of approach would that be?
Bullet - I don't know other engines - work like this (at the simplest).
world->stepSimulation(timeIncrement); // timeIncrement in seconds.
It is my understanding Bullet does not probe elapsed times internally - if not for profiling - and uses a constant tick internally. If the elapsed time since last tick is smaller than 1/30, results are produced by interpolation (extrapolation?) rather than simulation.
However, at an higher level of abstraction, this difference is not visible. As far as I understand, the time increment value is completely trusted. It is my understanding invariance is guaranteed.
From this, my original question: what kind of approach would that be?
But if you want to tick scripts in a similar manner, the concept for fixed time steps has not changed. It fully applies to ticking (updating) script as well. Scripts are only a subset of the whole engine. If the whole engine can wait 33.3 milliseconds until the next logical update, everything else can too. Except graphics.[/quote]Problem is figuring out what affects graphics. Thank you anyway, I suppose I will have my own thread about this at a proper time.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement