Stutter/Jitter and screen freezing in a simple 2D project

[di-kang]

Godot version:
Godot 3.0.6

OS/device including version:
MacOS 10.14.1
MacBook (Retina, 12-inch, 2017)
1.2 GHz Intel Core m3
8 GB 1867 MHz LPDDR3
Intel HD Graphics 615 1536 MB
(Also reproduced on multiple devices including PC and exported game on mobile and PC.)

Issue description:
Any object that is moving seems to periodically stutter or jitter accompanied by screen freezing in a 2D project.
And it seems to happen more frequently on devices with low processing powers or non-Windows devices.

Steps to reproduce:
Create a new project with a KinematicBody2D or an AnimatedSprite or a RidiBody2D and modify position with move_and_slide() or set_global_position() or apply_impulse() after adding a Camera2D as a child node.(But it still happens even without the Camera2D.)

Minimal reproduction project:
3.1 Beta 2
Godot_Jitter.zip
Improved Version by @Ploppy3

---

KinematicBody2D, _physics_process(), move_and_slide()

https://youtu.be/78S95yugRDk

extends KinematicBody2D
const SPEED = 75
var motion = Vector2()

func _physics_process(delta):
	if Input.is_action_pressed('ui_right'): motion.x = SPEED
	elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
	else: motion.x = 0
	motion = move_and_slide(motion, Vector2(0, -1))
	print(delta, position)

---

AnimatedSprite, _physics_process(), set_global_position()

https://youtu.be/gdc6NOoWG4E

extends AnimatedSprite
const SPEED = 75
var motion = Vector2()

func _physics_process(delta):
	if Input.is_action_pressed('ui_right'): motion.x = SPEED
	elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
	else: motion.x = 0
	set_global_position(get_global_position() + motion*delta)
	print(delta, position)

---

KinematicBody2D, _process(), set_global_position()

https://youtu.be/YVFtkbuyqEQ

extends KinematicBody2D
const SPEED = 75
var motion = Vector2()

func _process(delta):
	if Input.is_action_pressed('ui_right'): motion.x = SPEED
	elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
	else: motion.x = 0
	set_global_position(get_global_position() + motion*delta)
	print(delta, position)

---

RigidBody2D, _physics_process(), apply_impulse(), camera smoothing on

https://youtu.be/MGMlhl0tPTA

extends RigidBody2D
const SPEED = 7
var motion = Vector2()

func _physics_process(delta):
	if Input.is_action_pressed('ui_right'): motion.x = SPEED
	elif Input.is_action_pressed('ui_left'): motion.x = -SPEED
	else: motion.x = 0
	apply_impulse(position, motion)

I may have amplified the jittering by using apply_impulse() like that but modifying the position of the object directly using set_position() didn't make much difference.
EDIT: Changing the process mode of the camera to CAMERA2D_PROCESS_PHYSICS solved the severe jittering of rigidbody itself.

---

I'm about to sign a deal with a publisher with my game that I made with Godot and because of the jitter I might have to move all my codes to Unity. Time and cost to move all the codes put aside, I'm reluctant to switch to different engines because I really like the design philosophy of Godot and Godot itself.

I also noticed that in 3.1 'Physics Jitter Fix' option has been added in the settings menu ( https://twitter.com/reduzio/status/984783032459685890 ) but that doesn't seem to help solve the issue.

[Ploppy3]

Did you try without spamming the console? It can have a pretty significant impact.
As example: remove the print(...) line 15 of your character.gd

Edit: On my side, I can clearly see it stuttering with the print calls, and not without them.

[di-kang]

@Ploppy3 Yup I tried without it. I wish the solution was that simple... I really don't wanna switch to Unity.

[Xrayez]

This might work better when exported, maybe try to experiment with Vsync in project settings. If you have dual monitor setup with different refresh rate this could impact stuttering in my experience. In my case it would work smoothly on 1st monitor, while stuttering happens while debugging the game on 2nd monitor, for instance.

[di-kang]

@Xrayez I read comments on different threads about turning on or off Vsync making the issue disappear or at least less severe but in my case, it didn't make any difference.
The only thing that seemed to make it less severe was setting physics fps to higher than 60.#17823 (comment)
But it didn't make the issue disappear and the difference was negligible.

[eon-s]

@diiiiiiiii can you try with 3.1 beta? there were many fixes in KB2D, Camera2D and Viewport, also the Camera has a new update mode (physics) in the properties which may help on some cases.

[di-kang]

EDIT: Changing the process mode of the camera to CAMERA2D_PROCESS_PHYSICS solved the severe jittering of rigidbody itself.

@eon-s Yeah I've been testing with 3.1beta2. And it did fix the jitter of moving object itself when camera smoothing is on. But unfortunately overall stutter is still there.

[eon-s]

As a workaround while this is being investigated, the camera with smooth issue could be replaced by custom code to move the viewport and make a smoothing that moves and rounds positions on physics process.

Related issues (some comments may mention other workarounds):
#2667
#16918
#17823
#23758

[eon-s]

Wait, I think I have read it wrong, smooth enabled fixes some jittering?

[sicienss]

I am working in 3.1 beta 2, and thought I'd share my experience.

I notice periodic stuttering on my background when I am running in windowed mode in my native resolution (640x360), but it is perfectly smooth in fullscreen. There is a stutter about every half second.

I also notice that the FPS while windowed oscillates between 58 and 59, but while in fullscreen it is a smooth 60.

Changing the camera's process mode has no effect.

Not sure if this is related to the reported issue.

[eon-s]

Tested the sample project, got some stuttering on the background (Ubuntu, R5, godot 3.1b2), irregular and it do not seems to be related to physics, looks more like a floating precision issue because zoom is low, motion is also slow...

[sicienss]

I also tested the sample project (Window 8, Intel HD Graphics 4600, 3.1b2).

I also noticed stuttering on the background. For me, it was more pronounced and happened about every second. Commenting out the print() line didn't help.

When I put the test project in fullscreen, I did not notice the stuttering.

Tried to screen capture, but the quality isn't very good, so I'm not sure it'll be much help.

[eon-s]

I was playing a bit with refresh rates, with vsync off forcing fps to match the monitor (60 and 40) the stuttering was gone, could it be possible that the engine is not taking the correct vsync values or not applying it?

[girng]

i changed _physics_process to _process and removed print, seems like jitter is gone for me
OS; w10, 64-bit, 144hz monitor (gtx 950)

if you are still having this issue and don't want to move to unity... i recommend using _process and custom camera movement underneath it (if the camera2d node is the culprit, however, it should work fine there's been some work on it lately)

and yeah if i run it using physics_process it's insanely jittery (non playable)

[sicienss]

@eon-s , I tried this as well, in both the sample project and my full-scale project.

I disabled vsync and hard-coded the FPS to match my refresh rate (60 Hz). It pretty much got rid of the stuttering!

I wonder why this is. As I mentioned before, when vsync was enabled, I never noticed the stuttering in full screen—only windowed. Could it be that vsync is working properly in full screen mode but not in windowed mode?

[di-kang]

RigidBody2D, _physics_process(), apply_impulse(), camera smoothing on

https://youtu.be/MGMlhl0tPTA

@eon-s Camera smoothing is enabled only in the last code example. And unlike the stutter of entire screen or objects, which occurs in all code examples, when camera smoothing is enabled the moving object(RigidBody2D, KinematicBody2D, etc.) itself jitters back and forth viciously. And changing the process mode of the camera to CAMERA2D_PROCESS_PHYSICS solved the jittering of moving object itself but not the overall stutter.
And I'm sorry if I made any confusions. English isn't my first language.

Tested the sample project, got some stuttering on the background (Ubuntu, R5, godot 3.1b2), irregular and it do not seems to be related to physics, looks more like a floating precision issue because zoom is low, motion is also slow...

Since the issue remains even without the camera, I don't think it's related with zoom.

---

KinematicBody2D, _process(), set_global_position()

https://youtu.be/YVFtkbuyqEQ

@girng In the third code example, _process() was used instead of _physics_process(). I haven't tried the custom code for camera movement though. Yet again, it happens even without the camera.

---

@sicienss I read several comments in related threads about fixing fps and I tried fixing it to 60 and 40.(Whether Vsync is enabled or not didn't matter) And it seems like when fps is fixed to 40 or lower, stuttering happens a lot less frequently. But maybe it's because fps is too low and it becomes difficult to notice the stuttering. And also in my case, couldn't find a noticeable difference between full screen mode and windowed. But I'll test that again for just in case.

EDIT:
Test: Fullscreen
Test: 40Fps, Vsync-False
Test: 60Fps, Vsync-False
Test: No Camera2D
Test: 40Fps, Vsync-False, No Camera2D

[di-kang]

(Fps has been fixed to 60 in the settings)

I'm not sure this is normal or even related to this issue but 2nd and 3rd process delta spikes happen when the object starts moving. Is it normal to see that kind of spikes in a simple project and everything has finished loading before the movement?

[behelit2]

I'm having same problem diiiiiiiii is having in his move_and_slide use case.

2D project with kinematic characters
Godot 3.0.6
Win10 64bit
Intel i5-2550K CPU
16gb ram
Geforce GTX 970

[reduz]

Just as a side comment, you can use move_and_slide in regular _process now in 3.1, this can fix many jitter problems of having to use it in _physics_process. Although this nowadays seems it's not much of a problem.

Also stutter is most of the time OS related. When you go full-screen, both OSX and Windows give your process more priority so it gets interrupted less. If you don't see stutter full-screen, it sounds like some background task is the culprit.

Also, removing the print, I don' t see any stutter at all in your demo under X11. On Windows, I see occasional stutter (background task most likely) when windowed and nothing at full-screen. This is perfectly expected.

[behelit2]

@reduz I have seen the same results you have with X11, it runs flawlessly. However, I don't think it's wise to quickly blame the problem on background processes in Windows and OS-X. After all, 2D games in other engines/frameworks (Unity, XNA, etc) run flawlessly in Windows and OS-X without any noticeable stuttering. That tells me there is something those other engines are doing right, that Godot is doing wrong. Thus, it could be OS related, but also Godot related as well. Is my logic incorrect here?

[eon-s]

@reduz can you give more details about using move methods outside physics process? That may need to be documented and mentioned in tutorials too.

Ping @kidscancode @GDQuest

[reduz]

@behelit2 I don't know. If you or anyone else wants to investigate, here is something I suggest trying:

• Try making a similar project in Unity, XNA or whatever you like
• Try running this project windowed in both DirectX and OpenGL (I think you can use OpenGL on Windows in Unity)
• Investigate the priority of the running process in the task manager (go to details).

Let me know if you see anything odd.

[reduz]

On Windows, If I force the priority of this demo above normal or high, stutter goes away completely too. I Wonder if other engines to do this somehow.

[di-kang]

@reduz I was about to write a similar point that behelit2 has addressed. Even my Mac is a very low powered machine, it runs simple 2D games quite well without any stutter, in full-screen mode or not. And this example project is way much simpler(almost empty) than those games.

On Windows, I see occasional stutter (background task most likely) when windowed and nothing at full-screen. This is perfectly expected.

So it's a bit difficult to agree with you on expected stuttering on simple 2D project like this when it's not on full-screen mode.

Also as I mentioned above, it happens on ios(including iPad pro) as well which handles Fornite without a sweat.(But to be fair I haven't tried the example project on iPad pro. Only my full game. I'm planning on testing the example project on iPad pro tomorrow or so.)

[reduz]

@diiiiiiiii I tried your demo on Windows on high priority and stutter goes away when windowed. Apparently changing the priority manually is possible on Windows:

https://forums.ogre3d.org/viewtopic.php?t=83225#p518528

I am not so sure it's possible in OSX, though.

[eon-s]

What about forcing high performance settings on the GPU? maybe godot is detected as a regular app and the OS optimizations try to reduce the resources used by the program.

[reduz]

@eon-s I dont think this is GPU related

[reduz]

@diiiiiiiii I raised the process priority on windows, apparently it can be set to above normal (not high or critical). This got rid of the stutter for me (though it still does a bit of stutter for 3/4 seconds after loading, then goes completely smooth).

If you can build from master and test, let me know if it helps. On unixes doing something like this is impossible (though I see no problems on X11). Maybe OSX has something similar, but I don' t know much about the platform.

I personally never seen jitter/stutter on Android or iOS. Please test this with Godot 3.1, which fixes some jitter issues in all platforms.

[reduz]

For OSX there seems to be a really strange OS bug in fullscreen and the fix is pretty hacky. It affects most engines and libraries. If anyone with OSX wants to investigate and try any of the solutions mentioned here, feel free:

glfw/glfw#772

[reduz]

@diiiiiiiii I know that article, and also was familiar with that problem, but there is nothing that can be done in OpenGL (and platforms like iOS and Android). This is why I asked you guys to test the same thing in Unity (in GL vs DX) and why I mentioned that port to Vulkan may definitely help, as you have more control over the swapchain.

Still, process priority does have an influence on stutter, which is why on Windows-fullscreen you see it less.

[di-kang]

@reduz Yeah. Process priority did work for me, unlike full-screen mode.
I will try to test it in other engines. But due to my inexperience in Unity(since it could lead to inaccurate test results), I'd prefer someone else would do the test or make the test project in Unity.

[behelit2]

@reduz Sorry, I haven't had time to test and won't be able to get my hands on a Windows box until tomorrow. But I read that article that diiiiiiiii shared and now I'm intrigued. Could there be a miscommunication between the CPU and the GPU, causing the behavior shown in the article? This seems not only possible, but highly likely. In fact, it's the most likely explanation I've seen. Could it be... That (OpenGL/Multi-platform) games with no stutter are "cheating" a bit? I quote from the article:

"What happens here is that the game measures what it thinks is start of each frame, and those frame times sometimes oscillate due to various factors, especially on a busy multitasking system like a PC. So at some points, the game thinks it didn’t make 60 fps, so it generates animation frames slated for a slower frame rate at some of the points in time. But due to the asynchronous nature of GPU operation, the GPU actually does make it in time for 60 fps on every single frame in this sequence."

Is there any way we could test that? Disconnect the "timing shenanigans" and just pretend it's always going to run at 60fps no matter what? Because, lets be real here. With the speed of computers, multiple cores, test projects that only use 2% CPU time, and the other 97.9% of the CPU is free? THERE IS NO WAY it's interfering processes. I have never seen any games with a default process priority above normal.

[reduz]

@behelit2 The problem is that the time elapsed between frames in the logic side is not necesarily the time between frames being presented (screen hz). The right solution would definitely be to get this timing from the GPU driver, or have more control over swapchain to get more precise timing (afaik what you do in DX12 and Vulkan). Then again, not possible in OpenGL.

[starry-abyss]

@Ranoller

My opinion is that we need to stop the stutter test with the "Simple project" (testing if a sprite moving in screen stutters) because this stutter is gone when the project becomes more expensive for the CPU and the GPU, and we need to focus in the stutters that happends at the beggining of the execution, every x seconds in the execution, the focus gain- focus lost stutters, and the stutters asociated with the camera, physics, etc.... because at the end this kind of stutters will be the problem that final user will experiment...

I think that this statement is contradictory. To repro most those stutter/jitter types one by one, I think it's worth it to find a minimal project which clearly decouples one case from another ones (e.g. for that other thread's project I have a stable workaround, while for this one it doesn't work) - or a clear idea what OS/hardware set up is required to repro.
Some cases are impossible to solve (or impossible to solve universally), like in the Talos Principle article (BTW, Talos Principle has that camera move freeze issue for me in Vulkan beta mode - not article one, but shader one), but not all of them.
That said, let's allow dear developers to make a 3.1.0 release first...

[Ploppy3]

@reduz Even though I don't run into the jitter issue at all while in full-screen, I run into the stutter one which I explained quite in detail here ; you may have missed it. I would like to get your opinion though. I can give you more information and can do more tests if you want.

[Ranoller]

Win 7 without aero doesnt stutter in full screen. With aero can stutter. (it's seem that aero doesn't allow real full screen)

Win 8+ to win 10 can stutter full screen or not.

This stutter should be gone by doing an intensive project except multitasking interferences , more that one opengl aplication execution, godot editor rendering with the game, other godot instance execution, etc.... some times other godot instance can increment the processor/gpu requirements and magically the stutter is gone. There are now a bunch of issues that test this things. (Are referenced here and there)

[Ploppy3]

This is what the profiler gives me when it spikes:

https://i.imgur.com/yCIkwfq.png

Spike:

Followed by extremely low values (probably to counter the spike):

Other than that the graphs are constant at 16ms

NB: I just did a fresh start on Windows so my PC can't be any cleaner.

[eon-s]

@Ploppy3 that spike is usually the debugger itself, when updating the remote inspector and other stuff, you may be able to get some data in a exported debug game with Performance class to exclude editor interference and drop in a log file to check if the spike is there too (still may produce its own stutter if not in release mode).

[Ploppy3]

@eon-s As I explained in my original comment the stutter is there too when exported, so it's in no way related to the editor itself.

[Ranoller]

An stutter caused by a excesive large frame should be fixable inside godot or inside your own code...

[starry-abyss]

@Ranoller What you describe sounds like a compositor problem. Windows compositor uses v-sync too, and requires some workaround (like #19783 (comment)) to delay the game's frames. Otherwise, in my understanding, the compositor will sometimes take previous frames of the game, and sometimes - new ones.
Aero is the compositor, and in Win 8 and above it can't be turned off. But it's not an option to turn it off anyway, because for me on nvidia it stops using v-sync then, and all windows are vertically teared (not only one game).
The "intensive project" you're talking about, I guess, just naturally happens to delay frames after v-sync.
Pity, that for MacOS it's OK to include some hack for v-sync straight away, and on Windows we argue about "going only the right way", but some time we'll get there hopefully. :)

[plucian]

I tested the project on an intel 4570 (3193 Mhz) and integrated IntelHD 4600 card, Windows 10, RC3.
Stutters. Less on Full screen. I'm working on a similar game, the problem is even worse and it happens on Android too.. Maybe because large frames (2x screen) ? I'm hoping the problem will decrease as the game gets more complex..

[RaXaR]

I found the video options in the emulator RetroArch very intersting, here's a screenshot:

They have that wavy graphic in the menu background and I haven't seen it jitter or stutter once, in either fullscreen or windowed mode. I think those guys got it right. Notice all the Refresh Rate, Frame Rate and VSync options. Might be worth a look/chat with them?

[bruvzg]

My Monitor refresh rate is at times somewhere at 59.3Hz-59.9Hz

AFAIK VESA video timings (CVT) standard defines "nominal vertical refresh rates" (30Hz, 60Hz etc.) and "video optimized vertical refresh rates" with additional 1000/1001 multiplier, which gives 59.94Hz (to match NTSC 59.939Hz rate).

[Disputer]

Can't get rid of stutter/Jitter in the simplest platformer (((

• Actual Godot version
• Use Camera2d
• Base parallax background
• FTP always 60
• GLES3
• Testing on iphone 6/XR and problem is the same.

https://youtu.be/44-eq7n6hkE

Please Please help!

[Disputer]

I think this could be a reason:
https://dmtopolog.com/cadisplaylink-and-its-applications/

[golddotasksquestions]

I'm sorry I can't really contribute to the solution, but I feel the need to point out that this stutter has been incredibly annoying for me ever since I started using Godot. I am not publishing anything yet, so I was hoping for a solution by the time I would. I started using 3.0.6, but the problem exists in 3.1 and 3.2 beta1 for me just the same.
I do think it is a rather big problem, because even using nothing but the a blank project and the proposed movement code in the KinematicPlayer2D documentation tutorial, the stutter is impossible to miss. It becomes even more obvious if you increase the speed variable a bit (250 -> 600):

extends KinematicBody2D

var speed = 600
var velocity = Vector2()

func get_input():
	# Detect up/down/left/right keystate and only move when pressed.
	velocity = Vector2()
	if Input.is_action_pressed('ui_right'):
		velocity.x += 1
	if Input.is_action_pressed('ui_left'):
		velocity.x -= 1
	if Input.is_action_pressed('ui_down'):
		velocity.y += 1
	if Input.is_action_pressed('ui_up'):
		velocity.y -= 1
	velocity = velocity.normalized() * speed

func _physics_process(delta):
	get_input()
	move_and_collide(velocity * delta)

The article about fixing the stutter is simply false. Even in this minimal setting the stutter is appearing every few seconds on Windows, be it when played from the editor (windowed AND fullscreen), when exported (again windowed AND full screen).

In my projects I use velocity = move_and_slide(velocity) and various different Input code, but the stutter is just the same as in a blank project with the tutorial code above.
I really wished I would not have to wait to publish until 4.0. Who knows what new bugs 4.0 will introduce to my project? How much work it will be to transfer my project to 4.0?
I wish this stutter would have much higher priority.

3.2 beta1 minimal (incl win export): godot32beta1_stutter.zip

[Calinou]

@golddotasksquestions See discussion in #19783. As you can see, this isn't an easy problem to fix. There's a pull request open at #33414, but it needs further testing. I'll try to upload compiled Windows binaries for testing (with and without the PR commit included).

[Calinou]

I'll close this as #33414 has now been merged. We may enable that setting by default once it gets more testing.

[starry-abyss]

@diiiiiiiii Can you please confirm the new feature from the PR above helps with your issue, or is this an unrelated case?

[di-kang]

@starry-abyss Sorry, I haven't had the time to read the thread nor to test new versions for a while, but I will try to do those when I get the time.

[starry-abyss]

No worries, I just wouldn't want this issue closed unless it's really solved - in the name of jitter progress!