Godot: 単純な2Dゲームでの重い吃音の問題[Windows10、Nvidia]

こんにちは。他のコンピューター（自宅）でレポートをテストしたので、レポートを更新しました。問題は、アニメーションを変更したときと同じです。 したがって、これは問題の原因となるアニメーションではありません。 それが私のラップトップにあるのを見たとき、それは小さな画面を持っているので、私はそれを信じたと思います。 これが問題のビデオです（ビデオは60 FPSです）：
GodotStutter.zip

ビデオがリアルタイムで画面に表示されているものを正確に表現している場合、これは、ここでのスタッター関連の問題で言及されたものよりもはるかにスタッターです。 このWindows10 / GTX 1060のセットアップには深刻な問題があるはずです（Windowsのメジャーアップデート後のWindows 10 / Nvidiaのパフォーマンスの問題について詳しく説明しているインターネットに関する記事がかなりありますが、関連しているかどうかはわかりません）。

これが私のシステム、Mageia 6 x86_64（Linux）、最近のプロプライエタリドライバー（390.59）を搭載したNvidia GTX670MXでのテストプロジェクトのビデオです。 スタッターはまったくありません（Openboxでは-KWinではコンポジターが混乱し、10秒ごとに非常に軽いスタッターが発生します）。
StutterTest_LinuxNvidia_OK.zip

ところで、これはデモプロジェクトfirstGame_fixed.zipの修正バージョンです。元のプロジェクトでは、ファイルが3つの異なるフォルダー（「firstgame」、「firstGame」、「FirstGame」）に分割されていました。

ゲームは私にビデオと同じ量の吃音を与えます。
ただし、vsyncをオフにすると、スタッターが完全になくなります（ただし、ゲームは4000 fpsで実行されます）。
Windows 1064ビットnVidiaGTX1060もここにあります。

@Zylannがここで提案したようにテストしたところ、同じ結果が得られました。 私もWin10x64とnVidiaGTX1060を持っています。

編集：私はnVidiaからこれらのドライバーを使用します：
398.11-desktop-win10-64bit-international-whql

Win 7 64ビットGLES2およびGLES3テスト済み、GeForce GTX 660 / PCIe / SSE2 ...スタッターなし。 ゲームの背後にあるgodotの2DエディターでAeroをオンにすると、少しスタッターが発生します（Godotエディターのレンダリングはゲームのレンダリングに干渉します）。

ただし、Godotの吃音は目に見えない巨大な敵であり、そこにあることは誰もが知っていますが、解決策が単純ではないことを知っているため、あまり詳しく調べたくありません。

あなたの問題は、モニターのリフレッシュレートで異なる物理固定fpsのようです。エディターが物理fpsを構成したのと同じHzを持たないモニターで、この種のスタッターが見られますが、他の可能性もあります。

あなたの問題は、モニターのリフレッシュレートで異なる物理学の固定fpsのようです

デモでは物理学を使用せず、単純な_processのみを使用します。

本当...私はこの場合、その重い吃音しか見ないと言いますが、物理的なプロセスが含まれていないのは事実です。 モニターの1つのhzを変更してテストしましたが、違いはなく、ギアのスタッターは0です。

編集：私はこのコンピューターで7勝、8.1勝、10勝を獲得し、時間をかけてすべてをテストしました。 勝利8.1で吃音はありません。 私は今win10でテストしていて、とてもスムーズです...ウィンドウズの問題はありません。 Godotはあなたの1060に腹を立てていますか？

これが私のラップトップでの同じテストです。 ご覧のとおり、問題はここにもあります。 しかし、それはあまり目立たないようですが、ここにあります。

ラップトップの仕様：Windows 10-Geforce 940M

これがラップトップビデオです（60 FPSビデオです）：
GodotStutterLap.zip

スタッターの問題を抱えている人は、Player.gd _processを_physics_processで変更してデモを実行しようとできますか？

今晩、自宅のPCでテストします。これは、私がいつも問題を抱えている場所です。 しかし、私には奇妙なことがあります。今朝、ラップトップでプロジェクトのビデオを提供しました。ご覧のとおり、同じ種類の吃音があります。 問題は、今、もう一度実行しても、ランダムのように、これが再び途切れることがないことです。 そして、私は自分のラップトップで何も変更しませんでした、私はTSEセッションで午前中ずっとそれに取り組みました。

警告：私は自分のラップトップについてのみ話します。 GTX 1060を搭載した自宅のPCでは、問題は常にここにあります。 しかし、私のラップトップでは、問題はランダムに発生するようです。 そのため、今のところ、ラップトップを横に置いてテストし、常に問題のある自宅のPCでのみテストして、「バグ」を特定できるようにするつもりです。

@Ranoller私はそれをテストし、同じ結果を得ました。 吃音はまだあり、ほとんど同じように見えます。

@Ranollerテストを行い、何も変更しない同じà @ RaXaR 。 同じ問題が発生しました。

これはよく見えません...

バグを正確に特定するには、次のテストを行います。

1）フルスクリーンオン-オフ
2）複数のモニターの場合：
無効-共有デスクトップを有効にする
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：すでに1台のモニターで実行しようとしましたが（これは私の一般的な構成ですが、2台目のモニターもあるので、両方を試しました）、何も変わりません。

• 3：テストする必要があります（これは、今夜（フランス時間）に実行できるはずです）。

• 4：コードをテストする必要があります（今晩（フランス時間）にこれを実行できるはずです）。

コードをテストしただけで、何も変更されません:(

この問題はgodotに直接関係していないかもしれませんが、godotは吃音の問題を修正する必要があります...別のスレッドで述べられているように、すべてのゲームが吃音するというわけではありません。 今日、私はn ++、フルスクリーン、ウィンドウを再生し、スタッターを確認しようとしましたが、スタッターはまったくありませんでした。 オリとくらやみの森と同じように、このゲームでスタッターを発生させるには、多くの悪いことが必要です（バックグラウンドで他のプログラムでウィンドウ処理されるなど、1時間に2〜3フレームスキップするだけです...）。 Godotは、実行を開始すると、常にx秒のスタッターが発生し、後で安定しますが、X秒ごとにフレームスキップが発生します（もちろん、gtx1060の問題がない場合）。 この問題を小さな問題として扱うべきではありません。

私は問題を切り分けるために最善を尽くしますが、私のレベルでは少し難しいです。 さまざまなセットアップをテストしてみましたが、結果はありませんでした。 また、クリアスクリーンの色を使用する代わりに背景画像をテストしました。 「ボイドスクリーン」で2Dスプライトをレンダリングするとこの問題が発生するため、この問題が発生するエンジンはすでに見たことがあります（魔女を思い出さないでください）が、ここではそうではないようです。 だから今のところわからない。

好奇心から、68行目あたりのSwapBuffersがcontext_gl_win.cppにかかる時間をプロファイリングしてみてください。16msより長い場合は、ここにフレームをドロップしている可能性があります。

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 32ビットにエクスポートするとシャッターが切れますが、Win 64ビットにエクスポートすると、すべてが正常に実行され、途切れることはありません。

..興味深いことに、サンプルプロジェクト「FirstGame.zip」には問題はありません...それでも私のゲームには問題があります。IDEおよび32ビットバージョンから実行するとFPSは5に低下し、GPUは約2％になります。 。しかし、64ビットエクスポートではGPUは30％であり、すべてが正常です。

こんにちは、この問題に関するニュースはありますか？ 私はpongデモでテストしたばかりです（以前はチュートリアルゲームでテストしていませんでした）。このサンプルプロジェクトでも問題があるようです。 SteamでGodotの最後のバージョンを使用してテストします。

Nvidiaドライバーを更新しても何も変わらなかったので、この問題についていくつかのニュースを取り上げるようになりました。 乗り方がまだわかりませんでした。

私は今、geforce gtx 1060（3gb-安い）を搭載したコンピューターを持っていますが、Windows 10Homeでは問題はありません。 それはいくつかのバックグラウンドアプリである可能性がありますか？ 一部のハードウェア固有の構成AMD-NvidiaIntel-Nvidia ....？ 私はこのコンピューター（私の音楽レコーディングスタジオにあります）にはゲームのアプリケーションはありませんが、コンピューターに3つの画面が接続されていてもgodotはスムーズに動作します。 問題のある人は誰でも、ゲーム監視ソフトウェアがバックグラウンドで実行されているか、スチームで実行されているか、またはこのようなものがあるかどうかを確認できます...？ そして、もしそれを無効にしようとしたら？

Steamを使用してGodotを起動するときにSteamをオフにするのは難しい... Godotは非常によく動作します。問題は、作成するゲームです。 私はすでに無効にできるものをすべて無効にしようとしましたが、何も変わりません。 私は成功せずにたくさんのテストをしました。 また、たとえばnvidiaドライバーをリセットしたり、更新したりしようとしましたが、何も変わりません。

反対側には、スムーズに動作するエンジンがたくさんあるので、Godotを使ってみませんか？ それが私が見つけようとしたものです。 しかし、今のところ私は何かを見つけられません。 どこかに何かがありますが、何とどこで、それが問題です:-)

この問題は「engine-dev固有」であり、独自の検索で許容できる解決策を見つけることはできません。 私はgodotコードを何時間も探すことができ、これに関連するものを見つける可能性は決してないことを知っています...より多くのコードの新機能が好きなエンジン開発者と「バグ修正」はより「ジュニアワーク」と見なされることを知っています"またはこのようなもの。 しかし、この種の問題ではそうではありません。 この問題と他の「複雑なゴースト-低レベル-余裕がない」バグ修正を自動割り当てるには、エンジン開発者が必要です...

私はすでに開発バージョン（Steamなし）を試しましたが、問題は同じです。

こんにちは私はまったく同じスタッターの問題を抱えていました（GitソースのGodot 3.1を使用）。move_and_slideであれ、アニメーションプレーヤーの動きであれ、あなたのビデオとまったく同じように、動きが遅れていました。 しかし、プロジェクト設定でV-Syncをオンにすると、2Dゲームのスタッターの問題が完全に解決されました。

@ZylannがV-Syncをオフにすると吃音が

@Qwsをオフにして、ゲームを

新しいgtx1060で行った最初のテストでは問題はありませんが、後でそのスタッターが発生します。 私が変更したのは、dviからhdmiへの接続（および一部のプログラムのインストール）だけです...これは少し奇妙です。 私が確信した唯一のことは、問題がWindows10側にないということです。

私はこれだけ言います。 Gamedev.tvチュートリアルの2Dゲームチュートリアル「HoppyDays」に取り組んでいます。 私は3.0.2を使用して開発しましたが、問題なく動作していました。 チュートリアルで3.0.4を使用していることに気づいたので、文字通り今日は3.0.6にアップグレードすることにしました。 ゲームには目立った遅れがあります。 _3.0.2ではラグはまったくありませんでした_ 。 今そこにあります。 他のすべての設定は同じです。

私のノートパソコンは、かなり新しい（2017年3月に購入）Dell Inspiron7000シリーズゲーミングノートパソコンです。 プロセッサーは、第7世代Intel Core i7-7700HQクアッドコア（6MBキャッシュ、最大3.8 GHz）です。 ビデオカードは、4GBGDDR5を搭載したNVIDIAGeForce GTX1050Tiです。 RAMは16GB、2400MHz、DDR4です。 ハードドライブはSamsungSSDです。 ウィンドウズ10。

私には、3.0.4または3.0.6のいずれかで何かが変更されたように見えます.....他に何も変更されていません。 ゲームでさえありません（のように...私はレベルをまったく変更/編集/更新していません）。

@ emo10001 3.0.3をテストできますか？ そのとき、3.0.xバイナリの作成に使用されるビルドシステムを変更しました（3.0から3.0.2はMSVC2015を使用してAppVeyorCIでビルドされ、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 postでプロジェクトをダウンロードしましたが、まったく同じです。
V-Syncをオフにすると、問題が解消され、4000 + fpsで実行されます。

Linux Mint 19（つまり、windowsタグは不正確だと思います）と最新のプロプライエタリドライバーを備えたGTX760でバージョン3.0.6を実行しています。

Linux Mint 19（つまり、windowsタグは不正確だと思います）と最新のプロプライエタリドライバーを備えたGTX760でバージョン3.0.6を実行しています。

いいえ、しかしこれはおそらく別の問題です。 Linuxでのスタッターは、ウィンドウマネージャーの合成が原因で発生することがよくあります（たとえば、KWinを使用しているものもあれば、Openboxを使用しているものはありません）。

私のプロジェクトは20〜30秒間途切れ、その後スムーズに実行されます

これによく気づきます。編集中のシーンを実行すると、15〜30秒ほどスタッターとティアリング（vsyncがオンの状態）が発生しますが、メインメニューからプロジェクトを開始し、シーンセレクターでシーンを開くと...まあ、同じシーンに吃音はありません（最終的にはありますが、今までにありません）。 このイベントについて何か説明がありますか？ Godot？ ウィンドウズ？ 再生を安定させるために必要なフレーム数は？...ゲームデザインに必要なものがあるので、それを知っておくといいでしょう。

いいえ、しかしこれはおそらく別の問題です。

うーん、なるほど。 私が言いたかったのは、多くの人が同じ問題を経験しているので、この特定の問題はおそらくマルチプラットフォームです。

私はいじり回していて、move_and_slide（）とmove_and_collide（）の両方で、2つのキネマティックボディがまったく同時にスタッターすることに気づきました。

両方が振動するときにカメラを1つに接続すると、2つのキネマティックノードを除いて、シーン内のすべてが途切れます。 静的カメラは、2つのキネマティックノードのみがスタッターを表示します。

どのグラフィック設定を変更しても、_processや_physics_processは問題ではないようです。 また、別のデルタ変数を使用することもありません。

このプロジェクトは実際の使用を代表するものではないと思います...より複雑なプロジェクトは少しスムーズに実行されます。 Windowsは過度の大きなgodotアイドル時間をうまく処理できないと思います... godotだけでなく、それに関連する別の問題を見つけました：拡張デスクトップゲームを備えたマルチモニターでは、これがあればモニター1でよりスムーズになります「プライマリモニター」のようにタグ付けされています。 プライマリモニターが1以外の場合、セカンダリモニターにスタッターがあります（youtubeはそれに苦しんでいますが、oriのような統一された商用ゲームではありません）。 セカンダリモニターのフルスクリーン、勝利7のエアロ、モニターの交換（ej：プライマリのようなモニター2）では、風景が最悪で、大きなスタッターがあります（godotだけでなく、ゲームメーカーやユニティゲームも）... 。2つの1080p画面に拡張デスクトップを備えたマルチモニターは安価なGPUには難しいことを知っていますが、他のゲームはよりスムーズです（godotはfpsを失うことはなく、スタッターのみです）。 このテストを続行する場合は、より複雑な例を作成する必要があります。

@Ranoller私のセットアップは、gtx 760のデュアルモニター、「primary」のタグが付いた2番目のモニター、シナモン付きのlinux mint19です。 プロジェクトが途切れる具体的な状況を理解しようとしましたが、理解できませんでした。 これらの小さなプロジェクトは、ときどき途切れる場合とそうでない場合があります（途切れるだけで、fpsの損失はありません）。 また、スタッター（ウィンドウ化されたgodotテスト構成で実行）の場合、通常、2番目のモニター（プライマリではない）に1つ以上のクロームウィンドウがあり、それらを最小化すると、スタッターはなくなります...いくつかの最小化/クロームウィンドウで復元すると、吃音は完全になくなります。

私は2台のコンピューターを持っています-> 1台はi5gtx660 2画面1080p、もう1台はi7 gtx 1060 3画面（2 1080pおよびその他のhdready）...ええと、gtx660のセカンダリモニターに関連するこのスタッターの問題があります。レンダリング、godotとクロームスタッター、ゲームメーカーとユニティは排他的に関連していません（商用ゲーム、正確にはHiperLightDrifterとOri、デモやテンプレートはテストしていません）。 Windows Aeroはフルスクリーンでよりスタッターします（私は実際にはフルスクリーンではないと思います）が、win 7でエアロなしで非常に多くのfpsを持っています。 ..特定の条件（vsyncの有無にかかわらず）で（多くの）スタッター。 i7 gtx 1060でgodotを吃音にすることはできません（実際のプロジェクトでは、このスレッドのデモが吃音し、私の意見を説明します）。 最適化/ OpenGLの問題だと思います。ej：Light2Dはほとんど使用できません。システムがあまり強力でない場合、「ミックス」以外のミックスモードは途切れることがありますが、godotはゲームメーカーやUnityと同じレベルでパフォーマンスを処理する必要があります。 おそらく3.1がリリースされると、最適化の作業が始まる可能性があります（問題が修正可能で、Direct3D / OpenGLではない場合-もちろんWindowsの問題... WindowsでGLES2 / 3ゲームを見つけてテストし、破棄する方法がわかりません直接のOpenGL-Aero / Win7-8-10の問題）... godotのパフォーマンスは、所有者と同じになることは決してないことを理解しています-> 1つのゲームベースのエンジン（Ej：Raymanの起源は私が持っている古いラップトップでスムーズに動作します、godot 2はそうではありません）が、少なくともゲームメーカーと同じ安定したレベルでレンダリングする必要があります（Unityはおそらく長い間godotよりも最適化されるでしょう...）。 今のところ、godotはハイエンドハードウェアまたは低解像度の画面でのみうまく機能すると思います（私はi5 win732ビット15インチIntelHDグラフィックスコンピューターでテストし、優れたパフォーマンスを発揮しますが、HD画面ではこのコンピューターがうまくいくとは思いませんゴドットをスムーズに実行）...

もちろん、それはすべて私の意見/経験です、私は間違っている可能性があります（そして私はそうなることを望んでいます..これが単純な1行の修正であるならば、これは素晴らしいかもしれません!!!）

一方、godot実行可能ファイルの「プロセス優先度」に関連する何かを書いているreduzを読んだことを覚えていますが、Windowsでは、実行時にgodotの優先度を手動で変更しても違いはなく、godotのパフォーマンスは低下しません（単語を発明しましたか？）、プログラムの実行にはスパイクがありません、それはレンダリング、nvidia / godotとコンピュータデスクトップに関連するものです（Windowsでは、Linuxでは試しません）

こんにちは、それで、この問題について何かニュースはありますか？ ^^最新バージョンで再度テストしますが、まだ問題があるようです。

これはAndroidまたはiOSプラットフォームで終了しますか？初期のgodotによって作成されたGoogleストアには、シャッターの問題もあるゲームがいくつかあります。https ： .DunkUp

これは、特定の状況でテストされたすべてのプラットフォームに存在し、さまざまなGPUとさまざまなオペレーティングシステムがあります...コンソールには記載されていません。

LinuxとWindowsの両方でテストしましたが、ときどき小さなスタッターでスムーズに動作しました。ローエンドの統合インテルHDグラフィックスベイトレイルグラフィックスカードがあります。

スタッターの原因を突き止めようと何時間も試みた後、少なくとも私の場合は、「エディター設定」で「リモートシーンツリーへの自動切り替え」が有効になるまで、一貫した1のスタッターを追跡しました。 これをオフにすると、スタッターとパフォーマンスの問題が解決します。 （まだ非常にわずかなスタッターがある可能性がありますが、ほとんど目立ちません。）

Godotビルド8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64ビット、NVIDIA GeForce GTX 660、ドライバーv416.81

ゲームに吃音の問題もあります。 それを改善しているように見える唯一のことは、ゲームの実行中に全画面をオフにしてからオンにすることです...そしてそれでも、その後に忍び寄るわずかなスタッターがあります。 完全にランダムに発生するようです。 ゲームがほぼ完璧に実行される場合もあれば、吃音が発生する場合もあります。

キネマティックキャラクターを使用した2Dプロジェクト。
Intel i5-2550K CPU
16GBのRAM
Geforce GTX 970
Win1064ビット
Godot 3.0,6

Win 10では、フルスクリーンでより多くのスタッターが発生します。これは、Aero（および無効にできる）が原因です。 GodotはWindowsAeroでより少ないCPUとより多くのGPUを使用しているようですが、これはより吃音を引き起こします。 Windows 7では、Windows Aeroを無効にすると、全画面表示のスタッターがウィンドウ表示よりも少なくなり、より多くのCPUを使用します。 Win10は実際のフルスクリーンではないと思います。

私はプロトタイプのピンボール2Dゲームを作り始めましたが、ボールの動きに揺れがありすぎて、重力で落下する剛体しかありません。 私はWin10 / NVidia GTX 560 Ti 1Go（最新のドライバーを使用）/ 8 Go Ramを使用しています。私のコンピューターは最高ではありませんが、プロジェクトには境界線用のボールとStaticBody2Dしかなく、明らかにジッターが頻繁に発生していることがわかります。 vsyncを使用する場合と使用しない場合、opengl 3.0と2.0、ウィンドウとフルスクリーン、物理的なfpsを増やしたり減らしたりしてみましたが、問題はまだここにあります。
私のGodotバージョンは3.1アルファです。
これは大きな問題だと思います。修正するのは難しいかもしれませんが、スキップしてはいけません。2Dゲームではスムーズな2Dの動きが重要です。

そうです、Godotはすべてのトップエンジンの使いやすさが向上しています（もちろん私の意見です）。 使いやすさの面はそれらすべてを打ち負かします。 しかし......パフォーマンス側....エクスポート側....それはgodotがオペレーティングシステムで打ち負かされていたようであり、より流動的なユニティやゲームメーカーのエクスポートのようではありません（クロムの構造がより流動的になるまで） ）、そしてgdscriptの遅さ（GDScriptの有無にかかわらず発生する）のためではなく、「他の不確定なもの」があります。いつか誰かがcppファイルで1つの反乱行を見つけて1つの単純な「！」を変更できることを願っています。 この問題は修正されます...（Godotのように無料です！）

私はいくつかのプロジェクトを念頭に置いており、Godotでそれらを作りたいと思っています。（私の自由な時間のすべてを言うのではなく）多くの時間がかかりますが、エンジンが保証できない場合は悲しいことですシンプルなシーンでのアニメーションのスムーズな2Dの動き、これらすべての長所にもかかわらず、エンジンは単に役に立たない。 この場合、おそらく私にとって最も賢明な選択は、このように時間を失うリスクを冒さないことです。

この問題は一部の構成（Windows 10やNVidiaドライバーなど）でのみ発生することを理解していますが、知りたいのは次のとおりです。

• この問題（または同様の問題）はすでにマイルストーンで計画されていますか？
• この問題は、マイルストーン3.2でOpenGLがVulkanに置き換えられるのを待っているのでしょうか。

PS：私は別のPCで試しました：

• Intel i7 4790K 4.00 Ghz
• Win1064ビット16Go RAM
• NVidia GTX 1060 3Go（最新のドライバーを使用）
• Godot3.1アルファオフィシャル
  単純なシーンでも同じ問題が発生します。

この種のPC構成（Win10 + Nvidiaカード）は非常に一般的だと思います。Godotコミュニティ（ちなみに素晴らしい仕事をしています）がこの問題をすぐに修正し、優れた2Dゲームがリリースされて表示されることを願っていますGodotでできることですが、私にとってこの種の問題では、それは単純に不可能です。

多分それはある種のプログラムの焦点の問題ですか？ 全画面でゲームを始めると、基本的に毎回吃音が見られます。 しかし、（ゲームの実行中に）ウィンドウモードに切り替えて全画面に戻すと、毎回完璧に動作しているように見えます。 私も持っている場合は、これが自動的に発生するようにプログラムできますが、ぎこちないようです。 フルスクリーンからウィンドウ、フルスクリーンへの切り替えでスタッターが修正されることを他の誰かが確認できますか？

編集：ああ、もう1つ... Geforce Experienceアプリを無効にすると、状況は良くなったようです。

キネマティックキャラクターを使用した2Dプロジェクト
Godot 3.0.6
Win1064ビット
Intel i5-2550K CPU
16GBのRAM
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で自分のアイデアのプロトタイプを作成すると思います。 しかし、リリース可能なゲームを作成したい場合は、おそらく別のエンジンを試してみます。 （これは厳しすぎるように聞こえます...問題が修正されない場合、Godotは多くの潜在的な採用者を失う可能性があると思います。）

誰も取り組んでいないので進展はなく、そうです、深刻な問題です。 ただし、今のところ、商用ゲームをリリースする必要がある場合は、godotでプロトタイプを作成し、Unityに移植できます（C＃を使用できます）。 シーン-ゲームオブジェクト-コンポーネントのアプローチを念頭に置く必要があります。godotで複製できます。作品が流体の流れとパフォーマンスのために統一される場合、または2Dの場合はゲームメーカーに行きます。 私はプラグインでgodotプロジェクトを他のエンジンに変換し、gdscriptをモジュール、gml、またはUnity C＃に移植しようとしていますが、非常に大きな作業です（努力する価値があるかどうかはわかりません）それは、ゲームで動作しない時間が長すぎる）そして常に不完全になります（すべてのタイプを取得することはできません、ej：衝突によって返されたオブジェクト）。 スクリプト用の小さなパーサーがあり、tscnとtresにパーサーを開始しますが、gdscriptのパーサー結果をUnity C＃に変換するか、ゲームメーカーGMLに大量のコードが必要であり、これに関する「合法性」がわかりません（i jsonファイル内のすべてのAPI名ej。が必要であり、これのIPについてはわかりません）。 アニメーションは他の問題です。今のところ、それにアプローチする方法はわかりませんが、脊椎/ドラゴンボーンを使用すると簡単に移植できます。 それを行う私の主なアイデアは、godotで始まり、unityまたはgmで終わることでしたが、niwの場合は頭痛の種です... unityが同等に移植可能である場合（私はそれが必要です）、godotのように小さくて迅速に開発できます（32ビット編集者）私は数ヶ月前にメインプロジェクトを移植しました、私はgodotが大好きですが、小さなチーム（または私のような独身男性）の中規模プロジェクトではリスクがあり、完成したプロジェクトが大量のプロジェクトを提供しないことを誰もあなたに保証しません問題。 しかし、チームに優れたC ++プログラマーがいる場合は、godotをゲームにいつでも適応させることができます（団結してはできませんが、バグは少なくなります）。
途中のプロジェクトやエクスポートされたゲームでのエディターのパフォーマンスの低下が嫌いなように、この問題は嫌いですが、より団結が嫌いです（エディターを開くためにすべてのコンピューターでインターネットが必要なのはなぜですか？それがないコンピューターが1台あります！）そして嫌いですとても深くビジュアルなスタジオ...私は、godotが途切れを止め、パフォーマンスとエクスポートに取り組んでいれば、素晴らしい新進気鋭のゲームを見ることができると確信しています。

今日この問題を再確認するために、nVidia GTX1060を搭載したWindows10で、次のことを行いました。

The Binding ofIsaacのウィンドウモードを開きました。 ぐらぐらと走り、スタッターはありませんでした（これ以降、少なくとも30秒間は意味します）。 ゲームにV-syncがあるかどうかはわかりませんが、そのような設定はありません。

Minecraftのウィンドウモードを開きました。 ラグが存在しない地面を見て、スタッターのないフラットな世界をロードしました。

かなり大きなエンドゲームファクトリーで、まだウィンドウモードのFactorioを開きました。 吃音なしで一直線に走った。 ただし、V-syncはオフです。 オンにしてゲームを再起動すると...まだ途切れることはありません。

Slick2D（OpenGL）を使用して作成した古いJavaゲームを開きましたが、1つのスタッターではありません（まだ1つのOoを見ていません）。 オプションを確認すると、V-syncが有効になっています。 V-syncをオフにすると、毎秒かそこらで定期的にスタッターが発生します。 フレームレートキャップを2倍にすると、スタッターが発生しません。

ここで、Godot 3.1 alpha3を使用して3Dプロジェクトを開始しました。マップには、いくつかのアセットと動くキャラクターが含まれています。スタッターはほとんどなく、20秒ごとに1つしか表示されないため、気になりません。

また、Godot 3.0.6に移植した2DプロジェクトWallriderも試してみました。同じですが、気になるほどスタッターがありません（20秒ごとにランダムに1つ）。

上記のすべてのプロジェクトには、これが共通しています。画面に1つのスプライトを描画するだけではありません。

Godot 3.1 alpha3で@crystalnoirテストプロジェクトを試してみると、すぐに不規則な頻繁なスタッターが発生します。これは、最後に表示/最大化されてから約30秒待つと消えます。 _physics_processに切り替えてみましたが、 delta = 1.0 / 60.0も試してみましたが、すべて同じです。 deltaを印刷すると、毎秒変動があることがわかりますが、ゲームでは1秒間に複数回スタッターが発生し、 deltaはまったく反映されません。 エディターなしでゲームを開始した場合にも発生します。
また、Godot 2.1.5に移植しようとしましたが、同じ問題が発生します（プロジェクト： Stuttering_issue19783.zip ）

そして今、これはそれが面白くなるところです：
3Dゲームと@crystalnoirのテストの両方を画面上で

まだ終わりではありません！
2Dゲームに3Dカメラを追加しようとしました。 そして魔法のように、それをするだけで、スタッターは劇的に、そしてすぐに減少します。
PlayerWith3Dシーンでこれを自分で試すことができます： Stuttering_issue19783.zip
デフォルトでどれほどスムーズかを確認してください。 magicボタンを押して、3D環境が表示されていない場合にどのようにたわごとになるかを確認します（ただし、常に100％に戻るとは限りませんが、PlayerWith3D.tscnは常にPlayer.tscnよりも見栄えが良いことがわかります）。

さらに進んで、nVidiaコントロールパネルをOptimal Power （デフォルト）からMaximum performanceに変更するとどうなるかを確認したいのですが、...えーと...

とにかく、これから私が推測できるのは（しかし、それは推測なので、一粒の塩でそれを取る）：それは直接Godotのせいではありません。 「スマート」になろうとしているのはグラフィックスドライバーです。

吃音の神のために!!! 😂😂😂

これを捨てるだけです... 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 ...あなたは私を殺している。 Godotでプロトタイプを作成するように人々に指示するが、（Godotの発行スレッドで）商用タイトルのためにUnityに移植することは、私が今まで聞いた中で最もばかげたことであり、不快感はありません。

@Zylann電源管理モードを「Perfermaximumperformance」に設定しようとしましたが、スタッターの改善は見られませんでした。

@ behelit2攻撃なし

@Zylannアニメーションテクスチャでタイルマップをレンダリングするシーンの前にメッシュをレンダリングする3Dカメラを配置しましたが、ゲインフォーカスの数秒後にgodotが途切れる問題は修正されていません。 そのシーンには以前は他の種類のスタッター（「イニシャル」のみ）がないので、このトリックが何かを修正するかどうかはわかりませんが、興味深いことがわかります。 私はあなたとファイルをテストします。 godotのアイドル時間によってコンピューターの何かが「怠惰」になると思いますが、FPS、CPU使用率、スタッターのエアロありとなしの勝ちの違いが非常に大きいため、おそらくオペレーティングシステムです。 おそらく、グラフィックカードではなくスマートにしようとするOSです。

他のゲームの機能を分析するZylannのアイデアが好きです。 これがオフトピックかどうかはわかりませんが、いくつかテストを行いました。
まず第一に、Steamゲームの95％は32ビットのようです（最近のリリースも）。 ゲームの同じ割合がdirectxでレンダリングされているようです。 ゲームが実行するプロセスをキャプチャし、レンダリングで何が起こっているかを確認しようとします。 背後にあるいくつかの情報（結論はありません、情報のみです）：

ゲーム/実行可能ビット/エンジン/ Windows 764ビットおよびノー​​トでのレンダリングに使用するプロセス。

• HyperLightDrifter-> 32ビット/ゲームメーカー/ Windows GDI
• フック-> 32ビット/ Unity / Windows GDI
• ニーズヘッグ-> 32ビット/？ / Windows GDI

• オリとくらやみの森-> 32ビット/ Unity / WindowsGDI。 godotのようにOPENGL32と呼ばれるプロセスを実行しますが、WindowsGDIの一種のラッパーです。 OpenGL32からの単一の呼び出しではなく、すべての呼び出しはWindowsGDIからのものです。
  

• ほこり：エリシアンテール-> 32ビット/ Microsoft XNA / WindowsGDI。 gameoverlayrenderer.dllがあり、すべての呼び出しはこれ（ClientToScreen）からのものです。 OpenGLdllがありません。

• SuperMeatBoy-> 32ビット、Steamオーバーレイ内での実行、Windows GDI

• ΔV：Rings of Saturn（デモ）-> 64ビット、godot / OpenGLおよびWindowsGDI呼び出しを実行し、OpenGlSwapBuffersへの単一の呼び出しを実行します-値8のGetPixelformat。WindowsGDIへの呼び出しを多数実行します。 重複した呼び出しはありますか？ WindowsFromDCへ-SetRect（ウィンドウサイズ）、OffsetRect。
  

• Bastion-> 32ビット/ SDL2 / Windows GDIなしで純粋なOpenGL呼び出しを実行し、swapBuffersの一意の呼び出しを実行します-値10で常にGetPixelFormat。

• SouthPark the stick of Truth-> 32ビット/不明なエンジン/ Windows GDIですべての呼び出しを実行し、direct3D v 9のようです（d3d9.dllがありますが、このプロセスではほとんど呼び出しを行いません）。ほとんどの呼び出しはsteamとuxtheme.dllのgameoverlayrendererからのものです。 OffsetRectとIsRectEmptyおよびその他のウィンドウ機能を実行します。
  

• Sine Mora-> 32ビット/ Unknow engine / Steamオーバーレイ、dicect3d9によってWindowsGDIのすべての呼び出しを実行します

• Apotheon-> 32ビット/ Microsoft XNA / Windows GDIでのすべての呼び出し、スチームオーバーレイからの1回の呼び出し（クライアントから画面へ）、Microsoft XNAの1回の呼び出し（ScreenToClient）、およびuxtheme.dllと呼ばれるプロセスからの呼び出し（ windows？）からIsRectEmptyおよびPtInrect（すべてブール値）へ。
• 卵は家に帰る-> 64ビット/ Godot / OpenGLおよびWindowsGDIからの呼び出し、土星の環と同じ。
• 覆面闘士！ スーパーターボ....-> 32ビット/不明なエンジンですが、ファイルの場合はサインモーラに似ている可能性があります。 このゲームでは、画面のサイズを変更できます。/WindowsGDIからのすべての呼び出し。
• ヒーローではない-> 32ビット/ SDL2（ウィキペディアによるとClickTeam Fusion）/ Windows GDI Directx9からのすべての呼び出し。
• Middle Earth Shadow of War-> 64ビット（ええ、1つあります）/イントロはFirebirdと言っていますが、プロセスについては今のところ何もありません/ Windows GDIからのすべての呼び出しがありますが、他のゲームの呼び出しはほとんどありません。 1秒あたりの呼び出し数（ej、godot api呼び出しをほとんど追跡できません。1秒あたりの呼び出し数はトンです）。 しかし、このゲームはGPUを焼きます。

フォーカスが失われたほとんどのゲームはプロセスを停止して一時停止し（おそらく良い習慣ですか？）、画面のサイズを手動で変更できるゲームはほとんどありません（ej：ヒーローではありません）。 悲しいことに、ΔV：Rings of Saturn（デモ）でフォーカスが失われる/フォーカスが増えるという吃音の問題があります。

編集：godotはOpenGL32とWindowsGDIプロセスを同時に使用する唯一のエンジンのようです。
使用したアプリ：API Monitor v2

（編集：ΔVの正しい名前：土星の指輪（デモ））

Rings of SaturnがΔV：Rings of Saturn（demo）を意味する場合、それはGodot 3.1で構築されましたが、それらが使用した正確なリビジョンについてはわかりませんか？

スタッターの原因を突き止めようと何時間も試みた後、少なくとも私の場合は、「エディター設定」で「リモートシーンツリーへの自動切り替え」が有効になるまで、一貫した1のスタッターを追跡しました。 これをオフにすると、スタッターとパフォーマンスの問題が解決します。 （まだ非常にわずかなスタッターがある可能性がありますが、ほとんど目立ちません。）

Godotビルド8849d3b
Win10 64ビット、NVIDIA GeForce GTX 660、ドライバーv416.81

同じ途切れの問題があり、リモートツリーへの自動切り替えのチェックを外したことが原因でした。

私はここでも同じ問題を抱えています。 このジッターには複数の問題がありますが、それらのほとんどには適切な解決策がないようで、私は本当に助けが必要です。

Godotで作成したゲームでパブリッシャーと契約を結ぶところですが、ジッターのためにすべてのコードをUnityに移動する必要があるかもしれません。 すべてのコードを移動する時間とコストは別として、GodotとGodot自体の設計哲学が本当に好きなので、別のエンジンに切り替えるのは気が進まない。

また、3.1では「PhysicsJitter Fix」オプションが設定メニュー（https://twitter.com/reduzio/status/984783032459685890）に追加されていることに気付きましたが、それも役に立ちません。

Godotバージョン：
Godot 3.0.6

バージョンを含むOS /デバイス：
MacOS 10.14.1
MacBook（Retina、12インチ、2017年）
1.2 GHz Intel Core m3
8 GB 1867 MHz LPDDR3
インテルHDグラフィックス6151536 MB
（ただし、この問題は、PCや、モバイルおよびPC上のエクスポートされたゲームを含む複数のデバイスで発生します。）

問題の説明：
移動しているオブジェクトは、画面のフリーズを伴う定期的なスタッターまたはジッターのように見えます。

再現する手順：
KinematicBody2DまたはAnimatedSpriteを使用して新しいプロジェクトを作成し、Camera2Dを子ノードとして追加した後、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）、Godot3.0.6および3.1-beta1

ねえ、私は元のプロジェクトを微調整しました（アニメーションを停止し、手動で位置を調整する代わりに剛体を使用し、わずかにアニメーション化された背景を追加しました）

これが： FirstGame_2.zip

サイズ〜500x500のウィンドウと1920x1080のモニター解像度でテスト済み

今私の観察：

• ジッタは全方向性です（通常のvsyncの問題のように垂直だけでなく）
• ウィンドウサイズが小さいほど、ジッターの頻度が高くなります。
• vsyncをオフにすると、ジッターが削除されます（次の箇条書きはvsyncがオンの場合です）
• 同時に画面上でを実行すると（最小化するので、デスクトップだけになります-アイコン、壁紙、タスクバー、そしてファイルマネージャーやターミナルなどの静的ウィンドウ）ジッターを取り除きます
• エクスポートされたゲームまたはエディターからの実行は関係ありません
• 同じ画面でquakespasm-sdl2を使用してゲームを実行すると（ゾンビが水中でプレーヤーを攻撃している場合）、ジッターはほとんど見られません。
• 同じ画面で一時停止せずにshadertoyサイト（このデモ：https：//www.shadertoy.com/view/ll3fz4）でゲームを実行する多くのジッター
• シェーダートイサイトでゲームを実行したが、一時停止した場合、同じ画面でジッターがほとんど表示されません
• エディターで同じ画面でゲームを実行し、エディターに表示されるシーンが更新されない場合（Player.tscn）、ジッターはほとんど見られません。
• エディターで同じ画面でゲームを実行多くのジッター

Aeroをオフにしてみませんでしたか？すばやく前後に切り替える方法を忘れましたか？

@ starry-abyssでエアロをオフにし、構成パネルに移動して「外観とパーソナライズ」を選択すると、視覚効果を備えていない（そして、 Aero）、または「Windows7Classic」を使用します。

さて、古典的なテーマでは、画面にシェーダートイ/エディターが表示されているゲームは、スタッター状態からスムーズに行き来します（各状態は数秒間とどまることができます）。 また、このモードでは、スタッターは垂直フレームのティアリングを伴います。 そうは言っても、Firefoxのスクロールでさえ古典的なテーマで涙を流します： 'D

私はdiiiiiiiiiiが抱えているのとまったく同じ問題を抱えています。彼のmove_and_slideユースケースは私のものと同じです。 よく見ると、プレイヤーオブジェクトの揺れではなく、背後の視差の背景です。

キネマティックキャラクターを使用した2Dプロジェクト
Godot 3.0.6
Win1064ビット
Intel i5-2550K CPU
16GBのRAM
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を制限するオプションがいくつか見つかりました。 したがって、私にとっては、v-syncがオフの場合は60 fpsであり、現在は〜4000ではありません。
そして、v-syncをオフにするという事実自体が、私にとっての問題を解決します。

v-syncがウィンドウモードでまったく意味があるのだろうか。 Windowsはそれ自体でv-syncを使用しているようで、おそらくv-sync信号が受信された後より速くフレームを準備するGodotゲームと戦います。 また、IIRCの他のゲームは、ウィンドウモードではなく、v-syncをオフにした状態でフルスクリーンでのみティアリングします。

参考までに、diiiiiiiiiiの問題は代わりにここに続きます：＃25162

v-sync offアプローチに加えて、興味深い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私の考えは、ウィンドウモードでのみv-syncをオフにすることでした（つまり、コードから実行でき、fpsキャップのモニターのリフレッシュレートを照会することもできます）が、コア開発者はこのアプローチをサポートしていないため、何もありませんまだ再考する。 :)他にもWindows固有の方法がありますが、それでも、それらが適切に機能し、ハッキーすぎないことを証明する必要があります。

OPの問題に関する更新。 Godotには、v-syncを使用せずにfpsを制限するオプションがいくつか見つかりました。 したがって、私にとっては、v-syncがオフの場合は60 fpsであり、現在は〜4000ではありません。
そして、v-syncをオフにするという事実自体が、私にとっての問題を解決します。

v-syncがウィンドウモードでまったく意味があるのだろうか。 Windowsはそれ自体でv-syncを使用しているようで、おそらくv-sync信号が受信された後より速くフレームを準備するGodotゲームと戦います。 また、IIRCの他のゲームは、ウィンドウモードではなく、v-syncをオフにした状態でフルスクリーンでのみティアリングします。

どのようにしてfpsを60に制限しましたか？

プロジェクト設定のデバッグカテゴリのどこかで「強制fps」フィールドを使用する

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

OPの問題に関する更新。 Godotには、v-syncを使用せずにfpsを制限するオプションがいくつか見つかりました。 したがって、私にとっては、v-syncがオフの場合は60 fpsであり、現在は〜4000ではありません。
そして、v-syncをオフにするという事実自体が、私にとっての問題を解決します。
v-syncがウィンドウモードでまったく意味があるのだろうか。 Windowsはそれ自体でv-syncを使用しているようで、おそらくv-sync信号が受信された後より速くフレームを準備するGodotゲームと戦います。 また、IIRCの他のゲームは、ウィンドウモードではなく、v-syncをオフにした状態でフルスクリーンでのみティアリングします。
どのようにしてfpsを60に制限しましたか？
—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、スレッドをミュートしてください。

Intel GPUが統合されているI5-2500Kを除いて、システムにCPUを投稿している人を見たことがありません。

私のラップトップには、Intel統合GPUと専用のNvidaカードの両方があります。 2つのGPU /ドライバーとgodotの間に問題があるのではないかと思っています

多分。 しかし、GPU / CPUに依存しているようには見えません。 i7 2700 + 1080tiでは、Intel 4000（第1世代Surface Pro）を搭載したモバイルi5で、フルスクリーンでスタッター（ウィンドウ）とバタースムーズになります。

おかしなことに、940mのラップトップでデモプロジェクトを実行すると、吃音が見られます。 ただし、専用のIntel 530を使用してアプリケーションを実行すると、途切れることはまったくありません。

Windows10ホーム
i3-6100H CPU @ 2.70GHz、
GeForce 940M（26.21.14.3064）
インテル（R）HDグラフィックス530（26.20.100.6709）

このプロジェクトでは吃音が見られますか？ （矢印キーを押して移動します。）

補間をオンのままにして、物理演算を60に設定して、クイックエクスポートを実行しました。
940M時折ジャークがありましたが、せん断はありませんでした
Intel 530にはジャークはありませんでしたが、時には明らかなvsyncシアリングがありました。

私は後でもっとやります、そしてあなたに知らせます。

FPSを60に制限することで、ある程度の成功を収めました。60がマジックナンバーかどうかはわかりませんが、画面は144をサポートできます。上限を144に設定しようとしましたが、途切れが見られました。 FPSを120に下げましたが、スタッターはまだ表示されていましたが、「ぼやけた」ものではなかったため、間隔が短くなっているように見えます。 その後、FPSを80に下げ、以前と同じ結果になりましたが、吃音が目に見えて遅くなりました。 また、v-syncを無効にしてウィンドウモードで実行し、フルスクリーンでテストしましたが、同じ結果になりました。 エンジンに60FPSを上限とするプロセスはありますか？

エンジンに60FPSを上限とするプロセスはありますか？

デフォルトでは、物理は60 FPSでシミュレートされます。これは、レンダリングFPSが物理FPSよりも高い場合に目に見える不一致があることを意味します（表示が違いを示すのに十分な速さである場合）。 物理FPSは、プロジェクト設定で変更できます（[物理]

物理体を補間することで軽減できますが、これに対する公式のサポートはありません。 3.2alphaでは、ノードの補間を容易にするこの平滑化アドオンを使用できます。

エンジンに60FPSを上限とするプロセスはありますか？

デフォルトでは、物理は60 FPSでシミュレートされます。これは、レンダリングFPSが物理FPSよりも高い場合に目に見える不一致があることを意味します（表示が違いを示すのに十分な速さである場合）。 物理FPSは、プロジェクト設定で変更できます（[物理]

物理体を補間することで軽減できますが、これに対する公式のサポートはありません。 3.2alphaでは、ノードの補間を容易にするこの平滑化アドオンを使用できます。

素晴らしい、ありがとう、それは動きが物理プロセスの呼び出しで処理されるときにキャラクターが吃音する理由を説明するかもしれません

それでも3.1.1BTWで再現できますが、最も簡単な方法はFirefoxでShadertoyを開くことです（https://github.com/godotengine/godot/issues/19783#issuecomment-455830124）

私はここで解決策があることを期待して偶然見つけましたが、このスレッドで見たほとんどすべてのアドバイスを試した後、まだサイコロはありませんでした。 私にとって、ジッターはNVIDIAカードでプロジェクトを実行したときにのみ発生します。 統合されたIntelGPUを使用して実行すると、滑らかに実行されます。 ：/

Windows10でGodot3.2の最新のアルファビルドを使用しています

私はここで解決策があることを期待して偶然見つけましたが、このスレッドで見たほとんどすべてのアドバイスを試した後、まだサイコロはありませんでした。 私にとって、ジッターはNVIDIAカードでプロジェクトを実行したときにのみ発生します。 統合されたIntelGPUを使用して実行すると、滑らかに実行されます。 ：/

Windows10でGodot3.2の最新のアルファビルドを使用しています

Windowsでは修正できないと思います。これはLinuxでは発生しません。4.0では新しいvulkanレンダラーで修正される可能性があります。

私はここで解決策があることを期待して偶然見つけましたが、このスレッドで見たほとんどすべてのアドバイスを試した後、まだサイコロはありませんでした。 私にとって、ジッターはNVIDIAカードでプロジェクトを実行したときにのみ発生します。 統合されたIntelGPUを使用して実行すると、滑らかに実行されます。 ：/
Windows10でGodot3.2の最新のアルファビルドを使用しています

Windowsでは修正できないと思います。これはLinuxでは発生しません。4.0では新しいvulkanレンダラーで修正される可能性があります。

残念ながら、Vulkan APIはハイエンドデバイスのみに焦点を当てているのではありませんか？

特にOpenGL2.0をターゲットにしているので、ローエンドデバイスをサポートできます。 2Dゲームのためだけに非常にハイエンドのグラフィックスAPIを使用し、ローエンドのコンピューター/ラップトップを持っている人を締め出すのはちょっとばかげています。 😕

神話のように聞こえます。 たまに吃音をATMで修正できないかもしれませんが、私たちが経験している吃音はGodotのみの機能です。

神話のように聞こえます。

これで何を言っていたのですか？

これは難しい問題です。 一方で、私はこれをできるだけ早く個人的に修正したいと思います。 でも再現できないので、何もできません。 （私はNVidiaグラフィックカードでWindows 10を使用しています）

問題を再現できる人は、残念ながらそれを修正するために刺す必要があります。 :(

これは珍しい問題ですが、このスレッドに多くの人を引き付けるのに十分なほど一般的であるようです。 うまくいけば、あなたの一人がこれに取り組むことができます。

ああ、私が経験していることは、公式のGodotドキュメント用語ではジッターと呼ばれていることを常に忘れています。

_ハードウェアを購入せずに60FPSで問題を完全にキャプチャする方法を知っている人はいますか？_
見た目がいかにくだらないかを過小評価している人もいると思います。また、PCによって見た目が異なる問題かもしれません。

これで何を言っていたのですか？

神話：「これは常にOpenGL（またはWindowsなど）の場合と同じです。Vulkanだけが私たちを救うことができます」。

OK、そう：

1. これはOBSからのビデオです： https ：
2. OBSがないと、shadertoyを含むFirefoxを最小化するまでスムーズです。その後、途切れ始めますが、OBSではキャプチャできません。1。

私自身の録音を削って、これは

@clayjohn物理補間を実装することで修正されると思いますが、reduzは、いくつかの理由でコアに含めることに反対しています。 それでも、現在の物理ステップ比を公開するためのメソッドが3.2alphaに追加されました。これにより、正確な物理補間を手動で実装できます。

@ starry-abyss 3.2alphaを使用できる場合は、lawnjellyのスムージングを実行してください

考えてみれば、非現実的なエンジンやphysXソースで調べるのに役立つものはありますか？

乾杯、
ビクタースタン

2019年10月22日には、4：17 AMで、ヒューゴLocurcioの[email protected]は書きました：

@clayjohn物理補間を実装することで修正されると思いますが、reduzはそれをコアに含めることに反対しています。

@ starry-abyss 3.2alphaを使用できる場合は、lawnjellyのスムージングを実行してください-アドオンを試してみてください🙂

—
あなたがコメントしたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、登録を解除してください。

@victorbstan Unrealのソースコードはオープンソースライセンスの下にないため、見るべきではあり

クローズドソースからコードを削除することは絶対にありませんが、アーキテクチャ的には可能です
これからアイデアを集めませんか？ [弁護士ではありません]

11：07 AMヒューゴLocurcioで火、2019年10月22日には[email protected]
書きました：

@victorbstanhttps ：//github.com/victorbstan見てはいけません
Unrealのソースコード。オープンソースライセンスの下にないため。 （そうではありません
ライセンスのないUnrealEngineユーザーへの再配布も許可します。）

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/godotengine/godot/issues/19783?email_source=notifications&email_token=ACCZK74IFXROY6X64Z2Z6KDQP46NVA5CNFSM4FHBBLY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
または購読を解除する
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
。

@Razzlegames私はまだそのソースコードを見ることをお勧めしません。 独自のアルゴリズムからインスピレーションを得たい場合は、クリーンルームのリバースエンジニアリングを実行して、関連する法的リスクを軽減する必要があります。

それでも、ここでこれを行う必要はありません。 解決策は、現在最も人気のあるゲームエンジンが使用している物理補間を使用することです。 いくつかの欠点（オブジェクトをテレポートするときに補間を回避するためにユーザーの作業が必要になるなど）がありますが、利点はそれらをはるかに上回っていると思います。

私は理解しています、提案は解決策を見つけるための可能な方法のアイデアを得ることであり、必ずしも盗用する必要はありません。 ちらつき/吃音の問題を解決する特許があるとは思いませんが、IANALです。

乾杯、
ビクタースタン

2019年10月22日には、14:07で、ヒューゴLocurcioの[email protected]は書きました：

@victorbstan Unrealのソースコードはオープンソースライセンスの下にないため、見るべきではありません。 （ライセンスのないUnreal Engineユーザーへの再配布も許可されていません。）

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信するか、GitHubで表示するか、登録を解除してください。

私のシナリオでは、ジッター/スタッターが発生した場合でも、Godotプロファイラーは完全な60FPSを示します。 これは、問題が補間に関連していないことを意味しますか、それとも何かが足りないのですか？

私の仮定では、GodotのタイミングはWindowsのコンポジットタイミングに干渉する方法で実装されていました（おそらくSDLはGLFW Godotよりも優れているため、他のエンジンはGodotが失敗した場合にのみ機能します）。

（そしておそらくSDLはGLFWよりも優れているので、他のエンジンはGodotが失敗した場合にのみ機能します）。

Godotは独自のウィンドウ管理コードを使用し、SDLもGLFWも使用しません：slightly_smiling_face：

Windows10とnVidiaGeForce GTX 1070を使用していますが、vsyncを有効にした3.2 alpha2ビルドでは、ウィンドウモードでジッターが発生します。 フルスクリーンモードは問題ないようです。 ゲームの実行時にエディターが最小化されていない場合、この問題は特に深刻です。 私がテストしているゲームは、位置を更新するために_process()のみを使用します。 このため、問題は非常にノイズの多いdeltaまたはドロップされたフレーム（大きなデルタ）に関係していると思われましたが、そうではありませんでした。 deltaは、実際にはジッターの間、安定しています。

このスレッドの他の人の調査に基づいて、 context_gl_windows.cppへの変更をハッキングして、スワップ間隔を0に設定し、 swap_buffers() DwmFlush()を呼び出しました。

#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);部分は、オプションでv-syncをオフにするのと同じように見えます。

wglSwapIntervalEXT（0）;のように見えます。 一部は、オプションでv-syncをオフにするのと同じです。

です。 1 -vsyncを有効にし、 0 -無効にします。また、「適応型vsync」用の-1もあります（低フレームレートで同期を無効にし、高フレームレートで有効にします）。

3.1.xブランチで、単純なケースを使用して、上からDwmFlush（）をテストしました。

• それはshadertoyテストケースの状況を修正します。
• V-syncのオンまたはオフ-私には同じように見えます（wglSwapIntervalEXT（）部分にパッチを適用しませんでした）。
• OBSのケースはまだ揺らいでいますが（私が思うに同じように見えます）、GodotはFPSが40に低下したと報告しています（Godotのプロファイラーは実際に元のGodotバージョンにあるのだろうか）。
• また、SwapBuffers（hDC）の後にDwmFlush（）を呼び出そうとしましたが、3つのポイントはすべて同じままです。

よくわかりませんが、Godotはフレームを最も近いコンポジターの更新ではなく、最も近いコンポジターの更新に配置するため、SwapBuffers（hDC）の後のDwmFlush（）の方が正しいと思います。
Godotは、コンポジターが実行されているかどうかをより適切に検出し、実行されていない場合はバニラv-syncメソッドに戻す必要があるのではないかと思います。

次に、Calinouが言及した新しい補間機能を試してみます。

更新：はい、OBSの場合、Godotは0.03秒の処理時間を報告します（ただし、FPSは60と報告されます）。おそらく、Godot FPSカウンターは、1回おきにv-blankが欠落していることを考慮していません。
更新2：残念ながら、補間プラグインはここでは役に立たないようです。 OBSの場合はまだジッターがあり、shadertoyの場合はスタッターおよび/またはジッターが混在しています

wglSwapIntervalEXT(0);部分は、オプションでv-syncをオフにするのと同じように見えます。

正解ですが、 swap_buffers() DwmFlush()を追加すると、ゲームは同期にコンポジター（DWM）を使用します。 コンポジターが有効になっていると、必要かどうかに関係なく、実質的にダブルバッファリングが可能になります。 OpenGLのスワップ間隔を1に設定した場合、トリプルバッファリングが発生します（2つのバッファとコンポジタのバッファ）。

他のプロジェクトは、呼び出しを入れすぎて私はなぜだろDwmFlush()の前にSwapBuffers() 。 逆に思えますが、私はそれが正しいとほぼ確信しています。

これらのプロジェクトの場合、OpenGLのダブルバッファリング（コンポジターが有効になっている場合）を使用していないため、この方法で行うことは、垂直方向の空白期間と同期するための最良の方法のようです。 OpenGLスワップ間隔が0の場合、 SwapBuffers()の呼び出しはブロックされないため、現在のフレームで終了したことがわかったらすぐに、コンポジターを次のフレームに表示します。 これは、OpenGLスワップ間隔1を使用するのと実質的に同じ効果があります（コンポジターが干渉していない場合-フルスクリーンモードなど）。
>>
>>

Godotは、コンポジターが実行されているかどうかをより適切に検出し、実行されていない場合はバニラv-syncメソッドに戻す必要があるのではないかと思います。

私はあなたが正しいと思います。 コンポジターを有効にすると、OpenGLのv同期が機能しなくなることは明らかです。 glfwとChromiumのコードを見ると、彼らはこれを（ DwmFlush() ）HACKと呼んでいます。 この場合、OpenGLが壊れていると考えており、本来あるべきことをしなければならない可能性があります。

@ starry-abyss OBSのケースが変わらないという投稿を読み直した後、そのプロジェクトでvsyncが有効になっているかどうか疑問に思います。 vsyncを有効にして呼び出しをwglSwapIntervalEXT()変更しなかったため、基本的にゲームはDwmFlush()とSwapBuffers()両方でブロックされます。 それは0.03秒の処理時間を説明します。

@TerminalJackいいえ、すべての組み合わせを試しました。 OBSを実行すると、処理時間は常に0.03に増加します。 Godotは、この数フレームを連続して達成できなかった場合でも、60FPSになるように努力しているようです。

だから私はそれを2つの問題に分けます：
1）Godotはcompositorと友達ではありません。
2）Godotは、最大FPSを達成することに熱心すぎますが、負荷がかかっている場合は安定した30を提供できます。

しかし、0.03が純粋な計算時間であり、同期していないかどうかを（不）証明する信頼できる方法がある場合は、それを試すことができます。

@ starry-abyssテストの目的で、タスクマネージャーを使用してそのプロセスの「優先度」を「高」に上げることができます。 これにより、他のユーザーをプリエンプトし、処理時間の大部分を占めるようになります。 つまり、実行可能な状態にあり、 DwmFlush()および/またはSwapBuffers()ブロックされていない限りです。

今日はこれをいじくり回す機会はあまりありませんでしたが、Intel UHD Graphics 620GPUが統合されたWindows10システムで変更を実行してみました。 （かなりローエンドのGPUです。）

私は最初に最新の3.2alpha2ビルドでゲームを（ウィンドウモードで）実行しましたが、目立ったジッターはありませんでした。 次に、変更を加えてゲームを実行しましたが、問題なく動作しました。

2回の実行中にたまたま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)

（ここで最初の高いデルタは、シーンがロードされた直後に取得されたためです。アルファビルドは同じ動作を示します。）

テストビルドが最終的に落ち着き、定常状態に到達したことに注目してください。 3.2alpha2ビルドは決してしませんでした。

したがって、他のGPUはこの変更によって悪影響を受けないだけでなく、実際にその恩恵を受けると思われます。 私の推測では、GPUがより強力になるにつれてジッターは悪化し、メーカーやドライバーにも依存しません。

この問題を修正する必要がある単一のコミットを持つフォークを作成しました。

私は2台のWindows10マシンでしかテストしていませんが、他の人がそれを構築して他のWindowsバージョンでテストできれば素晴らしいと思います。 また、VC ++ 2019を使用してビルドしたので、mingwを使用している人がビルドできれば、それも素晴らしいことです。

プロジェクトの独自の（最近の）フォークがある場合は、この変更を問題なくパッチで適用できるはずです。

NVidia GTX1050を搭載したWindows10のIm。

シェーダートイを開いて実行していない限り、サンプルプロジェクトで吃音は発生しません（上記のいくつかのコメントで説明したように）。

@TerminalJackのコミットでは、

@clayjohnこれをテストしていただきありがとうございます。 あなたの場合の問題は単に処理能力の問題なのだろうか。

バックグラウンドで800x 450のシェーダートイを実行し、フォアグラウンドのウィンドウでGodotゲーム（エディターから実行）を実行でき、行った変更によるジッターはほとんどありません。 一方、alpha2ビルドには、同じ状況で深刻なジッターがあります。 私はシステムに負荷がかかっていなくてもジッターがひどい人の一人なので、それも考慮に入れるべきことかもしれません。

@TerminalJack良い点。 私はiqの熱帯雨林シェーダーを実行していました:)

ここでも複数の問題が発生している可能性が高いと思います。 @Calinouが上記で指摘したように、多くのユーザーは、補間された物理を使用する場合にも問題が修正されています。

この時点で、コミットをPRする必要があると思います。見栄えがよく、PRを作成すると、コミットの可視性が高まり、他のユーザーがビルドしてテストしやすくなります。

@clayjohnはい、これと同様に動作する他の問題が発生する可能性があることに同意します。

私は実際に、60〜90秒に1回発生する悪いスタッターの問題を追跡しようとし始め、このスレッドに出くわしました。 （60msから100msの間、時々何かがプロセスをブロックしているようです。）ゲームをフルスクリーンモードで実行していましたが、ジッターは発生していませんでした。 しかし、このスレッドに出くわした後、私はそれをウィンドウで実行しようとしました、そして、見よ、私はこの特定の問題を再現することができる幸運な人の一人です。

変更からデバッグステートメントを削除し、数時間以内にPRを送信する可能性があります。

@TerminalJackフォークは使用できなくなりました（またはプライベートに設定されています）。もう一度使用できるようにしてください。

@Calinouごめんなさい。 リポジトリをジャッキアップしたので削除しました。 もう一度フォークして、ここで変更をすぐに再コミットします。

@Calinou新しいコミットはここにあり

@TerminalJackあなたの修正はWindows専用のようですが、Ubuntuでも同じ問題に直面しています。

@TerminalJackあなたの修正はWindows専用のようですが、Ubuntuでも同じ問題に直面しています。

はい、これは間違いなくWindowsのみの修正です。 ごめんなさい。

Ubuntuで同様のことをする必要があるかどうかはわかりません。 コンポジターを使用しているかどうかさえわかりません。

Ubuntuで同様のことをする必要があるかどうかはわかりません。 コンポジターを使用しているかどうかさえわかりません。

実際、一部のウィンドウマネージャー（Ubuntuのデフォルトを含む）では無効にする方法がありません：slightly_smiling_face：

@TerminalJackは、Windows 7などでAeroが無効になっている場合のロジックも必要になる場合があります（IIRCはv-syncしないため、この場合、Godotはおそらくv-sync自体を実行する必要があります）

@ starry-abyss私はその事件が捕らえられることを望んでいます。 Windows7を搭載した古いラップトップを持っています。 それでも機能する場合は、テストを行い、変更が必要かどうかを確認します。

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

私は変更ありと変更なしの両方でプロジェクトを実行しましたが、どちらの方法でも目立った違いはありませんでした。 私の変更では、予想される場合はコンポジターがv同期に使用され（ウィンドウモード、コンポジターが有効）、それ以外の場合はOpenGLダブルバッファーが使用されます。

幸いなことに、_code_に必要な変更はありません。 このコードは、コンポジターが有効になっているかどうかを検出します。 アプリの実行中にコンポジターを有効または無効にする場合も処理します。 ただし、これは私が予測していなかったケースであるため、v-sync戦略がその場で変更される場合についてのswap_buffers()のコメントには含めませんでした。 ですから、私が知る限り、変更する必要があるのはそれだけです。

これ（およびTerminalJackのPR）について今日ircで取り上げられたものの1つは、測定された入力デルタのエラーを出力デルタのエラーから分離することです。

Calinouは、コマンドラインスイッチ--fixed-fps 60して実行することで、これをある程度テストできると指摘しました。 これにより、入力デルタは常に1/60秒であるかのように扱われます。

問題を抱えている人（特にWindows）が、これがジッターに影響を与えるかどうかを知らせてくれると非常に役立ちます。

@lawnjellyコマンドラインオプションの有無にかかわらずすばやく試しましたが、残念ながら今日は問題を再現できません％）OBSの場合を除いて、それはまだ同じです。
エディター間に保存されたオプションの値は偶然に実行されますか？

エディター間に保存されたオプションの値は偶然に実行されますか？

いいえ、これはコマンドライン引数（ステートレス）のみです。

OK。 また、ところで、Godot 3.1.1（ここでほとんどのテストを行うバージョン）で利用できるオプションはありますか？

OK。 また、ところで、Godot 3.1.1（ここでほとんどのテストを行うバージョン）で利用できるオプションはありますか？

3.1.1を使用してこれをテストしている場合、固定のタイムステップ補間がないため、_process中にデルタに比例した距離でオブジェクトを移動する必要があります。

@ starry-abyssそのコマンドライン引数は3.1で追加されたため、3.1.1でも使用できるようになります。

だから、 --fixed-fps 60は私にとってこの問題を助けませんでした。 また、コマンドラインから直接ゲームを実行しても役に立ちませんでした（より速く再現するために、画面上にエディターの別のインスタンスがありました）。

また、 --fixed-fps 60リクエストがこれを暗示している場合に備えて、両方を同時に試しましたが、それでもジッターが発生します。

昨日の再現の難しさは、以前のテストのオプションでv-syncをオフにしていたためです。 ：/

固定のタイムステップ補間はありません。

もちろん、私はメソッドを1つずつテストしていますが、一度にすべてではありません（補間プラグイン+ dwmflush +新しいアイデアとは異なります）。
また、次回は新しいアイデアを試すための具体的な手順を含めてください。Godotのバージョンを推測したり、エディターやゲームを直接実行したりする必要はありません。すべての可能な組み合わせをすべて試したいとは思っていません。組み合わせの量を2倍にするすべてのアイデア）。 ：P

もちろん、私はメソッドを1つずつテストしていますが、一度にすべてではありません（補間プラグイン+ dwmflush +新しいアイデアとは異なります）。
また、次回は新しいアイデアを試すための具体的な手順を含めてください。Godotのバージョンを推測したり、エディターやゲームを直接実行したりする必要はありません。すべての可能な組み合わせをすべて試したいとは思っていません。組み合わせの量を2倍にするすべてのアイデア）。 ：P

ドキュメントに記載されておらず、コアに固定のタイムステップ補間がないため、理解しています。 おそらく私はドキュメントのためにこれについて何かを書いてみるべきです、私は以前にドキュメントを追加していません。

_結果はこれです：_
他の問題（デルタ、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からPRを行っています。

これは、科学的調査と仮説検定の基礎です。 考えは、できるだけ多くの交絡効果を減らし、一度に1つずつ調べることです。

ここでは、主に3つの要素が関係しています。

1）オブジェクトの位置とゲームからの時間の間の線形関係（上記を参照）
2）入力タイミングのエラー
3）出力タイミングのエラー

上記のように（1）を削除します。 コマンドライン引数を使用して（2）を削除すると、（3）を個別に調べることができます。

また、ジッターの調査では、物理学がジッター自体を追加する可能性があるため、物理学を介さずにオブジェクトを直接移動する必要があります。

_編集：_
このスレッドの最小再現プロジェクト（クリープをかわす）を見たところ、_processで速度*デルタで動いています。これは問題ないはずです。 それはis_action_pressedに依存しており、個人的には問題の可能性としてそれを削除しますが、おそらく問題ありません。 ただし、別のプロジェクトを使用してジッタをテストする場合は、上記の点に注意してください。

@lawnjellyなるほど。 私は、補間プラグインもまだ数人の人だけがテストしたものであり、バグがあるかもしれない（そしてジッターを追加するかもしれない）という印象を受けました。 だから私は安定したもの（3.1.1）を採用しました。それが私にとって「科学的」な働き方です。
次回は新しい考慮事項を試してみます。

このスレッドで最小限の再現プロジェクトを見たところです

元のプロジェクトはアニメーションを使用しており（ジッターをマスクできます）、灰色の背景の上に灰色のスプライトがあるため、私は自分のバージョンのプロジェクトを使用しています。 基準を満たすように調整します。

だから、 --fixed-fps 60は私にとってこの問題を助けませんでした。

それは非常に有用な情報です。 これは、人差し指を出力遅延（およびコンポジター）に向けて動かし、PRのアプローチの種類に重みを与えるように見えます。 これは、ダブル/トリプルバッファリングを使用し、パイプラインにフィードを維持し、フレームをドロップしないことを前提としています。

これは、コマンドライン引数を持つ@TerminalJackにも

元のプロジェクトはアニメーションを使用しており（ジッターをマスクできます）、灰色の背景の上に灰色のスプライトがあるため、私は自分のプロジェクトを使用しています。 基準を満たすように調整します。

ああ、ありがとう！ ：+1：

@lawnjellyなるほど。 私は、補間プラグインもまだ数人の人だけがテストしたものであり、バグがあるかもしれない（そしてジッターを追加するかもしれない）という印象を受けました。

少し外れたトピックですが、問題はないはずです（数週間は触れていません）、ジッターを導入するべきではありません。 バグを見つけた場合は、課題追跡システムでお知らせいただくか、PRを行ってください。 ：+1：3.2の公式アドオンに追加するつもりです_私がそれに近づいたとき_：smile:。

@lawnjelly

これは、コマンドライン引数を持つ@TerminalJackにも

申し訳ありませんが、私はあなたの提案を試す機会がありませんでした。 私が取り組んでいる問題について、うさぎの穴を掘り下げました。

@lawnjelly PRスレッドでの議論によると、 --fixed-fps <fps>コマンドラインオプションについてはあなたが正しいと言っておきたいと思いました。 実際、vsyncを有効にしたままにします。 したがって、あなたが言っていたように、それを使用することは、デルタの計算に関する問題を除外するための良い方法です。 以前に試したときにめちゃくちゃになっていたに違いありませんが、今はそうではないので吃音がありました。

私が使用していることを確立するために、私の変化に伴って、そのオプションを使用してきたDwmFlush() 、エディタの外を実行しているときに助けを行います。 DwmFlush()を無効にすると、他のウィンドウをドラッグするか、タスクバーで実行中のタスクの1つにマウスを合わせるだけで、ゲームが途切れる可能性があります。 明らかに、ゲームは「通常より上」の優先度で実行されているため、これは発生しないはずです。 （そして、 DwmFlush()が使用されている場合はそうではありません。）