Das Spiel wird wahrscheinlich so eine Standard Pipeline haben:
Berechnen der Spiellogik(viel Single Threaded CPU + evtl GPU) -> Berechnen der Grapischen Spiellogik(viel Multi Threaded CPU + evtl GPU) -> Zeichnen (kaum CPU+vieeeeel GPU)
Berechnen der Spiellogik:
Berechnung der Bewegung, Verhalten, Position, Bewegungszustand, der Einheiten Geschosse KI Kollisionsberechnung, Scripting, Spielerbefehle und etc
-Diverse Berechnungen, wie Partikel oder Physik können auf die GPU ausgelagert werden, was CA hier allerdings wie ich vermute nicht getan hat
-Läuft mit fester FPS entkoppelt vom nächsten Schritt
-Kopiert immer wenn er mit einem Frame fertig ist alle potentiell graphisch relevanten Daten in einen Buffer, der vom Nächsten Schritt ausgelesen wird.
Weite Teile davon sind schlecht parallelisierbar weshalb der Schritt bei Shogun nur auf einen Kern läuft. Dies merkt man sehr schön wenn man aus einer laufenden Schlacht auf dem Desktop geht: Das Spiel lastet dann nur einen Kern komplett aus, während es bei mir im maximierten Zustand 1 Kern komplett und 3 halb auslastet.
Berechnen der Grapischen Spiellogik:
Berechnung des Graphischen Zustands der Spielwelt aus den Informationen des letzten Schritts:
-Bestimmt was muss überhaupt gezeichnet werden muss und dementsprechend einen Graphischen Zustand braucht.
-Berechnung des graphischen Zustands dieser Objekte: Hauptsächlich die Animationen bzw die Knochen der Soldaten aus dem Bewegunszustand
-Ist fest an den nächsten Schritt gekoppelt.
-Dieser Schritt "kann" einen Frame im "voraus" zu berechnen, dh er fängt mit dem rechnen an, sobald der ZeichenSchritt anfängt, die von diesem Schritt so eben berechneten Graphischen Zustände zu rendern. Denn dadurch erzielt man eine höhere Auslastung von CPU und GPU, was man sich allerdings durch ein höheres Delay erkauft . Alternativ ist es auch möglich diesen Schritt stark mit dem nächsten Schritt zu verschmelzen, so dass jegliche Graphischen Objekte, welche bereit wären gezeichnet zu werden sofort gezeichnet werden.
-Prinzipiell dynamische Genauigkeit möglich:Würde der Schritt zu lange dauern, werden diverse Objekte nicht mehr genau berechnet, wie Animationen, damit das Spiel dennoch flüssig spielbar bleibt. Das wird denke ich auch bei Shogun gemacht, da ich das Gefühl habe, dass die Soldaten bei großem Berechnungsaufwand in diesem Schritt über den Boden gleiten wie auf Rollschuhen oder sich über kurze Distanzen "Teleportieren".
-Auch ist dieser Schritt gut parallelisierbiar, je nachdem wie die CA Leute das aufgezogen haben, könnten davon Teile auf der GPU ablaufen. Wegen der starken CPU abhängigkeit in Situationen, wo dieser Schritt viel Rechenaufwand benötigt, schliesse ich das allerdings aus.
Interessant finde ich hier, da der Zeichenschritt nur kaum CPU benötigt, dass dementsprechend dieser Schritt für die oben erwähnten 3 halb ausgelasteten Kerne verantwortlich sein muss. Da sämtliche Berechnungen in diesem Schritt potentiell gut parallelisierbar sind, und Shogun es dennoch mit diesem Schritt nur schaft 3 Kerne halb auszulasten, hat CA hier wohl mal wieder designtechnisch sehr sehr großen Mist gebaut.
Zeichnen:
Die graphischen Zustände, sofern sie nicht schon im VRAM sind, und die Zeichenbefehle werden an die GPU gesendet und diese führt sie aus.
-In DX11 teilweise parallelisierbar (Display Lists) in DX9 nicht parallelisierbar
Je nachdem wo nun etwas limitiert sind andere Effekte zu erwarten:
1. Schritt:
Limitiert bei großen Schlachten vermutlich an der Single Threaded CPU Performance
Spiel wird langsamer, Animationen ruckeln, weil mehrmals die selbe Animationsphase gezeichnet wird
2. Schritt:
Limitiert bei vielen Objekten auf dem Bildschirm vermutlich an Multi Threaded CPU Performance
Bei dynamischer Genauigkeit bewegen sich die Einheiten evtl seltsam oder nicht mehr
Bildwiederholrate sinkt
3.Schritt
Limitiert bei großen Graphikdetails Auflösung etc an zu niedriger Graphikleistung
Bildwiederholrate sinkt
