Allein schon die Begrenzung auf 30Frames ist eine "sinnlose" Frechheit.
Korrigiert mich bitte, wenn ich falsch liege; ich kenne mich leider nicht mit der Programmierung einer PS3 aus.
Ich vermute jedoch, dass dies eine Designoptimierung für den Cellprozessor, welcher im wesentlich ein Hyper Threading Einkernprozessor mit 7 Coprozessoren ist. Dieser ist wohl am ehesten mit einem CPU + GPGPU Gespann zu vergleichen.
Da der Hauptprozessor selbst relativ schwach ist, werden viele einfach zu parallelisierende Probleme auf die Coprozessoren übergeben. Zudem ist die Graphik ebenfalls schwach, weshalb man diverse graphische Effekte, wie zB die Berechnungen auf Vertexbasis, auch auf diesen Coprozessoren ausführt.
So wird dieses Spiel in etwa einen solchen Mainloop (eine Pipeline ist es ja nicht mehr wirklich weil komplett sequentiell) haben:
Spiellogik (Physik, KI etc.) berechnen -> Graphik CPU Teil (zB Knochenanimation, Haare, Partikel, Sichtbarkeiten, Umrechnung der Vertices in Bildkoordinaten etc. ) -> Befehle und Daten werden an die GPU gesendet
-> Während die GPU diese ausführt folgt dann wieder der erste Schritt
Sind nun GPU und CPU Last gut aufeinander abgestimmt, wie es bei einem Konsolenspiel leicht möglich ist, kann man auf diese Art und Weise einfach, ohne Programmier oder Rechenaufwand für das Resourcenmanagement aufzuwenden, sowohl Prozessor als auch Graphik auslasten. Dieses Resourcenmanagement würde in diesem Fall bei einer entkoppelten Pipeline dann beinhalten, dynamisch festzulegen, für welche Berechnungen wie lange der Graphik oder der Logikthread die Coprozessoren belegen darf, so dass keiner der beiden Threads verhungert und das Spiel flüssig spielbar bleibt.
Allerdings folgt durch diesen sequentiellen Mainloop der Nachteil, dass dadurch die Bildwiederholrate fest an die Frequenz der Spiellogik gekoppelt wird; auf jeden logischen Frame folgt ein Bild. Zudem kann es jedoch trotz der Balancierung vorkommen, dass an diversen zu bombastischen Stellen dieses Spiels die Graphik nicht mehr mithalten kann. Damit das Spiel selbst nicht in Zeitlupe verläuft, wird der Graphikteil des Mainloops nur noch jeden zweiten Frame ausgeführt, wodurch sich dann die gleich auf 15 Bilder pro Sekunde halbiert und es stark ruckelt
Man könnte dies nun versuchen für einen PC umzuprogrammieren, um eine entkoppelte Pipeline welche gut auf heutigen Mehrkernprozessoren läuft. Je nachdem wie vernetzt die einzelnen Schritte des Mainloops des Spiels sind, würde dies jedoch einen großen Aufwand bedeuten, die nötigen Kopieroperationen und Buffer einzurichten, so dass man das Spiel mit einer Pipeline parallelisieren kann.
Gleichzeitig ist bei dem Spiel die logische FPS mit 30 sehr niedrig, der logische Timestep, also diejenige Zeit welche zwischen zwei Frames verstreicht, ist also konstant und hoch. Also müsste man, um eine entkoppelte Pipeline mit mehr als graphische 30 FPS zu bekommen, die Spiellogik in einer wesentlich höheren FPS (100 oder mehr) laufen lassen. Dies würde wohl wieder zu neuen Problemen führen, da das Spiel für eben diesen konstanten Timestep ausgelegt und getestet worden ist.
So kann es beispielhaft sein, dass sie selbst nirgendwo die Zeitdauer eines Timesteps vermerkt haben oder an diversen Stellen vergessen haben ihn in ihre Gleichungen einzubauen, so dass bei einem kleineren Timestep diverse Sachen viel zu schnell ablaufen.
Beides wäre also prinzipiell fixbar, aber je nach Codedesign, was ich allerdings als relativ schlecht einschätze, was ich bislang so über das Spiel gelesen habe, kann dies eine Tortur werden, weshalb sie es wohl nicht gemacht haben.