Time::GetSpeed()

[Vulcan]

What exactly is Time::GetSpeed() returning?

In the reference I find this:

Returns the application speed.

Is it seconds, ticks or what?

[AggrorJorn]

It is the time factor relative to the FPS.

 

For instance:

Your game runs at 30 FPS: Time:GetSpeed() returns 1.0f.

Your game runs at 60 FPS: Time:GetSpeed returns 0.5f.

 

Note: I used 30 fps as the base FPS. It could be 24 or some other value as well.

[Vulcan]

It is the time factor relative to the FPS.

 

For instance:

Your game runs at 30 FPS: Time:GetSpeed() returns 1.0f.

Your game runs at 60 FPS: Time:GetSpeed returns 0.5f.

 

Note: I used 30 fps as the base FPS. It could be 24 or some other value as well.

Ookkii that's why I could not understand it. I tryied on a much slower PC and it GetSpeed() got atleast 10x if not 100x more in difference. I think I need to dig further with GetSpeed().

Thanks

[shadmar]

For example if you want a steady counter to increase at the same rate no matter the fps you can do something like this in your update loop:

 

In Start()

self.index=0

 

in Update()

local count = 0
self.index=self.index+Time:GetSpeed()*0.5   --0.5 just controls the speed here.
count=math.floor(self.index)

 

count will then have a steady increase no matter the fps.

[Rick]

@shadmar

 

I think GetCurrent() would be best for that. http://www.leadwerks.com/werkspace/page/documentation/_/command-reference/time/timegetcurrent-r494. I know you are just giving an example but perhaps a confusing one given there are better commands for timer/counter like functionality.

 

 

I think GetSpeed() is more for moving non physics things at a speed that is the same on all PC's.

 

 

@Vulcan the reason you get higher values on a lower end PC is that it's main loop is getting called fewer times than on a faster PC. So in order for movement of your non physics objects to be the same, the slower PC has to give higher values to make up for this slowness. You take this value and multiply it by your movement variable.

 

A really fast PC will give you values less than 1 in order to slow things down so your non physics objects move the same since multiplying by a value less than 1 will reduce the final number.

 

z = 0

z = z + (10 * App::GetSpeed())

 

To use Aggrors example:

 

At 30 fps App::GetSpeed() returns 1 so the final value is 10 (z = 0 + (10 * 1))

 

At 60 fps App::GetSpeed() returns 0.5 so the final value is 5 (z = 0 + (10 * .5)). This needs to happen because your main game loop is getting called 2 times for every 1 time of the 30 fps so when the 60 fps is ran twice z will equal 10 which is the same value as the 30 fps running one cycle, giving you the same z movement speed on both PC's in the same amount of actual time real world time giving the same gameplay feel on both PC's. The main game loop on a PC will run as fast as possible which means how many times it runs in 1 second changes from PC to PC. This is a way to combat that and make it seem like all PC's are running the same. You only really do this for things that you need to be the same speed on all PC's like movement. For some other things like AI for example it may be fine that the main loop runs as fast as possible.

 

Without something like this fast PC's would move non physics objects too fast and slow PC's would move non physics objects too slow and players wouldn't get the same experience.

[shadmar]

@rick

 

Yes thst might be, never tried your way.

 

I was actually using a texture cycling example:

http://www.leadwerks.com/werkspace/topic/9646-animated-workshop-waternormals-usage-example/page__hl__waternormals

[Rick]

@shadmar It's not really my way