Hattori Hanso hat geschrieben:Alex hat geschrieben:http://www.eurogamer.net/articles/gdc-why-onlive-cant-possibly-work-article
Danke, interessanter Link der mit viel Fachwissen meine ganzen Zweifel die aus Gefühl entstanden sind in technische Fakten packt.
Fakten? Fachwissen? Gerade das vermisse ich bei diesem Artikel. Statt mal wirklich konkrete Bandbreiten und Latenzen zu betrachten oder die tatsächlich erreichbaren Werte heutiger Hardwareencoder heranzuziehen, langweilt einen der Autor mit dumpfem Blabla. *gähn* Schlauer ist man hinterher auch nicht, außer das jemand, der vorgibt Ahnung zu haben, seinen Senf dazu gibt. "So, let's say that Grand Theft Auto V is released..."
More than that, OnLive overlord Steve Perlmen has said that the latency introduced by the encoder is 1ms. Think about that; he's saying that the OnLive encoder runs at 1000fps.
wtf? Die Verzögerungszeit durch das Encoding beträgt 1 ms, aber es bleiben trotzdem immer nur 60 fps die es zu verarbeiten gilt.
Ganon hat geschrieben:Was mir dabei auffällt: Das Problem fällt jedem als erstes ein. Da kann man doch irgendwie annehmen, dass die Macher sich da auch besonders viel Gedanken über eine Lösung gemacht haben.
Wieso, das ist doch nicht deren Problem. Wenn ich bei ET einen schlechten Ping habe, kann ich den Serverbetreiber ja auch nicht belangen.
Davon abgesehen gibt es das Latenz-Problem bei jeder Echtzeit-Anwendung. In der Audiotechnik z.B. schafft RME tatsächlich eine verzögerungsfreie A/D-Wandlung, was in der Branche für viel Wirbel gesorgt hat. In der Automatisierungstechnik wünscht man sich ebenso niedrige Latenzen zur Steuerung und Regelung. Ich bin derzeit an einem Forschungsprojekt beteiligt, wo genau so etwas mit entwickelt wird. Das sind natürlich alles Anwendungen die man isoliert laufen lassen kann und die nicht über eine so unsichere Komponente wie das Internet laufen. Wenn ich von einer mittleren Verzögerung von 150 ms ausgehe, je 50 ms Übertragungszeit und 50 ms zur Berechnung, dann wird es schon recht knapp.