spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Außerdem hat nicht jeder Monitor notwendigerweise immer 60 Hz...

Zitat von »dot«

Außerdem hat nicht jeder Monitor notwendigerweise immer 60 Hz...

Aber dann würde er doch auch nicht mit 60 Hz synchronisieren, sondern eben mit 50 oder 70?

Nehmen wir an, du hast einen Monitor der mit 120 Hz läuft (ist nicht so lang her, dass sowas üblich war ), deine Anwendung packt aber nur 100 Hz...

Dann nehm ich 2 und alles läuft wunderbar mit 60 fps. Ok das erklärt es natürlich

Zitat von »Sebastian Müller«

V-Sync synchronisiert die Frame-rate von D3D (Anzahl der Durchläufe von der Renderfunktion) und die des Monitors.
Wenn der Monitor 60 hz hat (60 Bilder pro Sekunde) dann müsste die Renderfunktion auch ca. 60 mal in einer Sekunde durchlaufen.
(Vorausgesetzt es ist genügend Power da.)

V-Sync dient dazu, sog. Tearing-Artefakte zu vermeiden. Der Bildschirm liest (wenn wir sowas wie NVIDIA G-SYNC mal außer Acht lassen) mit einer fixen Frequenz (die Refresh Rate) das Eingangssignal aus. Wenn Front- und Backbuffer während dem Bildaufbau des Monitors getauscht werden, wird der bis zu diesem Zeitpunkt bereits ausgelesene Teil des Monitors den entsprechenden Teil des vorhergehenden Frame zeigen, während der nachfolgend aufgebaute Teil des Monitors den neuen Frame zeigt usw. Was passiert, ist also, dass auf dem Monitor nicht immer nur ein Frame zu sehen ist, so wie man das gerne hätte, sondern verschiedene Teile mehrerer aufeinanderfolgender Frames. Vor allem, wenn zwischen aufeinanderfolgenden Frames starke Bewegungen stattgefunden haben, kann dies dazu führen, dass das Bild "zerrissen" aussieht (engl. to tear "zerreißen"). Die Lösung für das Problem ist, mit dem Vertauschen von Front- und Backbuffer zu warten, bis der Monitor mit dem Bildaufbau fertig ist. Da der Bildaufbau des Monitors (wohl vor allem aus historischen Gründen) zeilenweise von oben nach unten (also vertikal) passiert, spricht man dabei von V-Sync (Vertical Synchronization).

IDXGISwapChain::Present() macht das mit dem Vertauschen von Front- und Backbuffer und der Parameter SyncInterval gibt an, der wievielte Bildaufbau des Monitors abgewartet werden soll, bis die Buffer getauscht werden. Wenn wir bis zum 0-ten Bildaufbau warten, warten wir nie, Present vertauscht die Buffer also sofort und wir haben potentiell Tearing, sind aber nicht an die Bildwiederholfrequenz des Monitors gebunden. Sobald wir bis zum 1-ten Bildaufbau nach dem Aufruf von Present() warten, haben wir V-Sync. Genausogut könnten wir aber auch bis zum übernächsten (2-ten) oder überübernächsten (3-ten) Bildaufbau warten wollen, z.B. wenn die Refresh-Rate unseres Monitors sehr viel größer ist, als wir brauchen (wie das beispielsweise bei Röhrenmonitoren der Fall ist/war), daher gibt es nicht einfach nur die Option V-Sync ein und V-Sync aus, sondern diese allgemeinere Variante...

Mal ne Frage, ich habe diesen VSync Parameter (SyncInterval) immer auf 1 gesetzt, weil ich das Tearing vermeiden möchte (sieht doof aus), aber trotzdem lasse ich den Benutzer entscheiden ob er es anschalten oder ausschalten möchte.
Ist das sinnvoll? Eigentlich will man doch immer das beste Ergebnis haben oder?

Wenn die Hardware von deinem Benutzer es nicht hergibt mit V-Sync immer ruckelfrei zu zocken, wird er die Artefakte wohl schnell in Kauf nehmen. Ruckeln ist viel schlimmer.