Hör doch auf rumzulabern.
Vielleicht können wir uns verständigen dass z.B. Bullet von "cleveren Leuten" geschrieben wurde, die es besser können, als jeder von uns beiden und siehe da:
http://bulletphysics.org/mediawiki-1.5.8…pping_The_World
Here's the prototype:
btDynamicsWorld::stepSimulation(
btScalar timeStep,
int maxSubSteps=1,
btScalar fixedTimeStep=btScalar(1.)/btScalar(60.));
The first parameter is the easy one. It's simply the amount of time to step the simulation by. Typically you're going to be passing it the time since you last called it
Bullet maintains an internal clock, in order to keep the actual length of ticks constant. This is pivotally important for framerate independence. The third parameter is the size of that internal step.
The second parameter is the maximum number of steps that Bullet is allowed to take each time you call it. If you pass a very large timeStep as the first parameter [say, five times the size of the fixed internal time step], then you must increase the number of maxSubSteps to compensate for this, otherwise your simulation is “losing” time.
...
It's important that timeStep is always less than maxSubSteps*fixedTimeStep, otherwise you are losing time. Mathematically,
timeStep < maxSubSteps * fixedTimeStep
Sei die Framerate nun bei 100% Maschinenauslastung nun gerade so dass die Gleichheit gilt, also 1/framerate = maxSubSteps * fixedTimeStep. Nun passiere irgendwas, was die framerate sinken und den timestep damit wachsen lässt, beispielsweise, ein neuer Prozess wird gestartet. Du verlierst nun zunächst die Echtzeiteigenschaft (s.o.). maxSubSteps erhöhen bringt nichts, da das System ja ausgelastet ist (siehe NachoMans Post) es bleibt dir also nur auf die Echtzeit zu pfeifen (das Spiel läuft in Zeitlupe, ist das kein "GodMode"?) Oder die fixedTimeStep hochzudrehen (und dadurch Genauigkeit zu verlieren).
Das ist bei allen mir bekannten Echtzeit/Gaming-PhysikEngines (bullet, ODE, Newton) so.
Du hast immer einen Tradeoff. Hubraum kann man durch nichts anderes ersetzen.