Jep, das hat mich auch gewundert, aber zum Teil wurde das tatsächlich so dargestellt, also, dass die Latenz vom "button press" auf dem Wirelesscontroller bis das entsprechende Bildsignal im Fernseher eintrifft maximal 80ms betragen soll.
Deshalb hab ich oben auch gesagt: Solange diese 80ms eingehalten werden ist alles in Butter, aber das eigentliche Problem ist viel eher ob sie tatsächlich eingehalten werden können.
Aber einige hier stellten ja 80ms Inputlag schon als "unspielbar" hin, dabei wäre das ein äußerst geringer Inputlag.
Aber selbst wenn sich nochmal 80ms dazuadieren würden - man wäre immerhin auf dem Niveau vieler 30fps-Spiele, Killzone wäre sogar zum Teil ein Tick schlechter.
Andererseits sprach Perlman auch davon, dass die Spiele vom PC "mit wenigen Codeveränderungen" portiert werden würden - vielleicht hat Onlive auch einige Methoden entwickelt, mit denen sich interne, programmierseitige Lags bei typischen Spiel- und Steuerungstypen gut reduzieren lassen.
Andererseits wäre natürlich auch denkbar, dass die Server an sich das Spiel auch etwas schneller als benötigt ausführen (was aber einen höheren Leistungsbedarf zu Folge hätte), wodurch der interne Lag auch reduziert werden würde (also Leistung im "Übermaß").
Aber wie gesagt, ob diese 80ms eingehalten werden ist schon äußerst zweifelhaft, wenn sie es tatsächlich werden würden (und zwar in obigem Verständnis) dann gäbe es keine Probleme.
Genau so wird es ablaufen.
Das einzelne Bild wird bei Onlive wesentlich schneller berechnet als auf dem heimischen PC. Ein Server wird ja mehrere Clients bedienen müssen die dann hintereinander abgearbeitet werden.
Wenn so ein Server z.B. für drei Clients zuständig ist dann berechnet er z.B. zuerst ein Bild für Client 1, dann für Client 2 und dann für Client 3. Bei 60fps pro Client verkürzt sich somit die Berechnung für ein Bild von ca. 16,6ms auf 5,5ms.
Ich seh die zeitliche Abfolge ungefähr so.
User drückt Taste.
paar MS bis der Befehl in der Konsole ankommt.
Dort wird er auf die Reise geschickt.
Pingzeiten zur Serverfarm
Dort wird dann auf den Anfang der Berechnung für diesen Client gewartet. Bei 60fps maximal 16.6ms. (Wenn er gerade mit der Berechnung eines Bildes für diesen Client begonnen hat und bis zum nächsten Bild warten muss)
Das Bild wird berechnet. Nach obigem Beispiel dauert das ca. 5.5ms.
Das Bild wird komprimiert. Vermutlich wird es in Teilen komrpimiert und schon gesendet bevor es komplett fertig ist. Dauert laut Entwickler nur wenige ms.
Das Bild geht auf die Reise.
Hier kommt der Ping von der Serverfarm zum Heimanschluss wieder zum Tragen.
Das Bild wird in der Konsole decodiert und bildschirmsynchron ausgegeben. Auch hier kann bei lagfreiem Display eine Zeit von wenigen bis 16,6ms (60Hz) verstreichen plus der Dekodierzeit für die man wohl auch ein paar ms einrechnen dürfte.
Wenn das Bild erst dekomprimiert werden kann wenn es vollständig übertragen wurde kommt hier dann auch noch die Zeit für diese Übertragung, die natürlich von der DSL-Leitung abhängig ist, zum Tragen. Dürften im Schnitt wohl noch mal ca. 10ms sein.
Da aber derzeitige Displays für die Bildverarbeitung noch eine gewisse Zeit brauchen - umso mehr, je mehr Bildverbesserungsklamotten man aktiviert hat- kommen da auch noch mal zwei bis drei Frames, also 33,3-50ms hinzu.
Auf Doublebuffering, wie es heute üblich ist, dürfte man wohl aufgrund der schnellen Bildberechnung verzichten können bzw es findet zwar statt, hat aber keine negativen Auswirkungen. Es werden ja schließlich in drei Zyklen nur einmal das Bild für jeden Client berechnet. Folglich fielen dann auch die dafür benötigte Zeit (wieder die 16,6ms) weg.
Ohne den Ping zum und von der Serverfarm komm ich auf ca. 16ms im Schnitt , die in der Serverfarm benötigt werden. Das ist doch schon recht flott. Dazu die Dekomprimierungszeit bzw. die Datenüberbragungszeit und man hat einen Grundping, den man nicht groß änden kann.
Das System steht und fällt natürlich mit der Anbindung zu den Serverfarmen. Bei guter Anbindung sollte man die angegebenen 80ms sogar unterschreiten können. Der Lag, der vom TV verursacht wird kommt natürlich noch dazu.
Das Problem sehe ich aber in der allgemeinen Struktur des Internets. Dort gibt es immer mal kleine Datenengpässe. Beim Betrachten eines herkömmlichen Films via Internet ist das kein Problem durch die Möglichkeit der Pufferung. Der Film wird erst dann gestartet wenn sich ein paar Sekunden davon schon im heimischen Rechner/Konsole befindet. Datenschwankungen lassen sich so kompensieren.
Onlive muss aber systembedingt auf jedwede Art von Pufferung bei ihrer Filmübtragung (und nichts weiteres ist es im Grunde ja) verzichten, da die den Lag ja linear in die Höhe treiben würde. Somit sind im Echtzeitbetrieb regelmäßige Bildstörungen oder temporär spürbare Lags praktisch nicht zu verhindern. Hier bin ich wirklich skeptisch, ob das funktionieren kann insbesondere, wenn später mal Millionen von individuellen Videoströmen in 720p von den Farmen ins Netz gestreut werden.
