@Xeno, danke für die durchdachte Antwort. Welch angenehme Abwechslung hier
Das Problem ist nur, dass ein Spiel bzw zumindest die visuelle Darstellung ein Szenengraph ist. Also ein gerichteter, azyklischer Graph.
Bei der Darstellung alleine stimme ich dir zu. Jedoch ist die Darstellung einer Szene doch nur ein sehr geringer Teil dessen, was ein komplettes Spiel ausmacht.
Nur mal so abstrakt gedacht: wir haben in einem Spielablauf die Benutzereingaben, die Aktionen und Reaktionen der Gamelogik auf diese Eingaben und das Feedback an den Benutzer (Ausgabe).
Konzentrieren wir uns mal auf die rechenzeitintensiven Aufgaben für die CPU. Das sind die Aktionen des Spiels und die Reaktionen auf die neue Situation durch die Benutzereingaben. Dazu gehören z.B.: Animation, KI, Objektkollision & Physik und Sound. Diese Dinge lassen sich doch hervorragend parallelisieren - gerade die Kollisionsabfragen und die (damit verbundene) Physik ergeben meist tonnenweise Rechenoperationen, die sogar untereinander parallelisiert bearbeitet werden könnten (z.B. wenn 2 Objekte, die sich nicht beeinflussen können, behandelt werden).
Für das Rendering der Ausgabe müssen dann natürlich alle Daten, die für die Darstellung relevant sind, vorliegen.
Es gibt immer gewissen Synchronisationspunkte im Rechenablauf eines Spiels. Aber wenn man diese geschickt plant, lassen sich um diese Punkte herum die zu erledigenden Aufgaben mithilfe der 7 SPEs so verteilen, dass die Abarbeitung deutlich schneller läuft.
Und das bringt mich genau zu meiner obigen Aussage: einfach den bestehenden Code compilen nutzt kaum die Power aus. Der code muss schon logisch so strukturiert sein, dass er zu dieser Struktur mit wenig Synchronisation passt.
