spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Du arbeitest so oder so hoffentlich ohnehin mit non-blocking Sockets? Denn wenn nicht, dann stellt sich die Frage gar nicht.

Klar, wenn man das Rendering an sich in mehrere Threads aufteilen kann, ist das wieder was anderes. Aber was in meinen Augen nicht geht, ist Rendering und Update in verschiedenen Threads zu machen, da diese stets aufeinander warten muessen. Beides fuer sich kann aber sich selbst natuerlich parallelisieren, das ist natuerlich machbar.

Zitat von »zeha«

Aber was in meinen Augen nicht geht, ist Rendering und Update in verschiedenen Threads zu machen, da diese stets aufeinander warten muessen.

Man kann es pipelinen, also während das Rendering des aktuellen Frame gemacht wird nebenher schon das Update für den nächsten machen...

Zitat von »zeha«

Aber was in meinen Augen nicht geht, ist Rendering und Update in verschiedenen Threads zu machen, da diese stets aufeinander warten muessen.

Wie ich bereits schrieb: genau das mache ich bereits. Ich würde Dir also widersprechen wollen.

Dann muesste man doch aber jedesmal den gesamten Spielstatus im Speicher kopieren, denn wenn ich den weiterhin veraendere, kann der Renderer nicht mehr sauber rendern. Also muesste man nach jedem Update eine Kopie des gesamten Spielstandes machen, und diese dem Renderer uebergeben, damit der nur diesen einen Spielstand rendert und im Hintergrund in Ruhe weitergerechnet werden kann. Wenn der Renderer dann soweit ist, dass er wieder den aktuellen Spielstand rendern kann, muss der zu diesem Zeitpunkt aktuellste Spielstand erst wieder kopiert werden.

Oder wie muss man sich das vorstellen?

Du musst lediglich das kopieren, was für das folgende Rendering relevant ist.

Exakt. Klassisches Pipelining. Der Renderer klappert alle Objekte der Spielwelt ab und erstellt dafür Renderjobs. Ab dann ist der Renderer autark, macht Frustum Calling und Lichtzuordnung usw. Und währenddessen kann schon das nächste Frame simulieren.

Mein Renderer ist wie gesagt noch DX9, daher gibt es in meiner parallelen Task-Verteilung auch eine spezielle Queue für Tasks, die nur im Hauptthread gemacht werden dürfen. Dort packst Du dann auch Eingabe-Verarbeitung und sowas rein. Der kippt dann seine Ergebnisse in irgendnem kleinen Container ab, von wo der nächste Simulationsschritt sich das Zeug holt und einarbeitet. Bedeutet alles natürlich zusätzliche Latenz, also sollte man darauf achten, das alles nicht allzu weit auseinander zu ziehen. Aber Eingabeverarbeitung sind ja auch Mikrosekunden, das muss man jetzt nicht unbedingt parallelisieren. Aber das Schöne an so einem Jobsystem ist ja, dass Du Abhängigkeiten formulieren kannst und damit automatisch erzwingst, dass Job X abgeschlossen ist, bevor Job Y loslaufen kann.