If you run one of the demos (e.g. LoadIrrFile, PerPixelLighting, SpecialFX), then switch to another window, so the action in the main window stops, then back to the main window, you can see "jumps" in the particles and the animated objects.
This probably happens because internally a time difference is taken between REAL times.
Question: is there something like an ENGINE TIME (which runs independently of the outer real time)?
There is a setSpeed(...) function ( with which you can simulate slow motion ), which in my opinion can only work, if you already have a "virtual" engine time.
internal timing
Re: internal timing
Yes, there is "engine time", and you can stop, start, set it, and set the rate. Read the ITimer docs.
Re: internal timing
fine - but still this would mean that the particles and animators (and maybe also animations) internally DON'T use the "engine time".
Re: internal timing
I believe you!
But i get "jumpy" behaviour when using the timer functions.
And i cannot stop the timer if the timer speed is smaller than 1.0.
And if i start the timer again all movements are reset.
But i get "jumpy" behaviour when using the timer functions.
And i cannot stop the timer if the timer speed is smaller than 1.0.
And if i start the timer again all movements are reset.
Re: internal timing
I just tried:
and it worked. The animation (a rotation animator) stops and starts as expected.
Code: Select all
while(device->run())
if (device->isWindowActive())
{
if (stopped)
{
stopped = 0;
device->getTimer()->start();
}
<snip>
}
else if (!stopped)
{
stopped = 1;
device->getTimer()->stop();
}Re: internal timing
Try the FlyCircleAnimator or the FlyStraightAnimator.
Take example "Movement", extend it by adding
while( device->run() )
{
-> if( ! device->isWindowActive() )
-> continue;
then run it, fetch the dos windows to front and back again and you see what i mean.
Same goes for examples with a particle system.
Take example "Movement", extend it by adding
while( device->run() )
{
-> if( ! device->isWindowActive() )
-> continue;
then run it, fetch the dos windows to front and back again and you see what i mean.
Same goes for examples with a particle system.
Re: internal timing
Uh, in that case the timer continues to run.
Re: internal timing
But where's the call to stop()?
Re: internal timing
Ahhh - i see!
with
bool bTimerRunning = true;
while( device->run() )
{
if( ! device->isWindowActive() ) {
if( bTimerRunning ) { device->getTimer()->stop(); bTimerRunning = false; }
continue;
} else {
if( ! bTimerRunning ) { device->getTimer()->start(); bTimerRunning = true; }
}
...
it works perfectly. Same with particle systems.
Didn't know that device->run() triggers the internal timer, but of course it's logical.
with
bool bTimerRunning = true;
while( device->run() )
{
if( ! device->isWindowActive() ) {
if( bTimerRunning ) { device->getTimer()->stop(); bTimerRunning = false; }
continue;
} else {
if( ! bTimerRunning ) { device->getTimer()->start(); bTimerRunning = true; }
}
...
it works perfectly. Same with particle systems.
Didn't know that device->run() triggers the internal timer, but of course it's logical.