Frame-Independent calculation (in Leadwerks called "Time:GetSpeed()")

[beo6]

I could not find any

```

Time:GetSpeed()

```

function like in Leadwerks to do Frame Independent calculations.
I guess the Update() function runs at a hardcoded 60 HZ update frequency, but there would still be an issue if the Users PC falls below 60 FPS.

[Josh]

It's already frame-independent, but I added a World:GetSpeed() method which will return a weighting value for use when a frequency other than 60 is passed to World:Update.

[Alienhead]

On 8/22/2024 at 5:56 PM, beo6 said:

I could not find any

```

Time:GetSpeed()

```

function like in Leadwerks to do Frame Independent calculations.
I guess the Update() function runs at a hardcoded 60 HZ update frequency, but there would still be an issue if the Users PC falls below 60 FPS.

This has been a concern of mine as well..  When I load the screen up with animated models and drop below 60fps my camera movement and animations are slowed down. There seems to be no frame - tweening involved yet.  Is this sometime that remains to be addressed ?

[Dreikblack]

We need something like Microseconds() to measure a difference between Updates() in Component  for applying a coefficient to camera speed and other stuff

[Dreikblack]

In debug it's not 16,667 and varies significantly, at least in specific component. Maybe i should get delta between world->updates since entity movement will happen at render i suppose.

Anyway if fps is lower 60 due performance reasons updates are definitely happens more rare than 60 hz.

[beo6]

But if i understood it correctly, the Update method is independent of the rendering thread.

So in case you are rendering too complex objects and your framerate drops below 60 fps because of that, it should still not affect the Update call?

Or i still don't get how these are working together completely.

[Josh]

I could not reply before the meeting, but now I can give you some more details.

If the World::Render method is called and the rendering thread has not performed at least one round trip yet, then the main thread will pause. The reason for this is that loading a new scene can cause a lot of objects to pile up, and the first render after that will be very slow, because a ton of new data is being passed into memory. This causes the rendering thread to run at a slow speed, that first frame. (At one point, I actually had some rendering calls being made in a callback while the scene was loading. It was funny to see the scene come into view piece-by-piece.)

The rendering thread already performs interpolation, which is how it is able to rendering at a framerate independent from the game update rate.

If the main thread did not pause when it detected the rendering thread was loading content, it would start piling up a lot of extra rendering commands. Let's say the rendering thread paused for one second because it was loading a lot of textures into memory. During the next render, there would be 60 frames of rendering commands piled up that would all have to be executed. This would slow make the next frame slow, and more extra commands would pile up. This could cause the rendering thread to be very slow for an extended period of time, or it could cause it to stop responding completely, if data was being sent faster than it could be processed.

Now if the framerate drops below the screen refresh rate for some other reason, either due to some inefficiency that needs to be ironed out, or due to just hitting the limits of the hardware, that is a situation we don't currently have a good solution for. The best thing to do is avoid it, and Ultra usually does a good job of preventing that from happening, but I understand it cannot always be guaranteed and we should find a way of dealing with it without making things too complicated.

Having multiple threads makes the engine very powerful because you have an amount of processing time for your game logic, which is almost impossible to max out. However, the problem of "overloading" the rendering thread is one issue that can arise, and it needs to be dealt with carefully.

[Alienhead]

Solid explanation, tyvm. 

[Josh]

I thought about this a bit more, and I think the simplest solution is to add some logic that makes the world update speed take this extra delay into account if it occurs, instead of just using the user-defined update frequency.

Under normal circumstances you would not need to multiply movement values by anything, but if you want to account for the possibility of the framerate dropping below the desired one, you would have that ability.

[Alienhead]

This would need to work with animations as well.