Godot: Heavy stuttering issue in simple 2D game [Windows 10, Nvidia]

[crystalnoir]

Godot version:
Godot 3.1-dev / Godot 2.X

OS/device including version:
PC - Windows 10, GeForce GTX 1060 6 GB, 16 GB RAM.

Issue description:
Stuttering / jitters when moving a 2D Sprite. Reproduced on 2 computers (with nvidia graphic cards, the one above and a laptop), a friend of mine reproduce this issue too.

Steps to reproduce:
I just download the "First project" that we can make in the documentation. I have tested to reproduce the first part of this tutorial to only have the player and nothing else. If I run it without change anything. I have some stuttering at the same as the game run with 60 FPS. The motion is not smooth. I collaborate with a dev to try to reproduce this problem and try to understand the issue. I have made a lot of test (Run from editor, run after compilation without debug mode etc...But when I deleted the animation, all run smoothly.

PS : it seems that physic behaviour make sprite stuttering too (try with kinematic and Area2D node with collision). If I desactivate collision and replace Area2D with a simple node2D there is no stuttering (if I don't play any animation on the player).

Minimal reproduction project:
Here's a minimalist project (that comes from the first game project of the documentation). If I run it, I have some stuttering. If I delete the player animation I have no more stuttering.
FirstGame.zip

[crystalnoir]

Hi, I have updated my report because I tested it on my other computer (home) and the issue is here at the same as I change the animation. So, this is not the animation that causes the issue. I think I believed it because when I saw that it was on my laptop, it has a small screen. Here's a video of the issue (the video is at 60 FPS) :
GodotStutter.zip

[akien-mga]

If the video is an accurate representation of what's on screen in real time, then it's a hell lot more stutter than I've ever seen mentioned in any stutter-related issue here. There must seriously be something wrong with this Windows 10 / GTX 1060 setup (I see quite a few articles on the Internet detailing performance issue on Windows 10 / Nvidia after major Windows updates, but can't tell if it's related).

[akien-mga]

Here's a video of the test project on my system, Mageia 6 x86_64 (Linux), Nvidia GTX 670MX with recent proprietary drivers (390.59). No stutter at all (on Openbox - on KWin the compositor messes things up and there's a very light stutter every 10 s or so).
StutterTest_LinuxNvidia_OK.zip

BTW here's a fixed version of the demo project firstGame_fixed.zip, the original one had files split over three different folders somehow ("firstgame", "firstGame" and "FirstGame").

[Zylann]

The game gives me the same amount of stuttering as in the video.
However, turning vsync off gets rid of the stuttering completely (but the game runs at 4000 fps).
Windows 10 64 bits nVidia GTX 1060 too here.

[RaXaR]

I also tested as @Zylann suggested here and got the same results. I too have Win10 x64 and nVidia GTX 1060.

Edit: I use these drivers from nVidia:
398.11-desktop-win10-64bit-international-whql

[Ranoller]

Win 7 64 bit GLES2 and GLES3 tested, GeForce GTX 660/PCIe/SSE2... no stutters. Turning on Aero, with the 2d editor of godot behind the game results in some little stutter (Godot editor render interfere with the rendering of the game).

However, Godot stuttering is the giant invisible enemy, we all know it is there but we do not want to look very closely because we know that the solution is not simple.

Your issue seems like different physics fixed fps with monitor refresh rate, i see this kind of stutter in monitors that have not same hz that editor configured physics fps, but can be other thing.

[Zylann]

Your issue seems like different physics fixed fps with monitor refresh rate

The demo doesn't uses physics, only a simple _process.

[Ranoller]

True... i say that i only see that heavy stutter in this case, but it´s true that there is no physics process involved. I test changing hz of one of the monitors and no differences, 0 stutter in my gear.

Edit: I got win 7, win 8.1 and win 10 in this computer and take the time to test all. No stutters in win 8.1. I´m testing in win 10 now and is very smooth... no windows problem. Godot is angry with your 1060?

[crystalnoir]

Here's the same test with my laptop. As you can see the problem is here too. But it seems that's less visible but it's here.

Laptop Specs : Windows 10 - Geforce 940M

Here's the Laptop video (it's a 60 FPS video) :
GodotStutterLap.zip

[Ranoller]

Can anyone with the stutter problem try to execute the demo changing in Player.gd _process with _physics_process?

[crystalnoir]

I will test this evening on my home PC this is where I have the problem all the time. But I have a weird thing : This morning, I gave you a video with the project on my laptop and as you can see you have the same kind of stuttering. The problem is that now, if I run it again I don't have this stuttering again, like it's random. And I didn't change anything on my laptop, I worked on it all the morning on a TSE session.

Warning : I talk only for my laptop. On my home PC with GTX 1060 the problem is always here. But on my laptop the problem seems to occur randomly. That's why I think that for now, I will let my laptop on the side for testing purpose and I will test only on my home PC that have the problem all the time, to be able to isolate the "bug".

[RaXaR]

@Ranoller I tested it and got the same result. The stutter is still there and it pretty much looks the same.

[crystalnoir]

@Ranoller Made the test and the same à @RaXaR that doesn't change anything. Got the same problem.

[Ranoller]

This not look well....

To exactly specify the bug I would do this tests:

1) Full screen on - off
2) If more than 1 monitor:
Disable- Enable shared desktop
3) Aero on-off

Your cards run well other games? ...

Reading the first post about the animation -> stutter / no animation -> no stutter i read the code and i see some stuff that i don´t think it´s correct... exactly: changing animation every frame. I think that code should check current animation. Probably it didn´t change nothing, but if someone want test to change Player.gd in this way:

extends Area2D

# class member variables go here, for example:
# var a = 2
# var b = "textvar"
export (int) var SPEED #How fast the player will move (pixel/sec)
var screenSize #size of the game window
onready var AnimSprite = $AnimatedSprite


func _ready():
    # Called when the node is added to the scene for the first time.
    # Initialization here
    screenSize = get_viewport_rect().size
    #Engine.target_fps = 60
    pass

func _process(delta):
#   # Called every frame. Delta is time since last frame.
#   # Update game logic here.
    var velocity = Vector2() #Player movement vector
    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
    if velocity.length() > 0 :
        velocity = velocity.normalized() * SPEED
        if !AnimSprite.is_playing():
            AnimSprite.play()
    else :
        if AnimSprite.is_playing():
            AnimSprite.stop()

    if velocity.x != 0 :
        if AnimSprite.animation != "right":
            AnimSprite.animation = "right"
        AnimSprite.flip_v = false
        AnimSprite.flip_h = velocity.x < 0
    elif velocity.y != 0 :
        if AnimSprite.animation != "up":
            AnimSprite.animation = "up"
        AnimSprite.flip_v = velocity.y > 0

    position += velocity * delta
    position.x = clamp(position.x, 0, screenSize.x)
    position.y = clamp(position.y, 0, screenSize.y)

This is the last idea... probably nosense for the problem, but... your graphic card is very common in players, so godot should execute well in it.

[crystalnoir]

@Ranoller

For :

• The first point : Already tried full screen or not, it doesn't change anything

• 2 : Already tried to run with only one monitor (that's my common config but I have a second monitor too sometimes, so I tried both) and it doesn't change anything.

• 3 : I have to test (should be able to do this, this evening (France Time).

• 4 : I have to test your code (should be able to do this, this evening (France Time).

[crystalnoir]

Just tested your code and it doesn't change anything :(

[Ranoller]

Although this problem may not be directly related to godot, godot must revise well stuttering issues... it´s not true that all games stutters as it was said in another thread. Today i was playing n++, full screen, windowed, trying to see any stutter and no.... no stutters at all. Same with Ori and the blind forest, to many bad things have to do to have any stutter in this game (windowed with other programs in background, etc.... and only 2 o 3 frame skips in a hour...). Godot, on starting execution, always stutter x number of seconds, later it stabilizes, but every X seconds you are going to have frame skips (if you don´t have the problem of the gtx1060 of course). We shouldn´t treat this issue as a minor problem.

[crystalnoir]

I try to do my best to isolate the problem but at my level it's a bit difficult. I tried testing different setups but without result. I also tested to but a background image instead of use a color with clearscreen. I've already seen (don't remembre witch) an engine with this problem because of rendering a 2D sprite on a "void screen" causes this problem, but it seems that's not the case here. So I don't have any idea for now.

[Zylann]

Out of curiosity, try to profile how long SwapBuffers takes in context_gl_win.cpp around line 68. If it takes longer than 16ms, then you are likely dropping a frame here.

[crystalnoir]

If someone that knows the sources of Godot could test that I'm interesting in the result (sorry for my english...)

[RaXaR]

I was playing with this issue yesterday and I it magically resolved itself after the game windows was running for about 60 seconds. Then it was smooth, this tells me that it could be a caching thing?

[Ranoller]

Out of curiosity, try to profile how long SwapBuffers takes in context_gl_win.cpp around line 68. If it takes longer than 16ms, then you are likely dropping a frame here.

Maybe could be helpful to know if the problem happends in GLES2, we don´t test that

[crystalnoir]

I tried to play with options in Godot about it, but it doesn't change anything for me, may be I don't know exactly what to change ?

Tried to let the game for more than 2 minutes but the problem is always here not solved for me after 60 s.

[meld-cp]

I had a similar issue with 3.0.3. (Win10 64 bit, Nvidia 660) I didn't notice it with 3.0.2.

I think it has something to do with the AnimatedSprite Node because I see the performance issues with levels which have this node. I get the shuttering when running from the IDE or if I export to Win 32bit, but If I export to Win 64bit everything runs as it should, no stuttering.

[meld-cp]

.. interestingly, I don't have the issue with the example project 'FirstGame.zip'... but still do with my game, FPS drops to 5 when run from the IDE and 32bit version, GPU sits about 2%... but, with the 64bit export GPU is at 30% and everything is fine.

[crystalnoir]

Hi there, is any news about this problem ? I've just tested with the pong demo (I didn't do that before, just with the tutorial game) and it seems the problem is here with this sample project too. I use the last version of Godot on Steam to test it.

Updating Nvidia drivers didn't change anything, so I come to take some news about this issue. I didn't find how to get ride of it yet.

[Ranoller]

I have now a computer with a geforce gtx 1060 (3gb- cheap) and don´t have the issue in windows 10 home. It can be some background app? Some hardware especific configuration AMD-Nvidia Intel-Nvidia....? I don´t have any game aplication in this computer (is in my music recording-studio) but godot runs smothly even with 3 screens connected to the computer. Anybody with the problem can check if have any game-monitoring software running in background, or steam, or something like this...? And if got it try to dissable?

[crystalnoir]

Difficult to turn off Steam when you use it to launch Godot...Godot runs great the problem is the game you make with. I already tried to disable all what I can disable, that changes nothing. I made a lot of tests without success. I also tried to reset the nvidia drivers for example, update them etc... but it changes nothing.

On the other side, I have a bunch of engines that run smoothly so why not Godot ? That's the thing I tried to find. But for now I don't find something. There is something somewhere but what and where, that is the question :-)

[Ranoller]

This issue is too "engine-dev-specific" to find a acceptable solution by own search. i can look for hours to the godot code and i know that never will have any possibility to find something related to this... i know that engine devs like more code new functionality and "bug-fix" is considerated more "junior-work" or something like this. But with this kind of issue is not the case. We need some engine dev to auto-assign this issue and other "complicated-ghost-low level-hard to afford" bug fixes...

[crystalnoir]

I mention that I already tried the dev version (without Steam) and the problem is the same.

[Qws]

Hi I had exact same stutter problem (using Godot 3.1 from Git source), any movement lagged for me, exactly like in your video, be it move_and_slide or just animation-player movement. but turning V-Sync on in project setting completely solved stutter problem in 2D game.

I'm kinda confused because @Zylann said turning V-Sync off removed the stuttering, but for me it's the opposite.

[Zylann]

@Qws turning it off AND making the game run at more than 60fps (which it did at the time) made the stutter go away for me but it brings other issues (using all power available and making fail everything that did not use a proper delta time). If you have stutter with V-sync off then it's either due to improper delta time or a situation where the game has to wait/process longer than a frame to update the screen.

[Ranoller]

First test that i did with new gtx 1060 give no problem... but later i experience that stutter. Only thing that i changed is the dvi to hdmi conexion (and some programs instaled)... this its a bit weird. Only thing that i convinced is that the problem is not in the windows 10 side.

[emo10001]

I will say this much. I am working on a 2D game tutorial "Hoppy Days" from the Gamedev.tv tutorials. I WAS using 3.0.2 to develop it, and it was working just fine. I noticed that the tutorial was using 3.0.4, so literally TODAY I decided to upgrade to 3.0.6. There is now a noticeable lag in the game. _The lag was not there at all in 3.0.2_. It is there now. All other settings are the same.

My Laptop is a fairly new (purchased March of 2017) Dell Inspiron 7000 series gaming laptop. Processor is 7th Generation Intel Core i7-7700HQ Quad Core (6MB Cache, up to 3.8 GHz). Video card is NVIDIA GeForce GTX 1050Ti with 4GB GDDR5. RAM is 16GB, 2400MHz, DDR4. Hard drive is a Samsung SSD. Windows 10.

To me, it very much seems like something changed either in 3.0.4 or 3.0.6.....Nothing else has changed at all. Not even the game (as in...I haven't changed/edited/updated the level at all).

[akien-mga]

@emo10001 Could you test 3.0.3? That's when we changed the buildsystem used to make 3.0.x binaries (3.0 up to 3.0.2 were built on AppVeyor CI with MSVC 2015, 3.0.3 up to 3.0.6 have been built with GCC 8 via MinGW).

If your laptop has Optimus/switchable graphics, it could be that your system whitelisted the 3.0.2 binary to be used with the Nvidia GPU, while 3.0.3+ would default to an IGP. Or it could be that 3.0.2 was whitelisted by your antivirus while 3.0.3+ are seen as coming from a different source (which is true) and not yet deemed as safe, so the antivirus would run its full checks and impact performance.
Those are only guesses, but otherwise I'm not sure what actual Godot change would impact performance like that, so I can only think of buildsystem changes.

CC @hpvb

[aaforcebox]

I'm having the same problem! My project stutters for 20 to 30 seconds, then runs smoothly afterwards. I downloaded the project in OP post and it is the exact same thing.
Turning V-Sync off removes the problem, and it runs at 4000+ fps.

I'm running version 3.0.6 on Linux Mint 19 (so I guess that windows tag is innacurate, eh?) and GTX 760 with latest proprietary drivers.

[akien-mga]

I'm running version 3.0.6 on Linux Mint 19 (so I guess that windows tag is innacurate, eh?) and GTX 760 with latest proprietary drivers.

No, but this is likely a different issue. Stuttering on Linux often happens due to window manager's compositing (for example I have some with KWin, none with Openbox).

[Ranoller]

My project stutters for 20 to 30 seconds, then runs smoothly afterwards

I notice this a lot, if i execute scene that i´m editing, there is stutter and some tearing (with vsync on) about 15-30 secs, but if i start project from main menu and open the scene with the scenes-selector... well, there is no stutter in the same scene (there is eventually, but not ever). There is some explanation about this event? Godot? Windows? How many frames are necessary to stabilize reproduction?... it will be great to know that things because there are necessary to the game-design.

[aaforcebox]

No, but this is likely a different issue.

Hmm, I see. What I meant is, this specific issue is probably multi-platform as many people are experiencing the same problems.

[jaredtjenkins]

I've been messing around and noticed that two kinematic bodies stutter exactly at the same time, for both move_and_slide() and move_and_collide().

Hooking a camera up to one as they both oscillate, everything in the scene stutters except for the two kinematic nodes. A static camera shows only the two kinematic nodes stutter.

It doesn't seem to matter what graphic settings I change, nor _process or _physics_process. nor does using a different delta variable.

[Ranoller]

I think that this project is not representative of real use... more complicated projects runs a bit smooth. I think that windows don't handle well an excesive large godot idle time... I found another related issue, not only for godot but it suffers a lot with that: in multimonitor with extended desktop game is more smooth in monitor 1 if this is taged like "primary monitor". If primary monitor is other that 1 there is stutter in secondary monitor ( youtube suffer from that to, but not unity commercial games like ori). With full screen in secondary monitor, aero in win 7, and monitors swapped (ej: monitor 2 like primary) the scenary is the worst and there is a big stutter (not only godot, but nor game maker or unity games).... i know that multimonitor with extended desktop in 2 1080p screens is hard for cheap GPUs but other games are smoother ( godot don't lose fps, only stutter). If this test will continue we should make a more complex example.

[aaforcebox]

@Ranoller my setup is a dual monitor in a gtx 760, second monitor tagged as 'primary', linux mint 19 with cinnamon. I was try to understand the specific condition the project stutters, but couldn't figure out. These small projects sometimes stutter, sometimes don't (only stuttering, no fps loss). Also, when it stutters (running in windowed, godot testing configs), I usually have one or more chrome windows in the second monitor (not the primary), and when I minimize them, the stutter is gone... after some minimizing/restoring on the chrome windows, the stuttering is totally gone.

[Ranoller]

I´ve got 2 computers -> one with i5 gtx660 2 screens 1080p and other with i7 gtx 1060 3 screens (2 1080p and other hdready)... well, i have this stutter problem related with secondary monitors in gtx660, i think that is related exclusivelly with rendering, godot and chrome stutters, game maker and unity don´t (commercial games, exactly HiperLightDrifter and Ori, i didn´t test demos or templates). Windows aero stutters more in full screen (i think is not really full screen) but have very much fps, without aero in win 7 i´ve got in my project 130-140 fps without vsync, with aero i pass 400 fps, but... stutters (a lot) in certains conditions (with and without vsync). I can´t barelly make godot stutter in the i7 gtx 1060 (with real project, the demo in this thread stutters and i explain jet my opinion about). I think is a optimization /OpenGL problem, ej: Light2D is barelly unusable, any mix mode other than "mix" can stutter if the system is not too powerful, but godot should handle permormance in same level that game maker or unity does. Probably once 3.1 was launched, work for optimization could beggin (if problem is fixable and it isn´t a Direct3D / OpenGL - Windows problem of course... i don´t know how to find GLES2/3 games in windows to test and disccard a direct OpenGL - Aero/Win7-8-10 problem)... I understand that permormance of godot never will be the same of propietary -> one game based engines (Ej: Rayman origins runs smooth in an old laptop i´ve got, godot 2 don´t), but it should render at least at the same stable level that game maker (Unity probably will be better optimized that godot for a long time, you know, the money...). For now i feel that godot performs well only in high end hardware or in low resolution screens (I test in an i5 win7 32bit 15" intel hd graphics computer and performs good, but i don´t think that with an hd screen this computer will run´s godot smoothly)...

Of course all of that are my opinions/experiencies, i can be wrong (and i hope to be.. if this would be a simple one-line fix this could be great!!!)

[Ranoller]

On other hand i remember to read reduz writing something related to the "process priority" of the godot executable, but in windows there is not difference if you manually change the priority of godot in execution, godot don´t underperformant (whou, I have invented a word?), execution of the program doesn´t have spikes, it´s the rendering, something related with nvidia/godot and the computer desktop (i n windows, i don´t try in linux)

[crystalnoir]

Hi there, so, are there any news about this problem ? ^^ I will test again with the newest version but it seems that the problem still there.

[zhagsenkk]

does this exit in android or ios platform now？there are some games in google store made by early godot that also have shutter problem.like: https://play.google.com/store/apps/details?id=com.MoTaiGikStudio.DunkUp

[Ranoller]

This exist in all tested platforms in certains circunstances, with diverse GPU´s and diverse operating systems... is not documented in consoles.

[MightyPrinny]

I tested it on both linux and windows and it ran smoothly with the ocasional small stuttering, I have a low end integrated intel hd graphics baytrail graphics card

[meld-cp]

After many hours of trying to figure out the cause of the stutter, in my case at least, I by chance tracked the consistent 1s stutter down to having the 'Auto Switch To Remote Scene Tree' enabled in 'Editor Settings'. Unticking this resolves the stutter and performance issues for me. (there is possibly a very slight stutter still, but it's barely noticeable.)

Godot build 8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64bit, NVIDIA GeForce GTX 660, driver v416.81

[behelit2]

I also have the stuttering issue with my game. The only thing that seems to make it better is switching full screen off and on while the game is running... And even then there is a slight stutter that creeps up afterwards. Seems to happen completely at random. Sometimes the game will run near perfect, other times the stuttering occurs.

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

[Ranoller]

In win 10 stutters happends more in full screen, and is because Aero (And can be disabled). It´s seems that Godot uses less CPU and more GPU with windows Aero but this provoques more stuttering. In windows 7, disabling windows Aero, full screen have less stutter that windowed and uses more CPU. I think that win 10 doesn´t have real full screen....

[linkoboy]

I've began to make a prototype pinball 2D game and I have me too jittering in the movement of the ball, I've only a rigidbody that falls with gravity. I'm on Win10 / NVidia GTX 560 Ti 1Go (with latest drivers) / 8 Go Ram, my computer is not the best but my project has only a ball and StaticBody2D for the borders and I can see clearly jittering happening very often, I've tried with and without vsync, with opengl 3.0 and 2.0, windowed and fullscreen, with more and less physic fps, the problem is still here.
My Godot version is 3.1 alpha.
I think it's a major problem, maybe hard to fix but that must not be skipped, it's important to have a smooth 2D movement for a 2D game.

[Ranoller]

You are right, Godot has now the better usability of all top engines (my opinion of course). Usability side beats them all. But...... performance side.... exporting side.... it´s like godot was beating with the operating system, not like unity or game maker exports that are more fluid (until construct in chrome is more fluid), and is not because gdscript slowness (happends with and without GDScript), there is "other indetermined thing", i hope one day someone can find one rebel line in a cpp file and changing one simple "!" this problem will be fixed... (hope is free like Godot!)

[linkoboy]

I've several projects in mind and I'd love to make them with Godot, it will take a lot of my time (to not say all of my free time), but it saddens me to say that if the engine can not guarantee a smooth 2D movement in the animation with a simple scene, the engine despite all this pros is simply useless. In this case perhaps the wisest choice for me is not to risk to lost time in this way.

I understand that this issue appears only in some configurations (Windows 10 and NVidia drivers for example) but I'd like to know :

• Is this issue (or similar one) already planned in a milestone or not ?
• Is this issue maybe put aside waiting for the replacement of OpenGL by Vulkan in milestone 3.2 ?

PS : I've tried with another pc :

• Intel i7 4790K 4.00 Ghz
• Win10 64 bits 16 Go RAM
• NVidia GTX 1060 3Go (with latest drivers)
• Godot 3.1 alpha official
  and I've the same issue with simple scenes.

I think these sort of PC configurations (Win10+ Nvidia cards) are very commun, and I hope that the Godot community (that make a great job by the way) will fix this issue very soon and that good 2D games will start to release to show that we can do with Godot but with this sort of issue for me it's simply impossible.

[behelit2]

Maybe it's some sort of program focus issue? When I start a game in full screen, I see the stuttering basically every time. But if (while the game is running) I switch to windowed mode and back to full screen, it seems to run perfect every time. If I have too, I can program this to happen automatically, but it seems janky. Can anyone else confirm switching from full screen, to windowed, to full screen again fixes the stuttering?

Edit: Oh and another thing... When I disabled the Geforce Experience app, things seemed to get better.

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

[linkoboy]

I tried what you propose, I've disable Geforce Experience, tried switching from fullscreen, to windowed, to fullscreen again, with vsync enabled and disabled (it's worse with vsync disabled) but the stuttering appears always unfortunalety for me.
It's pretty random but I've never exceeded about 15-20s without stuttering.

[behelit2]

Thanks for trying! That's so weird, your specs are better than mine. The problem with me is, it's so random... It's hard to reproduce precisely. Sometimes it will run great, other times it will stutter. I'm fairly certain it's something to do with Godot itself, however. I never experience stuttering in games made in Unity, or any other game engine for that matter.

[nausika]

Just noticed this stuttering.

(Godot 3.0.6, Windows 10, 64bit, i7-8550U, 16GB RAM, NVIDIA GeForce MX150)

As others already mentioned, this is a serious issue for Godot. This week I decided to create a prototype for a very simple game. I searched for a framework or engine (found quite a lot of them) and decided to go with Godot - since it's free and open. Then I noticed the stuttering, found this issue - and was surprised that there seems to be no progress. I guess I'll prototype my idea in Godot anyway. But if I wanted to create a releasable game, I would probably try another engine. (This sounds too harsh... I just think, Godot might lose a lot of potential adopters if is problem isn't fixed.)

[Ranoller]

There is no progress because there is no one working on this, and yes, it is a serious issue. But for now, if you need to release comercial game, you can prototype in godot and port to unity (you can use C#). You need have in mind the scene-gameobject- component approach and you can replicate in godot and if works go to unity for fluid flow and performance, or if is 2D go to gamemaker. I'm working in a plugin to try to convert a godot project to other engines and try to port gdscript to a module, to gml or to unity C#, but is a very huge task (i don't know if the effort is worth it, too much time not working in the game) and allways will be imperfect (i can' t get all types, ej: object returned by collision). I have a little parser for the scripts and will start a parser to tscn and tres, but convert the parser result of gdscript to unity c# or gamemaker GML requires a ton of code and i don't know the "legality" about this (i need all api names ej. in json files and don't know about the IP of this). Animations are other problem, i don't know for now how to approach that, but using spine/dragonbones will do easy to port. My main idea of doing that was start in godot and end in unity or gm, but for niw is a headache... If unity was equally portable (i need that),tiny and quick to develop like godot (and have a 32 bit editor) I did port my main project months ago, i love godot but for a middle size project in a small team (or single man like me) is a risk, no one garant to you that a finished project will not give a ton of problems. But if there is a good C++ programmer in your team is other thing, you can allways adapt godot to your game (in unity you can't, but is less buggy)....
I hate this issue like i hate the low performance of the editor in a mid project and the exported game, but i hate more unity ( why i need internet in all computers to open the editor? I have one computer without that!) and hate so deeply visual studio... i,m sure that if godot stops the stuttering and works on performance and export, we can start to see great upcomming games.

[Zylann]

To recheck this issue today, I did the following, still on Windows 10 with nVidia GTX 1060:

I opened The Binding of Isaac, windowed mode. Ran in circles, no stutter (by this onwards, I mean for at least 30 seconds). I don't know if the game has V-sync or not though, it has no such setting.

I opened Minecraft, windowed mode. Loaded a flat world looking at the ground where lag would be inexistent, no stutter.

I opened Factorio, still windowed mode, with a pretty large end-game factory. Ran in a straight line, no stutter. However, V-sync is off. If I turn it on and restart the game... still no stutter.

I opened an old Java game I made using Slick2D (OpenGL), not a single stutter (I have yet to see one Oo). Checking the options, V-sync was enabled. If I turn off V-sync, I get regular stutter every second or so. If I double framerate cap, I get no stutter.

Now, I opened a 3D project with Godot 3.1 alpha3, with a map having some assets and a moving character: almost no stutter, I can only see just one every 20 seconds maybe, which is too subtle to bother.

I also tried my 2D project Wallrider which I ported in Godot 3.0.6: same, not enough stutter to bother (random one per 20 seconds).

All these projects above have this in common: they don't just draw one sprite on the screen. They may be using a lot of OpenGL features together.

If I try @crystalnoir test project with Godot 3.1 alpha3, I get immediate, irregular frequent stutter, which only goes away if I wait for about 30 seconds after it was last shown/maximized. I tried switching to _physics_process, and even tried delta = 1.0 / 60.0, it's all the same. If I print delta, it shows that there is a fluctuation every second, but the game shows stutters multiple times per second that delta does not reflect at all. It also happens if I start the game without the editor.
I also tried porting it to Godot 2.1.5, and the same issue happens (project: Stuttering_issue19783.zip)

And now, this is where it gets interesting:
If I open both my 3D game AND @crystalnoir 's test back to back on the screen, they both run smoothly, immediately. The 2D game still stutters a little though, but not as much. If I close the 3D game, it still seem to work fine, but if I reduce the 2D game and maximize it again, it goes back to horrible stutters.

It's not the end yet!
I now tried to add a 3D camera in the 2D game. And magically, stutter is reduced drastically, and immediately, by just doing that.
You can try this yourself with PlayerWith3D scene: Stuttering_issue19783.zip
See how smooth it is by default. Now hit the magic button, see how it goes to shit if no 3D environment is shown (it doesn't always go back to shit 100% though, but I see PlayerWith3D.tscn always looks better than Player.tscn).

I would like to go further and see what happens if I change nVidia control panel from Optimal Power (the default) to Maximum performance, but... erhm...

Anyways, all I can guess from this is (but it's a guess so take it with a grain of salt): it's not directly Godot's fault. It's graphics drivers trying to be "smart".

[Ranoller]

For the god of the stutters!!! 😂😂😂

[behelit2]

Just throwing this out there... As of Nov 2018, the top 14 video cards on Steam are Nvidia. Lets look at the top cards in each GPU category:

NVIDIA GeForce GTX 1060: 14.60% of Steam users.
AMD Radeon R7 Graphics: 1.06% of Steam users.
Intel HD Graphics 4000: 1.06% of Steam users.

https://store.steampowered.com/hwsurvey/videocard/

Given the above data, it seems like this issue should take top priority. A overwhelming majority of gamers use Nvidia cards, it's the most common configuration by far. The amount of Radeon and Intel graphics users are minuscule by comparison.

@Ranoller ... You're killing me. Telling people to prototype in Godot but port to Unity for their commercial title (in a Godot issue thread) is the most ridiculous thing I've ever heard, no offense.

@Zylann I tried setting Power management mode to "Perfer maximum performance" successfully, but saw no improvement in stuttering.

[Ranoller]

@behelit2 No offense

@Zylann I put a 3D camera that render a mesh in front of a scene that renders a tilemap with animated textures and the problem of godot stuttering some seconds after gain focus is not fixed. There is not other kind of sttuter previously (only the "initial") in that scene so i don't know if this trick fix something, but is interesting you discover. I will test with you files. I think too that godot idle time makes something in the computer become "lazy", but probably is the operating system, because the differences in win with and without aero in FPS, CPU use, and stuttering are so high. Probably is the OS that try to be smart and not the graphic card.

[Ranoller]

I like the Zylann idea to analize what other games do. I don´t know if this is offtopic, but i did some test.
First of all, it seems that 95 % of steam games are 32bit (the recent releases too). It´s seems that equally percent of games renders by directx. I capture the processes that games execute and try to see what is happening with the rendering. Some info behind (Is not for have any conclusions, is only info):

Game / Executable bits / Engine / Process that uses to render in windows 7 64 bit and notes.

• HyperLightDrifter -> 32 bit/ Game Maker / Windows GDI
• Hook -> 32 bit / Unity / Windows GDI
• Nidhogg -> 32 bit / ? / Windows GDI

• Ori and the blind forest -> 32 bit /Unity / Windows GDI. Executes a process called OPENGL32 like godot but iside a kind of wrapper in Windows GDI. Not a single call from OpenGL32, all calls are from Windows GDI.
  

• Dust: An Elysyian Tail -> 32 bit / Microsoft XNA / Windows GDI. Has gameoverlayrenderer.dll and all calls are from this (ClientToScreen). Doesn´t have OpenGL dll.

• SuperMeatBoy -> 32 bit, execution inside Steam Overlay, Windows GDI

• ΔV: Rings of Saturn (demo) -> 64 bit, godot / Executes OpenGL and Windows GDI calls, do a single call to OpenGl SwapBuffers - GetPixelformat with a value of 8. Do a lot of calls to Windows GDI. Do duplicated calls? to WindowsFromDC- SetRect (window size), OffsetRect.
  

• Bastion -> 32 bit / SDL2 / Executes pure OpenGL calls, no Windows GDI, do a unique call of swapBuffers - GetPixelFormat all time with a value of 10.

• SouthPark the stick of truth -> 32 bit / Unknow engine / Executes all calls in Windows GDI, seems direct3D v 9 (has d3d9.dll but do little calls by this process), most calls are from gameoverlayrenderer of steam and uxtheme.dll that executes OffsetRect and IsRectEmpty and other window funcions.
  

• Sine Mora -> 32 bit / Unknow engine / Executes all calls in Windows GDI by steam overlay, dicect3d 9

• Apotheon -> 32 bit / Microsoft XNA / All calls in windows GDI, a single call from steam overlay (Client to screen), a single call of Microsoft XNA (ScreenToClient), and calls from a process called uxtheme.dll (window management in windows?) to IsRectEmpty and PtInrect (all booleans).
• Eggs return home -> 64 bit / Godot / Calls from OpenGL and from windows GDI, same that Ring of Saturn.
• Guacamelee! Super turbo.... -> 32 bit / Unknow engine but for the files can be similar to sine mora. This game allows resize screen./ All calls from Windows GDI.
• Not a Hero -> 32 bit /SDL2 (wikipedia says ClickTeam Fusion) / All calls from windows GDI Directx 9.
• Middle Earth Shadow of War -> 64 bit (yeah, there is one) / Intro says Firebird, nothing to now about processes / All calls from windows GDI, but, there is very very very few calls, few that in the other games, some calls per second (ej, you can barelly follow godot api calls, there are tons per second). But this game burns de GPU.

I notice that most games in focus lost stop the process and pause (maybe good practice?) and very few games allows you to resize manually the screen (ej: not a hero). Sadly i have the stuttering issue of focus lost / focus gain in ΔV: Rings of Saturn (demo).

Edit: It´s seems that godot is the only engine that uses OpenGL32 and WindowsGDI process at the same time.
App used: API Monitor v2

(Edit: Correct name of ΔV: Rings of Saturn (demo) )

[Zireael07]

If by Rings of Saturn you mean ΔV: Rings of Saturn (demo), it was built with Godot 3.1, but I'm not sure about the exact revision they used?

[paulhocker]

After many hours of trying to figure out the cause of the stutter, in my case at least, I by chance tracked the consistent 1s stutter down to having the 'Auto Switch To Remote Scene Tree' enabled in 'Editor Settings'. Unticking this resolves the stutter and performance issues for me. (there is possibly a very slight stutter still, but it's barely noticeable.)

Godot build 8849d3b
Win10 64bit, NVIDIA GeForce GTX 660, driver v416.81

I had the same stuttering issue and unchecking Auto Switch to Remote Tree was the culprit.

[diiiiiiiii]

I'm having the same problem here. There are multiple issues about this jitter but most of them don't seem to have any proper solutions and I really need some help.

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 engine 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 help either.

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
(But this issue happens 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.

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

And it seems to happen more frequently on devices with low processing powers.

Minimal reproduction project:
Godot_Jitter.zip

---

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)

[starry-abyss]

Win 7 64 bit, GTX 660 (drivers 391.35), Godot 3.0.6 and 3.1-beta1

Hey, I tweaked the original project (stopped animations, made use of rigid body instead of manually adjusting positions, added a slightly animated background, etc)

Here it is: FirstGame_2.zip

Tested with the window of size ~ 500x500 and monitor resolution of 1920x1080

Now my observations:

• Jitter is omnidirectional (not only vertical, like usual vsync issues)
• The less window size is, the more frequent jitter is
• Turning off vsync removes jitter (next bullet points are with vsync on)
• Running the game without the editor on the screen at the same time (minimize it, so it's just desktop - icons, wallpaper, taskbar and maybe some static windows like file manager or terminal) removes jitter
• Exported game or run from the editor doesn't matter
• If I run the game with quakespasm-sdl2 at the same screen (with a zombie attacking the player under water), I see little jitter
• If I run the game with a shadertoy site (this demo: https://www.shadertoy.com/view/ll3fz4), unpaused, at the same screen, I see a lot of jitter
• If I run the game with a shadertoy site, but paused, at the same screen, I see little jitter
• If I run the game with the editor at the same screen, with a scene shown in the editor not updating (Player.tscn), I see little jitter
• If I run the game with the editor at the same screen, with a scene shown in the editor updating frequently (main.tscn, I have an animated shader there), I see lot of jitter

Didn't try with Aero off, forgot how to quickly switch it back and forth?

[Zylann]

@starry-abyss to switch off aero, go to configuration panel, choose "appearance and personalization", there you should be able to change to an old theme like "Windows Classic", which doesn't feature visual effects (and then doesn't use Aero), or "Windows 7 Classic".

[starry-abyss]

OK, so with the classic theme the game, with shadertoy/editor on the screen too, goes back and forth from stutter state to smooth (each state can stay for several seconds). And stutter is accompanied with vertical frame tearing in this mode. That said, even Firefox scrolling tears with the classic theme :'D

[behelit2]

I'm having the exact same problem diiiiiiiii is having, his use case with move_and_slide is the same as mine. It you watch closely, it's not the player object jittering, but the parallax background behind it.

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

[diiiiiiiii]

Since this happens on many different kinds of devices, I don't think this is strictly related to hardware configurations. It even happens on exported games running on ios devices.

It you watch closely, it's not the player object jittering, but the parallax background behind it.

@behelit2 I'm not sure about that though. https://youtu.be/YVFtkbuyqEQ In this footage if you look at the player object, it even jiggles by itself. It may be a separate issue but it gets way much worse when camera smoothing is on or the object is switched to Rigidbody2D.

[diiiiiiiii]

https://youtu.be/MGMlhl0tPTA
This is what happens when camera smoothing is on and the object is switched to Rigidbody2D.

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.

[starry-abyss]

@diiiiiiiii I think you should have a separate issue open then. Otherwise, the thread will be full of contradictory statements because people are testing different things.
For example, I'm trying the OP project for now, not yours (sorry).

[diiiiiiiii]

@starry-abyss Got it ;)
Though there are many issues about jittering already and I think they are closely related and may have the same root cause.

[starry-abyss]

Update on OP issue. I found some options in Godot to cap the fps without using v-sync. So for me it's 60 fps with v-sync off and not ~4000 now.
And the very fact of switching off v-sync fixes the issue for me.

I wonder if v-sync makes sense in windowed mode at all. Windows seems to use v-sync by itself, and probably it fights with the Godot game who will prepare the frame faster after v-sync signal is received. Also IIRC other games only tear in fullscreen with v-sync off, and not in windowed mode.

[starry-abyss]

FYI, diiiiiiiii's issue continues here instead: #25162

[starry-abyss]

Besides the v-sync off approach, I found an interesting Windows-specific way (by the commit description it might be this issue), not sure if Godot already uses this, but maybe someone has time to try:
https://github.com/glfw/glfw/commit/8309e0ecb09fe5cf670dff5df1e7ca71821c27bd
Also this is related: https://bugzilla.mozilla.org/show_bug.cgi?id=1127151

However, there is also this thread which goes into more detail and with different approaches:
https://bugs.chromium.org/p/chromium/issues/detail?id=467617
And this is complementary, shorter and more to the point, but also with some emotions in the beginning: https://www.vsynctester.com/firefoxisbroken.html

[starry-abyss]

Changed stutter word to jitter in my above report, since that's what I experienced (see https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html).

[starry-abyss]

@ByTheQuietLake My idea was to turn v-sync off only in windowed mode (i.e. it can be done from code, even might query the monitor's refresh rate for fps cap), but since core devs don't support the approach, there is nothing to reconsider yet. :) There are other more Windows-specific ways, but we still have to prove that they work good and are not too hacky.

[MightyPrinny]

Update on OP issue. I found some options in Godot to cap the fps without using v-sync. So for me it's 60 fps with v-sync off and not ~4000 now.
And the very fact of switching off v-sync fixes the issue for me.

I wonder if v-sync makes sense in windowed mode at all. Windows seems to use v-sync by itself, and probably it fights with the Godot game who will prepare the frame faster after v-sync signal is received. Also IIRC other games only tear in fullscreen with v-sync off, and not in windowed mode.

how did you limit your fps to 60?

[starry-abyss]

Using "Force fps" field somewhere in Debug category of Project settings

Воскресенье, 17 февраля 2019, 9:25 +03:00 от FabiánLC [e-mail]:

Update on OP issue. I found some options in Godot to cap the fps without using v-sync. So for me it's 60 fps with v-sync off and not ~4000 now.
And the very fact of switching off v-sync fixes the issue for me.
I wonder if v-sync makes sense in windowed mode at all. Windows seems to use v-sync by itself, and probably it fights with the Godot game who will prepare the frame faster after v-sync signal is received. Also IIRC other games only tear in fullscreen with v-sync off, and not in windowed mode.
how did you limit your fps to 60?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub , or mute the thread .

[Ford81]

I haven't seen people posting their CPUs with systems, except for and I5-2500K which has an integrated Intel GPU.

My laptop has both an intel integrated GPU and a dedicated Nvida card. Im just wondering if there could be issue between the two gpu/drivers and godot

[AdamRatai]

Maybe. But it not look like gpu/cpu dependent. On i7 2700 + 1080ti can be stuttery (windowed) and butter smooth on mobile i5 with intel 4000 (1st gen surface pro) - in fullscreen.

[Ford81]

Funny you should say that If I run the demo project on my laptops 940m I see the stuttering. However when I run the application using the dedicated Intel 530 I see no stuttering at all.

Windows 10 home
i3-6100H CPU @ 2.70GHz,
GeForce 940M (26.21.14.3064)
Intel(R) HD Graphics 530 (26.20.100.6709)

[Calinou]

Is the stuttering visible in this project? (Move by pressing the arrow keys.)

[Ford81]

I just did a quick export leaving interpolation on and setting physics to 60:
940M there was occasional jerks but not shearing
Intel 530 there was no jerks but at times obvious vsync shearing,

I do more later, and let you know.

[victorbstan]

I have had some success it seems with capping my FPS at 60. Not sure if 60 is a magic number, my screen can support 144, I did try to set the cap at 144, but the stuttering was still visible. I lowered my FPS to 120, the stutter was still visible, but not as "blurry", which makes me think it's just occuring at a lower interval. Followed up with lowering FPS to 80, and the same result as previously, but stuttering now visibly slower. Also, I should say, I disabled v-sync and running in windowed mode, I have tested with fullscreen, but same result. Are there any processes in the engine capped at 60 FPS?

[Calinou]

Are there any processes in the engine capped at 60 FPS?

By default, physics are simulated at 60 FPS, which means that there will be a visible discrepancy when the rendering FPS is higher than the physics FPS (provided the display is fast enough to show the difference). The physics FPS can be changed in the Project Settings (Physics > Common > Physics Fps).

It can be alleviated by interpolating physics bodies, but there's no official support for this. In 3.2alpha, you can use this smoothing add-on which makes it easy to interpolate nodes.

[victorbstan]

Are there any processes in the engine capped at 60 FPS?

By default, physics are simulated at 60 FPS, which means that there will be a visible discrepancy when the rendering FPS is higher than the physics FPS (provided the display is fast enough to show the difference). The physics FPS can be changed in the Project Settings (Physics > Common > Physics Fps).

It can be alleviated by interpolating physics bodies, but there's no official support for this. In 3.2alpha, you can use this smoothing add-on which makes it easy to interpolate nodes.

Awesome, thanks, that might explain why characters stuttering as the movement is handled in the physics process call

[starry-abyss]

Still can reproduce in 3.1.1 BTW, the easiest way is with Shadertoy open in Firefox (https://github.com/godotengine/godot/issues/19783#issuecomment-455830124)

[sprite-1]

I stumbled across here hoping there would be a solution but after trying almost every advice I saw on this thread, still no dice. For me, the jittering only happens when I run the project in the NVIDIA card. If I run it using the integrated Intel GPU, it runs silky smooth. :/

I'm using the latest alpha build of Godot 3.2 on Windows 10

[MightyPrinny]

I stumbled across here hoping there would be a solution but after trying almost every advice I saw on this thread, still no dice. For me, the jittering only happens when I run the project in the NVIDIA card. If I run it using the integrated Intel GPU, it runs silky smooth. :/

I'm using the latest alpha build of Godot 3.2 on Windows 10

I don't think you can fix it on windows, this doesn't happen on linux, this might be fixed in 4.0 with the new vulkan renderer.

[sprite-1]

I stumbled across here hoping there would be a solution but after trying almost every advice I saw on this thread, still no dice. For me, the jittering only happens when I run the project in the NVIDIA card. If I run it using the integrated Intel GPU, it runs silky smooth. :/
I'm using the latest alpha build of Godot 3.2 on Windows 10

I don't think you can fix it on windows, this doesn't happen on linux, this might be fixed in 4.0 with the new vulkan renderer.

Well that sucks, doesn't the Vulkan API only focus on high end devices?

I specifically target OpenGL 2.0 so I can support low-end devices. It's kinda silly to use a very high end graphics API just for a 2D game and shut out people with lower end computers/laptops. 😕

[starry-abyss]

Sounds like a myth. Maybe stuttering from time to time cannot be fixed ATM, but the stutterware we are experiencing is a Godot-only feature.

[sprite-1]

Sounds like a myth.

What were you referring to with this?

[clayjohn]

This is a challenging issue. One the one hand I would like to personally fix this ASAP. But I can't reproduce, so there is nothing I can do. (I use Windows 10 with an NVidia graphics card)

Someone who can reproduce the issue needs to take a stab at fixing it unfortunately. :(

While it's an uncommon problem, it seems to be common enough to draw lots of people to this thread. So hopefully one of you can work on this.

[starry-abyss]

Ah, I'm always forgetting that what I experience is called jitter in official Godot doc terms.

_Does anyone know how to perfectly capture the issue in 60 FPS without buying some hardware?_
I think some people underestimate how shitty it looks, and maybe also it's a different-looking issue on different PCs.

What were you referring to with this?

The myth: "this is always like that on OpenGL (or Windows, etc). Only Vulkan can save us".

[starry-abyss]

OK, so:

1. this is a video from OBS: https://www.youtube.com/watch?v=osbJlk1XD8c The impact of OBS is that just having OBS running makes this jitter in the Godot project (even when capture is off).
2. Without OBS it's smooth until I unminimize Firefox with shadertoy in it, then it starts stuttering, but cannot capture with OBS, because 1.

[sprite-1]

Chipping in my own recording, this is done with Bandicam and for the most part this is how it performs with or without recording. As you can see, it starts out smooth but gradually starts having issues

[Calinou]

@clayjohn I think it'd be fixed by implementing physics interpolation, but reduz is opposed to having it in core for a few reasons. Still, a method was added in 3.2alpha to expose the current physics step ratio, which makes it possible to implement accurate physics interpolation manually.

@starry-abyss If you can use 3.2alpha, give lawnjelly's smoothing-addon a try :slightly_smiling_face:

[victorbstan]

Just a thought, I’s there anything useful in unreal engine or physX source to look at?

Cheers,
Victor Stan

On Oct 22, 2019, at 4:17 AM, Hugo Locurcio [e-mail] wrote:


@clayjohn I think it'd be fixed by implementing physics interpolation, but reduz is opposed to having it in core.

@starry-abyss If you can use 3.2alpha, give lawnjelly's smoothing-addon a try 🙂

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.

[Calinou]

@victorbstan We should not look at Unreal's source code, as it's not under an open source license. (It doesn't even allow redistribution to non-licensed Unreal Engine users.)

[Razzlegames]

Definitely don't lift code from closed source, but architecturally can you
not glean ideas from this? [not a lawyer]

On Tue, Oct 22, 2019 at 11:07 AM Hugo Locurcio [e-mail]
wrote:

@victorbstan https://github.com/victorbstan We should not look at
Unreal's source code, as it's not under an open source license. (It doesn't
even allow redistribution to non-licensed Unreal Engine users.)

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/godotengine/godot/issues/19783?email_source=notifications&email_token=ACCZK74IFXROY6X64Z2Z6KDQP46NVA5CNFSM4FHBBLY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEB6VJPQ#issuecomment-545084606,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
.

[Calinou]

@Razzlegames I still wouldn't recommend looking at its source code. If you ever want to take inspiration from a proprietary algorithm, you should perform clean room reverse engineering to reduce the legal risk associated.

Still, we don't need to do any of this here. The solution is to use physics interpolation, which most popular game engines use nowadays. It has some downsides (such as requiring work from the user to avoid interpolation when teleporting objects), but I think the upsides outweigh them by far.

[victorbstan]

I understand, the suggestion is to get an idea of possible avenues to find a solution, not necessarily plagiarize. I wouldn’t imagine there’s a patent of solving flickering/stuttering issues but IANAL.

Cheers,
Victor Stan

On Oct 22, 2019, at 2:07 PM, Hugo Locurcio [e-mail] wrote:


@victorbstan We should not look at Unreal's source code, as it's not under an open source license. (It doesn't even allow redistribution to non-licensed Unreal Engine users.)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

[starry-abyss]

In my scenarios Godot profiler shows perfect 60 FPS, even when I see jitter/stutter. Does this mean that the issue is not related to interpolation, or am I missing something?

My assumption was that Godot timings were implemented in a way that interferes with Windows' compositor timings (and maybe SDL does it better than GLFW Godot, hence other engines just work where Godot fails).

[Calinou]

(and maybe SDL does it better than GLFW, hence other engines just work where Godot fails).

Godot uses its own window management code, it uses neither SDL nor GLFW :slightly_smiling_face:

[TerminalJack]

I have Windows 10 and an nVidia GeForce GTX 1070 and, with the 3.2 alpha2 build with vsync enabled, have jitters when in windowed mode. Full screen mode seems fine. The problem is particularly bad if the editor isn't minimized when the game runs. The game I'm testing with uses only _process() to update positions. Because of this, I suspected that the problem had to do with a very noisy delta or dropped frames (large deltas) but that's not the case. The delta is actually rock-steady during the jittering.

Based on the research of others in this thread, I hacked-in a change to context_gl_windows.cpp to set the swap interval to 0 and call DwmFlush() in swap_buffers().

#include <dwmapi.h>

#pragma comment(lib, "dwmapi.lib")

...

void ContextGL_Windows::swap_buffers() {

    DwmFlush(); // Added this.
    SwapBuffers(hDC);
}

void ContextGL_Windows::set_use_vsync(bool p_use) {

    if (wglSwapIntervalEXT) {
        // changed this: wglSwapIntervalEXT(p_use ? 1 : 0);
        wglSwapIntervalEXT(0); // To this.
    }
    use_vsync = p_use;
}

This is based on what the glfw and Chromium projects do.

Making this change seems to fix the jitter when in windowed mode. In full screen mode, the game has tearing so the DWM is likely disabled and double-buffering via an interval value of 1 seems to be necessary. (Basically, the code needs to do what it does currently.)

If anyone else is willing and able to try this out then I would be interested in knowing how it goes.

[starry-abyss]

It looks like wglSwapIntervalEXT(0); part is the same as turning v-sync off in options.

[bruvzg]

It looks like wglSwapIntervalEXT(0); part is the same as turning v-sync off in options.

It is. 1 - enable vsync, 0 - disable, and there's also -1 for "adaptive vsync" (disable the sync on low frame rates, enable on high).

[starry-abyss]

I tested the DwmFlush() thing from above with my simple cases, on 3.1.x branch.

• It does fix the situation with shadertoy test case;
• V-sync on or off - looks the same for me (I didn't patch the wglSwapIntervalEXT() part);
• The OBS case is still jittering (looks the same I think), but Godot now reports FPS drop to 40 (I wonder if the profiler in Godot actually lies with the original Godot version);
• I also tried to call DwmFlush() after SwapBuffers(hDC), and all 3 points stay the same.

I'm not sure, but I guess DwmFlush() after SwapBuffers(hDC) might be more correct since Godot puts the frame in the nearest compositor's update, not on the next, which is after nearest.
I wonder if Godot should better detect if compositor is running and switch back to vanilla v-sync method if it's not.

So next to try will be the new interpolation feature mentioned by Calinou.

UPDATE: yes, in the OBS case the Godot reports 0.03 seconds process time (but FPS is reported as 60), probably Godot FPS counter doesn't take into account missing the v-blank every other time
UPDATE 2: sadly, the interpolation plugin doesn't seem to help here; I'm still having jitter in OBS case and stutter and/or jitter mix in shadertoy case

[TerminalJack]

It looks like wglSwapIntervalEXT(0); part is the same as turning v-sync off in options.

Correct, but adding the DwmFlush() in swap_buffers() will cause the game to use the compositor (DWM) for the syncing. When the compositor is enabled, you effectively have double buffering whether you want it or not. You would have triple-buffering in the case where you set OpenGL's swap interval to 1. (Your two buffers and the compositor's.)

I wonder too why the other projects put the call to DwmFlush() before SwapBuffers(). It seems backwards but I've nearly convinced myself that it is right.

In the case of those projects, they're not using OpenGL's double-buffering (when the compositor is enabled) so doing it this way seems like the best way to get in sync with the vertical blank period. With an OpenGL swap interval of 0, the call to SwapBuffers() doesn't block so you're presenting the compositor the next frame as soon as you know it has finished with the current one. This effectively has the same effect as using an OpenGL swap interval of 1. (When the compositor isn't interfering--full screen mode, for example.)
>
>

I wonder if Godot should better detect if compositor is running and switch back to vanilla v-sync method if it's not.

I think you are right. It seems obvious that OpenGL's v-syncing breaks when the compositor is enabled. If you look at glfw's and Chromium's code they call this (using DwmFlush()) a HACK. It is likely that they think OpenGL is broken in this case and are having to do something that it should be doing.

[TerminalJack]

@starry-abyss After re-reading your post about the OBS case not changing, I wonder if that project has vsync enabled. Since you didn't change the call to wglSwapIntervalEXT() having vsync enabled will basically cause the game to block in both DwmFlush() and SwapBuffers(). That would explain the 0.03 second process time.

[starry-abyss]

@TerminalJack No, I tried all the combinations. The process time always increases to 0.03 when I run OBS. It's just Godot seems to try hard to be at 60 FPS, even when it couldn't achieve this several frames in a row.

So I'd divide it in two issues:
1) Godot is not friends with compositor;
2) Godot is too eager to have max FPS while it could just deliver stable 30 if under load.

[starry-abyss]

But if there is a reliable way to (dis)prove if 0.03 is pure computation time and not syncing, I can try it.

[TerminalJack]

@starry-abyss For testing purposes, you might use Task Manager to boost that process' priority to 'high'. This will cause it to preempt the others and give it the lion's share of processing time. That is, so long as it is in a runnable state and not blocked in DwmFlush() and/or SwapBuffers().

[TerminalJack]

I haven't had much of a chance to mess around with this today but I did try running the change on a Windows 10 system that has an integrated Intel UHD Graphics 620 GPU. (A fairly low-end GPU.)

I first ran the game (in windowed mode) with the latest 3.2 alpha2 build and it didn't have any noticeable jitter. I then ran the game with the changes and it worked fine as well.

I happened to have logged the delta times during the two runs and I found that they were much more stable with the call to DwmFlush() than without...

3.2 alpha2

0.016667 (10 times)
0.016501
0.016667 (15 times)
0.016628
0.016667 (3 times)
0.016646
0.016667 (5 times)
0.016659
0.016667 (6 times)
0.016571
0.016667 (2 times)
0.016661
0.016667 (10 times)
0.016626
0.016667 (13 times)
0.016567
0.016667 (8 times)
0.016653

Test Build

0.018182
0.022628
0.018182 (3 times)
0.017982
0.016836
0.016781
0.016667 (5 times)
0.01671
0.016667 (129 times)
0.016935
0.016667 (13 times)
0.018094
0.016667 (2828 times)

(The high deltas at the beginning here are due to the fact that these were taken right after the scene was loaded. The alpha build exhibits the same behavior.)

Notice how the test build eventually settled down and reached a steady state. The 3.2 alpha2 build never did.

So it seems that not only will other GPUs not be adversely affected by this change but will actually benefit from it. My guess is that the jitter gets worse as the GPU gets more powerful and it doesn't depend on the manufacturer or even the drivers.

[TerminalJack]

I have created a fork that has a single commit that should fix this problem.

I have only tested it on two Windows 10 machines, however, so it would be great if other people could build it and test it on other Windows versions. Also, I built it using VC++ 2019, so if someone using mingw could build it then that would be great too.

If you have your own (recent) fork of the project then you should be able to patch this change into it without any problems.

[clayjohn]

Im on Windows 10 with an NVidia GTX 1050.

I don't have stuttering in the example project unless I have a shadertoy open and running (as described a few comments above).

With @TerminalJack's commit the stuttering is still present when shadertoy is running.

[TerminalJack]

@clayjohn Thanks for testing this. I wonder if the problem in your case is just a matter of processing power.

I can run an 800 x 450 shadertoy in the background and a Godot game (run from the editor) in a window in the foreground and get very little jitter with the changes I made. The alpha2 build, on the other hand, has severe jitter under the same circumstances. I'm one of the persons that has severe jitter even without any load on my system, though, so that's probably something to take into consideration as well.

[clayjohn]

@TerminalJack Good point. I was running iq's rainforest shader :)

I think there is also a high likelihood that there are multiple issues at play here. As @Calinou has pointed out above, many users have the issue fixed when using interpolated physics as well.

At this point I think you should PR your commit, it looks good and making a PR will give it more visibility and make it easier for other users to build and test.

[TerminalJack]

@clayjohn Yes, I agree that there are likely other issues that behave similar to this.

I actually started out trying to track down a problem with a bad stutter that happens once every 60 to 90 seconds and came across this thread. (It seems like something is blocking the process for 60ms to 100ms every now and then.) I was running my game in full screen mode and it wasn't experiencing any jitter. After coming across this thread, though, I tried running it in a window and, lo-and-behold: I'm one of the lucky ones that can happen to reproduce this particular problem.

I'll likely remove the debugging statements from my changes and send over a PR in a couple of hours.

[Calinou]

@TerminalJack The fork is no longer available (or it's set to be private), could you make it available again please?

[TerminalJack]

@Calinou Sorry. I jacked the repository up so I deleted it. I will fork it again and re-commit the changes here shortly.

[TerminalJack]

@Calinou The new commit is here.

[infosisio]

@TerminalJack Your fix seems to be only for Windows but I face the same issue on Ubuntu.

[TerminalJack]

@TerminalJack Your fix seems to be only for Windows but I face the same issue on Ubuntu.

Yes, this is definitely a Windows-only fix. Sorry.

I don't know if it is necessary to do something similar on Ubuntu or not. I'm not even sure if it uses a compositor.

[Calinou]

I don't know if it is necessary to do something similar on Ubuntu or not. I'm not even sure if it uses a compositor.

It does, in fact, there's no way to disable it on some window managers (including Ubuntu's default) :slightly_smiling_face:

[starry-abyss]

@TerminalJack Might also need some logic for when Aero is disabled in e.g. Windows 7 (IIRC it doesn't v-sync, so Godot probably should still v-sync itself in this case)

[TerminalJack]

@starry-abyss I'm hoping that case will be caught. I have an old laptop that has Windows 7 on it. If it still works I'll do some testing with it and see if any changes are necessary.

[TerminalJack]

I fired-up my 10-year old laptop that has Windows 7 on it and tested my changes. I had to use the simplest of projects for testing. (Laptop GPUs were extremely bad back then.) I used the project from this post. I added the following so that I could switch into/out-of full screen.

func _input(event):
    if event is InputEventKey && event.scancode == KEY_F && event.pressed:
        # Switch into or out of full screen mode.
        OS.window_fullscreen = !OS.window_fullscreen

I ran the project both with my changes and without and there weren't any noticeable differences either way. With my changes, the compositor would be used for v-syncing when expected (windowed mode, compositor enabled) and OpenGL double-buffering would be used in all other cases.

The good news is that there won't be any changes necessary to the _code_. The code detects whether the compositor is enabled or not like it should. It even handles the case where you enable or disable the compositor while the app is running. This is a case that I didn't foresee, however, so I didn't include it in the comments in swap_buffers() regarding the cases where the v-syncing strategy changes on the fly. So that's the only thing I need to change so far as I know.

[lawnjelly]

One of the things brought up on irc today discussing this (and TerminalJack's PR) is isolating error in the measured input delta from error in the output delta.

Calinou pointed out we can test this to an extent by running with the command line switch --fixed-fps 60. This will treat the input delta as though it is always 1/60th of a second.

It would be very helpful if those having the problem (especially on windows) could let us know if this has any effects on jitter.

[starry-abyss]

@lawnjelly I tried quickly with and without the command line option, but sadly I can't repro the issue today %) Except OBS case, which is still the same.
Is value of the option stored between the editor runs by chance?

[Calinou]

Is value of the option stored between the editor runs by chance?

No, it's only a command-line argument (which is stateless).

[starry-abyss]

OK. Also, BTW, is the option available in Godot 3.1.1 (the version on which I do most of the testing here)?

[lawnjelly]

OK. Also, BTW, is the option available in Godot 3.1.1 (the version on which I do most of the testing here)?

If you are using 3.1.1 to test this, you will need to be moving objects a distance proportional to the delta during _process, as there is no fixed timestep interpolation.

[Calinou]

@starry-abyss That command-line argument was added in 3.1, so it should be available in 3.1.1 as well.

[starry-abyss]

So, --fixed-fps 60 didn't help with the issue for me. And running game from command line directly didn't help either (I still had a separate instance of editor on the screen though to quicker reproduce).

And also tried both at once, in case the --fixed-fps 60 request implied this, still jitters.

The difficulty to reproduce yesterday was because I had v-sync off in options from previous tests. :/

there is no fixed timestep interpolation.

Of course, I'm testing methods one by one, not all at once (not like interpolation plugin + dwmflush + any new idea).
Also please next time include the specific steps to try the new idea, so I don't have to guess Godot versions, to run editor or game directly, etc. I don't have the desire to try all possible combinations of everything (with every idea doubling the amount of combinations). :P

[lawnjelly]

Of course, I'm testing methods one by one, not all at once (not like interpolation plugin + dwmflush + any new idea).
Also please next time include the specific steps to try the new idea, so I don't have to guess Godot versions, to run editor or game directly, etc. I don't have the desire to try all possible combinations of everything (with every idea doubling the amount of combinations). :P

I understand as it isn't mentioned in the docs, and there is no fixed timestep interpolation in core. Perhaps I should try and write something on this for the docs, I've not added documentation before.

_The upshot is this:_
Irrespective of other issues (delta, OS), if you use physics or move objects in _physics_process, currently Godot will give jitter as a result of aliasing between physics ticks and actual frames. This will occur to some extent in all physics tick rate / monitor refresh rate combinations, some will be worse than others.

The 'jitter fix' method was an attempt to bodge around this aliasing by making it occur in a less pronounced way (it will still occur). Think staircase aliasing.

In order to prevent this 'base level' jitter you currently either need to
1) (Available in all Godot versions) Move objects in _process and move them by a distance proportional to the delta. This is not ideal for games as you can't use physics, and behaviour is frame rate dependent, however it is ok for jitter testing.

2) (Available in Godot 3.2 onward) Used fixed timestep interpolation. This is only truly possible in 3.2 with the Engine->get_physics_interpolation_fraction() function. See https://github.com/lawnjelly/smoothing-addon for an example of how to use this.

These are the prerequisites BEFORE you start investigating jitter. They will give a linear relationship between the position of an object and time, which is what we want.

An alternative (more newbie friendly) method of achieving this is with semi-fixed timestep, which I've had a PR in for since July #30798.

This is the basis of scientific investigation and hypothesis testing. The idea is reduce as many of the confounding effects as possible and examine one at a time.

There are 3 main factors at play here:

1) Linear relationship between object position and time from the game (see above)
2) Error in input timings
3) Error in output timings

Eliminate (1) as above. Eliminate (2) by using the command line argument, then you can examine (3) in isolation.

Also, for any investigation of jitter, you should be moving objects directly, not via physics, as physics can potentially add jitter itself.

_Edit:_
I've just had a look at the minimum repro project in this thread (dodge the creeps) and it is moving with velocity * delta in _process, which should be fine. It does rely on is_action_pressed and personally I'd remove that as a possible problem, but its probably okay. If using another project to test jitter though, beware the points above.

[starry-abyss]

@lawnjelly I see. I was under impression that interpolation plugin is still also something tested only by a few guys, and may be buggy (and even add to jitter). So I took what's stable (3.1.1), that's how "scientific" works for me.
I'll try with the new considerations next time.

I've just had a look at the minimum repro project in this thread

I'm using my own version of the project, as the original one is using animations (can mask the jitter) and has grey sprite over grey background. I'll adjust it so it meets your criteria.

[lawnjelly]

So, --fixed-fps 60 didn't help with the issue for me.

That is very useful info. This does seem to move the pointy finger of blame towards the output delay (and the compositor), and lend weight to the kind of approach in the PR. This is assuming its using double / triple buffering and keeping the pipeline fed, and not dropping frames.

Is this also the case for @TerminalJack with the command line argument?

[lawnjelly]

I'm using my own project, as the original one is using animations (can mask the jitter) and has grey sprite over grey background. I'll adjust it so it meets your criteria.

Ah good, thank you! :+1:

@lawnjelly I see. I was under impression that interpolation plugin is still also something tested only by a few guys, and may be buggy (and even add to jitter).

A little off topic, but it should be fine (I haven't touched it in a few weeks), shouldn't introduce jitter. If you find any bugs let me know on the issue tracker or even make a PR. :+1: Am intending to put it on the official addons for 3.2 _when I get around to it_ :smile: .

[TerminalJack]

@lawnjelly

Is this also the case for @TerminalJack with the command line argument?

Sorry, I haven't had a chance to try your suggestions out. I kind of went down a rabbit hole on the issue that I'm working on.

[TerminalJack]

@lawnjelly Per our discussion in the PR thread, I just thought that I would mention that you were correct about the --fixed-fps <fps> command-line option. It does, in fact, keep vsync enabled. So, like you were saying, using it is a good way to factor-out any issues with the calculation of the delta. I must have messed up when I tried it earlier and I had stuttering because that's not the case now.

I've been using that option along with my changes to establish that using DwmFlush() does help when running outside of the editor. If you disable DwmFlush() then you can cause stutter in the game simply by dragging some other window around or hovering your mouse over one of the running tasks in the taskbar. Obviously, since the game is running at an 'Above Normal' priority, this shouldn't happen. (And it doesn't if DwmFlush() is being used.)