Jitter still present when FPS is lower than physicsFPS

[Norodix]

The problem

I created a simple little game but on some weak gpus (mobile) it does not run very well. This created a jitter. I tried to apply this addon to fix the issue but it did not work. After looking at the code a bit I think I found the problem. All in 2D, fps limited to 58, physics_fps is set to 60.

What I think is wrong

In the code the last frames that are used for the interpolation are updated in the process function via the RefreshTransform() function. This works perfectly if the game runs at a high fps with relatively slow physics. However this is problematic in case the visual process can run twice between two physics frames. In this case the previous and current positions are updated twice, effectively to the same value. This makes the object jump to the next frame, same as if no interpolation was applied.

My fix

For me, changing the code in a way that the positions are always updated in the pyhsics_process fixed the issue.

Is there a reason the updates are implemented inside the process function with flags signaling wether to use it or not? To me it looks like the flags only try to mimic the case where the physics_process function updates the positions.

Otherwise I really like this addon, it helped me a ton. Hope I could help.

[lawnjelly]

It's a while since I wrote the addon (2 and half years!) so it took me a little bit to try and refresh my memory! 😁

I too didn't remember the reason for the DIRTY flag immediately, but I think it's an optimization to prevent reading the transforms when not necessary. This can be more expensive than you would expect, because get_global_transform() actually can cause the matrix concatenation step to take place, as it is all done with dirty flags in Godot core.

In situations where _process runs twice before the next _physics_process, _RefreshTransform should run only once (on the first _process) because _RefreshTransform clears the dirty flag.

What may possibly be incorrect is _physics_process doing a refresh, setting the dirty flag, then _process doing another refresh. It's a long time since I did this so I'll have to test this out to remind myself.. this may be the bug you are referring to.

Good news is though, although there's a certain amount of gymnastics that had to be done in the addon, interpolation should be in Godot core soon, which will make all this redundant:
godotengine/godot#52846

It's pretty much working already, I just need to get a little more time with Juan looking over it finalising the API for users, and he's been busy the last couple of weeks trying to get Godot 4 alpha ready, hence the delay. But am hoping we'll be able to have it in 3.5 soon.

[Norodix]

Yes, I think that is the bug that I came across. For me, changing the call to _physics_process fixed the game.
I'm not sure the efficiency is affected by moving the call to _physics_process. The function should be called every physics frame, otherwise the m_Pos_prev and other "prev" variables would not store the correct values. So for correct operation it should be called every physics frame.

The new interpolation looks great, but still, thank you for the mod, it made the game playable on some mobiles where the effects were a bit too heavy. If you don't want to change things in this mod because it will soon be core function, I can understand that.

[lawnjelly]

I didn't want to have a look last night as too tired, but I'm checking it today and I think you are right, there is a problem when the physics tick rate is higher than the frame rate. I'll see if I can do a fix. 👍

I can only guess this hasn't come up before because in most cases it's the opposite (frame rate higher than tick rate), so there is no problem in that situation.

[lawnjelly]

Hopefully this is fixed now with:
036278b

I just removed the dirty flag and refresh the transforms on each physics tick. I don't really think the dirty flag was necessary anyway in the end (it may have been historical) and it obviously made it more bug prone.