Jump to content

Time::GetSpeed() not really useful?


MexSource
 Share

Recommended Posts

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?

C++ :3

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

C++ :3

Link to comment
Share on other sites

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 tongue.png ).

 

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.

--"There is no spoon"

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 :)

--"There is no spoon"

Link to comment
Share on other sites

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()

Link to comment
Share on other sites

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

 

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...