Time::GetSpeed() not really useful?

[MexSource]

Hey,

 

I noticed (in 3.0 and 3.1) that Time::GetSpeed() doesn't return really useful values.

When i opened some programs in the back (my computer is slower) I can run much faster and when my computer is very fast i run very slow.

 

Here's the code i used:

playerMovement.z = (window->KeyDown(Key::W) - window->KeyDown(Key::S)) * Time::GetSpeed() * moveSpeed;
playerMovement.x = (window->KeyDown(Key::A) - window->KeyDown(Key:)) * Time::GetSpeed() * strafeSpeed;

 

PS: if you activate vsync (context->Sync(true)) you can also run faster and when you disable it (more fps) you will run slower.

 

Does somebody else has these problem's and do josh know about this? Or should i create a new bug report?

[tempest]

It sounds a lot like this -> http://www.leadwerks.com/werkspace/topic/9328-linux-run-mode-slower-than-debug/

Having high framerate but the getting choppy video due to skipped frames.

 

If it's the same thing - yes, Josh is aware of it.

[MexSource]

no I think i explained me wrong. I mean the character speed is higher (e.g. he can run faster).

What you showed me seems is only something about the debug mode is faster than release mode

[tempest]

Can you post a video? It's hard to imagine what you mean.

[MexSource]

Yep i will do, just need to install bandicam now.

Wait, does leadwerks come with video recording? Or only the functon to upload videos?

 

PS: will not do it today (busy with trying to implement raknet)

[Naughty Alien]

..LE2.x was exposed to same issue..i never used it to stabilize motion in game as it was useless, with same issues as you describing..I guess, code base for that particular function remain same..

[YouGroove]

So what to use to get motion smoothed with frame rate and constant time interval ?

Or it is the only solution and this is a bug ?

[AggrorJorn]

I haven't tested it out but if this is true than there is a huge fundamental bug in the software.

 

In the mean time have a look at this article:

http://www.learn-cocos2d.com/2013/10/game-engine-multiply-delta-time-or-not/

[Rick]

Isn't the point of this function to return a value that deviates from 1 based on the speed of the computer at any given moment to achieve the same speed on all computers? If your computer runs at a specific speed you'd get 1 returned which wouldn't alter your value since you multiply by it. If your PC slows down the value returned is > 1 so as to put your positions where they should be in relation to a person who has a PC that runs at the "perfect" speed and if your PC is really fast then you'd get a value < 1 so as to put your positions where they should be in relation to a person who has a PC that runs at the "perfect" speed?

 

Also, wasn't code like that supposed to be in an UpdatePhysics() function (Lua gives this but in C++ you have to make it yourself I think) so that you don't have to multiply by App::Speed() when sending values to SetInput() (which I assume is what you are doing).

[MexSource]

I think i got it. I tried removing the Time::GetSpeed() completely, because it's not very effective, and i found out that it seems to run perfect. On slow pc's also on fast. I think Josh added this to the UpdatePhysics() function already.

 

Works fine

[AggrorJorn]

If you are applying the (movement * appspeed) to the CharachterController SetInput command, thinks will go wrong:

 

...The input values should not be modulated by the application speed, since they will only be used once per physics step.

http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entitysetinput-r706

[MexSource]

interesting

thanks

[Michael_J]

Rick, that would depend on how you're doing your timing, I think. For example (and I'm SURE you know all this but I'm going to explain for someone who might not), EVERYTHING is normally done "per second". So, if I only updated once per second then I'd multiply everything by a value of 1.0 to get the full effect. If, I suddenly started updating at 2 FPS, or 500 ms per frame, then I'd multiply everything by 0.5 so that the full value is applied over the course of a second.

 

60 FPS would give a multiplier of 0.01667 ((1000 / 60) / 1000). In case you're wondering, there's 1000 milliseconds per second, hence the use of that number (again, explaining for someone who may not know).

 

Using this method, then, a value greater than 1.0 SHOULD be impossible unless you're doing less than 1 FPS (in which case there's some other issues you should be addressing first ).

 

Now, what I CAN imagine is that maybe GetSpeed() is giving a multiplier based on some fixed FPS (60 maybe?). If that were the case then I could see how values above 1.0 would be easy to get back from it. If true then I wouldn't consider GetSpeed() useless or broken, only specific.

 

For those that don't know, if you want a down and dirty method for getting a speed multiplier that is NOT FPS specific, you'd do:

 

Diff = Current Clock Time - Previous Clock Time

Multi = 1000/Diff

Multi *= 0.001 (or Multi /= 1000 -- if you prefer)

(record current time as previous for use next cycle)

 

You'll want to use Leadwerks' method for getting clock time (Time::GetCurrent() ) because it handles "pausing" for you when you use Pause() and Resume().

 

As Josh has said though, when using physics (including the character controller) you DON'T want to adjust for timing as it is handled for you.

[Rick]

Now, what I CAN imagine is that maybe GetSpeed() is giving a multiplier based on some fixed FPS (60 maybe?). If that were the case then I could see how values above 1.0 would be easy to get back from it. If true then I wouldn't consider GetSpeed() useless or broken, only specific.

 

I think this is how it's setup which, like you said, is how you get values > 1 if your PC runs slow.

 

 

 

As Josh has said though, when using physics (including the character controller) you DON'T want to adjust for speed as it is handled for you.

 

But only when inside the UpdatePhysics() function I believe (which is only in Lua I think) because it's already set to run at a specific FPS. In C++ you'd have to make an UpdatePhysics() function yourself to act the same (maybe there is a hook for it?). I think Aggror had a topic on this and that's what Josh said.

 

 

 

 

http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/entity/entityupdatephysicshook-r62

 

For the OP, a good test would be to implement this function hook for your character controller entity and then remove multiplying by AppSpeed() and see how it works.

[Michael_J]

But only when inside the UpdatePhysics() function I believe (which is only in Lua I think) because it's already set to run at a specific FPS. In C++ you'd have to make an UpdatePhysics() function yourself to act the same (maybe there is a hook for it?). I think Aggror had a topic on this and that's what Josh said.

 

 

My CC is already in a physics hook, so I never noticed if this was the case; but it's certainly possible and does make sense if he (Josh) was referring to LUA and its UpdatePhysics(). However, it was my understanding (which obviously could be wrong) that as physics is run on its own thread the timing and timing adjustments were handled for you regardless (60 FPS).

 

I am new to the engine so I'll defer to the more experienced here

[Rick]

However, it was my understanding (which obviously could be wrong) that as physics is run on its own thread the timing and timing adjustments were handled for you regardless (60 FPS).

 

 

I have to wonder why an UpdatePhysics() hook would even exist then? I don't think it's ran on it's own thread. I think LE handles the timing and that's why there is an UpdatePhysics hook. Doing things inside UpdatePhysics is the way you get the timing don't for you.

 

Either way, I think the point is (OP) to put your physics functions inside the UpdatePhysics hook and don't multiply by App::Speed()

[MexSource]

ok thanks all i hope you're right, because i can't test now

[Flexman]

I'm just throwin in my 0.02$ from an LE2.5 user. LE would go to your hook first (if defined), then the internal update which you can't see.

We've done a lot of this recently.

[Admin]

Don't modulate physics functions by GetSpeed(). When you set the velocity of the character controller, you are setting a value that is measured in units/time. Modulating this by the execution speed will result in incorrect values.

 

If on the other hand, you are manually moving an object each rendering frame, and you want to know how far it should move each time to account for execution speed, then the movement value should be multiplied by Time:GetSpeed().

[Naughty Alien]

..what i did in LE2.x was creating timer independent from rendering and calculated time between frames and then applied changes on to dynamic entities in game..it worked well and accurate..