spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ist die Frage in wie fern sich das ganze lohnt. An irgendeiner Stelle musst du die beiden Threads synchronisieren damit eben auch der aktuelle Zustand und nicht irgendein veraltetes Zeugs gerendert wird. Und an diesem Punkt wird es dann eben kritisch.

Soweit ich weiß, ist sowas bei modernen “großen“ Spielen schon parallelisiert. Sogar das Rendering selbst kann wiederum parallel erfolgen (also das Vorbereiten der Kommandos für die Grafikkarte).

Das hängt viel zu sehr vom konkreten Spiel ab, als dass ich diese Frage generell mit ja oder nein beantworten würde. Ich versuche es aber zu vermeiden, wenn nicht unbedingt notwendig. Da ich nur kleinere Casual-Games mache, ist es mir den Ärger nicht wert, zumal völlig unnötig für die von meinen Games benötigte Performance.

Wird von den großen Engines so gemacht, wird mit Vulkan und Dx12 auch unterstützt und macht absolut Sinn. Für kleinere Hobby Projekte ist es aber meistens Overkill und macht die Anwendung nur Fehleranfälliger.

Mein D3D9/OpenGL3-Renderer ist "threaded" in dem Sinne, dass ich die Spiellogik antrete, während der Renderer im Main Thread noch die DrawCalls des letzten Frames abarbeitet. Der Renderer macht auch Frustum Culling und so, kann also trotz antiker 3D-API ein paar Sachen auf Cores verteilen. Die eigentlichen DrawCalls müssen dann aber trotzdem aus dem Hauptthread abgefeuert werden.

Dazu hatte ich mir übrigens einen schicken Job Manager gebaut, der Fibers in Worker Threads instanziiert oder beendete/pausierte/wartende Fibers ablegt. Inzwischen ist Boost V1.62 rausgekommen und hat ein nahezu identisches System mitgebracht :-( Irgendwann, falls ich mal wieder zum Coden komme, hau ich meins raus und ersetze es durch Boost.Fibers

Ich habe mir dazu mal vor einigen Jahren Gedanken gemacht und bin zu dem Schluss gekommen, dass es eigentlich gar nicht wirklich machbar ist. Keine Ahnung wie also die grossen Engines das machen wollen. Letztendlich darf der Render-Thread ja nur einen "sauberen" Zustand zeichnen, und waehrenddessen braucht der Update-Thread eigentlich auch keine weiteren Updates machen, da diese ja den Zustand wieder kaputtmachen wuerden. Es sei denn, es wird der Zustand zwischendrin komplett kopiert, aber ich bezweifle, dass das irgendwie sinnvoll ist.

Das einzige, was ich in Threads auslagern wuerde, waeren vermutlich Netzwerk-Sachen und KI, aber beides habe ich bisher fuer meine Spiele nicht benoetigt.

Wenn mir jemand erklaeren koennte, wie man Rendering und Update als Thread realisieren kann, so dass es wirklich etwas bringt, waere ich sehr dankbar, auch wenn ich das vermutlich nie machen wuerde oder werde. Trotzdem wuerde mich interessieren, wie das funktionieren kann.

Davon abgesehen, habe ich das Gefuehl dass vor allem Anfaenger oder sagen wir mal noch weniger erfahrene Programmierer liebend gerne alles moegliche mithilfe von Threads machen wollen, weil sie glauben, dass es einen Vorteil bringt und dass die "Profis" das auch so machen. Letztendlich wuerde aber vermutlich jeder Profi empfehlen, moeglichst keine Threads zu verwenden, sondern nur dann, wenn es sinnvoll bzw. nicht anders machbar ist. So zumindest meine Einschaetzung. Denn Threads erhoehen die Komplexitaet deutlich und fuehren zu sehr vielen potentiellen Fehlerquellen, die auch noch sehr schwierig zu debuggen sind und manchmal auch erst auf anderen Rechnern oder nach einem Jahr auftreten. Threads sind an sich nichts boeses und in einigen Faellen sehr hilfreich oder fast essentiell, aber man sollte meiner Meinung nach aufpassen, dass man sie nicht einfach nur deshalb einsetzt, weil man gerade glaubt, dass das so "gemacht wird" oder dass das "doch ganz cool" waere etc.

Grundlegen habe ich hier herausgelesen, dass man extra Threads nicht unbedingt brauch.
Wie sieht das ganze bei render & networking aus? Sollte man dort einen extra Thread für die Kommunikation zwischen Server und Client spendieren um den Render Thread nicht zu blockieren.