Godot: 简单的2D游戏中的严重口吃问题[Windows 10，Nvidia]

嗨，我更新了我的报告，是因为我在另一台计算机（家用）上对其进行了测试，因此问题与我更改动画的位置相同。 因此，这不是导致问题的动画。 我认为我相信是因为当我看到它在笔记本电脑上时，它的屏幕很小。 这是一个有关该问题的视频（视频速度为60 FPS）：
GodotStutter.zip

如果视频能够实时准确地显示屏幕上的内容，那么这比我在任何与口吃相关的问题中所见过的口吃得多。 Windows 10 / GTX 1060设置肯定存在严重问题（主要Windows更新后，我在Internet上看到很多文章详细介绍Windows 10 / Nvidia的性能问题，但无法确定是否相关）。

这是我的系统上的测试项目的视频，Mageia 6 x86_64（Linux），Nvidia GTX 670MX和最新的专有驱动程序（390.59）。 完全没有口吃（在Openbox-在KWin上，合成器将事情弄乱了，每10秒钟左右就有一个非常轻的口吃）。
StutterTest_LinuxNvidia_OK.zip

顺便说一下，这是演示项目firstGame_fixed.zip的固定版本，原始版本的文件以某种方式分成了三个不同的文件夹（“ firstgame”，“ firstGame”和“ FirstGame”）。

游戏给了我与视频相同的口吃感。
但是，关闭vsync可以完全消除口吃（但是游戏以4000 fps的速度运行）。
Windows 10 64位nVidia GTX 1060也在这里。

我也按照@Zylann的建议进行了测试，并得到了相同的结果。 我也有Win10 x64和nVidia GTX 1060。

编辑：我使用从nVidia这些驱动程序：
398.11-desktop-win10-64bit-international-whql

赢得7个64位GLES2和GLES3的测试，GeForce GTX 660 / PCIe / SSE2 ...没有结结巴巴。 启用Aero，将godot的2d编辑器放在游戏后面会导致一些停顿（Godot编辑器渲染会干扰游戏的渲染）。

但是，戈多结结巴巴是巨大的看不见的敌人，我们都知道它在那里，但我们不想仔细观察，因为我们知道解决方案并不简单。

您的问题似乎与显示器刷新率不同，是物理固定帧速率，我在监视器中看到这种口吃，其编辑器配置物理fps的频率不相同，但也可以是其他事物。

您的问题似乎与显示器刷新率不同，是物理固定的fps

该演示不使用物理，仅使用简单的_process 。

没错...我说在这种情况下我只会看到沉重的结巴，但是确实没有涉及任何物理过程。 我测试了其中一台显示器的hz变化，并且没有差异，我的齿轮卡死了0。

编辑：我在这台计算机上赢得了7、8.1和10的胜利，并花了一些时间测试所有东西。 胜利8.1不会有结局。 我现在在win 10中进行测试，非常顺利...没有Windows问题。 Godot对您的1060感到生气吗？

这是与我的笔记本电脑相同的测试。 如您所见，问题也在这里。 但这似乎不那么明显，但是就在这里。

笔记本电脑规格：Windows 10-Geforce 940M

这是笔记本电脑视频（这是60 FPS视频）：
GodotStutterLap.zip

遇到口吃问题的人可以尝试使用_physics_process在Player.gd _process中执行演示更改吗？

今天晚上，我将在家用PC上进行测试，这一直是我遇到问题的地方。 但是，我有一个奇怪的事情：今天早上，我在笔记本电脑上给了您一个有关该项目的视频，正如您所看到的，您遇到了同样的问题。 问题是，现在，如果我再次运行它，就不会再出现这种口吃了，就​​像它是随机的一样。 而且我没有在笔记本电脑上进行任何更改，我整天在TSE会议上进行了研究。

警告：我只说说我的笔记本电脑。 在装有GTX 1060的家用PC上，问题始终存在。 但是在我的笔记本电脑上，问题似乎是随机发生的。 这就是为什么我认为暂时将笔记本电脑放在一边进行测试的原因，并且仅在始终有问题的家用PC上进行测试，以便能够隔离“错误”。

@Ranoller我测试了一下，得到了相同的结果。 断断续续仍然存在，看起来几乎一样。

@Ranoller进行了测试，并与没有改变任何内容的à @RaXaR相同。 有同样的问题。

看起来不太好...

为了准确地指定错误，我将执行以下测试：

1）全屏开-关
2）如果有1个以上的监视器：
禁用-启用共享桌面
3）航空开关

您的卡在其他游戏中运行良好吗？ ...

阅读有关动画的第一篇文章->断断续续/没有动画->断断续续我读了代码，我看到一些我认为不正确的内容……确切地说：每帧都要更改动画。 我认为该代码应检查当前动画。 可能它什么都没有改变，但是如果有人想要测试以这种方式改变Player.gd：

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)

这是最后一个主意……可能对这个问题毫无意义，但是……您的图形卡在玩家中很常见，因此godot在其中应该表现良好。

@拉诺勒

对于：

• 第一点：是否已尝试全屏显示，它什么都没有改变

• 2：已经尝试仅使用一个监视器运行（这是我的常用配置，但是有时我也有第二个监视器，因此我都尝试了这两个），并且它没有任何改变。

• 3：我必须测试（今天晚上（法国时间）应该能够做到这一点。

• 4：我必须测试您的代码（今天晚上（法国时间）应该可以执行此操作。

刚刚测试了您的代码，它没有任何改变:(

尽管这个问题可能与godot并不直接相关，但是godot必须修正口吃的问题……事实并非所有游戏都口吃，就像在另一个线程中所说的那样。 今天，我正在玩n ++，全屏，开窗口，试图看到任何卡顿现象，并且没有....根本没有卡顿现象。 与Ori和盲目的森林一样，要使游戏结结巴结，必须要做很多坏事（在后台有其他程序的窗口等等。。。一个小时内仅跳过2 o 3帧...）。 Godot在开始执行时，总是停顿x秒，后来稳定下来，但每隔X秒就会跳帧（当然，如果您没有gtx1060的问题）。 我们不应该将此问题视为次要问题。

我尽力找出问题所在，但就我而言，这有点困难。 我尝试测试其他设置，但没有结果。 我还测试了背景图像，而不是使用带有透明屏幕的颜色。 我已经看到（不要记住巫婆）带有此问题的引擎，因为在“无效屏幕”上渲染2D精灵会导致此问题，但似乎并非如此。 所以我暂时没有任何想法。

出于好奇，尝试剖析SwapBuffers在context_gl_win.cpp 68行附近花费

如果有人知道Godot的来源可以证明我对结果很感兴趣（对不起我的英语...）

我昨天玩这个问题，在游戏窗口运行约60秒后，它神奇地解决了问题。 然后很顺利，这告诉我这可能是缓存内容吗？

出于好奇，尝试在第68行周围的Context_gl_win.cpp中分析SwapBuffers花费的时间。如果花费的时间超过16ms，则可能会在此处丢帧。

也许知道该问题是否在GLES2中发生可能会有所帮助，我们不进行测试

我尝试过在Godot中进行选择，但是它对我没有任何改变，也许我不知道该怎么改变吗？

尝试让游戏停留2分钟以上，但问题始终在60秒钟后无法解决。

我对3.0.3有类似的问题。 （Win10 64位，Nvidia 660）在3.0.2中没有注意到它。

我认为这与AnimatedSprite节点有关，因为我看到具有该节点的关卡的性能问题。 从IDE运行时，或者导出到Win 32bit时，会出现快门，但是如果导出到Win 64bit，则一切都会按原样运行，不会出现卡顿现象。

..有趣的是，示例项目“ FirstGame.zip”没有问题...但是我的游戏仍然存在问题，从IDE和32位版本运行时，FPS降至5，GPU占2％。但是，使用64位导出时，GPU占30％，一切都很好。

嗨，关于这个问题有什么消息吗？ 我刚刚用pong演示进行了测试（我以前没有做过，只是通过教程游戏进行过测试），看来这个示例项目也存在问题。 我在Steam上使用了Godot的最新版本进行测试。

更新Nvidia驱动程序并没有改变任何东西，因此我来了解一些有关此问题的消息。 我还没找到如何驾驭它的方法。

我现在有一台配备geforce gtx 1060（价格便宜3GB）的计算机，并且在Windows 10家庭版中没有此问题。 可以是一些后台应用程序吗？ 一些特定于硬件的配置AMD-Nvidia Intel-Nvidia ....？ 我在这台计算机上没有任何游戏应用程序（在我的音乐录音室中），但即使将3个屏幕连接到计算机，godot仍可以顺利运行。 任何有问题的人都可以检查是否有任何游戏监控软件在后台运行或运行在Steam或类似系统中？ 如果可以尝试禁用它？

使用Steam启动Godot时很难关闭Steam ... Godot运行得很好，问题在于您制作的游戏。 我已经尝试禁用所有我可以禁用的内容，这不会改变任何内容。 我进行了许多测试，但均未成功。 我也尝试过重设nvidia驱动程序，例如更新它们等，但是它什么也没改变。

另一方面，我有一堆运转平稳的引擎，为什么不选择Godot？ 那就是我试图找到的东西。 但是目前我还没有找到任何东西。 在某处有什么东西，但是在什么地方和什么地方，那就是问题:-)

该问题过于“引擎特定于引擎”，无法通过自己的搜索找到可接受的解决方案。 我可以花几个小时的时间去寻找godot代码，而且我知道永远都不可能找到与此相关的东西...我知道引擎开发人员喜欢更多的代码新功能，而“ bug修复”被认为是更“初级的工作”或类似的内容。 但事实并非如此。 我们需要一些引擎开发人员来自动分配此问题，并修复其他“复杂的，幽灵的，低水平的，难以承受的”错误...

我提到我已经尝试过开发版本（没有Steam），问题是相同的。

嗨，我遇到了完全相同的口吃问题（使用Git来源的Godot 3.1），任何动作对我来说都是滞后的，就像您的视频中一样，无论是move_and_slide还是动画播放器动作。 但是在项目设置中打开垂直同步完全可以解决2D游戏中的卡顿问题。

我有点困惑，因为@Zylann说关闭V-Sync可以消除结巴，但是对我而言却相反。

@Qws将其关闭并让游戏以超过60fps的速度运行（当时是这样做的）使口吃对我而言消失了，但它带来了其他问题（使用所有可用的电源并使所有未使用适当增量的功能均失败）时间）。 如果您关闭了V-sync口吃功能，则可能是由于时间间隔不正确，或者是游戏等待/处理的时间长于一帧以更新屏幕的情况。

我对新的gtx 1060所做的第一次测试没有问题...但是后来我遇到了断断续续的情况。 我唯一改变的是将dvi转为hdmi conexion（以及安装的某些程序）...这有点不可思议。 我确信的唯一问题是问题不在Windows 10方面。

我会这么说。 我正在研究Gamedev.tv教程中的2D游戏教程“ Hoppy Days”。 我当时使用3.0.2进行开发，并且运行良好。 我注意到本教程使用的是3.0.4，所以从字面上讲，今天我决定升级到3.0.6。 现在游戏中存在明显的滞后。 _在3.0.2_中根本没有滞后。 现在在那里。 其他所有设置均相同。

我的笔记本电脑是相当新的（2017年3月购买）Dell Inspiron 7000系列游戏笔记本电脑。 处理器为第七代Intel Core i7-7700HQ四核（6MB高速缓存，最高3.8 GHz）。 显卡是具有4GB GDDR5的NVIDIA GeForce GTX 1050Ti。 RAM为16GB，2400MHz，DDR4。 硬盘是三星SSD。 Windows 10。

对我来说，在3.0.4或3.0.6中似乎有些变化.....没有其他变化。 甚至都不是游戏（如……我根本没有更改/编辑/更新关卡）。

@ emo10001您可以测试3.0.3吗？ 到那时，我们更改了用于制作3.0.x二进制文件的构建系统（3.0最高为3.0.2是在MSV 2015的AppVeyor CI上构建的，而3.0.3最高为3.0.6是通过MinGW的GCC 8构建的）。

如果您的笔记本电脑具有Optimus /可切换图形，则可能是您的系统将要与Nvidia GPU一起使用的3.0.2二进制文件列入了白名单，而3.0.3+将默认为IGP。 也可能是您的防病毒软件将3.0.2列入了白名单，而3.0.3+被视为来自不同的来源（这是正确的），但尚未被认为是安全的，因此防病毒软件将进行全面检查并影响性能。
这些仅是猜测，但是否则我不确定实际的Godot更改会像那样影响性能，因此我只能想到构建系统的更改。

CC @hpvb

我遇到了同样的问题！ 我的项目停顿了20到30秒，然后运行平稳。 我在OP帖子中下载了该项目，并且完全一样。
关闭垂直同步可以消除此问题，并且可以4000+ fps的速度运行。

我正在Linux Mint 19上运行3.0.6版本（所以我猜想Windows标记是无用的，是吗？）和具有最新专有驱动程序的GTX 760。

我正在Linux Mint 19上运行3.0.6版本（所以我猜想Windows标记是无用的，是吗？）和具有最新专有驱动程序的GTX 760。

不，但这可能是另一个问题。 由于窗口管理器的合成，Linux经常出现卡顿现象（例如，我使用KWin有一些，而使用Openbox则没有）。

我的项目停顿了20到30秒，然后运行顺利

我经常注意到这一点，如果我执行正在编辑的场景，则会出现断断续续的情况，并且会有大约15-30秒的撕裂（在启用vsync的情况下），但是如果我从主菜单开始项目并使用场景选择器打开场景……好吧，在同一场景中没有结巴（最终会有，但从来没有）。 关于此事件有一些解释吗？ 戈多？ 视窗？ 要稳定再现，需要多少帧？...一定要知道一些事情，因为游戏设计是必须的。

不，但这可能是另一个问题。

嗯，我明白了。 我的意思是，这个特定的问题可能是多平台的，因为许多人都遇到相同的问题。

我一直在弄乱，注意到两个运动机构正好同时口吃，对move_and_slide（）和move_and_collide（）而言。

当相机都摆动时，将相机最多固定一台，除了两个运动学节点之外，场景中的其他所有东西都断断续续。 静态摄像机仅显示两个运动学结结。

我更改什么图形设置似乎都不重要，_process或_physics_process也无关紧要。 也不使用其他增量变量。

我认为该项目不能代表实际用途...更复杂的项目运行会比较顺利。 我认为Windows无法很好地处理巨大的godot空闲时间...我发现了另一个相关问题，不仅是godot，而且还遭受了很多苦难：在带有扩展桌面游戏的多显示器中，显示器1更加流畅被标记为“主要监视器”。 如果主监视器不是1，则辅助监视器会结结巴巴（YouTube受此困扰，但没有ori等统一的商业游戏）。 在辅助监视器中使用全屏显示，在win 7中使用Aero监视，并且监视器互换（例如，监视器2像主要监视器一样），场景是最糟糕的，并且结结巴巴（不仅是godot，而且不是游戏制造商或统一游戏）...我知道在2个1080p屏幕上具有扩展台式机的多显示器对于廉价的GPU来说很难，但是其他游戏则更流畅（godot不会丢失fps，只会结结巴巴）。 如果这个测试继续进行，我们应该举一个更复杂的例子。

@Ranoller我的设置是

我有2台计算机->一台配备i5 gtx660 2屏1080p，另一台配备i7 gtx 1060 3屏（2 1080p和其他hdready）...好吧，我遇到了与gtx660中的辅助显示器有关的口吃问题，我认为与渲染，godot和chrome口吃，游戏制作者和unity do n't唯一相关（商业游戏，确切地说是HiperLightDrifter和Ori，我没有测试演示或模板）。 Windows Aero在全屏模式下口吃更多（我认为不是真正的全屏），但帧速率非常高，而在Win 7中没有Aero的情况下，我的项目中没有vsync时我的速度为130-140 fps，而Aero则通过了400 fps。 ..口吃（很多）在某些情况下（使用和不使用vsync）。 我无法在i7 gtx 1060中强行使godot结结巴巴（在实际项目中，此结结巴巴中的演示会出现，我解释一下我的看法）。 我认为这是一个优化/ OpenGL问题，例如：Light2D几乎无法使用，如果系统不是太强大，则除“ mix”以外的任何混合模式都可能结结巴巴，但是godot应该以与游戏开发商或单位制相同的水平处理持久性。 可能一旦启动3.1，就可以开始进行优化工作（如果问题是可修复的，并且不是Direct3D / OpenGL-Windows问题，当然...我不知道如何在Windows中找到GLES2 / 3游戏进行测试和记录卡一个直接的OpenGL-Aero / Win7-8-10问题）...我知道godot的持久性永远不会像专有的->一个基于游戏的引擎（Ej：Rayman的起源在我拥有的一台旧笔记本电脑上运行顺畅，godot 2不会），但它的渲染效果至少应与游戏制造商处于同一水平（很长一段时间，Unity可能会比godot更好地进行优化，这就是金钱……）。 现在，我觉得godot仅在高端硬件或低分辨率屏幕上表现良好（我在i5 win7 32位15英寸intel高清图形计算机上进行了测试，并表现良好，但我不认为在高清屏幕下，这台计算机会顺利运行​​godot）...

当然，所有这些都是我的观点/经验，我可能是错的（我希望是..如果这将是一个简单的单行修复程序，那就太好了！！！）

另一方面，我记得读过reduz编写的内容与godot可执行文件的“进程优先级”相关，但是在Windows中，如果您手动更改执行过程中godot的优先级并没有区别，那么godot不会表现不佳（发明了一个字？），程序的执行没有峰值，而是渲染，与nvidia / godot和计算机桌面有关（在Windows中，我不尝试在Linux中使用）

嗨，所以，关于这个问题有什么消息吗？ ^^我将再次使用最新版本进行测试，但问题似乎仍然存在。

这会在Android或ios平台上退出吗？早期的godot在Google商店中有一些游戏也存在快门问题。例如： https ： .DunkUp

在某些情况下，所有经过测试的平台都存在这种情况，具有各种GPU和各种操作系统...在控制台中没有记录。

我在linux和Windows上都对其进行了测试，并且在小口吃的情况下可以平稳运行，我有一个低端集成的Intel HD图形Baytrail图形卡

经过数小时的努力，找出了卡顿的原因，至少在我的情况下，我偶然发现了一致的1s卡顿，原因是在“编辑器设置”中启用了“自动切换到远程场景树”。 解开这个问题可以解决我的口吃和性能问题。 （仍然可能会出现非常轻微的断断续续，但几乎没有引起注意。）

Godot内部版本8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64位，NVIDIA GeForce GTX 660，驱动程序v416.81

我的游戏也遇到口吃的问题。 似乎唯一可以改善的事情是在游戏运行时关闭全屏，然后再打开...即便如此，此后还会出现轻微的卡顿现象。 似乎完全是随机发生的。 有时游戏会接近完美，而有时会出现卡顿现象。

具有运动学特征的2D项目。
英特尔i5-2550K CPU
16GB内存
Geforce GTX 970
Win10 64位
戈多3.0,6

在获胜中，全屏出现10次口吃的机会更多，这是因为Aero（可以禁用）。 似乎Godot在Windows Aero上使用的CPU更少，而GPU则更多，但是这却使口吃更加复杂。 在Windows 7中，禁用Windows Aero时，全屏显示的窗口不那么粘连，并占用更多CPU。 我认为胜利10并没有真正的全屏显示。

我已经开始制作弹球2D游戏原型，并且我在球的运动中也太紧张了，我只有一个因重力而下落的刚体。 我在Win10 / NVidia GTX 560 Ti 1Go（使用最新驱动程序）/ 8 Go Ram上，我的计算机不是最好的，但是我的项目只有一个球和StaticBody2D作为边界，我可以清楚地看到经常发生抖动曾经尝试过使用vgsync和不使用vsync，opengl 3.0和2.0，窗口化和全屏显示以及越来越多的物理fps，问题仍然存在。
我的Godot版本是3.1 alpha。
我认为这是一个主要问题，也许很难解决，但绝对不能忽略，对于2D游戏来说，平滑2D运动非常重要。

没错，Godot现在具有所有顶级引擎更好的可用性（我当然认为）。 可用性方面胜过所有人。 但是……性能方面……出口方面……就像godot在操作系统上跳动一样，不像团结或游戏制造商的出口更加灵活（直到chrome中的构造更加流畅） ），这不是因为gdscript速度慢（无论是否使用GDScript），都存在“其他不确定因素”，我希望有一天，有人可以在cpp文件中找到一条反叛者行并更改一个简单的“！”。 这个问题将得到解决...（希望像戈多一样免费！）

我有几个项目在想，我很想和Godot一起做，这将花费我很多时间（不说我所有的空闲时间），但是让我很难过的是，如果发动机不能保证在具有简单场景的动画中实现平滑的2D运动，尽管有这些优点，但引擎却毫无用处。 在这种情况下，对我而言，最明智的选择是不要冒险浪费时间。

我知道此问题仅在某些配置（例如Windows 10和NVidia驱动程序）中出现，但我想知道：

• 这个问题（或类似问题）是否已经计划在里程碑中？
• 是否可以将这个问题放在一边，等待里程碑3.2中Vulkan替换OpenGL？

PS：我已经尝试了另一台PC：

• 英特尔i7 4790K 4.00 Ghz
• Win10 64位16 Go RAM
• NVidia GTX 1060 3Go（带有最新驱动程序）
• Godot 3.1 Alpha官方
  对于简单的场景我也有同样的问题。

我认为这类PC配置（Win10 + Nvidia卡）非常常用，我希望Godot社区（在此方面做得很好）将很快解决此问题，并且好的2D游戏将开始发行以展示我们可以用Godot来做，但是对我来说，这是根本不可能的。

也许这是某种程序焦点问题？ 当我全屏启动游戏时，基本上每次都会看到口吃。 但是，如果（在游戏运行时）我切换到窗口模式并返回全屏，则似乎每次运行都完美。 如果我也有，我可以将其编程为自动发生，但是看起来很简陋。 其他人可以确认再次从全屏切换到窗口切换到全屏吗？

编辑：哦，还有另一件事...当我禁用Geforce Experience应用程序时，情况似乎会变得更好。

具有运动学特征的2D项目
戈多3.0.6
Win10 64位
英特尔i5-2550K CPU
16GB内存
Geforce GTX 970

我尝试了您的建议，我禁用了Geforce Experience，尝试在启用和禁用vsync的情况下再次从全屏切换到窗口，再切换到全屏（更糟的是禁用vsync），但是口吃对我来说总是很不幸。
这是非常随机的，但我从未超过15-20秒而不会结结巴巴。

感谢您的尝试！ 太奇怪了，您的规格比我的还要好。 我的问题是，它是如此随机……很难精确再现。 有时它会运行良好，而其他时候它会结巴。 我相当确定这与Godot本身有关。 在Unity或其他任何游戏引擎中，我从未经历过口吃。

刚注意到这种口吃。

（Godot 3.0.6，Windows 10、64位，i7-8550U，16GB RAM，NVIDIA GeForce MX150）

正如其他人已经提到的那样，这对戈多来说是一个严重的问题。 本周，我决定为一款非常简单的游戏创建原型。 我搜索了一个框架或引擎（找到了很多），并决定选择Godot，因为它是免费和开放的。 然后我注意到结结巴巴，发现了这个问题-并对似乎没有任何进展感到惊讶。 我想我还是会在Godot中建立我的想法的原型。 但是，如果我想创建一个可发布的游戏，我可能会尝试另一个引擎。 （这听起来太苛刻了……我只是认为，如果问题没有解决，戈多特可能会失去很多潜在的采用者。）

没有任何进展，因为没有人在努力，是的，这是一个严重的问题。 但是就目前而言，如果您需要发布商业游戏，则可以在godot中原型制作并移植到统一版本（可以使用C＃）。 您需要牢记“场景-游戏对象-组件”方法，并且可以在godot中进行复制，并且如果工作要统一以实现流畅的流动和性能，或者如果是2D则请交给游戏制作人。 我正在一个插件中尝试将godot项目转换为其他引擎，并尝试将gdscript移植到模块，gml或统一的C＃，但这是一项非常艰巨的任务（我不知道是否值得付出努力它，太多的时间不能在游戏中工作），反过来也不完美（我无法获得所有类型，例如：碰撞返回的对象）。 我为脚本提供了一个小解析器，并将启动一个解析器到tscn和tres，但是将gdscript的解析器结果转换为统一的c＃或游戏制造商GML需要大量代码，而我对此一无所知（i需要json文件中的所有api名称ej。，并且不知道其IP）。 动画是另一个问题，我暂时不知道该如何处理，但是使用书脊/龙骨很容易移植。 我这样做的主要想法是从godot开始，以unity或gm结尾，但是对于niw来说很头疼...如果unity同样具有可移植性（我需要），则像godot一样微小而快速地发展（并具有32位编辑）几个月前我确实移植了我的主要项目，我喜欢godot，但是对于一个小团队（或像我这样的单身男人）的中型项目来说，这是一种风险，没人敢保证完成的项目不会给你很多问题。 但是，如果您的团队中有优秀的C ++程序员，那么您始终可以使godot适应您的游戏（虽然您不可能团结一致，但越野车少）。
我讨厌这个问题，就像我讨厌中端项目中编辑器的性能低下和导出的游戏一样，但是我更讨厌团结（为什么我需要在所有计算机上都使用Internet才能打开编辑器？我有一台没有此功能的计算机！）并且讨厌如此深入的视觉工作室...我敢肯定，如果godot停止了结结巴巴的工作，并致力于表现和出口，我们可以开始看到出色的即将到来的游戏。

为了今天重新检查此问题，我仍然在具有nVidia GTX 1060的Windows 10上执行以下操作：

我以窗口模式打开了以撒的绑定。 绕圈跑，没有结结巴巴（此后至少要持续30秒）。 我不知道游戏是否具有垂直同步，它没有这样的设置。

我以视窗模式打开了Minecraft。 加载一个平坦的世界，看着没有滞后的地面，没有结巴。

我以一个相当大的终端游戏工厂打开了仍然是窗口模式的Factorio。 直线跑，没有结巴。 但是，垂直同步关闭。 如果我打开它并重新启动游戏，仍然不会结结巴巴。

我打开了使用Slick2D（OpenGL）制作的旧Java游戏，而不是一个结结巴巴的东西（我还没有看到一个Oo）。 检查选项，启用垂直同步。 如果我关闭垂直同步，则每秒大约会出现断断续续的断续现象。 如果将帧速率上限提高一倍，则不会结结巴巴。

现在，我使用Godot 3.1 alpha3打开了一个3D项目，该地图具有一些资产和移动的角色：几乎没有断断续续，也许我每20秒只能看到一个，这太微妙了。

我还尝试了我在Godot 3.0.6中移植的2D项目Wallrider：相同，不够结实（每20秒随机产生一个）。

上面所有这些项目都有一个共同点：它们不仅在屏幕上绘制一个精灵。

如果我在Godot 3.1 alpha3上尝试@crystalnoir测试项目，口才消失。 我尝试切换到_physics_process ，甚至尝试delta = 1.0 / 60.0 ，都是一样的。 如果我打印delta ，则表明每秒都有波动，但是游戏每秒显示多次口吃，而delta根本不反映。 如果我在没有编辑器的情况下开始游戏，也会发生这种情况。
我还尝试将其移植到Godot 2.1.5，并且发生了相同的问题（项目： Stuttering_issue19783.zip ）

现在，这变得有趣了：
如果我在屏幕上背靠背打开3D游戏和@crystalnoir的测试，它们都将立即平稳运行。 虽然2D游戏仍然有些断断续续，但并没有那么多。 如果我关闭3D游戏，它似乎仍然可以正常工作，但是如果我缩小2D游戏并将其再次最大化，则它会回到令人发指的卡顿状态。

还没有结束！
我现在尝试在2D游戏中添加3D相机。 神奇的是，通过这样做，可大大减少口吃。
您可以在PlayerWith3D场景中自己尝试： Stuttering_issue19783.zip
查看默认情况下的平滑度。 现在点击magic按钮，看看在没有显示3D环境的情况下如何处理狗屎（虽然并不总是回到100％，但我看到PlayerWith3D.tscn总是比Player.tscn更好。 ）。

我想进一步了解如果将nVidia控制面板从Optimal Power （默认值）更改Maximum performance ，但是...嗯...

无论如何，我只能从中猜出（但这是一个猜测，因此请加一点盐）：这不是戈多的直接错。 图形驱动程序试图变得“智能”。

对于口吃之神！！！ 😂😂😂

只是把它扔在那里...截至2018年11月，Steam上排名前14的视频卡是Nvidia。 让我们看一下每个GPU类别中的热门卡片：

NVIDIA GeForce GTX 1060：Steam用户的14.60％。
AMD Radeon R7图形：Steam用户的1.06％。
Intel HD Graphics 4000：Steam用户的1.06％。

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

根据以上数据，似乎应该优先考虑此问题。 绝大多数游戏玩家使用Nvidia卡，这是迄今为止最常见的配置。 相比之下，Radeon和Intel图形用户的数量微不足道。

@Ranoller ...你

@Zylann我尝试将电源管理模式成功设置为“ Perfer maximum performance”，但结结口没有任何改善。

@ behelit2没有冒犯

@Zylann我在场景前放置了一个渲染网格的3D相机，该场景渲染了带有动画纹理的图块，并且在获得焦点后几秒钟内点胶卡死的问题没有得到解决。 该场景中以前没有其他类型的sttuter（仅是“ initial”），所以我不知道此技巧是否可以解决问题，但是您会发现很有趣。 我将与您一起测试文件。 我也认为godot的空闲时间会使计算机中的某些东西变得“懒惰”，但可能是操作系统，因为在FPS，CPU使用率和停顿方面，无论有无气动，胜利的差异都很大。 可能是试图变得智能的操作系统，而不是图形卡。

我喜欢Zylann的想法来分析其他游戏的功能。 我不知道这是否是题外话，但我做了一些测试。
首先，似乎95％的Steam游戏都是32位的（最新版本也是如此）。 似乎同样有百分比的游戏是由DirectX渲染的。 我捕获了游戏执行的过程，并尝试查看渲染过程。 后面的一些信息（没有任何结论，仅是信息）：

游戏/可执行位/引擎/用于在Windows 7中渲染64位和注释的进程。

• HyperLightDrifter-> 32位/ Game Maker / Windows GDI
• 挂钩->​​ 32位/ Unity / Windows GDI
• Nidhogg-> 32位/？ / Windows GDI

• Ori和盲林-> 32位/ Unity / Windows GDI。 执行类似于godot的称为OPENGL32的进程，但它是Windows GDI中的一种包装。 不是来自OpenGL32的单个调用，所有调用都来自Windows GDI。
  

• 灰尘：Elysyian尾巴-> 32位/ Microsoft XNA / Windows GDI。 具有gameoverlayrenderer.dll，所有调用均来自此（ClientToScreen）。 没有OpenGL dll。

• SuperMeatBoy-> 32位，在Steam Overlay中执行，Windows GDI

• ΔV：土星环（demo）-> 64位，godot /执行OpenGL和Windows GDI调用，一次调用OpenGl SwapBuffers-GetPixelformat，值为8。多次调用Windows GDI。 重复通话吗？ 到WindowsFromDCSetRect（窗口大小），OffsetRect。
  

• 堡垒-> 32位/ SDL2 /执行纯OpenGL调用，不执行Windows GDI，始终以10的值唯一地调用swapBuffers-GetPixelFormat。

• SouthPark坚持真相-> 32位/未知引擎/在Windows GDI中执行所有调用，似乎是direct3D v 9（具有d3d9.dll，但在此过程中执行的调用很少），大多数调用来自steam和uxtheme.dll的gameoverlayrenderer执行OffsetRect和IsRectEmpty以及其他窗口函数。
  

• Sine Mora-> 32位/未知引擎/通过Steam overlay，dicect3d 9执行Windows GDI中的所有调用

• Apotheon-> 32位/ Microsoft XNA / Windows GDI中的所有调用，来自Steam覆盖的单个调用（客户端到屏幕），Microsoft XNA的单个调用（ScreenToClient）和来自名为uxtheme.dll的进程的调用（窗口管理） Windows？）到IsRectEmpty和PtInrect（所有布尔值）。
• 鸡蛋返回原位-> 64位/ Godot /来自OpenGL和Windows GDI的调用，与土星之环相同。
• 番石榴！ 超级涡轮...-> 32位/未知引擎，但文件可能类似于正弦莫拉。 此游戏允许调整屏幕大小。/来自Windows GDI的所有呼叫。
• 不是英雄-> 32位/ SDL2（维基百科说ClickTeam Fusion）/来自Windows GDI Directx 9的所有调用。
• 《 Middle Earth War of Shadow》-> 64位（是的，只有一个）/ Intro表示Firebird，有关进程的内容一无所有/所有来自Windows GDI的调用，但是调用非常少，在其他游戏中很少每秒一些调用（例如，您可以勉强跟随godot api调用，每秒有吨）。 但是这个游戏烧毁了de GPU。

我注意到，大多数失去焦点的游戏会停止进程并暂停（也许是很好的做法？），并且很少有游戏允许您手动调整屏幕大小（例如：不是英雄）。 可悲的是，我在ΔV：土星环（演示）中遇到了焦点丢失/焦点增加的口吃问题。

编辑：似乎godot是唯一同时使用OpenGL32和WindowsGDI进程的引擎。
使用的应用：API Monitor v2

（编辑：ΔV的正确名称：土星环（演示））

如果用“土星之环”指的是ΔV：“土星之环”（演示），它是用Godot 3.1构建的，但是我不确定它们使用的确切版本吗？

经过数小时的努力，找出了卡顿的原因，至少在我的情况下，我偶然发现了一致的1s卡顿，原因是在“编辑器设置”中启用了“自动切换到远程场景树”。 解开这个问题可以解决我的口吃和性能问题。 （仍然可能会出现非常轻微的断断续续，但几乎没有引起注意。）

Godot内部版本8849d3b
Win10 64位，NVIDIA GeForce GTX 660，驱动程序v416.81

我遇到了同样的口吃问题，并且取消选中“自动切换到远程树”是罪魁祸首。

我在这里遇到同样的问题。 关于此抖动的问题很多，但其中大多数似乎都没有适当的解决方案，我确实需要一些帮助。

我将要与我与Godot一起制作的游戏与发行商签约，由于抖动，我可能不得不将所有代码移至Unity。 移动所有代码的时间和成本，我不愿意切换到其他引擎，因为我非常喜欢Godot和Godot本身的设计理念。

我还注意到，在3.1设置菜单中已添加了“物理抖动修复”选项（https://twitter.com/reduzio/status/984783032459685890），但这也无济于事。

Godot版本：
戈多3.0.6

操作系统/设备，包括版本：
MacOS 10.14.1
MacBook（Retina，12英寸，2017年）
1.2 GHz英特尔酷睿m3
8 GB 1867 MHz LPDDR3
英特尔高清显卡615 1536 MB
（但是，此问题会在包括PC在内的多种设备上以及在移动设备和PC上导出的游戏上发生。）

问题说明：
任何正在移动的物体似乎都会周期性地出现口吃或抖动，并伴随屏幕冻结。

重现步骤：
在将Camera2D添加为子节点之后，使用KinematicBody2D甚至是AnimatedSprite创建一个新项目，并使用move_and_slide（）或set_position（）修改位置（但是即使没有Camera2D，它仍然会发生）。

在处理能力较低的设备上，这种情况似乎更常见。

最小复制项目：
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)

Win 7 64位，GTX 660（驱动程序391.35），Godot 3.0.6和3.1-beta1

嘿，我调整了原始项目（停止动画，使用刚体代替手动调整位置，添加略带动画的背景等）

它是： FirstGame_2.zip

使用约500x500的窗口和1920x1080的显示器分辨率进行测试

现在我的观察：

• 抖动是全向的（不仅像通常的vsync问题一样是垂直的）
• 窗口大小越小，抖动越频繁
• 关闭vsync可消除抖动（下一个要点已启用vsync）
• 无需在屏幕上同时运行
• 导出游戏或从编辑器运行都没关系
• 如果我在同一屏幕上使用quakespasm-sdl2运行游戏（僵尸在水下攻击玩家），我几乎看不到抖动
• 如果在同一个屏幕上未暂停的shadertoy网站（此演示：https: 很多抖动
• 如果我在一个有阴影的网站上运行游戏，但在同一屏幕上暂停了，则看不到抖动
• 如果我在同一屏幕上使用编辑器运行游戏，但编辑器中显示的场景未更新（Player.tscn），则看不到抖动
• 如果我在同一屏幕上使用编辑器运行游戏很多抖动

没尝试过关闭Aero，忘记了如何快速地来回切换它吗？

@ starry-abyss关闭aero，转到配置面板，选择“外观和个性化”，在那里您应该能够更改为不具有视觉效果的旧主题，例如“ Windows Classic”（然后没有）请使用Aero）或“ Windows 7 Classic”。

好的，因此对于经典主题游戏，在屏幕上也同时具有着色/编辑的游戏，会从停滞状态到平稳状态来回移动（每个状态可以停留几秒钟）。 在此模式下，口吃伴随垂直框架撕裂。 就是说，即使Firefox在经典主题下滚动眼泪也是如此：'D

我有与diiiiiiiii完全相同的问题，他的move_and_slide用例与我的相同。 您仔细观察，这不是播放器对象抖动，而是其后面的视差背景。

具有运动学特征的2D项目
戈多3.0.6
Win10 64位
英特尔i5-2550K CPU
16GB内存
Geforce GTX 970

由于这种情况发生在许多不同类型的设备上，因此我认为这与硬件配置没有严格关系。 它甚至发生在ios设备上运行的导出游戏上。

您仔细观察，这不是播放器对象抖动，而是其后面的视差背景。

@ behelit2虽然我不确定。 https://youtu.be/YVFtkbuyqEQ在此素材中，如果您查看播放器对象，它甚至会自身抖动。 这可能是一个单独的问题，但是当启用相机平滑或将对象切换到Rigidbody2D时，情况会变得更糟。

https://youtu.be/MGMlhl0tPTA
这是在启用摄影机平滑并将对象切换到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)

我可以通过使用apply_impulse（）来放大抖动，但是直接使用set_position（）修改对象的位置并没有太大区别。

@diiiiiiiii我认为您
例如，我现在正在尝试OP项目，而不是您的项目（对不起）。

@ starry-abyss明白了;）
尽管已经有很多有关抖动的问题，但我认为它们是密切相关的，并且可能有相同的根本原因。

关于OP问题的更新。 我在Godot中找到了一些选项，可以在不使用v-sync的情况下限制fps。 所以对我来说，关闭垂直同步时为60 fps，现在不是〜4000。
关闭垂直同步的事实为我解决了这个问题。

我不知道垂直同步在窗口模式下是否有意义。 Windows似乎独自使用了v-sync，并且可能与Godot游戏抗衡，后者在收到v-sync信号后会更快地准备帧。 此外，IIRC其他游戏仅在关闭了v-sync的情况下才全屏播放，而不是在窗口模式下播放。

仅供参考，diiiiiiiii的问题继续在此处出现：＃25162

除了关闭v-sync方法之外，我还找到了一种有趣的Windows特定方式（通过提交描述，可能是此问题），不确定Godot是否已使用此方式，但是也许有人有时间尝试：
https://github.com/glfw/glfw/commit/8309e0ecb09fe5cf670dff5df1e7ca71821c27bd
也与此有关： https :

但是，还有一个线程将以更详细的方式介绍不同的方法：
https://bugs.chromium.org/p/chromium/issues/detail?id=467617
这是互补的，更短的，更切合实际的，但是在开始时也带有一些情感： https ：

在我上面的报告中，将口吃的单词更改为抖动，因为这就是我的经历（请参阅https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html）。

@ByTheQuietLake我的想法是仅在窗口模式下关闭

关于OP问题的更新。 我在Godot中找到了一些选项，可以在不使用v-sync的情况下限制fps。 所以对我来说，关闭垂直同步时为60 fps，现在不是〜4000。
关闭垂直同步的事实为我解决了这个问题。

我不知道垂直同步在窗口模式下是否有意义。 Windows似乎独自使用了v-sync，并且可能与Godot游戏抗衡，后者在收到v-sync信号后会更快地准备帧。 此外，IIRC其他游戏仅在关闭了v-sync的情况下才全屏播放，而不是在窗口模式下播放。

您如何将fps限制为60？

在项目设置的“调试”类别中的某处使用“强制fps”字段

Воскресенье，17февраля2019，9:25 +03：00отFabiánLC [email protected] ：

关于OP问题的更新。 我在Godot中找到了一些选项，可以在不使用v-sync的情况下限制fps。 所以对我来说，关闭垂直同步时为60 fps，现在不是〜4000。
关闭垂直同步的事实为我解决了这个问题。
我不知道垂直同步在窗口模式下是否有意义。 Windows似乎独自使用了v-sync，并且可能与Godot游戏抗衡，后者在收到v-sync信号后会更快地准备帧。 此外，IIRC其他游戏仅在关闭了v-sync的情况下才全屏播放，而不是在窗口模式下播放。
您如何将fps限制为60？
-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看，或使该线程静音。

除了I5-2500K和集成英特尔GPU的I5-2500K之外，我还没有看到其他人在系统上发布他们的CPU。

我的笔记本电脑同时具有英特尔集成GPU和专用Nvida卡。 我只是想知道两个gpu /驱动程序和godot之间是否可能存在问题

也许。 但它看起来不像gpu / cpu依赖。 在i7 2700 + 1080ti上，在具有Intel 4000（第一代Surface Pro）的移动i5上，可能会结结巴巴（开窗）且黄油光滑（全屏显示）。

有趣的是，您应该说，如果我在940m笔记本电脑上运行演示项目，就会发现口吃。 但是，当我使用专用的Intel 530运行应用程序时，根本看不到任何卡顿现象。

Windows 10家庭版
i3-6100H CPU @ 2.70 GHz，
GeForce 940M（26.21.14.3064）
英特尔（R）高清显卡530（26.20.100.6709）

在这个项目中，结巴可见吗？ （通过按箭头键移动。）

我只是做了一个快速导出，保留了插值功能并将物理设置为60：
940M偶尔有抽搐但没有剪切
Intel 530并没有抽搐，但有时会出现明显的vsync剪切，

我稍后再做，并告诉您。

我将FPS的上限设置为60似乎已经取得了一些成功。不确定60是否是一个魔术数字，我的屏幕是否可以支持144，我确实尝试将上限设置为144，但是口吃仍然可见。 我将FPS降低到120，但仍然可以看到断断续续，但不是“模糊不清”，这使我认为它只是在较低的间隔内发生。 随后将FPS降低到80，结果与以前相同，但现在停顿明显变慢了。 另外，我应该说，我禁用了v-sync并以窗口模式运行，我已经测试了全屏显示，但是结果相同。 发动机中是否有任何限制为60 FPS的过程？

发动机中是否有任何限制为60 FPS的过程？

默认情况下，以60 FPS进行物理模拟，这意味着当渲染FPS高于物理FPS时（如果显示速度足够快以显示差异），将出现明显的差异。 可以在“项目设置”（“物理”>“通用”>“物理Fps” ）中更改物理FPS。

可以通过插补物理实体来缓解这种情况，但是对此没有官方的支持。 在3.2alpha中，可以使用此平滑附加组件，使插入节点变得容易。

发动机中是否有任何限制为60 FPS的过程？

默认情况下，以60 FPS进行物理模拟，这意味着当渲染FPS高于物理FPS时（如果显示速度足够快以显示差异），将出现明显的差异。 可以在“项目设置”（“物理”>“通用”>“物理Fps” ）中更改物理FPS。

可以通过插补物理实体来缓解这种情况，但是对此没有官方的支持。 在3.2alpha中，可以使用此平滑附加组件，使插入节点变得容易。

太好了，谢谢，这也许可以解释为什么在物理过程调用中处理动作时角色口吃的原因

仍然可以在3.1.1 BTW中进行复制，最简单的方法是在Firefox中打开Shadertoy（https://github.com/godotengine/godot/issues/19783#issuecomment-455830124）

我在这里偶然发现希望有解决方案，但是在尝试了我在该线程上看到的几乎所有建议后，仍然没有问题。 对我而言，仅当我在NVIDIA卡中运行项目时才会发生抖动。 如果我使用集成的Intel GPU来运行它，那么它运行起来就如丝般流畅。 ：/

我正在Windows 10上使用最新版本的Godot 3.2

我在这里偶然发现希望有解决方案，但是在尝试了我在该线程上看到的几乎所有建议后，仍然没有问题。 对我而言，仅当我在NVIDIA卡中运行项目时才会发生抖动。 如果我使用集成的Intel GPU来运行它，那么它运行起来就如丝般流畅。 ：/

我正在Windows 10上使用最新版本的Godot 3.2

我不认为您可以在Windows上修复它，这在Linux上不会发生，这可能会在新的vulkan渲染器的4.0中修复。

我在这里偶然发现希望有解决方案，但是在尝试了我在该线程上看到的几乎所有建议后，仍然没有问题。 对我而言，仅当我在NVIDIA卡中运行项目时才会发生抖动。 如果我使用集成的Intel GPU来运行它，那么它运行起来就如丝般流畅。 ：/
我正在Windows 10上使用最新版本的Godot 3.2

我不认为您可以在Windows上修复它，这在Linux上不会发生，这可能会在新的vulkan渲染器的4.0中修复。

好吧，Vulkan API不仅专注于高端设备吗？

我专门针对OpenGL 2.0，因此我可以支持低端设备。 仅将高端图形API用于2D游戏，而将低端计算机/笔记本电脑拒之门外的人有点愚蠢。 😕

听起来像是个神话。 也许不时会出现口吃不能固定的ATM，但我们遇到的口吃软件只是Godot的一项功能。

听起来像是个神话。

你指的是什么？

这是一个具有挑战性的问题。 我一方面要亲自解决此问题。 但是我无法繁殖，所以我无能为力。 （我将Windows 10与NVidia图形卡一起使用）

可以重现此问题的人很不幸需要解决。 :(

尽管这是一个不常见的问题，但似乎很常见，足以吸引很多人使用此线程。 因此，希望你们中的一个可以从事这一工作。

啊，我总是忘了，我在Godot官方文档中所经历的被称为抖动。

_有人知道如何在不购买任何硬件的情况下以60 FPS完美地捕获问题吗？_
我认为有些人低估了它的外观，这也许在不同的PC上是一个看起来不同的问题。

你指的是什么？

神话：“这总是像在OpenGL（或Windows等）上那样。只有Vulkan可以拯救我们”。

好的，所以：

1. 这是OBS的视频： https :
2. 如果没有OBS，它会很平滑，直到我最小化其中包含shadertoy的Firefox，然后它开始出现口吃，但无法用OBS捕获，因为1。

插入我自己的录音中，这是用Bandicam完成的，并且在大多数情况下，这是有或没有录音时的性能。 如您所见，它开始很平稳，但逐渐开始出现问题

@clayjohn我认为可以通过实现物理插值来解决此问题，但是出于某些原因，reduz反对将其置于内核中。 仍然在3.2alpha中添加了一种方法来暴露当前的物理步长比，这使得可以手动实现精确的物理插值。

@ starry-abyss如果可以使用3.2alpha，请尝试一下grassjelly的平滑附件：：slightly_smiling_face：

只是一个想法，我在虚幻引擎或physX源代码中有什么有用的东西要看吗？

干杯，
维克多·斯坦

2019年10月22日上午4：17，Hugo Locurcio [email protected]写道：

</ s> </ s> </ s>
@clayjohn我认为可以通过实现物理插值来解决此问题，但是reduz反对将其置于内核中。

@ starry-abyss如果可以使用3.2alpha，请尝试一下grassjelly的平滑附件🙂

-
您收到此邮件是因为您发表了评论。
直接回复此电子邮件，在GitHub上查看或取消订阅。

@victorbstan我们不应该看虚幻的源代码，因为它不是在开源许可证。 （它甚至不允许重新分配给未经许可的虚幻引擎用户。）

绝对不要从封闭的源代码中获取代码，但在架构上可以
不从中收集想法吗？ [不是律师]

星期二，十月22，2019在11:07雨果·洛科西奥[email protected]
写道：

@victorbstan https://github.com/victorbstan我们不应该看
虚幻的源代码，因为它不受开放源代码许可。 （没有
甚至允许重新分配给未经许可的虚幻引擎用户。）

-
您收到此消息是因为您已订阅此线程。
直接回复此电子邮件，在GitHub上查看
https://github.com/godotengine/godot/issues/19783吗？
或退订
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
。

@Razzlegames我仍然不建议查看其源代码。 如果您想从专有算法中获得启发，则应执行无尘室反向工程以减少相关的法律风险。

不过，我们无需在此处执行任何操作。 解决方案是使用物理插值，这是当今大多数流行的游戏引擎所使用的。 它有一些缺点（例如，要求用户进行工作以避免在传送物体时插值），但我认为这些缺点远远超过了它们。

我知道，建议是要找到可能的途径来寻找解决方案，而不必窃。 我想不到只有IANAL可以解决闪烁/口吃问题的专利。

干杯，
维克多·斯坦

2019年10月22日下午2：07，Hugo Locurcio [email protected]写道：

</ s> </ s> </ s>
@victorbstan我们不应该查看Unreal的源代码，因为它不在开放源代码许可之下。 （它甚至不允许重新分配给未经许可的虚幻引擎用户。）

-
您收到此邮件是因为有人提到您。
直接回复此电子邮件，在GitHub上查看或取消订阅。

在我的场景中，即使看到抖动/卡顿现象，Godot分析器仍显示出完美的60 FPS。 这是否意味着该问题与插值无关，还是我错过了什么？

我的假设是Godot计时的实现方式会干扰Windows的合成器计时（也许SDL比GLFW Godot更好，因此其他引擎只能在Godot出现故障的情况下工作）。

（也许SDL比GLFW做得更好，因此其他引擎仅在Godot出现故障时才起作用）。

Godot使用自己的窗口管理代码，它既不使用SDL也不使用GLFW：slightly_smiling_face：

我有Windows 10和nVidia GeForce GTX 1070，并且在启用了vsync的3.2 alpha2版本中，处于窗口模式时会有抖动。 全屏模式似乎很好。 如果在游戏运行时未最小化编辑器，则问题特别严重。 我正在测试的游戏仅使用_process()来更新位置。 因此，我怀疑问题可能与非常嘈杂的delta或掉帧（较大的增量）有关，但事实并非如此。 在抖动期间， delta实际上是稳定的。

基于对该线程中其他人员的研究，我侵入了context_gl_windows.cpp的更改以将交换间隔设置为0，并在swap_buffers()调用DwmFlush() 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;
}

这基于glfw和Chromium项目的工作。

在窗口模式下进行此更改似乎可以解决抖动问题。 在全屏模式下，游戏会撕裂，因此DWM可能被禁用，并且似乎需要通过间隔值1进行双缓冲。 （基本上，代码需要执行当前的操作。）

如果其他人愿意并且有能力尝试一下，那么我会对了解它的运行方式很感兴趣。

看起来wglSwapIntervalEXT(0);部分与在选项中关闭垂直同步相同。

看起来像wglSwapIntervalEXT（0）; 部分与在选项中关闭垂直同步相同。

它是。 1 -启用vsync， 0 -禁用，还有-1用于“自适应vsync”（在低帧频时禁用同步，在高帧率时启用）。

我在3.1.x分支上用简单的例子从上面测试了DwmFlush（）东西。

• 它确实使用shadertoy测试用例解决了这种情况；
• 垂直同步打开或关闭-对我来说看起来是一样的（我没有修补wglSwapIntervalEXT（）部分）；
• OBS案例仍然令人不安（看起来与我的想法相同），但是Godot现在报告FPS降至40（我想知道Godot中的探查器是否实际上与原始Godot版本相同）；
• 我也尝试过在SwapBuffers（hDC）之后调用DwmFlush（），并且所有3个点都保持不变。

我不确定，但是我猜SwapBuffers（hDC）之后的DwmFlush（）可能更正确，因为Godot将帧放在最近的合成器更新中，而不是放在最近的更新器上。
我想知道Godot是否应该更好地检测合成器是否正在运行，如果不是，则切换回普通v-sync方法。

因此，接下来要尝试的是Calinou提到的新插值功能。

更新：是的，在OBS情况下，Godot报告了0.03秒的处理时间（但FPS被报告为60），可能Godot FPS计数器未考虑到每隔两次便丢失了v空白
更新2：可悲的是，插值插件似乎并没有帮助。 我在OBS情况下仍然有抖动，在sharttoy情况下有结巴和/或抖动

看起来wglSwapIntervalEXT(0);部分与在选项中关闭垂直同步相同。

正确的，但加入DwmFlush()的swap_buffers()会导致游戏使用合成器（DWM）的同步。 启用合成器后，无论是否需要，都可以有效地进行双重缓冲。 如果将OpenGL的交换间隔设置为1，则将具有三重缓冲（您的两个缓冲区和合成器的间隔）。

我也想知道为什么其他项目在SwapBuffers()之前将调用移至DwmFlush() SwapBuffers() 。 似乎倒退了，但我几乎使自己确信这是正确的。

对于那些项目，他们没有使用OpenGL的双缓冲（启用合成器时），因此以这种方式执行似乎是与垂直空白期同步的最佳方法。 在OpenGL交换间隔为0的情况下，对SwapBuffers()的调用不会阻塞，因此，只要知道当前帧结束，就立即向合成器显示下一帧。 这实际上与使用OpenGL交换间隔为1具有相同的效果。（例如，当合成器不干扰时，例如，全屏模式。）
>
>

我想知道Godot是否应该更好地检测合成器是否正在运行，如果不是，则切换回普通v-sync方法。

我想你是对的。 启用合成器后，OpenGL的v同步似乎中断了。 如果您查看glfw和Chromium的代码，他们将其称为HACK（使用DwmFlush() ）。 他们可能认为OpenGL在这种情况下已损坏，因此必须做一些应做的事情。

@ starry-abyss重新阅读有关OBS情况没有改变的文章后，我想知道该项目是否启用了vsync。 由于您没有将呼叫更改为wglSwapIntervalEXT()已启用vsync，因此基本上会导致游戏同时阻塞DwmFlush()和SwapBuffers() 。 这将解释0.03秒的处理时间。

@TerminalJack不，我尝试了所有组合。 运行OBS时，处理时间始终增加到0.03。 只是Godot努力将其设置为60 FPS，即使无法连续达到这几帧也是如此。

因此，我将其分为两个问题：
1）Godot不是合成人的朋友；
2）Godot渴望拥有最大FPS，而在负载情况下仅能提供稳定的30。

但是，如果有一种可靠的方法来（证明）0.03是纯计算时间而不是同步，我可以尝试一下。

@ starry-abyss为了进行测试，您可以使用任务管理器将该进程的优先级提高为“高”。 这将使它抢占其他资源，并给它最大的处理时间。 也就是说，只要它处于可运行状态且未在DwmFlush()和/或SwapBuffers()被阻塞。

我今天没有太多机会解决这个问题，但是我确实尝试在具有集成Intel UHD Graphics 620 GPU的Windows 10系统上运行此更改。 （一个相当低端的GPU。）

我首先使用最新的3.2 alpha2版本运行游戏（以窗口模式运行），并且没有明显的抖动。 然后，我使用更改运行了游戏，并且效果也很好。

我碰巧在两次运行中记录了delta次，我发现调用DwmFlush()比没有调用更加稳定。

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

测试版本

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)

（此处的高增量是由于在场景加载后立即获取了这些增量。Alpha版本表现出相同的行为。）

注意测试版本最终如何稳定下来并达到稳定状态。 3.2 alpha2版本从未执行过。

因此看来，不仅其他GPU不会受到此更改的不利影响，而且实际上会从中受益。 我的猜测是，随着GPU功能的增强，抖动会变得更糟，它并不取决于制造商甚至驱动程序。

我创建了一个具有单个提交的fork ，它应该可以解决此问题。

但是，我仅在两台Windows 10计算机上对其进行了测试，因此，如果其他人可以构建它并在其他Windows版本上对其进行测试，那就太好了。 此外，我使用VC ++ 2019构建了它，因此如果使用mingw的人可以构建它，那也将很棒。

如果您有自己的（最近的）项目分支，则应该可以将此更改修补到其中，而不会出现任何问题。

我在Windows 10上使用NVidia GTX 1050。

除非我打开并运行一个shadertoy（如上面的一些评论所述），否则示例项目中不会出现口吃。

使用@TerminalJack的commit时，运行shadertoy时，口吃仍然存在。

@clayjohn感谢您对此进行测试。 我想知道您的问题是否仅仅是处理能力的问题。

我可以在后台运行800 x 450的阴影，并在前景的窗口中运行Godot游戏（由编辑器运行），并且所做的更改几乎不会引起抖动。 另一方面，在相同情况下，alpha2版本具有严重的抖动。 尽管我的系统没有任何负载，但我还是抖动严重的人之一，因此也可能需要考虑这一点。

@TerminalJack好点。 我正在运行iq的热带雨林着色器:)

我认为这里也很可能存在多个问题。 正如@Calinou指出的那样，许多用户在使用插值物理时也解决了该问题。

在这一点上，我认为您应该PR您的提交，它看起来不错，并且进行PR将使其更具可见性，并使其他用户更容易构建和测试。

@clayjohn是的，我同意可能还有其他行为与此类似。

实际上，我最初是尝试查找一个错误结结的问题，该结结问题每60到90秒发生一次，并遇到该线程。 （似乎有些东西不时地在60毫秒到100毫秒之间阻塞该过程。）我在全屏模式下运行游戏，并且没有任何抖动。 但是，在遇到该线程之后，我尝试在一个窗口中运行它，然后瞧瞧：我是碰巧可以重现此特定问题的幸运者之一。

我可能会从更改中删除调试语句，并在几个小时内通过PR发送。

@TerminalJack该分叉不再可用（或设置为私有），您能否再次使用它？

@Calinou对不起。 我顶了仓库，所以删除了它。 我将再次对其进行分叉，并在不久之后重新提交更改。

@Calinou新提交在这里。

@TerminalJack您的修复程序似乎仅适用于Windows，但我在Ubuntu上也遇到相同的问题。

@TerminalJack您的修复程序似乎仅适用于Windows，但我在Ubuntu上也遇到相同的问题。

是的，这绝对是仅Windows的修复程序。 抱歉。

我不知道是否有必要在Ubuntu上做类似的事情。 我什至不确定它是否使用合成器。

我不知道是否有必要在Ubuntu上做类似的事情。 我什至不确定它是否使用合成器。

实际上，它确实无法在某些窗口管理器（包括Ubuntu的默认设置）上禁用它：slightly_smiling_face：

@TerminalJack可能还需要一些逻辑，例如，在Windows 7中禁用Aero时（IIRC不会进行垂直同步，因此Godot在这种情况下可能仍应进行垂直同步）

@ starry-abyss我希望案件能被抓到。 我有一台装有Windows 7的旧笔记本电脑。 如果仍然有效，我将对其进行一些测试，看看是否有必要进行任何更改。

我启动了装有Windows 7的10年旧笔记本电脑，并测试了我的更改。 我不得不使用最简单的项目进行测试。 （笔记本电脑的GPU极差当时）我从使用的工程这个职位。 我添加了以下内容，以便可以进入/退出全屏模式。

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

无论是否进行更改，我都运行该项目，并且两种方式都没有任何明显的差异。 进行我的更改后，该合成器将在预期的情况下用于垂直同步（窗口模式，启用了合成器），而在所有其他情况下将使用OpenGL双缓冲。

好消息是_code_不需要任何更改。 该代码检测是否启用了合成器。 它甚至可以处理在应用程序运行时启用或禁用合成器的情况。 但是，这是我无法预见的情况，因此我没有在swap_buffers()的注释中包括有关v同步策略动态更改的情况。 就我所知，这是我唯一需要更改的内容。

今天在irc上讨论此问题（以及TerminalJack的PR）的事情之一就是将测量的输入增量中的误差与输出增量中的误差隔离开。

Calinou指出，可以通过使用命令行开关--fixed-fps 60进行一定程度的测试。 这会将输入增量视为始终是1/60秒。

如果有问题的人（尤其是在Windows上）可以让我们知道这是否对抖动有影响，那将非常有帮助。

@lawnjelly我在有和没有命令行选项的情况下都进行了快速尝试，但可悲的是，今天我无法重现此问题％）除OBS情况外，它仍然相同。
存储在编辑器之间的选项的值是否偶然运行？

存储在编辑器之间的选项的值是否偶然运行？

不，它只是一个命令行参数（无状态）。

好。 另外，顺便说一句，Godot 3.1.1（我在此处进行大多数测试的版本）是否提供了该选项？

好。 另外，顺便说一句，Godot 3.1.1（我在此处进行大多数测试的版本）是否提供了该选项？

如果使用3.1.1对此进行测试，则由于_process中没有固定的时间步插值，因此需要在_process期间将对象移动的距离与增量成比例。

@ starry-abyss该命令行参数是在3.1中添加的，因此它也应该在3.1.1中可用。

因此， --fixed-fps 60对我来说没有帮助。 而且直接从命令行运行游戏也无济于事（尽管为了更快地重现，我在屏幕上仍然有一个单独的编辑器实例）。

并且还一次尝试了这两种方法，以防--fixed-fps 60请求暗示了这一点，但仍然有些抖动。

昨日重现的困难是因为我在先前测试的选项中没有进行垂直同步。 ：/

没有固定的时间步插值。

当然，我要一次而不是一次地测试方法（不像插值插件+ dwmflush +任何新想法）。
另外，请下次提供尝试新想法的具体步骤，这样我就不必猜测Godot版本，直接运行编辑器或游戏了。等等。我不想尝试所有可能的组合（包括每个想法加倍组合数量）。 ：P

当然，我要一次而不是一次地测试方法（不像插值插件+ dwmflush +任何新想法）。
另外，请下次提供尝试新想法的具体步骤，这样我就不必猜测Godot版本，直接运行编辑器或游戏了。等等。我不想尝试所有可能的组合（包括每个想法加倍组合数量）。 ：P

据我了解，文档中没有提到它，并且内核中没有固定的时间步插值。 也许我应该尝试为此编写一些文档，但是我之前没有添加文档。

_结果是这样的：_
不管其他问题（delta，OS）如何，如果您使用物理或在_physics_process中移动对象，由于物理滴答和实际帧之间的混叠，当前Godot会产生抖动。 在所有物理滴答速度/监视器刷新速度组合中，这种情况都会在某种程度上发生，某些情况会比其他情况差。

“抖动修复”方法是尝试通过使混叠以不太明显的方式发生（仍会发生）来绕过该混叠。 考虑楼梯别名。

为了防止这种“基本水平”抖动，您当前要么需要
1）（在所有Godot版本中可用）在_process中移动对象并将它们移动与增量成比例的距离。 由于您不能使用物理方法，因此这对游戏而言并不理想，并且行为取决于帧速率，但是可以进行抖动测试。

2）（在Godot 3.2及更高版本中可用）使用固定的时间步插值。 只有在3.2版中，使用Engine-> get_physics_interpolation_fraction（）函数才能真正做到这一点。 有关如何使用此功能的示例，请参见https://github.com/lawnjelly/smoothing-addon 。

这些是开始研究抖动之前的先决条件。 它们将在对象的位置和时间之间给出线性关系，这就是我们想要的。

实现此目标的另一种方法（更适合新手）是半固定的时间步长，自7月以来，我一直在进行公关活动＃30798。

这是科学调查和假设检验的基础。 这个想法是尽可能减少许多混杂的影响，并一次检查一个。

这里有3个主要因素在起作用：

1）游戏中物体位置和时间之间的线性关系（见上文）
2）输入时序错误
3）输出时序错误

如上所述消除（1）。 通过使用命令行参数消除（2），然后可以单独检查（3）。

另外，对于抖动的任何调查，您都应该直接移动对象，而不是通过物理方法移动对象，因为物理方法本身可能会增加抖动。

_编辑：_
我刚刚看了这个线程中的最小repro项目（躲避了小兵），它正在_process中以速度*增量移动，这应该很好。 它确实依赖于is_action_pressed，因此我个人认为这可能是一个问题，但可能还可以。 但是，如果使用另一个项目测试抖动，请当心以上几点。

@lawnjelly我明白了。 我印象深刻的是，插值插件仍然只有少数几个人测试过，并且可能有问题（甚至会增加抖动）。 因此，我采用了稳定的（3.1.1），这就是“科学”对我起作用的方式。
下次，我将尝试新的考虑因素。

我刚刚看了这个线程中的最小repro项目

我使用的是我自己的项目版本，因为原始版本使用的是动画（可以掩盖抖动），并且在灰色背景上具有灰色精灵。 我会对其进行调整，使其符合您的标准。

因此， --fixed-fps 60对我来说没有帮助。

这是非常有用的信息。 这似乎确实将责任归咎于输出延迟（和合成器），并为PR中的这种方法提供了支持。 这是假定它使用了双重/三次缓冲并保持流水线馈入，并且不丢失帧。

使用命令行参数的@TerminalJack也是如此吗？

我正在使用自己的项目，因为原始项目正在使用动画（可以掩盖抖动），并且在灰色背景上具有灰色精灵。 我会对其进行调整，使其符合您的标准。

很好，谢谢！ ：+1：

@lawnjelly我明白了。 我印象深刻的是，插值插件仍然只有少数几个人测试过，并且可能有问题（甚至会增加抖动）。

有点偏离主题，但这应该没问题（我已经有几周没动了），不应该引入抖动。 如果您发现任何错误，请在问题跟踪器上告诉我，甚至进行PR。 ：+1：打算将它放到3.2的正式插件上_：微笑：。

@lawnjelly

使用命令行参数的@TerminalJack也是如此吗？

抱歉，我没有机会尝试您的建议。 对于正在解决的问题，我有点不知所措。

@lawnjelly根据我们在PR线程中的讨论，我只是想提一提您对--fixed-fps <fps>命令行选项是正确的。 实际上，它确实启用了vsync。 因此，就像您说的那样，使用它是排除增量计算中任何问题的好方法。 早些时候尝试时我一定搞砸了，口吃了，因为现在不是这种情况。

我一直在使用该选项以及所做的更改来确定在编辑器外部运行时使用DwmFlush()确实会有所帮助。 如果禁用DwmFlush()则只需在其他任务栏中拖动其他窗口或将鼠标悬停在某个正在运行的任务上，就可以在游戏中造成结结。 显然，由于游戏的运行优先级高于“正常”，因此不应发生这种情况。 （如果使用DwmFlush()则不会。）