Godot: Schweres Stottern in einem einfachen 2D-Spiel [Windows 10, Nvidia]

Hallo, ich habe meinen Bericht aktualisiert, weil ich ihn auf meinem anderen Computer (zu Hause) getestet habe und das Problem hier auftritt, während ich die Animation ändere. Dies ist also nicht die Animation, die das Problem verursacht. Ich glaube, ich habe es geglaubt, denn als ich sah, dass es auf meinem Laptop war, hat es einen kleinen Bildschirm. Hier ist ein Video des Problems (das Video hat 60 FPS):
GodotStutter.zip

Wenn das Video eine genaue Darstellung dessen ist, was in Echtzeit auf dem Bildschirm angezeigt wird, dann ist es verdammt viel mehr Stottern, als ich jemals in einem stotternden Problem gesehen habe. Es muss ernsthaft etwas mit diesem Windows 10 / GTX 1060-Setup nicht stimmen (ich sehe einige Artikel im Internet, in denen Leistungsprobleme unter Windows 10 / Nvidia nach größeren Windows-Updates beschrieben werden, kann aber nicht sagen, ob es damit zusammenhängt).

Hier ist ein Video des Testprojekts auf meinem System, Mageia 6 x86_64 (Linux), Nvidia GTX 670MX mit aktuellen proprietären Treibern (390.59). Überhaupt kein Ruckeln (bei Openbox - bei KWin bringt der Compositor die Dinge durcheinander und es gibt alle 10 s oder so ein sehr leichtes Ruckeln).
StutterTest_LinuxNvidia_OK.zip

Übrigens ist hier eine feste Version des Demo-Projekts firstGame_fixed.zip , das ursprüngliche hatte Dateien, die irgendwie auf drei verschiedene Ordner aufgeteilt waren ("firstgame", "firstGame" und "FirstGame").

Das Spiel gibt mir das gleiche Stottern wie im Video.
Durch das Ausschalten von vsync wird das Stottern jedoch vollständig beseitigt (das Spiel läuft jedoch mit 4000 fps).
Windows 10 64 Bit nVidia GTX 1060 auch hier.

Ich habe auch getestet, wie @Zylann hier vorgeschlagen hat, und die gleichen Ergebnisse erzielt. Ich habe auch Win10 x64 und nVidia GTX 1060.

Edit: Ich benutze diese Treiber von nVidia:
398.11-desktop-win10-64bit-international-whql

Win 7 64 Bit GLES2 und GLES3 getestet, GeForce GTX 660 / PCIe / SSE2 ... keine Ruckler. Das Einschalten von Aero mit dem 2D-Editor von Godot hinter dem Spiel führt zu einem kleinen Ruckeln (das Rendern des Godot-Editors stört das Rendern des Spiels).

Godot-Stottern ist jedoch der riesige unsichtbare Feind, wir alle wissen, dass er da ist, aber wir wollen nicht sehr genau hinsehen, weil wir wissen, dass die Lösung nicht einfach ist.

Ihr Problem scheint wie verschiedene physikalisch festgelegte fps mit Monitor-Aktualisierungsrate zu sein. Ich sehe diese Art von Ruckeln in Monitoren, die nicht die gleiche Hz haben, die der Editor für physikalische fps konfiguriert hat, aber eine andere Sache sein kann.

Ihr Problem scheint wie verschiedene physikalisch festgelegte fps mit Monitor-Aktualisierungsrate

Die Demo verwendet keine Physik, nur ein einfaches _process .

Stimmt ... ich sage, dass ich in diesem Fall nur dieses starke Stottern sehe, aber es ist wahr, dass es keinen physikalischen Prozess gibt. Ich teste das Ändern der Hz eines der Monitore und keine Unterschiede, 0 stottern in meiner Ausrüstung.

Bearbeiten: Ich habe Win 7, Win 8.1 und Win 10 in diesem Computer und nehme mir die Zeit, um alle zu testen. Kein Ruckeln bei Sieg 8.1. Ich teste jetzt in Win 10 und bin sehr flüssig ... kein Windows-Problem. Godot ist wütend auf deine 1060?

Hier ist der gleiche Test mit meinem Laptop. Wie Sie sehen, liegt das Problem auch hier. Aber es scheint, dass das weniger sichtbar ist, aber es ist hier.

Laptop-Spezifikationen: Windows 10 - Geforce 940M

Hier ist das Laptop-Video (es ist ein Video mit 60 FPS):
GodotStutterLap.zip

Kann jemand mit dem Stottern-Problem versuchen, die Demo-Änderung in Player.gd _process mit _physics_process auszuführen?

Ich werde heute Abend auf meinem Heim-PC testen. Hier habe ich die ganze Zeit das Problem. Aber ich habe eine seltsame Sache: Heute Morgen habe ich dir ein Video mit dem Projekt auf meinem Laptop gegeben und wie du sehen kannst, hast du die gleiche Art von Stottern. Das Problem ist, dass ich jetzt, wenn ich es erneut starte, dieses Stottern nicht mehr habe, als wäre es zufällig. Und ich habe nichts an meinem Laptop geändert, ich habe den ganzen Morgen an einer TSE-Sitzung daran gearbeitet.

Warnung: Ich spreche nur für meinen Laptop. Auf meinem Heim-PC mit GTX 1060 ist das Problem immer da. Aber auf meinem Laptop scheint das Problem zufällig aufzutreten. Aus diesem Grund denke ich, dass ich meinen Laptop vorerst zu Testzwecken zur Seite stellen und nur auf meinem Heim-PC testen werde, auf dem ständig Probleme auftreten, um den "Fehler" zu isolieren.

@Ranoller Ich habe es getestet und das gleiche Ergebnis

@Ranoller Hat den Test gemacht und das gleiche à @RaXaR , das nichts ändert. Habe das gleiche Problem.

Das sieht nicht gut aus ....

Um den Fehler genau zu spezifizieren, würde ich diese Tests durchführen:

1) Vollbild ein / aus
2) Wenn mehr als 1 Monitor:
Deaktivieren - Freigegebenen Desktop aktivieren
3) Aero ein-aus

Ihre Karten laufen gut andere Spiele? ...

Lesen des ersten Beitrags über die Animation -> Stottern / keine Animation -> kein Stottern Ich lese den Code und sehe einige Dinge, die ich nicht für richtig halte ... genau: Ändern der Animation in jedem Frame. Ich denke, dieser Code sollte die aktuelle Animation überprüfen. Wahrscheinlich hat es nichts geändert, aber wenn jemand möchte, dass der Test Player.gd auf diese Weise ändert:

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)

Dies ist die letzte Idee ... wahrscheinlich eine Nosese für das Problem, aber ... Ihre Grafikkarte ist bei Spielern sehr verbreitet, daher sollte Godot darin gut abschneiden.

@ Ranoller

Zum :

• Der erste Punkt: Bereits im Vollbildmodus versucht oder nicht, es ändert nichts

• 2: Ich habe bereits versucht, mit nur einem Monitor zu arbeiten (das ist meine übliche Konfiguration, aber manchmal habe ich auch einen zweiten Monitor, also habe ich beide ausprobiert), und es ändert nichts.

• 3: Ich muss testen (sollte dies heute Abend tun können (France Time).

• 4: Ich muss Ihren Code testen (sollte dies heute Abend (France Time) tun können.

Habe gerade deinen Code getestet und er ändert nichts :(

Obwohl dieses Problem möglicherweise nicht direkt mit Godot zusammenhängt, muss Godot gut stotternde Probleme überarbeiten ... es ist nicht wahr, dass alle Spiele stottern, wie es in einem anderen Thread gesagt wurde. Heute habe ich n ++ gespielt, Vollbild, mit Fenstern, versucht, ein Stottern zu sehen und nein ... überhaupt kein Stottern. Das Gleiche gilt für Ori und den blinden Wald. Zu viele schlechte Dinge müssen getan werden, um in diesem Spiel zu stottern (Fenster mit anderen Programmen im Hintergrund usw. ... und nur 2 oder 3 Frame-Sprünge in einer Stunde ...). Godot stottert beim Starten der Ausführung immer x Sekunden, später stabilisiert es sich, aber alle X Sekunden werden Frame-Skips angezeigt (wenn Sie natürlich nicht das Problem des GTX1060 haben). Wir sollten dieses Problem nicht als kleines Problem behandeln.

Ich versuche mein Bestes zu geben, um das Problem einzugrenzen, aber auf meiner Ebene ist es ein bisschen schwierig. Ich habe versucht, verschiedene Setups zu testen, aber ohne Ergebnis. Ich habe auch nur ein Hintergrundbild getestet, anstatt eine Farbe mit klarem Bildschirm zu verwenden. Ich habe bereits eine Engine mit diesem Problem gesehen (erinnere mich nicht daran), weil das Rendern eines 2D-Sprites auf einem "leeren Bildschirm" dieses Problem verursacht, aber es scheint, dass dies hier nicht der Fall ist. Ich habe also vorerst keine Ahnung.

Versuchen Sie aus Neugier zu profilieren, wie lange SwapBuffers in Zeile 68 context_gl_win.cpp dauert. Wenn es länger als 16 ms dauert, werden Sie wahrscheinlich hier einen Frame ablegen.

Wenn jemand, der die Quellen von Godot kennt, testen könnte, ob ich am Ergebnis interessiert bin (Entschuldigung für mein Englisch ...)

Ich habe gestern mit diesem Problem gespielt und es hat sich auf magische Weise von selbst gelöst, nachdem das Spielfenster etwa 60 Sekunden lang lief. Dann war es glatt, das sagt mir, dass es eine Caching-Sache sein könnte?

Versuchen Sie aus Neugier zu profilieren, wie lange SwapBuffers in context_gl_win.cpp um Zeile 68 dauert. Wenn es länger als 16 ms dauert, werden Sie hier wahrscheinlich einen Frame ablegen.

Vielleicht könnte es hilfreich sein zu wissen, ob das Problem in GLES2 auftritt. Wir testen das nicht

Ich habe versucht, mit Optionen in Godot zu spielen, aber es ändert nichts für mich. Vielleicht weiß ich nicht genau, was ich ändern soll?

Versucht, das Spiel länger als 2 Minuten laufen zu lassen, aber das Problem ist hier nach 60 s immer nicht für mich gelöst.

Ich hatte ein ähnliches Problem mit 3.0.3. (Win10 64 Bit, Nvidia 660) Ich habe es mit 3.0.2 nicht bemerkt.

Ich denke, es hat etwas mit dem AnimatedSprite-Knoten zu tun, da ich die Leistungsprobleme bei Ebenen sehe, die diesen Knoten haben. Ich bekomme die Schalung, wenn ich von der IDE aus laufe oder wenn ich nach Win 32bit exportiere, aber wenn ich nach Win 64bit exportiere, läuft alles wie es sollte, kein Stottern.

Interessanterweise habe ich kein Problem mit dem Beispielprojekt 'FirstGame.zip' ... aber bei meinem Spiel sinkt der FPS-Wert auf 5, wenn er von der IDE- und 32-Bit-Version ausgeführt wird. Die GPU liegt bei etwa 2%. Aber mit dem 64-Bit-Export liegt die GPU bei 30% und alles ist in Ordnung.

Hallo, gibt es Neuigkeiten zu diesem Problem? Ich habe gerade mit der Pong-Demo getestet (das habe ich vorher nicht gemacht, nur mit dem Tutorial-Spiel) und es scheint, dass das Problem auch bei diesem Beispielprojekt hier liegt. Ich benutze die letzte Version von Godot auf Steam, um es zu testen.

Das Aktualisieren der Nvidia-Treiber hat nichts geändert, daher möchte ich einige Neuigkeiten zu diesem Problem veröffentlichen. Ich habe noch nicht herausgefunden, wie ich damit umgehen kann.

Ich habe jetzt einen Computer mit einem Geforce GTX 1060 (3 GB - billig) und habe das Problem in Windows 10 Home nicht. Es kann eine Hintergrund-App sein? Einige hardwarespezifische Konfiguration AMD-Nvidia Intel-Nvidia ....? Ich habe keine Spielanwendung in diesem Computer (befindet sich in meinem Musikaufnahmestudio), aber Godot läuft auch mit 3 an den Computer angeschlossenen Bildschirmen reibungslos. Jeder, der das Problem hat, kann überprüfen, ob im Hintergrund eine Spielüberwachungssoftware oder Steam oder ähnliches ausgeführt wird ...? Und wenn ja, versuchen Sie es zu lösen?

Es ist schwierig, Steam auszuschalten, wenn Sie Godot damit starten ... Godot läuft großartig. Das Problem ist das Spiel, mit dem Sie machen. Ich habe bereits versucht, alles zu deaktivieren, was ich deaktivieren kann, das ändert nichts. Ich habe viele Tests ohne Erfolg gemacht. Ich habe auch versucht, die NVIDIA-Treiber zurückzusetzen, sie beispielsweise zu aktualisieren usw., aber es ändert sich nichts.

Auf der anderen Seite habe ich eine Reihe von Motoren, die reibungslos laufen. Warum also nicht Godot? Das habe ich versucht zu finden. Aber im Moment finde ich nichts. Irgendwo ist etwas anderes als was und wo, das ist die Frage :-)

Dieses Problem ist zu "engine-dev-spezifisch", um durch eigene Suche eine akzeptable Lösung zu finden. Ich kann stundenlang nach dem Godot-Code suchen und ich weiß, dass es nie eine Möglichkeit geben wird, etwas in diesem Zusammenhang zu finden ... Ich weiß, dass Engine-Entwickler mehr Code für neue Funktionen und "Bugfix" als "Junior-Arbeit" betrachten " oder so ähnlich. Bei dieser Art von Problem ist dies jedoch nicht der Fall. Wir brauchen einige Engine-Entwickler, um dieses Problem automatisch zuzuweisen, und andere Fehlerbehebungen, die "kompliziert, gespenstisch, niedrig, schwer zu leisten" sind ...

Ich erwähne, dass ich bereits die Entwicklerversion (ohne Steam) ausprobiert habe und das Problem dasselbe ist.

Hallo, ich hatte genau das gleiche Stotterproblem (mit Godot 3.1 aus der Git-Quelle), jede Bewegung blieb für mich zurück, genau wie in Ihrem Video, sei es move_and_slide oder nur die Bewegung des Animations-Players. Durch das Einschalten von V-Sync in der Projekteinstellung wurde das Rucklerproblem im 2D-Spiel vollständig gelöst.

Ich bin ein bisschen verwirrt, weil @Zylann sagte, das Ausschalten von V-Sync habe das Stottern beseitigt, aber für mich ist es das Gegenteil.

@Qws, das es ausschaltet UND das Spiel mit mehr als 60 fps laufen lässt (was es zu der Zeit tat), ließ das Stottern für mich verschwinden, aber es bringt andere Probleme mit sich (alle verfügbaren Kräfte nutzen und alles scheitern lassen, was kein richtiges Delta verwendet) Zeit). Wenn Sie bei ausgeschalteter V-Synchronisation stottern, liegt dies entweder an einer falschen Delta-Zeit oder an einer Situation, in der das Spiel länger als ein Frame warten / verarbeiten muss, um den Bildschirm zu aktualisieren.

Der erste Test, den ich mit dem neuen GTX 1060 gemacht habe, ist kein Problem ... aber später spüre ich dieses Stottern. Das einzige, was ich geändert habe, ist die Konvertierung von dvi zu hdmi (und einige installierte Programme) ... das ist ein bisschen komisch. Das einzige, was ich überzeugt habe, ist, dass das Problem nicht in der Windows 10-Seite liegt.

Ich werde so viel sagen. Ich arbeite an einem 2D-Spiel-Tutorial "Hoppy Days" aus den Gamedev.tv-Tutorials. Ich habe 3.0.2 verwendet, um es zu entwickeln, und es hat gut funktioniert. Ich bemerkte, dass das Tutorial 3.0.4 verwendete, also entschied ich mich HEUTE buchstäblich für ein Upgrade auf 3.0.6. Es gibt jetzt eine merkliche Verzögerung im Spiel. Die Verzögerung war in 3.0.2 überhaupt nicht vorhanden . Es ist jetzt da. Alle anderen Einstellungen sind gleich.

Mein Laptop ist ein ziemlich neuer (im März 2017 gekaufter) Gaming-Laptop der Dell Inspiron 7000-Serie. Der Prozessor ist der Intel Core i7-7700HQ Quad Core der 7. Generation (6 MB Cache, bis zu 3,8 GHz). Die Grafikkarte ist NVIDIA GeForce GTX 1050Ti mit 4 GB GDDR5. RAM ist 16 GB, 2400 MHz, DDR4. Die Festplatte ist eine Samsung SSD. Windows 10.

Mir scheint, dass sich entweder in 3.0.4 oder 3.0.6 etwas geändert hat ..... Sonst hat sich überhaupt nichts geändert. Nicht einmal das Spiel (wie in ... Ich habe das Level überhaupt nicht geändert / bearbeitet / aktualisiert).

@ emo10001 Könnten Sie

Wenn Ihr Laptop über Optimus / umschaltbare Grafiken verfügt, hat Ihr System möglicherweise die 3.0.2-Binärdatei für die Verwendung mit der Nvidia-GPU auf die Whitelist gesetzt, während 3.0.3+ standardmäßig ein IGP verwendet. Oder es könnte sein, dass 3.0.2 von Ihrem Antivirenprogramm auf die Whitelist gesetzt wurde, während 3.0.3+ als von einer anderen Quelle stammend angesehen wird (was wahr ist) und noch nicht als sicher eingestuft wurde, sodass das Antivirenprogramm seine vollständigen Überprüfungen durchführt und die Leistung beeinträchtigt.
Dies sind nur Vermutungen, aber ansonsten bin ich mir nicht sicher, welche tatsächliche Godot-Änderung die Leistung so beeinflussen würde, sodass ich nur an Änderungen am Buildsystem denken kann.

CC @hpvb

Ich habe das gleiche Problem! Mein Projekt stottert 20 bis 30 Sekunden lang und läuft danach reibungslos ab. Ich habe das Projekt in OP Post heruntergeladen und es ist genau das gleiche.
Durch Ausschalten von V-Sync wird das Problem behoben und es läuft mit über 4000 fps.

Ich verwende Version 3.0.6 unter Linux Mint 19 (also denke ich, dass das Windows-Tag nicht korrekt ist, oder?) Und GTX 760 mit den neuesten proprietären Treibern.

Ich verwende Version 3.0.6 unter Linux Mint 19 (also denke ich, dass das Windows-Tag nicht korrekt ist, oder?) Und GTX 760 mit den neuesten proprietären Treibern.

Nein, aber dies ist wahrscheinlich ein anderes Problem. Unter Linux stottert es oft aufgrund des Compositing des Fenstermanagers (zum Beispiel habe ich einige mit KWin, keine mit Openbox).

Mein Projekt stottert 20 bis 30 Sekunden lang und läuft danach reibungslos ab

Ich merke das sehr oft, wenn ich eine Szene ausführe, die ich gerade bearbeite, gibt es Stottern und einige Risse (mit eingeschaltetem vsync) ungefähr 15-30 Sekunden, aber wenn ich das Projekt über das Hauptmenü starte und die Szene mit der Szenenauswahl öffne ... nun, es gibt kein Stottern in derselben Szene (es gibt schließlich, aber nie). Gibt es eine Erklärung zu diesem Ereignis? Godot? Windows? Wie viele Frames sind notwendig, um die Reproduktion zu stabilisieren? ... es wird toll sein, diese Dinge zu wissen, weil das Game-Design notwendig ist.

Nein, aber dies ist wahrscheinlich ein anderes Problem.

Hmm, ich verstehe. Was ich damit gemeint habe ist, dass dieses spezielle Problem wahrscheinlich plattformübergreifend ist, da viele Menschen die gleichen Probleme haben.

Ich habe herumgespielt und festgestellt, dass zwei kinematische Körper genau gleichzeitig stottern, sowohl für move_and_slide () als auch für move_and_collide ().

Wenn Sie eine Kamera an eine anschließen, während beide schwingen, ruckelt alles in der Szene, bis auf die beiden kinematischen Knoten. Eine statische Kamera zeigt nur das Stottern der beiden kinematischen Knoten.

Es scheint egal zu sein, welche Grafikeinstellungen ich ändere, noch _process oder _physics_process. Es wird auch keine andere Delta-Variable verwendet.

Ich denke, dass dieses Projekt nicht repräsentativ für den tatsächlichen Gebrauch ist ... kompliziertere Projekte laufen ein bisschen reibungslos. Ich denke, dass Windows mit einer übermäßig großen Leerlaufzeit von Godot nicht gut zurechtkommt ... Ich habe ein anderes verwandtes Problem gefunden, nicht nur für Godot, sondern es leidet auch sehr darunter: In Multimonitor mit erweitertem Desktop-Spiel ist es in Monitor 1 reibungsloser, wenn dies der Fall ist wird wie "primärer Monitor" behandelt. Wenn der primäre Monitor nicht 1 ist, gibt es im sekundären Monitor ein Ruckeln (YouTube leidet darunter, aber keine kommerziellen Spiele wie ori). Mit Vollbild im sekundären Monitor, Aero in Win 7 und getauschten Monitoren (ej: Monitor 2 wie primär) ist die Szenerie die schlechteste und es gibt ein großes Stottern (nicht nur Godot, sondern auch Game Maker oder Unity-Spiele) ... Ich weiß, dass Multimonitor mit erweitertem Desktop in 2 1080p-Bildschirmen für billige GPUs schwierig ist, aber andere Spiele sind flüssiger (man darf keine fps verlieren, nur stottern). Wenn dieser Test fortgesetzt wird, sollten wir ein komplexeres Beispiel machen.

@Ranoller Mein Setup ist ein Dual-Monitor in einem GTX 760, zweiter Monitor als "primär" gekennzeichnet, Linux Mint 19 mit Zimt. Ich habe versucht, den spezifischen Zustand zu verstehen, den das Projekt stottert, konnte es aber nicht herausfinden. Diese kleinen Projekte stottern manchmal, manchmal nicht (nur Stottern, kein FPS-Verlust). Wenn es stottert (in Fenstern ausgeführt wird, Godot-Testkonfigurationen), habe ich normalerweise ein oder mehrere Chromfenster im zweiten Monitor (nicht im primären), und wenn ich sie minimiere, ist das Ruckeln weg ... nach einigem Minimieren / Bei der Restaurierung der Chromfenster ist das Stottern völlig verschwunden.

Ich habe 2 Computer -> einen mit i5 gtx660 2 Bildschirme 1080p und einen mit i7 gtx 1060 3 Bildschirmen (2 1080p und andere hdready) ... nun, ich habe dieses Rucklerproblem im Zusammenhang mit sekundären Monitoren in gtx660, ich denke das ist exklusiv mit Rendering, Godot- und Chrome-Stottern, Game Maker und Unity verbunden (kommerzielle Spiele, genau HiperLightDrifter und Ori, ich habe keine Demos oder Vorlagen getestet). Windows Aero ruckelt mehr im Vollbildmodus (ich denke, es ist nicht wirklich Vollbild), hat aber sehr viel fps, ohne Aero in Win 7 habe ich in meinem Projekt 130-140 fps ohne vsync, mit Aero übergebe ich 400 fps, aber. .. stottert (viel) unter bestimmten Bedingungen (mit und ohne vsync). Ich kann Godot im i7 GTX 1060 nicht zum Stottern bringen (bei echtem Projekt stottert die Demo in diesem Thread und ich erkläre Jet meine Meinung dazu). Ich denke, es ist ein Optimierungs- / OpenGL-Problem, ej: Light2D ist kaum verwendbar. Jeder andere Mix-Modus als "Mix" kann stottern, wenn das System nicht zu leistungsfähig ist, aber Godot sollte die Permormanz auf dem gleichen Level behandeln wie Game Maker oder Unity. Wahrscheinlich könnte nach dem Start von 3.1 die Optimierungsarbeit beginnen (wenn das Problem behoben werden kann und es sich nicht um ein Direct3D / OpenGL - Windows-Problem handelt ... Ich weiß nicht, wie man GLES2 / 3-Spiele in Windows findet, um sie zu testen und zu verwerfen ein direktes OpenGL - Aero / Win7-8-10 Problem) ... Ich verstehe, dass die Permormanz von Godot niemals die gleiche sein wird wie die von Propietary -> eine spielbasierte Engine (Ej: Rayman Ursprünge laufen reibungslos in einem alten Laptop, den ich habe , godot 2 nicht), aber es sollte mindestens auf dem gleichen stabilen Level wie der Spielehersteller sein (Unity wird diesen Godot wahrscheinlich für eine lange Zeit besser optimieren, weißt du, das Geld ...). Im Moment habe ich das Gefühl, dass Godot nur in High-End-Hardware oder in Bildschirmen mit niedriger Auflösung eine gute Leistung erbringt (ich teste in einem i5 win7 32bit 15 "Intel HD-Grafikcomputer und habe eine gute Leistung, aber ich glaube nicht, dass dieser Computer mit einem HD-Bildschirm funktioniert läuft´s godot reibungslos) ...

Natürlich sind das alles meine Meinungen / Erfahrungen, ich kann mich irren (und ich hoffe es zu sein .. wenn dies eine einfache einzeilige Lösung wäre, könnte dies großartig sein !!!)

Andererseits erinnere ich mich daran, Reduz zu lesen und etwas zu schreiben, das mit der "Prozesspriorität" der ausführbaren Godot-Datei zusammenhängt, aber in Windows gibt es keinen Unterschied, wenn Sie die Priorität von Godot in der Ausführung manuell ändern, Godot ist nicht unterdurchschnittlich (was ich habe) ein Wort erfunden?), die Ausführung des Programms hat keine Spitzen, es ist das Rendering, etwas, das mit nvidia / godot und dem Computer-Desktop zu tun hat (in Windows versuche ich es nicht unter Linux)

Hallo, gibt es Neuigkeiten zu diesem Problem? ^^ Ich werde nochmal mit der neuesten Version testen aber es scheint, dass das Problem immer noch da ist.

tut diese Ausfahrt in Android oder ios Plattform jetzt gibt es einige Spiele in Google Store von früh Godot gemacht , dass auch Auslöser problem.like haben: https://play.google.com/store/apps/details?id=com.MoTaiGikStudio .DunkUp

Dies gibt es auf allen getesteten Plattformen unter bestimmten Umständen, mit verschiedenen GPUs und verschiedenen Betriebssystemen ... ist nicht in Konsolen dokumentiert.

Ich habe es sowohl unter Linux als auch unter Windows getestet und es lief reibungslos mit dem gelegentlichen kleinen Stottern. Ich habe eine integrierte Intel HD-Grafik-Baytrail-Grafikkarte

Nachdem ich viele Stunden lang versucht hatte, die Ursache des Stotterns herauszufinden, zumindest in meinem Fall, verfolgte ich zufällig das konsistente 1s-Stottern, bis der "Automatische Wechsel zum Remote-Szenenbaum" in den "Editor-Einstellungen" aktiviert war. Wenn Sie dies deaktivieren, werden die Probleme mit Stottern und Leistung für mich behoben. (Möglicherweise gibt es immer noch ein leichtes Stottern, aber es ist kaum wahrnehmbar.)

Godot Build 8849d3b47de8ab936549f0b9262c1193164feee5
Win10 64bit, NVIDIA GeForce GTX 660, Treiber v416.81

Ich habe auch das stotternde Problem mit meinem Spiel. Das einzige, was es besser zu machen scheint, ist das Ein- und Ausschalten des Vollbildschirms während des Spiels ... Und selbst dann gibt es ein leichtes Stottern, das sich danach einschleicht. Scheint völlig zufällig zu passieren. Manchmal läuft das Spiel nahezu perfekt, manchmal tritt das Stottern auf.

2D-Projekt mit kinematischen Zeichen.
Intel i5-2550K CPU
16 GB RAM
Geforce GTX 970
Win10 64bit
Godot 3.0,6

In Win 10 Stottern passiert mehr im Vollbildmodus, und das liegt daran, dass Aero (und deaktiviert werden kann). Es scheint, dass Godot mit Windows Aero weniger CPU und mehr GPU verwendet, aber dies provoziert mehr Stottern. Wenn Sie in Windows 7 Windows Aero deaktivieren, stottert der Vollbildmodus weniger als im Fenster und benötigt mehr CPU. Ich denke, dass Win 10 keinen echten Vollbildmodus hat ...

Ich habe angefangen, einen Prototyp eines Flipper-2D-Spiels zu machen, und ich habe zu viel Jitter in der Bewegung des Balls. Ich habe nur einen starren Körper, der vor Schwerkraft fällt. Ich bin auf Win10 / NVidia GTX 560 Ti 1Go (mit den neuesten Treibern) / 8 Go Ram, mein Computer ist nicht der beste, aber mein Projekt hat nur einen Ball und StaticBody2D für die Grenzen und ich kann deutlich sehen, dass sehr oft Jitter auftreten Ich habe es mit und ohne vsync versucht, mit opengl 3.0 und 2.0, mit Fenstern und Vollbild, mit mehr und weniger physischen Bildern pro Sekunde, das Problem ist immer noch da.
Meine Godot-Version ist 3.1 Alpha.
Ich denke, es ist ein großes Problem, vielleicht schwer zu beheben, aber das darf nicht übersprungen werden. Es ist wichtig, eine reibungslose 2D-Bewegung für ein 2D-Spiel zu haben.

Sie haben Recht, Godot hat jetzt die bessere Benutzerfreundlichkeit aller Top-Motoren (meine Meinung natürlich). Die Usability-Seite schlägt sie alle. Aber ...... Leistungsseite .... Exportseite .... es ist, als hätte Godot mit dem Betriebssystem geschlagen, nicht wie Unity- oder Game Maker-Exporte, die flüssiger sind (bis das Konstrukt in Chrom flüssiger ist ), und nicht weil GDScript Langsamkeit (passiert mit und ohne GDScript), gibt es "andere unbestimmte Sache", ich hoffe, eines Tages kann jemand eine Rebellenzeile in einer CPP-Datei finden und eine einfache ändern "!" Dieses Problem wird behoben ... (Hoffnung ist frei wie Godot!)

Ich habe mehrere Projekte im Sinn und würde sie gerne mit Godot machen. Es wird viel Zeit in Anspruch nehmen (um nicht meine gesamte Freizeit zu sagen), aber es macht mich traurig zu sagen, dass der Motor dies nicht garantieren kann Eine reibungslose 2D-Bewegung in der Animation mit einer einfachen Szene, die Engine ist trotz all dieser Profis einfach nutzlos. In diesem Fall ist es für mich vielleicht die klügste Wahl, nicht zu riskieren, auf diese Weise Zeit zu verlieren.

Ich verstehe, dass dieses Problem nur in einigen Konfigurationen auftritt (z. B. Windows 10- und NVidia-Treiber), möchte aber Folgendes wissen:

• Ist dieses (oder ein ähnliches) Problem bereits in einem Meilenstein geplant oder nicht?
• Wird dieses Problem möglicherweise beiseite gelegt, um auf den Ersatz von OpenGL durch Vulkan in Meilenstein 3.2 zu warten?

PS: Ich habe es mit einem anderen PC versucht:

• Intel i7 4790K 4,00 GHz
• Win10 64 Bit 16 Go RAM
• NVidia GTX 1060 3Go (mit den neuesten Treibern)
• Godot 3.1 Alpha offiziell
  und ich habe das gleiche Problem mit einfachen Szenen.

Ich denke, diese Art von PC-Konfigurationen (Win10 + Nvidia-Karten) sind sehr kommunikativ und ich hoffe, dass die Godot-Community (die übrigens einen tollen Job macht) dieses Problem sehr bald beheben wird und dass gute 2D-Spiele veröffentlicht werden dass wir mit Godot machen können, aber mit dieser Art von Problem ist es für mich einfach unmöglich.

Vielleicht ist es eine Art Programmfokusproblem? Wenn ich ein Spiel im Vollbildmodus starte, sehe ich das Stottern im Grunde jedes Mal. Aber wenn ich (während das Spiel läuft) in den Fenstermodus und zurück zum Vollbildmodus wechsle, scheint es jedes Mal perfekt zu laufen. Wenn ich auch habe, kann ich dies so programmieren, dass es automatisch passiert, aber es scheint ruckelig. Kann jemand anderes bestätigen, dass das Umschalten von Vollbild auf Fenster auf Vollbild das Stottern wieder behebt?

Bearbeiten: Oh und noch etwas ... Als ich die Geforce Experience App deaktivierte, schien es besser zu werden.

2D-Projekt mit kinematischen Zeichen
Godot 3.0.6
Win10 64bit
Intel i5-2550K CPU
16 GB RAM
Geforce GTX 970

Ich habe versucht, was Sie vorschlagen, ich habe Geforce Experience deaktiviert, versucht, von Vollbild zu Fenster, wieder zu Vollbild zu wechseln, wobei vsync aktiviert und deaktiviert ist (es ist schlimmer, wenn vsync deaktiviert ist), aber das Stottern erscheint mir immer unglücklich.
Es ist ziemlich zufällig, aber ich habe nie über 15-20 Sekunden ohne zu stottern überschritten.

Danke für den Versuch! Das ist so komisch, deine Angaben sind besser als meine. Das Problem bei mir ist, dass es so zufällig ist ... Es ist schwer, genau zu reproduzieren. Manchmal läuft es großartig, manchmal stottert es. Ich bin mir ziemlich sicher, dass es etwas mit Godot selbst zu tun hat. Ich habe nie ein Stottern in Spielen, die in Unity oder einer anderen Spiel-Engine erstellt wurden.

Ich habe gerade dieses Stottern bemerkt.

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

Wie andere bereits erwähnt haben, ist dies ein ernstes Problem für Godot. Diese Woche habe ich beschlossen, einen Prototyp für ein sehr einfaches Spiel zu erstellen. Ich suchte nach einem Framework oder einer Engine (fand ziemlich viele davon) und entschied mich für Godot - da es kostenlos und offen ist. Dann bemerkte ich das Stottern, fand dieses Problem - und war überrascht, dass es keine Fortschritte zu geben scheint. Ich denke, ich werde meine Idee sowieso in Godot prototypisieren. Aber wenn ich ein freisetzbares Spiel erstellen wollte, würde ich wahrscheinlich eine andere Engine ausprobieren. (Das klingt zu hart ... Ich denke nur, Godot könnte viele potenzielle Anwender verlieren, wenn das Problem nicht behoben ist.)

Es gibt keine Fortschritte, weil niemand daran arbeitet, und ja, es ist ein ernstes Problem. Aber für den Moment, wenn Sie ein kommerzielles Spiel veröffentlichen müssen, können Sie Prototypen in Godot erstellen und zur Einheit portieren (Sie können C # verwenden). Sie müssen den Ansatz der Szene-Spielobjekt-Komponente berücksichtigen und können in Godot replizieren. Wenn die Arbeiten für den Flüssigkeitsfluss und die Leistung zur Einheit gehen, oder wenn 2D ist, gehen Sie zum Gamemaker. Ich arbeite in einem Plugin, um zu versuchen, ein Godot-Projekt in andere Engines zu konvertieren und gdscript in ein Modul, in gml oder in Unity C # zu portieren, aber es ist eine sehr große Aufgabe (ich weiß nicht, ob sich der Aufwand lohnt es, zu viel Zeit funktioniert nicht im Spiel) und immer wird unvollkommen sein (ich kann nicht alle Typen bekommen, ej: Objekt durch Kollision zurückgegeben). Ich habe einen kleinen Parser für die Skripte und werde einen Parser für tscn und tres starten, aber das Parser-Ergebnis von gdscript in Unity c # zu konvertieren oder Gamemaker GML erfordert eine Menge Code und ich kenne die "Legalität" darüber nicht (i brauche alle api namen ej. in json dateien und weiß nicht über die IP davon). Animationen sind ein anderes Problem, ich weiß im Moment nicht, wie ich das angehen soll, aber die Verwendung von Wirbelsäule / Drachenknochen ist einfach zu portieren. Meine Hauptidee dabei war, in Godot zu beginnen und in Unity oder GM zu enden, aber für NiW sind Kopfschmerzen ... Wenn Unity gleichermaßen portabel wäre (ich brauche das), würde es sich winzig und schnell wie Godot entwickeln (und 32 Bit haben) editor) Ich habe mein Hauptprojekt vor Monaten portiert, ich liebe Godot, aber für ein mittelgroßes Projekt in einem kleinen Team (oder einem einzelnen Mann wie mir) ist ein Risiko, niemand garantiert Ihnen, dass ein abgeschlossenes Projekt nicht viel bringt Probleme. Aber wenn es einen guten C ++ - Programmierer in Ihrem Team gibt, können Sie Godot immer an Ihr Spiel anpassen (in der Einheit können Sie nicht, aber es ist weniger fehlerhaft) ....
Ich hasse dieses Problem, wie ich die geringe Leistung des Editors in einem mittleren Projekt und das exportierte Spiel hasse, aber ich hasse mehr Einheit (warum brauche ich Internet auf allen Computern, um den Editor zu öffnen? Ich habe einen Computer ohne das!) Und hasse So tief visuelles Studio ... Ich bin mir sicher, dass wir großartige Upcomming-Spiele sehen können, wenn Godot das Stottern aufhört und an Leistung und Export arbeitet.

Um dieses Problem heute noch einmal zu überprüfen, habe ich Folgendes getan, immer noch unter Windows 10 mit nVidia GTX 1060:

Ich öffnete die Bindung von Isaac im Fenstermodus. Lief im Kreis, kein Stottern (damit meine ich mindestens 30 Sekunden lang). Ich weiß nicht, ob das Spiel V-Sync hat oder nicht, es hat keine solche Einstellung.

Ich habe Minecraft im Fenstermodus geöffnet. Geladen eine flache Welt mit Blick auf den Boden, wo es keine Verzögerung geben würde, kein Stottern.

Ich habe Factorio geöffnet, immer noch im Fenstermodus, mit einer ziemlich großen Endspielfabrik. Lief in einer geraden Linie, kein Stottern. Die V-Synchronisierung ist jedoch deaktiviert. Wenn ich es einschalte und das Spiel neu starte ... immer noch kein Stottern.

Ich habe ein altes Java-Spiel geöffnet, das ich mit Slick2D (OpenGL) erstellt habe, kein einziges Stottern (ich habe noch kein Oo gesehen). Beim Überprüfen der Optionen wurde die V-Synchronisierung aktiviert. Wenn ich die V-Synchronisierung ausschalte, stottert ich jede Sekunde oder so regelmäßig. Wenn ich die Framerate-Kappe verdopple, bekomme ich kein Stottern.

Jetzt habe ich mit Godot 3.1 alpha3 ein 3D-Projekt mit einer Karte mit einigen Assets und einem sich bewegenden Charakter eröffnet: Fast kein Ruckeln, ich kann nur alle 20 Sekunden nur eines sehen, was zu subtil ist, um es zu stören.

Ich habe auch mein 2D-Projekt Wallrider ausprobiert, das ich in Godot 3.0.6 portiert habe: dasselbe, nicht genug Stottern, um sich die Mühe zu machen (zufällig eines pro 20 Sekunden).

Alle oben genannten Projekte haben Folgendes gemeinsam: Sie zeichnen nicht nur ein Sprite auf dem Bildschirm.

Wenn ich das Testprojekt @crystalnoir mit Godot 3.1 alpha3 ausprobiere, bekomme ich sofort ein unregelmäßiges, häufiges Stottern, das nur verschwindet, wenn ich nach der letzten Anzeige / Maximierung etwa 30 Sekunden warte. Ich habe versucht, zu _physics_process wechseln, und habe sogar delta = 1.0 / 60.0 ausprobiert, es ist alles das Gleiche. Wenn ich delta , zeigt dies, dass es jede Sekunde eine Schwankung gibt, aber das Spiel zeigt mehrmals pro Sekunde Ruckler, die delta überhaupt nicht widerspiegeln. Es passiert auch, wenn ich das Spiel ohne Editor starte.
Ich habe auch versucht, es auf Godot 2.1.5 zu portieren, und das gleiche Problem tritt auf (Projekt: Stuttering_issue19783.zip )

Und hier wird es interessant:
Wenn ich sowohl mein 3D-Spiel als auch den Test von öffne , laufen beide sofort reibungslos. Das 2D-Spiel stottert zwar noch ein wenig, aber nicht so sehr. Wenn ich das 3D-Spiel schließe, scheint es immer noch gut zu funktionieren, aber wenn ich das 2D-Spiel reduziere und es wieder maximiere, geht es zurück zu schrecklichen Stottern.

Es ist noch nicht das Ende!
Ich habe jetzt versucht, dem 2D-Spiel eine 3D-Kamera hinzuzufügen. Und auf magische Weise wird das Stottern drastisch reduziert, und zwar sofort, indem Sie dies einfach tun.
Sie können dies selbst mit PlayerWith3D scene: Stuttering_issue19783.zip versuchen
Sehen Sie, wie reibungslos es standardmäßig ist. Klicken Sie jetzt auf die Schaltfläche magic und sehen Sie, wie es zum Scheißen kommt, wenn keine 3D-Umgebung angezeigt wird (es wird zwar nicht immer zu 100% geschissen, aber ich sehe, dass PlayerWith3D.tscn immer besser aussieht als Player.tscn ).

Ich würde gerne noch weiter gehen und sehen, was passiert, wenn ich das nVidia-Kontrollfeld von Optimal Power (Standardeinstellung) auf Maximum performance ändere, aber ... ähm ...

Wie auch immer, alles, was ich daraus erraten kann, ist (aber es ist eine Vermutung, also nimm es mit einem Körnchen Salz): Es ist nicht direkt Godots Schuld. Es sind Grafiktreiber, die versuchen, "schlau" zu sein.

Für den Gott der Stotterer !!! 😂😂😂

Wirf das einfach raus ... Ab November 2018 sind Nvidia die 14 besten Grafikkarten bei Steam. Schauen wir uns die Top-Karten in jeder GPU-Kategorie an:

NVIDIA GeForce GTX 1060: 14,60% der Steam-Benutzer.
AMD Radeon R7 Graphics: 1,06% der Steam-Nutzer.
Intel HD Graphics 4000: 1,06% der Steam-Benutzer.

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

Angesichts der oben genannten Daten scheint es, dass dieses Problem oberste Priorität haben sollte. Eine überwältigende Mehrheit der Spieler verwendet Nvidia-Karten, dies ist bei weitem die häufigste Konfiguration. Die Anzahl der Radeon- und Intel-Grafikbenutzer ist im Vergleich dazu winzig.

@Ranoller ... Du bringst mich um. Es ist das Lächerlichste, was ich je gehört habe, Menschen zu sagen, sie sollen in Godot Prototypen erstellen, aber für ihren kommerziellen Titel (in einem Godot-Themen-Thread) nach Unity portieren.

@Zylann Ich habe versucht, den Energieverwaltungsmodus erfolgreich auf "Maximale Leistung ausführen" zu setzen, aber keine Verbesserung beim Stottern festgestellt.

@ behelit2 Nichts für ungut

@Zylann Ich habe eine 3D-Kamera, die ein Netz rendert, vor eine Szene gestellt, die eine Tilemap mit animierten Texturen rendert, und das Problem, dass Godot einige Sekunden nach dem Verstärkungsfokus stottert, ist nicht behoben. Es gibt bisher keine andere Art von Sttuter (nur die "Initiale") in dieser Szene, daher weiß ich nicht, ob dieser Trick etwas behebt, aber es ist interessant, dass Sie es entdecken. Ich werde mit Ihnen Dateien testen. Ich denke auch, dass die Leerlaufzeit etwas im Computer "faul" macht, aber wahrscheinlich das Betriebssystem ist, weil die Unterschiede beim Gewinn mit und ohne Aero in FPS, CPU-Auslastung und Stottern so groß sind. Wahrscheinlich ist das Betriebssystem, das versucht, klug zu sein, und nicht die Grafikkarte.

Ich mag die Idee von Zylann, zu analysieren, was andere Spiele tun. Ich weiß nicht, ob dies offtopisch ist, aber ich habe einige Tests gemacht.
Zunächst scheint es, dass 95% der Steam-Spiele 32-Bit sind (auch die jüngsten Versionen). Es scheint, dass gleich viel Prozent der Spiele von DirectX gerendert werden. Ich fange die Prozesse ein, die Spiele ausführen, und versuche zu sehen, was mit dem Rendern passiert. Einige Infos dahinter (Ist nicht für irgendwelche Schlussfolgerungen, ist nur Info):

Spiel / Ausführbare Bits / Engine / Prozess, der zum Rendern in Windows 7 64-Bit und Notizen verwendet.

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

• Ori und der blinde Wald -> 32 Bit / Unity / Windows GDI. Führt einen Prozess namens OPENGL32 wie godot aus, ist jedoch eine Art Wrapper in Windows GDI. Kein einziger Anruf von OpenGL32, alle Anrufe kommen von Windows GDI.
  

• Staub: Ein Elysyian-Schwanz -> 32 Bit / Microsoft XNA / Windows GDI. Hat gameoverlayrenderer.dll und alle Aufrufe kommen von diesem (ClientToScreen). Hat keine OpenGL-DLL.

• SuperMeatBoy -> 32 Bit, Ausführung in Steam Overlay, Windows GDI

• ΔV: Ringe des Saturn (Demo) -> 64 Bit, godot / Führt OpenGL- und Windows GDI-Aufrufe aus, führt einen einzelnen Aufruf von OpenGl SwapBuffers - GetPixelformat mit dem Wert 8 durch. Führen Sie viele Aufrufe von Windows GDI durch. Doppelte Anrufe tätigen? zu WindowsFromDC-SetRect (Fenstergröße), OffsetRect.
  

• Bastion -> 32 Bit / SDL2 / Führt reine OpenGL-Aufrufe aus, kein Windows GDI, führt einen eindeutigen Aufruf von swapBuffers - GetPixelFormat mit einem Wert von 10 durch.

• SouthPark der Stick der Wahrheit -> 32 Bit / Unknow Engine / Führt alle Aufrufe in Windows GDI aus, scheint direct3D v 9 (hat d3d9.dll, führt aber nur geringe Aufrufe durch diesen Prozess aus), die meisten Aufrufe stammen vom Gameoverlayrenderer von Steam und uxtheme.dll führt OffsetRect und IsRectEmpty sowie andere Fensterfunktionen aus.
  

• Sinus Mora -> 32 Bit / Unknow Engine / Führt alle Aufrufe in Windows GDI per Steam-Overlay aus, dicect3d 9

• Apotheon -> 32 Bit / Microsoft XNA / Alle Aufrufe in Windows GDI, ein einzelner Aufruf von Steam Overlay (Client zu Bildschirm), ein einzelner Aufruf von Microsoft XNA (ScreenToClient) und Aufrufe von einem Prozess namens uxtheme.dll (Fensterverwaltung in Windows?) zu IsRectEmpty und PtInrect (alle Booleschen Werte).
• Eier kehren nach Hause zurück -> 64 Bit / Godot / Anrufe von OpenGL und von Windows GDI, genau wie Ring of Saturn.
• Guacamelee! Super Turbo .... -> 32 Bit / Unknow Engine, aber für die Dateien kann Sinus Mora ähnlich sein. Dieses Spiel ermöglicht die Größenänderung des Bildschirms. / Alle Anrufe von Windows GDI.
• Kein Held -> 32 Bit / SDL2 (Wikipedia sagt ClickTeam Fusion) / Alle Aufrufe von Windows GDI Directx 9.
• Schatten des Krieges in Mittelerde -> 64 Bit (ja, es gibt einen) / Intro sagt Firebird, bisher nichts über Prozesse / Alle Aufrufe von Windows GDI, aber es gibt sehr, sehr wenige Aufrufe, wenige in den anderen Spielen, Einige Anrufe pro Sekunde (ej, Sie können Godot-API-Anrufen kaum folgen, es gibt Tonnen pro Sekunde). Aber dieses Spiel brennt de GPU.

Ich stelle fest, dass die meisten Spiele im Fokus verloren gehen und den Prozess stoppen und pausieren (vielleicht eine gute Übung?). Bei sehr wenigen Spielen können Sie die Größe des Bildschirms manuell ändern (ej: kein Held). Leider habe ich das stotternde Problem des Fokusverlusts / Fokusgewinns in ΔV: Ringe des Saturn (Demo).

Bearbeiten: Es scheint, dass Godot die einzige Engine ist, die gleichzeitig OpenGL32- und WindowsGDI-Prozesse verwendet.
Verwendete App: API Monitor v2

(Bearbeiten: Richtiger Name von ΔV: Ringe des Saturn (Demo))

Wenn Sie mit Saturnringen ΔV: Saturnringe (Demo) meinen, wurde es mit Godot 3.1 erstellt, aber ich bin mir nicht sicher, welche genaue Revision sie verwendet haben?

Nachdem ich viele Stunden lang versucht hatte, die Ursache des Stotterns herauszufinden, zumindest in meinem Fall, verfolgte ich zufällig das konsistente 1s-Stottern, bis der "Automatische Wechsel zum Remote-Szenenbaum" in den "Editor-Einstellungen" aktiviert war. Wenn Sie dies deaktivieren, werden die Probleme mit Stottern und Leistung für mich behoben. (Möglicherweise gibt es immer noch ein leichtes Stottern, aber es ist kaum wahrnehmbar.)

Godot baut 8849d3b
Win10 64bit, NVIDIA GeForce GTX 660, Treiber v416.81

Ich hatte das gleiche stotternde Problem und das Deaktivieren von Auto Switch to Remote Tree war der Schuldige.

Ich habe hier das gleiche Problem. Es gibt mehrere Probleme mit diesem Jitter, aber die meisten scheinen keine richtigen Lösungen zu haben, und ich brauche wirklich Hilfe.

Ich bin dabei, mit meinem Spiel, das ich mit Godot gemacht habe, einen Vertrag mit einem Publisher zu unterschreiben, und wegen des Jitters muss ich möglicherweise alle meine Codes nach Unity verschieben. Zeit und Kosten, um alle Codes beiseite zu legen, ich zögere es, auf einen anderen Motor umzusteigen, weil mir die Designphilosophie von Godot und Godot selbst sehr gefällt.

Ich habe auch festgestellt, dass in 3.1 die Option 'Physics Jitter Fix' im Einstellungsmenü hinzugefügt wurde (https://twitter.com/reduzio/status/984783032459685890), aber das hilft auch nicht.

Godot-Version:
Godot 3.0.6

Betriebssystem / Gerät einschließlich Version:
MacOS 10.14.1
MacBook (Retina, 12 Zoll, 2017)
1,2 GHz Intel Core m3
8 GB 1867 MHz LPDDR3
Intel HD Graphics 615 1536 MB
(Dieses Problem tritt jedoch auf mehreren Geräten auf, einschließlich PC und exportiertem Spiel auf Mobilgeräten und PCs.)

Fehlerbeschreibung:
Jedes Objekt, das sich bewegt, scheint regelmäßig zu stottern oder zu zittern, begleitet von einem Einfrieren des Bildschirms.

Schritte zum Reproduzieren:
Erstellen Sie ein neues Projekt mit einem KinematicBody2D oder sogar einem AnimatedSprite und ändern Sie die Position mit move_and_slide () oder set_position (), nachdem Sie eine Camera2D als untergeordneten Knoten hinzugefügt haben. (Dies geschieht jedoch auch ohne Camera2D.)

Und es scheint häufiger auf Geräten mit geringer Verarbeitungsleistung zu passieren.

Minimales Reproduktionsprojekt:
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 Bit, GTX 660 (Treiber 391.35), Godot 3.0.6 und 3.1-beta1

Hey, ich habe das ursprüngliche Projekt optimiert (Animationen gestoppt, starre Körper verwendet, anstatt Positionen manuell anzupassen, einen leicht animierten Hintergrund hinzugefügt usw.)

Hier ist es: FirstGame_2.zip

Getestet mit einem Fenster mit einer Größe von ~ 500x500 und einer Monitorauflösung von 1920x1080

Nun meine Beobachtungen:

• Jitter ist omnidirektional (nicht nur vertikal, wie bei normalen vsync-Problemen)
• Je kleiner die Fenstergröße ist, desto häufiger tritt Jitter auf
• Durch Deaktivieren von vsync wird Jitter entfernt (die nächsten Aufzählungspunkte sind vsync aktiviert).
• Wenn Sie das Spiel gleichzeitig ohne den Editor auf dem Bildschirm ausführen (minimieren Sie es, es handelt sich also nur um Desktop-Symbole, Hintergrundbilder, Taskleisten und möglicherweise einige statische Fenster wie Dateimanager oder Terminal), wird Jitter entfernt
• Exportiertes Spiel oder Ausführen aus dem Editor spielt keine Rolle
• Wenn ich das Spiel mit quakespasm-sdl2 auf demselben Bildschirm starte (wobei ein Zombie den Spieler unter Wasser angreift), sehe ich wenig Jitter
• Wenn ich das Spiel mit einer Shadertoy-Site (diese Demo: https://www.shadertoy.com/view/ll3fz4) ohne Pause auf demselben Bildschirm starte, sehe ich viel Jitter
• Wenn ich das Spiel mit einer Shadertoy-Site starte, aber auf demselben Bildschirm pausiere, sehe ich wenig Jitter
• Wenn ich das Spiel mit dem Editor auf demselben Bildschirm starte und eine im Editor angezeigte Szene nicht aktualisiert wird (Player.tscn), sehe ich wenig Jitter
• Wenn ich das Spiel mit dem Editor auf demselben Bildschirm starte und eine im Editor viel Jitter

Haben Sie es nicht mit ausgeschaltetem Aero versucht und vergessen, wie man es schnell hin und her schaltet?

@ starry-abyss, um Aero auszuschalten, zum Konfigurationsfenster zu gehen, "Erscheinungsbild und Personalisierung" zu wählen, dort sollten Sie in der Lage sein, zu einem alten Thema wie "Windows Classic" zu wechseln, das keine visuellen Effekte bietet (und dann nicht) t Aero) oder "Windows 7 Classic" verwenden.

OK, mit dem klassischen Thema wechselt das Spiel mit Shadertoy / Editor auf dem Bildschirm vom Stottern zum Glätten (jeder Zustand kann mehrere Sekunden lang bestehen bleiben). Und Stottern geht in diesem Modus mit einem vertikalen Rahmenriss einher. Das heißt, sogar Firefox Scrolling Tränen mit dem klassischen Thema: 'D.

Ich habe genau das gleiche Problem, das diiiiiiiii hat. Sein Anwendungsfall mit move_and_slide ist der gleiche wie meiner. Wenn Sie genau hinschauen, zittert nicht das Spielerobjekt, sondern der Parallaxenhintergrund dahinter.

2D-Projekt mit kinematischen Zeichen
Godot 3.0.6
Win10 64bit
Intel i5-2550K CPU
16 GB RAM
Geforce GTX 970

Da dies auf vielen verschiedenen Arten von Geräten geschieht, glaube ich nicht, dass dies eng mit Hardwarekonfigurationen zusammenhängt. Dies geschieht sogar bei exportierten Spielen, die auf iOS-Geräten ausgeführt werden.

Wenn Sie genau hinschauen, zittert nicht das Spielerobjekt, sondern der Parallaxenhintergrund dahinter.

@ behelit2 Da bin ich mir allerdings nicht sicher. https://youtu.be/YVFtkbuyqEQ Wenn Sie sich in diesem Filmmaterial das Player-Objekt ansehen, wackelt es sogar von selbst. Es kann ein separates Problem sein, aber es wird viel schlimmer, wenn die Kameraglättung aktiviert ist oder das Objekt auf Rigidbody2D umgeschaltet wird.

https://youtu.be/MGMlhl0tPTA
Dies geschieht, wenn die Kameraglättung aktiviert ist und das Objekt auf Rigidbody2D umgeschaltet wird.

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)

Ich habe das Jittering möglicherweise durch die Verwendung von apply_impulse () verstärkt, aber das direkte Ändern der Position des Objekts mit set_position () hat keinen großen Unterschied gemacht.

@diiiiiiiii Ich denke, Sie sollten dann ein separates Problem offen haben. Andernfalls ist der Thread voller widersprüchlicher Aussagen, weil Leute verschiedene Dinge testen.
Zum Beispiel versuche ich vorerst das OP-Projekt, nicht deins (sorry).

@ starry-abyss Verstanden;)
Obwohl es bereits viele Probleme mit Jitter gibt und ich denke, dass sie eng miteinander verbunden sind und möglicherweise dieselbe Grundursache haben.

Update zum OP-Problem. Ich habe in Godot einige Optionen gefunden, um die fps ohne Verwendung von v-sync zu begrenzen. Für mich sind es also 60 fps ohne V-Sync und nicht ~ 4000 jetzt.
Und schon das Ausschalten von V-Sync behebt das Problem für mich.

Ich frage mich, ob V-Sync im Fenstermodus überhaupt Sinn macht. Windows scheint V-Sync für sich zu verwenden, und wahrscheinlich kämpft es mit dem Godot-Spiel, das den Frame schneller vorbereitet, nachdem das V-Sync-Signal empfangen wurde. Auch IIRC andere Spiele reißen nur im Vollbildmodus mit ausgeschalteter V-Sync und nicht im Fenstermodus.

Zu Ihrer Information, das Problem von diiiiiiiii wird stattdessen hier fortgesetzt: # 25162

Neben dem V-Sync-Off-Ansatz habe ich einen interessanten Windows-spezifischen Weg gefunden (anhand der Commit-Beschreibung könnte es sich um dieses Problem handeln). Ich bin mir nicht sicher, ob Godot dies bereits verwendet, aber vielleicht hat jemand Zeit, es zu versuchen:
https://github.com/glfw/glfw/commit/8309e0ecb09fe5cf670dff5df1e7ca71821c27bd
Auch dies ist verwandt: https://bugzilla.mozilla.org/show_bug.cgi?id=1127151

Es gibt jedoch auch diesen Thread, der detaillierter und mit unterschiedlichen Ansätzen behandelt wird:
https://bugs.chromium.org/p/chromium/issues/detail?id=467617
Und dies ist komplementär, kürzer und auf den Punkt gebracht, aber auch mit einigen Emotionen am Anfang: https://www.vsynctester.com/firefoxisbroken.html

Das Stotterwort wurde in meinem obigen Bericht in Jitter geändert, da ich dies erlebt habe (siehe https://docs.godotengine.org/en/latest/tutorials/misc/jitter_stutter.html).

@ByTheQuietLake Meine Idee war, die V-Synchronisierung nur im Fenstermodus auszuschalten (dh sie kann über Code ausgeführt werden und möglicherweise sogar die Aktualisierungsrate des Monitors nach fps cap abfragen), aber da Core-Entwickler den Ansatz nicht unterstützen, gibt es nichts noch zu überdenken. :) Es gibt andere Windows-spezifischere Möglichkeiten, aber wir müssen noch beweisen, dass sie gut funktionieren und nicht zu hackig sind.

Update zum OP-Problem. Ich habe in Godot einige Optionen gefunden, um die fps ohne Verwendung von v-sync zu begrenzen. Für mich sind es also 60 fps ohne V-Sync und nicht ~ 4000 jetzt.
Und schon das Ausschalten von V-Sync behebt das Problem für mich.

Ich frage mich, ob V-Sync im Fenstermodus überhaupt Sinn macht. Windows scheint V-Sync für sich zu verwenden, und wahrscheinlich kämpft es mit dem Godot-Spiel, das den Frame schneller vorbereitet, nachdem das V-Sync-Signal empfangen wurde. Auch IIRC andere Spiele reißen nur im Vollbildmodus mit ausgeschalteter V-Sync und nicht im Fenstermodus.

Wie hast du deine fps auf 60 begrenzt?

Verwenden Sie das Feld "Force fps" irgendwo in der Debug-Kategorie der Projekteinstellungen

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

Update zum OP-Problem. Ich habe in Godot einige Optionen gefunden, um die fps ohne Verwendung von v-sync zu begrenzen. Für mich sind es also 60 fps ohne V-Sync und nicht ~ 4000 jetzt.
Und schon das Ausschalten von V-Sync behebt das Problem für mich.
Ich frage mich, ob V-Sync im Fenstermodus überhaupt Sinn macht. Windows scheint V-Sync für sich zu verwenden, und wahrscheinlich kämpft es mit dem Godot-Spiel, das den Frame schneller vorbereitet, nachdem das V-Sync-Signal empfangen wurde. Auch IIRC andere Spiele reißen nur im Vollbildmodus mit ausgeschalteter V-Sync und nicht im Fenstermodus.
Wie hast du deine fps auf 60 begrenzt?
- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder schalten Sie den Thread stumm.

Ich habe keine Leute gesehen, die ihre CPUs mit Systemen gepostet haben, außer I5-2500K mit integrierter Intel-GPU.

Mein Laptop verfügt sowohl über eine Intel-integrierte GPU als auch über eine dedizierte Nvida-Karte. Ich frage mich nur, ob es ein Problem zwischen den beiden GPU / Treibern und Godot geben könnte

Könnte sein. Aber es sieht nicht nach GPU / CPU-abhängig aus. Auf dem i7 2700 + 1080ti kann es auf dem Mobile i5 mit Intel 4000 (1st Gen Surface Pro) stotternd (mit Fenstern) und butterweich sein - im Vollbildmodus.

Komisch sollte man sagen, wenn ich das Demo-Projekt auf meinen Laptops 940m starte, sehe ich das Stottern. Wenn ich die Anwendung jedoch mit dem dedizierten Intel 530 ausführe, sehe ich überhaupt kein Stottern.

Windows 10 nach Hause
i3-6100H CPU bei 2,70 GHz,
GeForce 940M (26.21.14.3064)
Intel (R) HD Graphics 530 (26.20.100.6709)

Ist das Stottern in diesem Projekt sichtbar? (Bewegen Sie sich durch Drücken der Pfeiltasten.)

Ich habe gerade einen schnellen Export durchgeführt, die Interpolation aktiviert und die Physik auf 60 gesetzt:
940M gab es gelegentlich Rucke, aber keine Scherung
Intel 530 gab es keine Idioten, aber manchmal offensichtliche vsync Scherung,

Ich mache später mehr und lass es dich wissen.

Ich hatte anscheinend einige Erfolge mit der Begrenzung meiner FPS auf 60. Ich bin mir nicht sicher, ob 60 eine magische Zahl ist. Mein Bildschirm kann 144 unterstützen. Ich habe versucht, die Obergrenze auf 144 zu setzen, aber das Stottern war immer noch sichtbar. Ich habe meine FPS auf 120 gesenkt, das Stottern war immer noch sichtbar, aber nicht als "verschwommen", was mich denken lässt, dass es nur in einem niedrigeren Intervall auftritt. Anschließend wurde die FPS auf 80 gesenkt und das gleiche Ergebnis wie zuvor erzielt, das Stottern jedoch jetzt sichtbar langsamer. Außerdem sollte ich sagen, dass ich die V-Synchronisierung deaktiviert und im Fenstermodus ausgeführt habe. Ich habe mit Vollbild getestet, aber das gleiche Ergebnis. Gibt es Prozesse im Motor, die auf 60 FPS begrenzt sind?

Gibt es Prozesse im Motor, die auf 60 FPS begrenzt sind?

Standardmäßig wird die Physik mit 60 FPS simuliert, was bedeutet, dass eine sichtbare Diskrepanz auftritt, wenn die Rendering-FPS höher als die Physik-FPS sind (vorausgesetzt, die Anzeige ist schnell genug, um den Unterschied anzuzeigen). Die Physik-FPS können in den Projekteinstellungen ( Physik> Allgemein> Physik-FPS) geändert werden.

Es kann durch Interpolation von Physikkörpern gelindert werden, aber es gibt keine offizielle Unterstützung dafür. In 3.2alpha können Sie dieses Glättungs-Add-On verwenden, das das Interpolieren von Knoten erleichtert.

Gibt es Prozesse im Motor, die auf 60 FPS begrenzt sind?

Standardmäßig wird die Physik mit 60 FPS simuliert, was bedeutet, dass eine sichtbare Diskrepanz auftritt, wenn die Rendering-FPS höher als die Physik-FPS sind (vorausgesetzt, die Anzeige ist schnell genug, um den Unterschied anzuzeigen). Die Physik-FPS können in den Projekteinstellungen ( Physik> Allgemein> Physik-FPS) geändert werden.

Es kann durch Interpolation von Physikkörpern gelindert werden, aber es gibt keine offizielle Unterstützung dafür. In 3.2alpha können Sie dieses Glättungs-Add-On verwenden, das das Interpolieren von Knoten erleichtert.

Genial, danke, das könnte erklären, warum Charaktere stottern, während die Bewegung im Physikprozessaufruf behandelt wird

Kann immer noch in 3.1.1 BTW reproduziert werden. Am einfachsten ist es, wenn Shadertoy in Firefox geöffnet ist (https://github.com/godotengine/godot/issues/19783#issuecomment-455830124).

Ich stolperte hierher und hoffte, dass es eine Lösung geben würde, aber nachdem ich fast jeden Rat ausprobiert hatte, den ich in diesem Thread gesehen hatte, gab es immer noch keine Würfel. Für mich tritt das Jitter nur auf, wenn ich das Projekt auf der NVIDIA-Karte ausführe. Wenn ich es mit der integrierten Intel-GPU ausführe, läuft es seidenweich. : /

Ich verwende den neuesten Alpha-Build von Godot 3.2 unter Windows 10

Ich stolperte hierher und hoffte, dass es eine Lösung geben würde, aber nachdem ich fast jeden Rat ausprobiert hatte, den ich in diesem Thread gesehen hatte, gab es immer noch keine Würfel. Für mich tritt das Jitter nur auf, wenn ich das Projekt auf der NVIDIA-Karte ausführe. Wenn ich es mit der integrierten Intel-GPU ausführe, läuft es seidenweich. : /

Ich verwende den neuesten Alpha-Build von Godot 3.2 unter Windows 10

Ich glaube nicht, dass Sie es unter Windows reparieren können, dies passiert nicht unter Linux, dies könnte in 4.0 mit dem neuen Vulkan-Renderer behoben werden.

Ich stolperte hierher und hoffte, dass es eine Lösung geben würde, aber nachdem ich fast jeden Rat ausprobiert hatte, den ich in diesem Thread gesehen hatte, gab es immer noch keine Würfel. Für mich tritt das Jitter nur auf, wenn ich das Projekt auf der NVIDIA-Karte ausführe. Wenn ich es mit der integrierten Intel-GPU ausführe, läuft es seidenweich. : /
Ich verwende den neuesten Alpha-Build von Godot 3.2 unter Windows 10

Ich glaube nicht, dass Sie es unter Windows reparieren können, dies passiert nicht unter Linux, dies könnte in 4.0 mit dem neuen Vulkan-Renderer behoben werden.

Nun, das ist scheiße, konzentriert sich die Vulkan-API nicht nur auf High-End-Geräte?

Ich ziele speziell auf OpenGL 2.0 ab, damit ich Low-End-Geräte unterstützen kann. Es ist ein bisschen albern, eine sehr hochwertige Grafik-API nur für ein 2D-Spiel zu verwenden und Leute mit Computern / Laptops der unteren Preisklasse auszuschließen. 😕

Klingt nach einem Mythos. Vielleicht kann das Stottern von Zeit zu Zeit nicht am Geldautomaten behoben werden, aber das Stottern, das wir erleben, ist eine reine Godot-Funktion.

Klingt nach einem Mythos.

Worauf haben Sie sich damit bezogen?

Dies ist ein herausforderndes Thema. Einerseits möchte ich dieses Problem so schnell wie möglich persönlich beheben. Aber ich kann nicht reproduzieren, also kann ich nichts tun. (Ich verwende Windows 10 mit einer NVidia-Grafikkarte)

Jemand, der das Problem reproduzieren kann, muss leider versuchen, es zu beheben. :(

Obwohl es ein ungewöhnliches Problem ist, scheint es häufig genug zu sein, um viele Leute auf diesen Thread aufmerksam zu machen. Hoffentlich kann einer von euch daran arbeiten.

Ah, ich vergesse immer, dass das, was ich erlebe, in offiziellen Godot-Dokumenten als Jitter bezeichnet wird.

_Wusst jemand, wie man das Problem mit 60 FPS perfekt erfasst, ohne Hardware zu kaufen? _
Ich denke, einige Leute unterschätzen, wie beschissen es aussieht, und vielleicht sieht es auch auf verschiedenen PCs anders aus.

Worauf haben Sie sich damit bezogen?

Der Mythos: "Das ist unter OpenGL (oder Windows usw.) immer so. Nur Vulkan kann uns retten."

OK, also:

1. Dies ist ein Video von OBS: https://www.youtube.com/watch?v=osbJlk1XD8c Die Auswirkung von OBS ist, dass nur das Ausführen von OBS diesen Jitter im Godot-Projekt verursacht (selbst wenn die Erfassung deaktiviert ist).
2. Ohne OBS ist es glatt, bis ich Firefox mit Shadertoy unminimiere, dann beginnt es zu stottern, kann aber nicht mit OBS erfassen, weil 1.

In meiner eigenen Aufnahme wird dies mit Bandicam gemacht und zum größten Teil wird dies mit oder ohne Aufnahme ausgeführt. Wie Sie sehen können, beginnt es reibungslos, hat aber allmählich Probleme

@clayjohn Ich denke, es würde durch die Implementierung der Physikinterpolation behoben, aber Reduz ist aus einigen Gründen dagegen, es im Kern zu haben. Dennoch wurde in 3.2alpha eine Methode hinzugefügt, um das aktuelle Physikschrittverhältnis aufzudecken, die es ermöglicht, eine genaue Physikinterpolation manuell zu implementieren.

@ starry-abyss Wenn Sie 3.2alpha verwenden können, probieren Sie das Smoothing -Addon von Lawnjelly aus: leicht_smiling_face:

Nur ein Gedanke, gibt es irgendetwas Nützliches in einer unwirklichen Engine oder einer physX-Quelle, das man sich ansehen kann?

Prost,
Victor Stan

Am 22. Oktober 2019, um 4:17 Uhr, schrieb Hugo Locurcio [email protected] :

Wenn Sie
@clayjohn Ich denke, es würde durch die Implementierung der Physikinterpolation behoben, aber Reduz ist dagegen, es im Kern zu haben.

@ starry-abyss Wenn Sie 3.2alpha verwenden können, probieren Sie das Smoothing-Addon von Lawnjelly aus 🙂

- -
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder melden Sie sich ab.

@victorbstan Wir sollten uns den Quellcode von Unreal nicht ansehen, da er nicht unter einer Open Source-Lizenz steht. (Es erlaubt nicht einmal die Weiterverteilung an nicht lizenzierte Unreal Engine-Benutzer.)

Heben Sie auf keinen Fall Code aus einer geschlossenen Quelle an, aber architektonisch können Sie das
keine Ideen daraus gewinnen? [kein Anwalt]

Am Dienstag, 22. Oktober 2019, um 11:07 Uhr Hugo Locurcio [email protected]
schrieb:

@victorbstan https://github.com/victorbstan Wir sollten nicht schauen
Unreals Quellcode, da er nicht unter einer Open Source-Lizenz steht. (Es tut nicht
erlauben sogar die Weiterverteilung an nicht lizenzierte Unreal Engine-Benutzer.)

- -
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/godotengine/godot/issues/19783?
oder abbestellen
https://github.com/notifications/unsubscribe-auth/ACCZK7Z7E4F3NCHQNS2SHX3QP46NVANCNFSM4FHBBLYQ
.

@Razzlegames Ich würde immer noch nicht empfehlen, sich den Quellcode Reinraum-Reverse Engineering durchführen , um das damit verbundene rechtliche Risiko zu verringern.

Trotzdem müssen wir hier nichts davon tun. Die Lösung besteht in der Verwendung der Physikinterpolation, die heutzutage von den meisten gängigen Spiele-Engines verwendet wird. Es hat einige Nachteile (z. B. das Erfordernis der Arbeit des Benutzers, um eine Interpolation beim Teleportieren von Objekten zu vermeiden), aber ich denke, die Vorteile überwiegen bei weitem.

Ich verstehe, der Vorschlag ist, sich ein Bild von möglichen Wegen zu machen, um eine Lösung zu finden, und nicht unbedingt zu plagiieren. Ich würde mir nicht vorstellen, dass es ein Patent für die Lösung von flackernden / stotternden Problemen gibt, aber IANAL.

Prost,
Victor Stan

Am 22. Oktober 2019, um 14:07 Uhr, schrieb Hugo Locurcio [email protected] :

Wenn Sie
@victorbstan Wir sollten uns den Quellcode von Unreal nicht ansehen, da er nicht unter einer Open Source-Lizenz steht. (Es erlaubt nicht einmal die Weiterverteilung an nicht lizenzierte Unreal Engine-Benutzer.)

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail, zeigen Sie sie auf GitHub an oder melden Sie sich ab.

In meinen Szenarien zeigt der Godot-Profiler perfekte 60 FPS, selbst wenn ich Jitter / Stottern sehe. Bedeutet dies, dass das Problem nicht mit der Interpolation zusammenhängt, oder fehlt mir etwas?

Ich ging davon aus, dass Godot-Timings so implementiert wurden, dass sie die Compositor-Timings von Windows beeinträchtigen (und SDL macht es möglicherweise besser als GLFW Godot, daher funktionieren andere Engines nur dort, wo Godot ausfällt).

(und vielleicht macht SDL es besser als GLFW, daher funktionieren andere Engines nur dort, wo Godot ausfällt).

Godot verwendet seinen eigenen Fensterverwaltungscode, es verwendet weder SDL noch GLFW: leicht_smiling_face:

Ich habe Windows 10 und eine nVidia GeForce GTX 1070 und mit dem Build 3.2 alpha2 mit aktiviertem vsync im Fenstermodus Jitter. Der Vollbildmodus scheint in Ordnung zu sein. Das Problem ist besonders schlimm, wenn der Editor beim Ausführen des Spiels nicht minimiert wird. Das Spiel, mit dem ich teste, verwendet nur _process() , um Positionen zu aktualisieren. Aus diesem Grund vermutete ich, dass das Problem mit einem sehr lauten delta oder ausgelassenen Frames (großen Deltas) zu tun hatte, aber das ist nicht der Fall. Das delta ist während des Jitters tatsächlich felsenfest.

Basierend auf den Recherchen anderer in diesem Thread habe ich eine Änderung in context_gl_windows.cpp , um das Swap-Intervall auf 0 zu setzen und DwmFlush() in swap_buffers() aufzurufen.

#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;
}

Dies basiert auf den Aufgaben der Chromium- Projekte.

Durch diese Änderung wird der Jitter im Fenstermodus behoben. Im Vollbildmodus ist das Spiel gerissen, sodass das DWM wahrscheinlich deaktiviert ist und eine doppelte Pufferung über einen Intervallwert von 1 erforderlich zu sein scheint. (Grundsätzlich muss der Code das tun, was er gerade tut.)

Wenn jemand anderes bereit und in der Lage ist, dies auszuprobieren, würde mich interessieren, wie es geht.

Es sieht so aus, als ob wglSwapIntervalEXT(0); Teil dasselbe ist wie das Deaktivieren der V-Synchronisierung in Optionen.

Es sieht aus wie wglSwapIntervalEXT (0); Teil ist dasselbe wie das Ausschalten der V-Synchronisierung in Optionen.

Es ist. 1 - vsync aktivieren, 0 - deaktivieren, und es gibt auch -1 für "adaptives vsync" (Synchronisierung bei niedrigen Bildraten deaktivieren, bei hoher aktivieren).

Ich habe das DwmFlush () -Ding von oben mit meinen einfachen Fällen auf dem 3.1.x-Zweig getestet.

• Es behebt die Situation mit dem Shadertoy-Testfall.
• V-Sync ein oder aus - sieht für mich gleich aus (ich habe den Teil wglSwapIntervalEXT () nicht gepatcht);
• Der OBS-Fall ist immer noch nervös (sieht meiner Meinung nach genauso aus), aber Godot meldet jetzt einen Rückgang der FPS auf 40 (ich frage mich, ob der Profiler in Godot tatsächlich mit der ursprünglichen Godot-Version liegt).
• Ich habe auch versucht, DwmFlush () nach SwapBuffers (hDC) aufzurufen, und alle 3 Punkte bleiben gleich.

Ich bin mir nicht sicher, aber ich denke, DwmFlush () nach SwapBuffers (hDC) ist möglicherweise korrekter, da Godot den Frame in das Update des nächsten Compositors einfügt, nicht in das nächste, das nach dem nächsten liegt.
Ich frage mich, ob Godot besser erkennen sollte, ob Compositor ausgeführt wird, und zur Vanilla V-Sync-Methode zurückkehren sollte, wenn dies nicht der Fall ist.

Als nächstes wird die von Calinou erwähnte neue Interpolationsfunktion vorgestellt.

UPDATE: Ja, im OBS-Fall meldet der Godot eine Prozesszeit von 0,03 Sekunden (der FPS wird jedoch als 60 angegeben). Wahrscheinlich berücksichtigt der Godot-FPS-Zähler nicht, dass der V-Rohling jedes Mal fehlt
UPDATE 2: Leider scheint das Interpolations-Plugin hier nicht zu helfen. Ich habe immer noch Jitter im OBS-Fall und Stottern und / oder Jitter-Mix im Shadertoy-Fall

Es sieht so aus, als ob wglSwapIntervalEXT(0); Teil dasselbe ist wie das Deaktivieren der V-Synchronisierung in Optionen.

Richtig, aber wenn Sie DwmFlush() in swap_buffers() hinzufügen, verwendet das Spiel den Compositor (DWM) für die Synchronisierung. Wenn der Compositor aktiviert ist, haben Sie effektiv doppelte Pufferung, ob Sie es wollen oder nicht. In dem Fall, in dem Sie das Swap-Intervall von OpenGL auf 1 setzen, haben Sie eine dreifache Pufferung. (Ihre beiden Puffer und die des Compositors.)

Ich frage mich auch, warum die anderen Projekte DwmFlush() vor SwapBuffers() aufrufen. Es scheint rückwärts zu sein, aber ich habe mich fast davon überzeugt, dass es richtig ist.

Bei diesen Projekten wird die Doppelpufferung von OpenGL nicht verwendet (wenn der Compositor aktiviert ist). Daher scheint es der beste Weg zu sein, sich mit der vertikalen Leerperiode zu synchronisieren. Bei einem OpenGL-Swap-Intervall von 0 wird der Aufruf von SwapBuffers() nicht blockiert, sodass Sie dem Compositor den nächsten Frame präsentieren, sobald Sie wissen, dass er mit dem aktuellen abgeschlossen ist. Dies hat effektiv den gleichen Effekt wie die Verwendung eines OpenGL-Swap-Intervalls von 1. (Wenn der Compositor nicht stört - zum Beispiel im Vollbildmodus.)
>
>

Ich frage mich, ob Godot besser erkennen sollte, ob Compositor ausgeführt wird, und zur Vanilla V-Sync-Methode zurückkehren sollte, wenn dies nicht der Fall ist.

Ich glaube, Du hast recht. Es scheint offensichtlich, dass die V-Synchronisierung von OpenGL unterbrochen wird, wenn der Compositor aktiviert ist. Wenn Sie sich den Code von glfw und Chromium ansehen, nennen sie dies (unter Verwendung von DwmFlush() ) einen HACK. Es ist wahrscheinlich, dass sie denken, OpenGL sei in diesem Fall kaputt und müssen etwas tun, was es tun sollte.

@ starry-abyss Nachdem ich Ihren Beitrag über den sich nicht ändernden OBS-Fall erneut gelesen habe, frage ich mich, ob für dieses Projekt vsync aktiviert ist. Da Sie den Aufruf nicht in wglSwapIntervalEXT() geändert haben und vsync aktiviert hat, blockiert das Spiel im Grunde genommen sowohl DwmFlush() als auch SwapBuffers() . Das würde die Prozesszeit von 0,03 Sekunden erklären.

@TerminalJack Nein, ich habe alle Kombinationen ausprobiert. Die Prozesszeit erhöht sich immer auf 0,03, wenn ich OBS ausführe. Es ist nur so, dass Godot sich sehr bemüht, 60 FPS zu erreichen, selbst wenn dies nicht mehrere Frames hintereinander erreichen konnte.

Also würde ich es in zwei Ausgaben aufteilen:
1) Godot ist nicht mit dem Komponisten befreundet;
2) Godot ist zu eifrig, um maximale FPS zu haben, während es unter Last nur stabile 30 liefern könnte.

Aber wenn es einen zuverlässigen Weg gibt, um zu (dis) beweisen, ob 0.03 reine Rechenzeit ist und nicht synchronisiert, kann ich es versuchen.

@ starry-abyss Zu Testzwecken können Sie den Task-Manager verwenden, um die Priorität dieses Prozesses auf "hoch" zu erhöhen. Dies führt dazu, dass es die anderen vorwegnimmt und ihm den Löwenanteil der Verarbeitungszeit einräumt. Das heißt, solange es sich in einem ausführbaren Zustand befindet und nicht in DwmFlush() und / oder SwapBuffers() blockiert ist.

Ich hatte heute keine große Chance, damit herumzuspielen, aber ich habe versucht, die Änderung auf einem Windows 10-System mit integrierter Intel UHD Graphics 620-GPU auszuführen. (Eine ziemlich Low-End-GPU.)

Ich habe das Spiel zum ersten Mal (im Fenstermodus) mit dem neuesten 3.2 alpha2 Build ausgeführt und es hatte keinen merklichen Jitter. Ich habe dann das Spiel mit den Änderungen ausgeführt und es hat auch gut funktioniert.

Ich habe zufällig die delta -Zeiten während der beiden Läufe protokolliert und festgestellt, dass sie mit dem Aufruf von DwmFlush() viel stabiler waren als ohne ...

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)

(Die hohen Deltas am Anfang hier sind darauf zurückzuführen, dass diese direkt nach dem Laden der Szene aufgenommen wurden. Der Alpha-Build zeigt dasselbe Verhalten.)

Beachten Sie, wie sich der Testaufbau schließlich beruhigte und einen stabilen Zustand erreichte. Der 3.2 alpha2 Build hat es nie geschafft.

Es scheint also, dass andere GPUs von dieser Änderung nicht nur nicht beeinträchtigt werden, sondern tatsächlich davon profitieren werden. Ich vermute, dass der Jitter schlimmer wird, wenn die GPU leistungsfähiger wird und es nicht vom Hersteller oder sogar von den Treibern abhängt.

Ich habe einen Fork mit einem einzigen Commit erstellt , der dieses Problem beheben soll.

Ich habe es jedoch nur auf zwei Windows 10-Computern getestet. Es wäre also großartig, wenn andere Leute es erstellen und auf anderen Windows-Versionen testen könnten. Außerdem habe ich es mit VC ++ 2019 erstellt. Wenn also jemand mit mingw es erstellen könnte, wäre das auch großartig.

Wenn Sie einen eigenen (aktuellen) Zweig des Projekts haben, sollten Sie in der Lage sein, diese Änderung problemlos zu patchen.

Ich bin auf Windows 10 mit einer NVidia GTX 1050.

Ich habe kein Stottern im Beispielprojekt, es sei denn, ich habe ein offenes und laufendes Shadertoy (wie oben in einigen Kommentaren beschrieben).

Mit @TerminalJacks Commit ist das Stottern immer noch vorhanden, wenn Shadertoy ausgeführt wird.

@clayjohn Danke, dass hast . Ich frage mich, ob das Problem in Ihrem Fall nur eine Frage der Rechenleistung ist.

Ich kann ein 800 x 450 Shadertoy im Hintergrund und ein Godot-Spiel (vom Editor ausgeführt) in einem Fenster im Vordergrund ausführen und bekomme sehr wenig Jitter mit den Änderungen, die ich vorgenommen habe. Der Alpha2-Build hingegen weist unter den gleichen Umständen starken Jitter auf. Ich gehöre zu den Personen, die auch ohne Belastung meines Systems starken Jitter haben. Das sollte wahrscheinlich auch berücksichtigt werden.

@ TerminalJack Guter Punkt. Ich habe den Regenwald-Shader von iq ausgeführt :)

Ich denke, es besteht auch eine hohe Wahrscheinlichkeit, dass hier mehrere Probleme im Spiel sind. Wie @Calinou oben ausgeführt hat, haben viele Benutzer das Problem auch bei Verwendung der interpolierten Physik behoben.

An diesem Punkt denke ich, dass Sie Ihr Commit PR machen sollten, es sieht gut aus und eine PR macht es sichtbarer und erleichtert anderen Benutzern das Erstellen und Testen.

@clayjohn Ja, ich stimme zu, dass es wahrscheinlich andere Probleme gibt, die sich ähnlich verhalten.

Ich habe tatsächlich versucht, ein Problem mit einem schlechten Stottern aufzuspüren, das alle 60 bis 90 Sekunden auftritt, und bin auf diesen Thread gestoßen. (Es scheint, als würde ab und zu etwas den Prozess für 60 bis 100 ms blockieren.) Ich habe mein Spiel im Vollbildmodus ausgeführt und es gab keinen Jitter. Nachdem ich auf diesen Thread gestoßen war, habe ich versucht, ihn in einem Fenster auszuführen, und siehe da: Ich bin einer der Glücklichen, die dieses spezielle Problem reproduzieren können.

Ich werde wahrscheinlich die Debugging-Anweisungen aus meinen Änderungen entfernen und in ein paar Stunden eine PR senden.

@TerminalJack Die Gabel ist nicht mehr verfügbar (oder sie ist privat).

@Calinou Entschuldigung. Ich habe das Repository aufgebockt und es gelöscht. Ich werde es wieder gabeln und die Änderungen hier in Kürze erneut festschreiben.

@Calinou Das neue Commit ist da .

@TerminalJack Ihr Fix scheint nur für Windows zu sein, aber ich habe das gleiche Problem unter Ubuntu.

@TerminalJack Ihr Fix scheint nur für Windows zu sein, aber ich habe das gleiche Problem unter Ubuntu.

Ja, dies ist definitiv ein Windows-Fix. Es tut uns leid.

Ich weiß nicht, ob es notwendig ist, unter Ubuntu etwas Ähnliches zu tun oder nicht. Ich bin mir nicht mal sicher, ob es einen Compositor verwendet.

Ich weiß nicht, ob es notwendig ist, unter Ubuntu etwas Ähnliches zu tun oder nicht. Ich bin mir nicht mal sicher, ob es einen Compositor verwendet.

Tatsächlich gibt es keine Möglichkeit, es auf einigen Fenstermanagern zu deaktivieren (einschließlich Ubuntus Standard): leicht_smiling_face:

@TerminalJack Benötigt möglicherweise auch eine Logik, wenn Aero in z. B. Windows 7 deaktiviert ist (IIRC synchronisiert nicht v, daher sollte Godot sich in diesem Fall wahrscheinlich selbst v-synchronisieren).

@ starry-abyss Ich hoffe, dass der Fall gefangen wird. Ich habe einen alten Laptop mit Windows 7. Wenn es immer noch funktioniert, werde ich einige Tests damit durchführen und prüfen, ob Änderungen erforderlich sind.

Ich habe meinen 10 Jahre alten Laptop mit Windows 7 gestartet und meine Änderungen getestet. Ich musste das einfachste Projekt zum Testen verwenden. (Laptop-GPUs waren damals extrem schlecht.) Ich habe das Projekt aus diesem Beitrag verwendet. Ich habe Folgendes hinzugefügt, damit ich in den Vollbildmodus wechseln kann.

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

Ich habe das Projekt sowohl mit als auch ohne Änderungen ausgeführt und es gab keine merklichen Unterschiede. Bei meinen Änderungen würde der Compositor erwartungsgemäß für die V-Synchronisierung verwendet (Fenstermodus, Compositor aktiviert), und in allen anderen Fällen würde die OpenGL-Doppelpufferung verwendet.

Die gute Nachricht ist, dass am _code_ keine Änderungen erforderlich sind. Der Code erkennt, ob der Compositor aktiviert ist oder nicht. Es wird sogar der Fall behandelt, in dem Sie den Compositor aktivieren oder deaktivieren, während die App ausgeführt wird. Dies ist ein Fall, den ich jedoch nicht vorausgesehen habe, sodass ich ihn nicht in die Kommentare in swap_buffers() Bezug auf die Fälle, in denen sich die V-Synchronisierungsstrategie im laufenden Betrieb ändert. Soweit ich weiß, muss ich das nur ändern.

Eines der Dinge, die heute auf irc angesprochen wurden, um dies (und die PR von TerminalJack) zu diskutieren, ist das Isolieren von Fehlern im gemessenen Eingangsdelta von Fehlern im Ausgangsdelta.

Calinou wies darauf hin, dass wir dies bis zu einem gewissen Grad testen können, indem wir mit dem Befehlszeilenschalter --fixed-fps 60 . Dadurch wird das Eingangsdelta so behandelt, als ob es immer eine 1/60 Sekunde beträgt.

Es wäre sehr hilfreich, wenn diejenigen, die das Problem haben (insbesondere unter Windows), uns mitteilen könnten, ob dies Auswirkungen auf den Jitter hat.

@lawnjelly Ich habe es schnell mit und ohne Befehlszeilenoption versucht, aber leider kann ich das Problem heute nicht wiederholen.%) Außer OBS-Fall, der immer noch der gleiche ist.
Wird der Wert der zwischen dem Editor gespeicherten Option zufällig ausgeführt?

Wird der Wert der zwischen dem Editor gespeicherten Option zufällig ausgeführt?

Nein, es ist nur ein Befehlszeilenargument (das zustandslos ist).

IN ORDNUNG. Übrigens, ist die Option in Godot 3.1.1 verfügbar (die Version, auf der ich die meisten Tests hier durchführe)?

IN ORDNUNG. Übrigens, ist die Option in Godot 3.1.1 verfügbar (die Version, auf der ich die meisten Tests hier durchführe)?

Wenn Sie dies mit 3.1.1 testen, müssen Sie Objekte während des _process um eine Entfernung bewegen, die proportional zum Delta ist, da keine feste Zeitschrittinterpolation erfolgt.

@ starry-abyss Dieses Befehlszeilenargument wurde in 3.1 hinzugefügt, daher sollte es auch in 3.1.1 verfügbar sein.

Also, --fixed-fps 60 hat mir bei dem Problem nicht geholfen. Und das direkte Ausführen des Spiels über die Befehlszeile hat auch nicht geholfen (ich hatte jedoch immer noch eine separate Instanz des Editors auf dem Bildschirm, um die Wiedergabe zu beschleunigen).

Und auch beide gleichzeitig ausprobiert, falls die --fixed-fps 60 -Anforderung dies impliziert, immer noch nervös.

Die Schwierigkeit, gestern zu reproduzieren, war, weil ich die V-Synchronisierung in Optionen aus früheren Tests deaktiviert hatte. : /

Es gibt keine feste Zeitschrittinterpolation.

Natürlich teste ich Methoden einzeln, nicht alle auf einmal (nicht wie Interpolations-Plugin + dwmflush + jede neue Idee).
Bitte geben Sie beim nächsten Mal auch die spezifischen Schritte an, um die neue Idee auszuprobieren, damit ich keine Godot-Versionen erraten, keinen Editor oder kein Spiel direkt ausführen muss usw. Ich habe nicht den Wunsch, alle möglichen Kombinationen von allem (mit) auszuprobieren jede Idee verdoppelt die Anzahl der Kombinationen). : P.

Natürlich teste ich Methoden einzeln, nicht alle auf einmal (nicht wie Interpolations-Plugin + dwmflush + jede neue Idee).
Bitte geben Sie beim nächsten Mal auch die spezifischen Schritte an, um die neue Idee auszuprobieren, damit ich keine Godot-Versionen erraten, keinen Editor oder kein Spiel direkt ausführen muss usw. Ich habe nicht den Wunsch, alle möglichen Kombinationen von allem (mit) auszuprobieren jede Idee verdoppelt die Anzahl der Kombinationen). : P.

Ich verstehe, da es in den Dokumenten nicht erwähnt wird und es im Kern keine feste Zeitschrittinterpolation gibt. Vielleicht sollte ich versuchen, etwas dazu für die Dokumente zu schreiben, ich habe noch keine Dokumentation hinzugefügt.

_Das Ergebnis ist: _
Unabhängig von anderen Problemen (Delta, Betriebssystem), wenn Sie Physik verwenden oder Objekte in _physics_process verschieben, verursacht Godot derzeit Jitter aufgrund des Aliasing zwischen Physik-Ticks und tatsächlichen Frames. Dies tritt in gewissem Maße bei allen Kombinationen aus Physik-Tickrate und Monitor-Bildwiederholfrequenz auf, einige sind schlechter als andere.

Die 'Jitter Fix'-Methode war ein Versuch, dieses Aliasing zu umgehen, indem es weniger ausgeprägt auftrat (es wird immer noch auftreten). Denken Sie an Treppen-Aliasing.

Um diesen Jitter auf Basisniveau zu vermeiden, müssen Sie dies derzeit entweder tun
1) (Verfügbar in allen Godot-Versionen) Verschieben Sie Objekte in _process und um eine Entfernung, die proportional zum Delta ist. Dies ist nicht ideal für Spiele, da Sie keine Physik verwenden können und das Verhalten von der Bildrate abhängt. Für Jitter-Tests ist es jedoch in Ordnung.

2) (Verfügbar ab Godot 3.2) Verwendete feste Zeitschrittinterpolation. Dies ist nur in 3.2 mit der Funktion Engine-> get_physics_interpolation_fraction () wirklich möglich. Ein Beispiel für die Verwendung finden Sie unter https://github.com/lawnjelly/smoothing-addon .

Dies sind die Voraussetzungen, bevor Sie mit der Untersuchung von Jitter beginnen. Sie geben eine lineare Beziehung zwischen der Position eines Objekts und der Zeit, was wir wollen.

Eine alternative (neulingfreundlichere) Methode, um dies zu erreichen, ist der halbfeste Zeitschritt, für den ich seit Juli # 30798 eine PR habe.

Dies ist die Grundlage für wissenschaftliche Untersuchungen und Hypothesentests. Die Idee ist, so viele verwirrende Effekte wie möglich zu reduzieren und einzeln zu untersuchen.

Hier spielen drei Hauptfaktoren eine Rolle:

1) Lineare Beziehung zwischen Objektposition und Zeit aus dem Spiel (siehe oben)
2) Fehler bei den Eingabezeiten
3) Fehler in den Ausgabezeiten

Eliminiere (1) wie oben. Beseitigen Sie (2) mithilfe des Befehlszeilenarguments, und Sie können (3) isoliert untersuchen.

Für jede Untersuchung von Jitter sollten Sie Objekte direkt und nicht über die Physik bewegen, da die Physik möglicherweise selbst Jitter hinzufügen kann.

_Bearbeiten:_
Ich habe mir gerade das minimale Repro-Projekt in diesem Thread angesehen (Ausweichen vor dem Kriechen) und es bewegt sich mit Geschwindigkeit * Delta in _process, was in Ordnung sein sollte. Es hängt von is_action_pressed ab und ich persönlich würde das als mögliches Problem entfernen, aber es ist wahrscheinlich in Ordnung. Wenn Sie jedoch ein anderes Projekt zum Testen von Jitter verwenden, beachten Sie die obigen Punkte.

@lawnjelly Ich
Ich werde es beim nächsten Mal mit den neuen Überlegungen versuchen.

Ich habe mir gerade das minimale Repro-Projekt in diesem Thread angesehen

Ich verwende meine eigene Version des Projekts, da das Original Animationen verwendet (kann den Jitter maskieren) und graues Sprite über grauem Hintergrund hat. Ich werde es so anpassen, dass es Ihren Kriterien entspricht.

Also, --fixed-fps 60 hat mir bei dem Problem nicht geholfen.

Das sind sehr nützliche Informationen. Dies scheint den spitzen Finger der Schuld in Richtung der Ausgangsverzögerung (und des Compositors) zu bewegen und der Art des Ansatzes in der PR Gewicht zu verleihen. Dies setzt voraus, dass Doppel- / Dreifachpufferung verwendet wird und die Pipeline gespeist wird und keine Frames gelöscht werden.

Ist dies auch bei @TerminalJack mit dem Befehlszeilenargument der Fall?

Ich verwende mein eigenes Projekt, da das Original Animationen verwendet (kann den Jitter maskieren) und graues Sprite über grauem Hintergrund hat. Ich werde es so anpassen, dass es Ihren Kriterien entspricht.

Ah gut, danke! : +1:

@lawnjelly Ich

Ein wenig abseits des Themas, aber es sollte in Ordnung sein (ich habe es seit einigen Wochen nicht mehr angefasst), sollte keinen Jitter einführen. Wenn Sie Fehler finden, lassen Sie es mich im Issue-Tracker wissen oder machen Sie sogar eine PR. : +1: Ich beabsichtige, es auf die offiziellen Addons für 3.2 zu setzen, wenn ich dazu komme.

@lawnjelly

Ist dies auch bei @TerminalJack mit dem Befehlszeilenargument der Fall?

Entschuldigung, ich hatte keine Gelegenheit, Ihre Vorschläge auszuprobieren. Ich bin in dem Thema, an dem ich arbeite, in ein Kaninchenloch gegangen.

@lawnjelly Gemäß unserer Diskussion im PR-Thread dachte ich nur, ich würde erwähnen, dass Sie in --fixed-fps <fps> korrekt waren. Tatsächlich bleibt vsync aktiviert. Wie Sie bereits sagten, ist die Verwendung eine gute Möglichkeit, Probleme bei der Berechnung des Deltas herauszufiltern. Ich muss es vermasselt haben, als ich es früher versucht habe und ich hatte Stottern, weil das jetzt nicht der Fall ist.

Ich habe diese Option wurde unter Verwendung zusammen mit meinen Änderungen , die unter Verwendung einzurichten DwmFlush() Hilfe tut , wenn sie außerhalb des Editors ausgeführt wird . Wenn Sie DwmFlush() deaktivieren, können Sie im Spiel Stottern verursachen, indem Sie einfach ein anderes Fenster ziehen oder die Maus über eine der laufenden Aufgaben in der Taskleiste bewegen. Da das Spiel mit der Priorität "Über Normal" ausgeführt wird, sollte dies natürlich nicht passieren. (Und es ist nicht so, wenn DwmFlush() verwendet wird.)