Framerate
 | |
| Bilder des weißen Balls auf dunklem Hintergrund fehlen (Abschnitt "Unschärfe bei Bewegung"): - Ball links - Ball in der Mitte - Ball rechts - Ball unscharf Ein st-Diagramm passend zu Mikrorucklern wäre toll (Abschnitt "Variation der Framerate"). |
Das englische Wort "frame" lässt sich in etwa mit "Rahmen" übersetzen. Das "Frame" in Framerate hat aber nichts mit einem Bilderrahmen o.ä. zu tun, sondern gemeint ist der zeitliche Rahmen, in dem ein bestimmter Rechenvorgang stattfindet. Wenn man von der Framerate von Spielen spricht, ist ein Frame also genau die Zeit, die der Computer benötigt, um ein neues Bild auf den Bildschirm zu rendern. Die Framerate gibt an, wie viele dieser Frames pro Sekunde (fps) vergehen.
Inhaltsverzeichnis
24 fps Mythos
Damit die grafische Ausgabe nicht wie eine Abfolge von Einzelbildern, sondern wie eine flüssige Bewegung aussieht, muss das angezeigte Bild schnell genug aktualisiert werden - mit anderen Worten: Die Framerate muss hoch genug sein. Experimente haben ergeben, dass das menschliche Auge eine Animation ab etwa 24 Bildern pro Sekunde nicht mehr als Bildfolge, sondern als Bewegung wahrnimmt. Daher stammt auch die weit verbreitete Meinung, ein Spieler könne keinen Unterschied zwischen 24 fps und beispielsweise 60 fps erkennen. Diese Annahme ist jedoch aus verschiedenen Gründen falsch! Siehe folgender Text.
Unschärfe bei Bewegung
Überlegen wir einmal, was passiert, wenn ein weißer Ball schnell von links nach rechts durchs Bild fliegt. Das erste Bild, das der Computer rendert, zeigt den Ball auf der linken Seite des Bildes.
(Bild)
Sofort nachdem das Bild fertig ist, misst das Programm natürlich die Zeit, die es für das eine Bild gebraucht hat (bei 24 fps knapp 42 ms). Anhand der gemessenen Zeit kann er bestimmen, welche Strecke der Ball in dieser Zeit zurückgelegt hat (s = v*t, Timebased Movement). Nun verschiebt es den Ball um die entsprechende Strecke und beginnt sofort, das nächste Bild zu rendern. Nun ist der Ball schon in der Mitte des Bildschirms angelangt.
(Bild)
Wieder misst das Programm die vergangene Zeit, verschiebt den Ball um die entsprechende Strecke und rendert das nächste Bild. Nun ist der Ball rechts.
(Bild)
Im nächsten Bild wird er gar nicht mehr zu sehen sein. Der Betrachter bekommt also hintereinander drei gestochen scharfe Bilder zu sehen, die er als Bewegung interpretieren soll. Das Problem dabei ist das "gestochen scharf".
Betrachten wir zum Vergleich einmal, was passieren würde, wenn sich diese Szene in der Natur abspielt. Der Ball wird von einer oder mehrerer Lichtquellen beleuchtet und reflektiert einen Teil des Lichts zum Auge des Betrachters. (Der Einfachheit halber nehmen wir an, dass der arme Betrachter nur ein Auge hat.) Währenddessen bewegt sich der Ball, und da der Betrachter seine Blickrichtung in dieser Zeit nicht ändert, wird das Licht während des Frames von 42 ms an verschiedene Stellen der Netzhaut reflektiert - allerdings wird kein Teil der Netzhaut 42 ms lang belichtet. Über den Sehnerv wird für jeden "Pixel" auf der Netzhaut der mittlere Helligkeitswert ans Gehirn übermittelt. Das Resultat ist ein grauer (nicht weißer) Streifen quer durchs Bild. Der Ball "verwischt" sozusagen, wie man es auch von Fotos mit zu langer Belichtungszeit kennt.
(Bild)
Genau diese Unschärfe erwartet auch der Spieler eines Computerspiels. Fehlt dieser Effekt, wirkt die Bewegung ruckelig. Eine Möglichkeit, diesen Effekt zu erzielen, wäre alle Bewegungen unscharf zu zeichnen. Das hat aber einen gewaltigen Nachteil, wie du im nächsten Abschnitt sehen wirst. Die andere Möglichkeit ist, einfach deutlich mehr Bilder pro Sekunde zu rendern, als nur 24.
Schärfe bei Bewegung
Warum ist das Unscharf-Zeichnen keine Lösung des Problems? Ganz einfach: Man stelle sich die selbe Szene noch einmal vor - mit dem einzigen Unterschied, dass der Betrachter dieses Mal nicht auf eine Stelle starrt, sondern den Ball mit seinem Blick verfolgt. Er sieht also erst auf die linke Seite des Bildschirms und bewegt seinen Blick mit konstanter Geschwindigkeit nacht rechts. Was würde er erwarten zu sehen? Denk' mal kurz darüber nach.
Der Spieler erwartet natürlich die selben Effekte, die er (unbewusst) zuvor in der Natur beobachtet hat. Nämlich dass der fliegende Ball gestochen scharf zu sehen ist, während der Hintergrund in Unschärfe verwischt. Denn dadurch, dass der Beobachter sein Auge immer nach dem Ball ausrichtet, trifft das von ihm reflektierte Licht immer die gleichen Stellen der Netzhaut.
Dem Ball auf dem Bildschirm zu folgen, nachdem dieser unscharf gezeichnet wurde, geht aber nicht - man sieht ja nur einen grauen Streifen, überall dort, wo der Ball im Laufe des Frames einmal war. Das Problem ist, dass der Programmierer nicht wissen kann, wie der oder die Betrachter des Bildschirms ihre Augen bewegen.
Würde man die gesamte Szene mit 24000 fps rendern (was natürlich kein PC oder Bildschirm schaffen würde), dann würde sich der Ball in jedem Frame um einen oder zwei Pixel verschieben und wäre zu jeder Zeit gestochen scharf, wenn man ihm folgt. Gleichzeitig würde er (für das Auge) verwischen, wenn man ihm nicht folgt.
Variation der Framerate
Auch wenn die Framerate deutlich über 24 fps liegt, können selbst langsamere Bewegungen noch ruckelig wirken. Grund dafür ist dann, dass die Framelänge stark variiert. Als Beispiel muss mal wieder der Ball herhalten, der diesmal aber nicht in einer achtel Sekunde durchs gesamte Bild fliegt, sondern gemächlich mit konstanter Geschwindigkeit ins Bild rollt. Die Szene wird mit (normalerweise sehr flüssigen) 60 fps gerendert. Ein Frame hat also eine Dauer von 16,67 ms. Leider kommt es nun durch ungünstige Umstände dazu, dass ein einziges Frame plötzlich doppelt so lange dauert wie die anderen zuvor. Welche Auswirkungen hat das?
Die Hälfte von 60 fps sind 30 fps. Man sollte meinen, dass dies immer noch als ruckelfrei empfunden wird. Das Problem ist auch nicht die Framelänge als solches, sondern die Framelänge im Vergleich zu den vorherigen Frames. Der Betrachter erwartet, dass der Ball mit konstanter Geschwindigkeit weiterrollt - also jeden Frame um die gleiche Strecke weiterbewegt wird. Da nun ein Frame aber doppelt so lange gebraucht hat, sieht es so aus, als wenn sich die Kugel für einen Frame gar nicht bewegt und dafür im nächsten einen doppelt so großen Sprung gemacht hat. Wir hatten also zu keiner Zeit zu geringe Framerate und trotzdem kann haben wir ein leichtes Ruckeln wahrgenommen. In diesem Fall spricht man auch von Mikrorucklern, weil diese Ruckler nicht als ganz so schlimm wahrgenommen werden, wie eine dauerhaft zu niedrige Framerate.
Bildschirmfrequenz und V-Sync
Kein Bildschirm kann beliebig viele Bilder pro Sekunde darstellen. Eine übliche Refreshrate bei Flachbildschirmen ist 60 Hz (das heißt, das Bild wird 60 mal pro Sekunde erneuert). Es gibt aber auch welche mit 120 Hz (für Stereoskopie) oder 200 Hz. Da 60 Hz auf Röhrenbildschirmen stark flimmern, können diese alten Kisten oft auch 75, 85, oder 100 Hz. Egal, wie oft ein Monitor pro Sekunde sein Bild erneuern kann - es gibt (von Ausnahmefällen wie Benchmarking abgesehen) keinen Grund, die Grafikkarte mehr Bilder berechnen zu lassen, zumal dies zu unerwünschten Artefakten führt (Tearing). Deshalb gibt es eine Technik, die sich V-Sync nennt. Dabei wartet die Grafikkarte, bis das neue Bild an den Bildschirm übertragen wurde, bis sie das nächste beginnt.
Es ist unbedingt zu empfehlen V-Sync einzuschalten, wenn der Computer sowieso mehr Bilder pro Sekunde rendern kann als der Bildschirm darzustellen vermag.
(Mehr Informationen/weitere Artikel)
Auswirkungen von V-Sync auf Framerate und Mikroruckler fehlen. |
 |
