Forward Plus Renderer causes frameskips/jitter/judder/stutter, GPU frames aren't sorted correctly on Windows

[Cyangmou]

Godot version

4.1.3

System information

Windows 11, NVIDIA GeForce GTX 1070, i7-7700K CPU 4.20GHz, 1920x1080 60Hz IPS monitor & a 2560x1440 adaptive 100Hz monitor

Issue description

The forward plus renderer, causes jitters in movement. It's especially visible when V-Sync is switched on.
This happens in 2D and 3D
Those jitters are more or less pronounced, depending on which screen you use, they might not be very visible on a 60HZ screen but are still there.

Resolve_27I0HkMqLD.mp4

when i talk about "jitter" i am talking about this effect happening in the video above or clearly observable in this older video here at 5, 8, 11 and 13 seconds:
Video

The problem seems to be tha tthe renderer has a cache of 4 GPU frames and that the sorting of those frames is jumbled up.
So basically by design we seem to have an reoccuring order of 0, 1, 3, 2, 3, ... 4, 5, 8, 7, 8...
This means some frames don't get shown, others get shown twice and the judder is caused by a step back

Currently it's not clear if it's a problem with the way how the frames are put together, or if it's a driver related issue related to memory. It could be 2 bugs, as comment sin the thread show other bugs play into this

Steps to reproduce

• Simply use forward plus renderer.
• Preferably use a screen with a low refresh rate, as frames are displayed longer and the jumbles are easier to see.
• If you want to experience it very clearly, switch off camera smoothing and switch on V-Sync.
• set your game to a very low resolution e.g. 160x90 scaled by 12 something like this makes the steps between images way bigger and therefore the issue is clearer visible.

Can this be circumvented?

No. It's a very critical and very deep sitting bug.
With the forward plus renderer there is no way to circumvent this and it will happen on any hardware. THe higher the resolution, the less obvious the bug is, however it's always there. The forward plus renderer is simply broken and can't be used in the current state.

You could Use the gl_compatibility renderer, which doesn't have this problem, but this is not a good solution either.

Minimal reproduction project:

I made a simple project in which the character can only run left and right per key input. That's literally all the code we need to test the issue properly, the setup described above is key for making it visible.

Conclusion

1. Only by enabling the gl_compatibility renderer the jitter seems to be solved. The visibility of the problem and the intensity the skips are happening is however different based on the settings.
2. It happens in 2D and 3D
3. Disabling V-Sync with the forward plus renderer makes issues less pronounced than with having V-Sync enabled...
4. ...especially on a 60Hz screen on windows disabling the V-Sync leads to way less experienced jitter, it's still there though
5. The problem happens with process function and with physics_process() function.

Hypothesis

I think the core of the problem lies with the forward plus renderer (There however might be additional problems with V_Sync, Camera or Physics)

Minimal reproduction project

Project Download
This includes a small platformer project. Project settings need to be adjusted according to my tests to reproduce the issues.

[golddotasksquestions]

Would it be possible for you to use your phone filming your monitors to record all those various tests and post the videos here under each setting description?

We all have different hardware and it is close to impossible to fully replicate your result, or be able to tell if we have replicated the same result without seeing yours. If you record your monitors with your phone we would have the best chance to see what you are seeing as screen recording software would likely alter the result as well.

[Cyangmou]

Initial Tests (Outdated, lower in the thread are actual videos, much better than anything written here

-Forward Plus renderer was used
-The camera is conneced to the character.
-you can see the positioning issues just with moving the character
-If we connect the camera to the character and have bunch of sprites in the game it's easier to see if there are visual positioning problems.
-sprite scaling set to nearest neighbor
-Display -> Window -> Size: Window Width Override: 0
-Display -> Window -> Size: Window Height Override: 0

Test 2.1: Basic window size, physics loop, 100%, v-sync on

-Display -> Window -> Size: Viewport Width: 640
-Display -> Window -> Size: Viewport Height: 360
-Display -> Window -> Stretch: Mode: viewport
-Display -> Window -> Stretch: Scale: 1
-Display -> Window -> V-Sync: enabled
-character code with func _physics_process(delta):
-display scaling: viewport

Here the character displays the jitter
It however is barely visible on the 60hz monitor and very visible on the 100 Hz monitor

Test 2.2: Basic window size, process loop, 100%, v-sync on

-Display -> Window -> Size: Viewport Width: 640
-Display -> Window -> Size: Viewport Height: 360
-Display -> Window -> Stretch: Mode: viewport
-Display -> Window -> Stretch: Scale: 1
-Display -> Window -> V-Sync: enabled
-character code with func_process(delta):
-display scaling: viewport

Here the character displays the jitter
It however is slightly more visible on the 60hz monitor than without phsics process and disturbingly well visible on the 100 Hz monitor

Test 2.3: zoomed window size, process loop, 300%, v-sync on

-Display -> Window -> Size: Viewport Width: 1920
-Display -> Window -> Size: Viewport Height: 1080
-Display -> Window -> Stretch: Mode: viewport
-Display -> Window -> Stretch: Scale: 3
-Display -> Window -> V-Sync: enabled
-character code with func_process(delta):
-display scaling: viewport

Here the character displays the jitter, very clearly

Test 2.4: zoomed window size, physics process loop, 300%, v-sync on

-Display -> Window -> Size: Viewport Width: 1920
-Display -> Window -> Size: Viewport Height: 1080
-Display -> Window -> Stretch: Mode: viewport
-Display -> Window -> Stretch: Scale: 3
-Display -> Window -> V-Sync: enabled
-character code with func_physics_process(delta):
-display scaling: viewport

Here the character displays the jitter, very clearly

Test 2.5: Basic window size, physics loop, 100%, v-sync off

-Display -> Window -> Size: Viewport Width: 640
-Display -> Window -> Size: Viewport Height: 360
-Display -> Window -> Stretch: Mode: viewport
-Display -> Window -> Stretch: Scale: 1
-Display -> Window -> V-Sync: disabled
-character code with func _physics_process(delta):
-display scaling: viewport

Here the character displays no jitter

Test 2.2: Basic window size, process loop, 100%, v-sync off

-Display -> Window -> Size: Viewport Width: 640
-Display -> Window -> Size: Viewport Height: 360
-Display -> Window -> Stretch: Mode: viewport
-Display -> Window -> Stretch: Scale: 1
-Display -> Window -> V-Sync: disabled
-character code with func_process(delta):
-display scaling: viewport

Here the character displays no jitter

Test 2.3: zoomed window size, process loop, 300%, v-sync off

-Display -> Window -> Size: Viewport Width: 1920
-Display -> Window -> Size: Viewport Height: 1080
-Display -> Window -> Stretch: Mode: viewport
-Display -> Window -> Stretch: Scale: 3
-Display -> Window -> V-Sync: disabled
-character code with func_process(delta):
-display scaling: viewport

Here the character displays no jitter

Test 2.4: zoomed window size, physics process loop, 300%, v-sync off

-Display -> Window -> Size: Viewport Width: 1920
-Display -> Window -> Size: Viewport Height: 1080
-Display -> Window -> Stretch: Mode: viewport
-Display -> Window -> Stretch: Scale: 3
-Display -> Window -> V-Sync: disabled
-character code with func_physics_process(delta):
-display scaling: viewport

Here the character displays no jitter

The whole issue also comes up in a ton of other issue reports with physics, sprite 2d and whatever. It#s not only me experiencing those issues, I also have it on my laptop and found a bunch of similar bug reports, but I found out that it's the renderer

If I use the compatibility renderer all is smooth

So by sheer logic that's where the issue must lie.

[reduz]

I am not familiar with the code, but I hypothesize that the swapchain is using the wrong monitor hz for the window.

[Cyangmou]

Also because it came up: changing the project settings to fullscreen also produces the jitter, having fullscreen without forward plus v-sync runs smooth again.

[Cyangmou]

I got another very interesting observation:
After I was switching the project settings to fullscreen mode and then setting them back to windowed the game suddenly ran smooth.
Just before it did not run smooth in the fullscreen.

So it also could be that the V-Sync is fine, but just something with the initial initialization of the windowed mode Hz might be wrong.
I started this as a clean project and did not touch the window mode, just let it run in windowed.
Now for this project it seems to be fixed (not the uploaded one, but the one I had on my HD)

I quickly created another new project and the issue again applies

My main system monitor is the 100Hz monitor, my secondar ymonitor is the 60Hz monitor.

Exact steps which accidentally seem to solve this issue:
1.) switching the renderer to compatibility renderer, save project, restart
2.) switching the render back to forward_plus renderer, save project, restart
3.) set window mode in the project settings to fullscreen, again choose viewport in the stretch mode settings, playtest
4.) set window mode in the project settings back to windowed, playtest (now it ran smooth for me)

[chutneyio]

Hi @Cyangmou , I have just run the demo and got jittered whenever stretch mode set to viewport no matter v-sync is enabled or not. After changing to canvas_item there is no jitter anymore. I only have a 60 Hz monitor so this could be a multiple monitors problem.

Btw, I'm usingSubviewport in a top-down game to deal with jittering because canvas_item will not work with diagonal movement. This is the demo:
JitterTest_Subviewport.zip

I'm kinda concerning about the multiple monitors issue but I could not verify it because I don't have the setup to test myself so your result on this would be much appreciated!

[Cyangmou]

I just ran that linked demo how it came out of the box. I performed all tests on my 100Hz 2560x1440 monitor

Test 1: out of the box
jitter

what is different here:
Window Stretch Mode: disabled
Renderer: forward plus
Window Height Override: 1920
Window Width Override: 1080
V-Sync: enabled

Test 1: disabling V-Sync
very soft, barely noticeable jitter, jitter became a lot softer than with v-sync enabled but is not gone

Test 2: v sync enabled, but using process instead of physics process
solved the jitter, I could not detect any jitter

Test 3: v sync diabled, physics-process
a few stutters could be observed

So with this viewport override it seems to make a difference if you use a physics process or no physics process
As with the physics process the jitter is way more pronounced than with a normal process
But in both cases the jitter can be observed!

Also I additionally tried then to set the stretch mode to viewport and to canvas items
in both cases I would neithe rsee the gameworld correctly positioned nor the character, only the numbers running you added in the output.

[chutneyio]

@Cyangmou Thanks so much!

So with Subviewport I can still achieve pixel perfect on multiple monitors setup with v-sync enabled by using _process for both player and camera as you mentioned in Test 2 right? Don't know if this is still a bug or not because I expect movement code with physics to happen in _physics_process. But at least there is a workaround for it.

[Cyangmou]

The point is that not using the physics process further in dev could drag down the game, as running physics operations in frames is costly.
I mean smoothness could be the case with this small project on my machine, which is probably more powerful than the machine most people play those small indiegames on.
But if the game scales up and you put all of your stuff in the process loop, it's literally in terms of performance an insanely bad idea.

I would not call it a solution, rather something which unexpectedly worked. The important parts would be the physics ticks.

[chutneyio]

@Cyangmou I don't know how costly physics operations is but the way Godot handle pixel perfect is very similar to GameMaker to me. There is no _physics_process function in GameMaker, only Step event that is very much like _process, and I need to do almost the same things in GameMaker to make the game pixel perfect (scale the application surface, rounding the camera position). Also _process in Godot run like 60 times per second so I don't think there will be problem if we put all the code in _process.

[Cyangmou]

You can of course do it. It's just neither professional nor smart to do it.
And yes I agree about GameMaker, but GameMaker really scales badly for big projects and that's why it's uninteresting for any medium to bigger sized game.
There is a reason why a physics tick exists and why both Unreal and Unity which have the bigge rshare on the market make use of this optimization.

[chutneyio]

Oh @Cyangmou wait... In my demo I forgot to change player to _physics_process which results in player and camera running in different update function. Did you test the case where both of them using _physics_process yet?
Edit: Nevermind, player is using _physics_process already, just my mistake after messing things around.

[CattyClouds]

I am also experiencing this issue and did some testing and may have found a hint to the issue. It appears that when changing the Max FPS setting to be 60 to bump up against VSync's max stepping, the issue seems to disappear. I'm not 100% sure if it actually disappears after looking at it for so long, but, the jitter is 99% reduced in conjunction with the Physics Jitter Fix setting at 0.5 (default).

Monitor 1: 2560x1440p @ 60hz
Monitor 2: 2560x1440p @ 60hz
Godot: v4.1.2.stable.mono.official [399c9dc]

Settings changed:
Project > Project Settings > General Tab > Application > Run > Max FPS
Project > Project Settings > General Tab > Display > Window > V-Sync > V-Sync Mode

When VSync is enabled and Max FPS is set to 0, the jitter is there.
When VSync is enabled and Max FPS is set to 60, the jitter disappears
When VSync is enabled and Max FPS is set to 61, the jitter is there

When VSync is disabled and Max FPS is set to 0 (goes to around 3k+), the jitter disappears
When VSync is disabled and Max FPS is set to 90, the jitter disappears

[Cyangmou]

Yep, if you lock a 60Hz game on a 60Hz screen and your hardware can blow the specs, for sure it's running smooth. I mean that's within the expectation.
But then it's running smooth for you only and it's not an overarching solution for releasing a game for a lot of different hardware setups.
This is not even a bandaid, it's just that with this specific setting and setup the issue would be greatly reduced.

[Cyangmou]

Ok, I decided to run other tests with setups with 4 different (close to) 60HZ screens

On Windows you can check in the Advanced display settings the exact Hz the screen runs.

Adding those 2 lines of code in godot should give us a good idea about the return

print(DisplayServer.screen_get_refresh_rate(0))
print(DisplayServer.screen_get_refresh_rate(1))

Setup 1:

screen1: 1920x1080, on Windows 11: 59,95Hz
screen2: 1920x1080 on Windows 11: 60Hz

results in:
59,95 Hz screen results in a value Godot returns of 59
60.00 Hz screen results in a value godot returns of 60

---

Setup 2:

59,97 Hz screen results in a value godot returns of 60
59,95 Hz screen results in a value godot returns of 59

Conclusion:

Jitter could be experienced on all screens
What's interesting about the return number of the engine is that it's an integer.
It's not aligning with the system information.
The rounding when sorted also looks totally weird:
60.00 Hz screen results in a value godot returns of 60
59,97 Hz screen results in a value godot returns of 60
59,95 Hz screen results in a value godot returns of 59

Something is really really off here
This might or might not have an impact on the issue, i don't know if the output of the DisplayServer.screen_get_refresh_rate() is rounded or not, but I have the feleing it should align with the OS information, which it doesn't

[RPicster]

I did some tests on my own.
I can confirm that there is definitely something very broken here.

I have a lot of experience with pixelart games in Godot 3 and never had the feeling that anything was problematic there and so far have not worked with pixelart in Godot 4.

I "ported" the MRP to Godot 3 and used settings that were as close as possible to the MRP.
I disabled camera smoothing on both projects as I found it makes the issue much more obvious.

Here is footage that is slowed down to 1000% from both versions:
Testing it in Godot 4 I had "position skips" very, very regulary where the sprite skipped a pixel and jumped to the next pixel immediately. And even when not skipping, it didn't feel as smooth as the test in Godot 3.

It didn't always skip a pixel of course...

In Godot 3 I was not able to reproduce any of these problem - it was super smooth.

My screens are both 144 fps and I disabled VSync for both tests.

⚡⚡⚡ EDIT: Sorry, my bad. I enabled pixel snapping for transforms which led to these bad stutters, without this setting I have smooth movement. ⚡⚡⚡

[Cyangmou]

Here is a lossless recording with camera smoothing switched off
There are multiple framelosses, which are very hard to see unless your eye is trained and a 2 frame loss at around 15 seconds, when the character is mid jump - focus on the environment and this will be really easy to spot.

60hz screen
forward plus renderer
1920x1080, 300%
windowed mode, stretch mode viewport
v-sync enabled

lossless-video-recording

[Cyangmou]

Edited the name that the description of the issue is in line with all known test results.

[byte-arcane]

Regarding the issue of refresh rate appearing incorrectly, it looks like that Godot uses DEVMODEW here and this structure seems to used a DWORD for the storage of the refresh rate, which means that it can't deal with fractional refresh rates.

Instead, the structure DWM_TIMING_INFO seems to provide "UNSIGNED_RATIO rateRefresh;" which supports fractional refresh rates, so this looks like it should be used instead

[RPicster]

Here is a lossless recording with camera smoothing switched off There are multiple framelosses, which are very hard to see unless your eye is trained and a 2 frame loss at around 15 seconds, when the character is mid jump - focus on the environment and this will be really easy to spot.

60hz screen forward plus renderer 1920x1080, 300% windowed mode, stretch mode viewport v-sync enabled

lossless-video-recording

I watched the footage very carefully... had to do it a couple of times to spot it.
But I put my observation into a short gif so it's very obvious.

Frame 7 is dropped/skipped

[LimestaX]

2 different users having this issue w/ VSYNC enabled and both of us use 5700XT graphics cards, forward+, vulkan (on mine, not sure on theirs)
https://www.youtube.com/watch?v=06wlTIDRx3U&t=4s

[TestSubject06]

2 different users having this issue w/ VSYNC enabled and both of us use 5600XT graphics cards, forward+, vulkan (on mine, not sure on theirs) https://www.youtube.com/watch?v=06wlTIDRx3U&t=4s

Oh hey, I was wondering where that recording went. Yes I'm also forward+ vulkan on a 5700 XT with VSync enabled.

[LimestaX]

Sorry 5700XT, and yeah I was following up on this bug and I figured we'd want it tagged.

…

On Thu, Dec 21, 2023, 6:31 PM TestSubject06 ***@***.***> wrote: 2 different users having this issue w/ VSYNC enabled and both of us use 5600XT graphics cards, forward+, vulkan (on mine, not sure on theirs) https://www.youtube.com/watch?v=06wlTIDRx3U&t=4s Oh hey, I was wondering where that recording went. Yes I'm also forward+ vulkan on a 5700 XT with VSync enabled. — Reply to this email directly, view it on GitHub <#84137 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKYWUIVYY3EMT6III2XYAM3YKTBEJAVCNFSM6AAAAAA6UYGWNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRXGA2TAMJRG4> . You are receiving this because you commented.Message ID: ***@***.***>

[HybridEidolon]

The minimal reproduction does not appear to have the issue as of 3be3d50 (#87340).

[vpellen]

My Vulkan vsync stutters seem similarly fixed by the above, although it's worth noting I had to go into my NVidia control panel and set "Vulkan/OpenGL present method" to "Prefer layered on DXGI Swapchain", which probably makes sense to somebody smarter than me.

[DarioSamo]

My Vulkan vsync stutters seem similarly fixed by the above, although it's worth noting I had to go into my NVidia control panel and set "Vulkan/OpenGL present method" to "Prefer layered on DXGI Swapchain", which probably makes sense to somebody smarter than me.

This is not that odd of a fix, I've been considering that we could get much more consistent behavior if we used a DXGI swap chain instead even when using Vulkan. It'd get lower latency and a more consistent presentation. That control panel option does essentially do that for you at the low level AFAIK.

[Calinou]

I've been considering that we could get much more consistent behavior if we used a DXGI swap chain instead even when using Vulkan. It'd get lower latency and a more consistent presentation.

See godotengine/godot-proposals#5692 where I originally proposed this. It would also allow for HDR output to be implemented in Vulkan-based rendering methods, as DXGI is the only way to achieve HDR output on Windows.

Using DXGI directly also allows NvTrueHDR to work on Vulkan apps without requiring changes in the NVIDIA Control Panel to force layered DXGI presentation.

[jbikeler]

Screenbits.2024-03-09_153433.mp4

Hey, I've encountered this issue as well within Godot v4.2.1.stable.official [b09f793] where toggling VSYNC on and off leads to noticeable changes in tween behavior attached to nodes like Sprites. This seems to extend beyond the previously discussed impacts on character controllers and cameras, affecting animations and movements across the board.

Steps to Reproduce

1. Attach a script incorporating a tween to a node, for example, a Sprite.
2. Experiment with turning VSYNC on and off.
3. Observe the variations in tween behavior with these changes.

To provide a clearer picture, I’ve included a video demonstrating these steps and the observed effects.

Expected vs. Observed Behavior

Ideally, tween operations should remain stable and consistent irrespective of VSYNC status, ensuring animations are smooth. However, toggling VSYNC alters the tween behavior, compromising animation smoothness and predictability.

Technical Environment

• Operating System: Windows 10
• Processor: AMD Ryzen 7 3700X 8-Core, 3.59 GHz
• Graphics Card: NVIDIA GeForce RTX 3060 Ti
• RAM: 16 GB
• Primary Monitor: LG 32" UHD with FreeSync 32UN550-W - 59.951Hz
• Secondary Monitor: Asus Designo MX279HS Monitor 27" - 60Hz
• Godot Version: v4.2.1.stable.official [b09f793]

Please let me know if further information is required or how I can help contribute to resolving this.

[vpellen]

@jbikeler This may be fixed in 4.3, there was some work done on the renderer, can you reproduce it on the latest dev release?

[jbikeler]

@jbikeler This may be fixed in 4.3, there was some work done on the renderer, can you reproduce it on the latest dev release?

Yes, using 4.3 Dev 4 I still get the same result. I did see earlier in this forum that it could be a swap chain issue and I saw that there are new settings related to VSYNC and swap chain but I haven't done any testing with them in 4.3. Purely through enabling and disabling VSYNC I still get the same results.

Screenbits.2024-03-09_183857.mp4

[jbikeler]

The recording I just posted was a duplicated project from 4.2.1 opened in 4.3.dev4, but just to make sure I also completely rebuilt the project for the tween test in 4.3.dev4 from scratch and I still got the same results.

[vpellen]

Do you encounter such issues with the directx renderer, or only vulkan? I had similar jittering but managed to fix it by modifying the uhhh swapchain setting in my nvidia control panel after the render fixes were merged

[jbikeler]

I believe only Vulkan. To be honest, I didn't know we could switch to directx anymore since there wasn't an option when you first create the project. I assume it's this setting in Godot:

And the Nvidia Control Panel is this? :

Is this then a temporary fix? I guess I'm just confused on how these renderers effect players. If I fix jitter on my pc by changing a bunch of settings will players need to do the same to not experience jitter?

[darksylinc]

Can you try a newer NVIDIA driver? There's a chance they fixed it on their end.

[jbikeler]

Can you try a newer NVIDIA driver? There's a chance they fixed it on their end.

After updating my 3060 ti driver to 551.76, Godot 4.3.dev4 fixes most of the jitter issues even with Vulkan. Godot 4.2.1 still has a bit of jitter after updating, but it actually improved a bit with the update.

I'll continue to test, but it seems 4.3 will fix the issue.

[DarioSamo]

Is this then a temporary fix? I guess I'm just confused on how these renderers effect players. If I fix jitter on my pc by changing a bunch of settings will players need to do the same to not experience jitter?

The TL;DR so far from my understanding is that:

• Undeniably, there was a Vulkan synchronization issue in 4.2 that could lead to inconsistent presentation of frames. This has been fixed as the presentation behavior has been completely rewritten and it is now consistent from Godot's side.
• Seemingly on NVIDIA hardware on Windows there's a chance the issue is still prevalent (most likely a different bug with a very similar result). We've seen reports of people saying the issue fixes itself by using this option in the control panel and it's possible they fixed it in a driver update. It's unknown what is/was the cause yet but one possible link seems to be multi-monitor setups with different refresh rates.

I'd not be surprised if this issue is consistent even on other Vulkan applications on NVIDIA/Windows, but I don't have enough evidence to support that yet. It's possible the issue has gone unnoticed because games are far more likely to use D3D on Windows than Vulkan, while on Godot it's the default option since it's the open standard.

EDIT: It seems your latest comment would also support the theory that these are indeed two separate bugs with a similar result.

[bazsupport]

To be honest, I didn't know we could switch to directx anymore since there wasn't an option when you first create the project.

How did you get that direct x option??

[jbikeler]

How did you get that direct x option??

The option appears in the Godot 4.3.dev build. I don't have it for 4.2.1 either.

[mrjustaguy]

One thing to ask, is GPU hardware scheduling enabled, and or windowed optimizations in windows?

[h0lley]

I can't reconstruct this on Windows at all, however, I am getting something that looks just like this on Ubuntu (x11).

here's a curious test:
set the window mode to MODE_EXCLUSIVE_FULLSCREEN
enable display/window/per_pixel_transparency/allowed

for some reason, this result in buttery smooth scrolling for me with Forward+
would be interested in hearing if you can observe something similar on Windows.