Synchronisation der Spielgeschwindigkeit auf verschiedenen Rechnern

[Savini]

Bei alten Spielen war es so, dass ein Spiel umso schneller ablief, je schneller der Rechner war. Anscheinend war festgelegt, um wie viele Pixel sich die Spielfigur von Frame zu Frame bewegen sollte. Berechnete ein schneller Rechner doppelt so viele Frames pro Zeiteinheit wie ein langsamer, bewegte sich die Figur auf dem schnellen Rechner auch doppelt so schnell.

Dies ist bei heutigen Spielen ja AFAIK nicht mehr so. Läßt man ein aktuelles Spiel auf einem langsamen und einem schnellen Rechner laufen, so legt die Spielfigur auf beiden Rechnern in einer bestimmten Zeit gleich große Wege zurück. Der schnelle Rechhner hat zwar immer noch mehr Frames berechnet als der langsame, doch sind nun die Wegdifferenzen zwischen den Frames bei dem schnellen Rechner kleiner als bei dem langsamen, so dass im Endeffekt dieselbe Geschwindigkeit jedoch mit flüssigerer Bewegung auf dem schnellen Rechner rauskommt.

Frage: Wie erreicht man das oben beschriebene, also dass ein Spiel auf allen Rechnern gleich schnell läuft (auf dem schnellen halt flüssiger mit mehr fps, die dieselbe Bewegung halt nur feiner zerlegen)? Schließlich hängt es ja von zig Faktoren ab, wie schnell ein Rechner ist. Wie kann also ein Spiel sofort nach dem Start rausfinden, um wie viele Pixel die Spielfigur beim nächsten Frame fortbewegt dargestellt werden muss (oder um welchen Winkel die Szenerie im nächsten Frame gedreht erscheinen muss), damit sich die gewünschte Standard-Geschwindigkeit des Spiels ergibt?

[micki]

früher hat man versucht eine feste geschwindigkeit zu erhalten indem man die wiederhollfrequenz des monitors zum synchronisieren benutzt hat, die hat sich dann aber mit neuen monitoren geändert und man ist "aus dem takt" geraten. (natürlich hing es auch mit der cpugeschwindigkeit zusammen, aber das wollte man eben durch die bildschirm wiederholfrequenz verhindern)

bei neuen spielen läuft die Grafik und Logic eigentlich unabhängig ab. die Logic versucht man fest z.B. 40 mal in der sekunde (alle 25ms) aufzurufen, je nach schnelligkeit des rechners zeigt man zwischendurch manchmal 5 bilder an oder es kommt vor dass ein paar logicdurchläufe hintereinander durchlaufen bis man wieder ein Bild rendert.
In der Logic macht man das Setup für das rendering z.B. sendet man in dem Logicdurchlauf Partikel aus z.B. Rauch. dabei legt man fest dass der rauch sich jeder Partikel vom Rauch z.B. mit 10°/s rotiert und mit 10pixel/s nach oben bewegt. Ab da ist es für die Logic egal wo sich der Rauch befindet und der Renderingdurchlauf zeichnet die Partikel und interpoliert sie, eventuell sogar nur auf der Grafikkarte ohne dass die CPU mehr machen muss als die aktuelle zeit zu übergeben.
Bei manchen dingen wie z.B. Personen, die von der Logic und vom Rendering gebraucht werden, macht man das Setup an animatoren. Diese haben z.B. die position von einem Bot von dem Aktuellem Logicdurchlauf und dem letzten Logicdurchlauf, daraufhin interpoliert der Animator wärend des Renderings die Positionen, natürlich ist dann alles um 25ms delayed, man kann alternativ animatoren programmieren die extrapolieren, jedoch kann es da zu hoppeln kommen, was man aber bei einem logicdurchlauf alle 25ms kaum merken sollte.

natürlich ist das eine möglichkeit (wenn auch sehr geläufig), es gibt noch viele andere möglichkeiten.

MfG
micki

[Savini]

???

Nochmal das Problem: Ich drücke in einem Spiel den Knopf, um mich vorwärts zu bewegen. Sowohl auf einem schnellen als auch auf einem langsamen Rechner bin ich nach 1 Sekunde dann z.B. 80 Pixel weit gelaufen, wenn die Geschwindigkeit der Fortbewegung 80Pixel/s ist (gilt natürlich nur bei einer bestimmten Auflösung). Wenn mein Rechner 40fps schafft, müßten innerhalb dieser Sekunde 40 Frames berechnet werden, in denen die Spielfigur jeweils 2 Pixel weiter vorne steht. Schafft mein Rechner nur 10fps, werden halt nur 10 Frames berechnet, in denen die Spielfigur jeweils 8 Pixel weiter vorne steht. So ergibt sich auf beiden Rechnern eine Geschwindigkeit von 80 Pixel/s, wobei die Bewegung auf dem schnellen Rechner natürlich flüssiger aussieht, weil die Wegdifferenz von 80 Pixeln hier ja in 40 und nicht nur in 10 Abschnitte unterteilt wurde und innerhalb einer Sekunde abgespielt wurde.

Doch: Im voraus kann das Spiel doch gar nicht wissen, wie groß die fps Rate sein wird, um somit auszurechnen, um wieviel Pixel die Figur pro Frame verschoben werden muss. Außerdem kann sich ja auch innerhalb einer Sekunde die fps Rate ändern, wenn sich am Aufwand der Grafik was ändert (Figuren kommen hinzu, man bewegt sich in einen anderen graphisch aufwändigeren Raum etc.) Dies würde ja bedeuten, dass, wenn man sich 0,5 Sekunden mit 40fps bewegt hat und danach die Framerate auf 10fps sinkt, nun wieder größere Sprünge von Frame zu Frame gemacht werden müssen, damit man nach einer Sekunde tatsächlich 80 Pixel weiter gekommen ist.

Als nochmal die Frage: Wie managet ein Spiel das?

[Demirug]

1. Du siehst immer nur einen alten Zustand und zwar genau den welcher zu dem Zeitpunkt aktiv war als die Daten an den Treiber übergeben wurden. Das Spiel muss also nichts im Vorraus berechnen.

2. Um nun herauszubekommen wie weit sich die Spielfigure von einem Frame zum nächchsten bewegt hat ermittelt man einfach die Zeit welche für das Berechnen und das übergeben der daten an den Treiber benötigt wurden. Dabei ergibt sich dann ein Bruchteil einer Sekunden. Da alle Geschwindigkeiten auf einer Zeitbasis gespeichert sind kann man nun genau bestimmten um welche Entfernung sich alles in dem Zeitraum seit der letzten aktualisierung bewegt hat.

[Savini]

Original geschrieben von Demirug

2. Um nun herauszubekommen wie weit sich die Spielfigure von einem Frame zum nächchsten bewegt hat ermittelt man einfach die Zeit welche für das Berechnen und das übergeben der daten an den Treiber benötigt wurden. Dabei ergibt sich dann ein Bruchteil einer Sekunden. Da alle Geschwindigkeiten auf einer Zeitbasis gespeichert sind kann man nun genau bestimmten um welche Entfernung sich alles in dem Zeitraum seit der letzten aktualisierung bewegt hat.



ABER: Beim Übergeben der Daten - und natürlich schon vorher beim Berechnen -muss doch schon klar sein, wie der nächste Frame aussehen soll (wo also die Figur im nächsten Frame steht, um wieviel Grad sich die Szenerie gedreht hat usw.) Man kann ja schlecht ins Blaue rechnen, dann feststellen, dass es 1/n Sekunde gedauert hat und die Figur dann 1/n * v weiter vorne positionieren. Um ein neues Frame rendern zu können, muss die Engine doch bereits wissen, wo in diesem Frame die Figur sein wird und um wieviel Grad sich die Szenerie gedreht hat usw. Diese Infos sind doch die Grundlage für die Berechnung des neuen Frames. Oder verstehe ich hier was falsch?

[Demirug]

Der nächste Frame welche zum Treiber geschickt wird entspricht immer genau dem Zustand der zu dem Zeitpunkt zu welchem er erzeugt wird der Aktuelle ist. Dieser Zustand ist genau berechenbar weil alle informationen die dafür notwendig sind ja vorhanden sind.

[zeckensack]

Der aktuelle Frame ist idR um 2 Frames 'zu spät'. Bei 60 fps verschwinden ~32ms.

Deswegen sind hohe fps so schön :)
Und deswegen gibt es 'Mouselag'.

[micki]

je höcher die fps, desto mehr "lag" hat man, weil die driver mehr cachen damit sie keine buffer-underflows haben :)
deswegen sind hoche framerates immer weniger wirkungsvoll zur kompensation der 'mouselags' :)


MfG
micki

[zeckensack]

Original geschrieben von micki
je höcher die fps, desto mehr "lag" hat man, weil die driver mehr cachen damit sie keine buffer-underflows haben :)
deswegen sind hoche framerates immer weniger wirkungsvoll zur kompensation der 'mouselags' :)


MfG
micki Bei NV: ja (mit Treiber-Defaults, siehe "Prerender limit")
Bei ATI: nein ;)

Jedenfalls kommt's mir so vor ;)

[micki]

bei ATI sollen es zur zeit bis 5Frames sein, die im cache landen.. hab ich irgendwo mal gelesen. ich schätze, dass das nur passiert wenn man relativ wenig zur graka schickt und deswegen wohl ne hoche framerate hat. somit müßte man den Lag auf gleichem niveau halten.... ob man sowat messen könnte indem man im window rendert und gleichzeitig captured? oder wäre das capturen auch in der d3d/ogl pipe?

Mfg
micki