spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Ich denke, dass alles grafikbezogene Updaten (z.B. Animationen) nur in Threads ausgeführt werden kann, wenn das die Renderengine unterstüzt. Wenn du Objekte Spiellogigmäßig updaten musst, also rein auf der CPU, dann ist das in jedem Fall besser, als wenn das Spiel laggt. Versuchst du einen Teil-Update in jedem Frame in einer Singlethread-Anwendung, dann ist das allemal komplizierter, als wenn du einfach einen zweiten Thread erstellst.

Effektiv ist das bestimmt, denn heutzutage hast du fast nur noch Multicoreprozessoren. Effizient im Hinblick auf was? Speicher oder Codelänge? Wie es schon im letzten Satz im erstem Absatz angeklungen ist, ist dein Code viel übersichtlicher, da du kein stückweises Updaten implementieren brauchst.

Ich hoffe, das war einigermaßen verständlich.

Ich glaub, beim Speicher fällt sowas nicht so ins Gewicht. Du musst bei Teilupdates halt den aktuellen Updatefortschritt speichern - hast du beim Threading aber nicht - da hast du ja deine Objekte threadübergreifend gespeichert, da ists dann egal, wie viele Threads drauf zugreifen - musst den Zugriff nur anständig regeln...

Wichtig beim Multithreading ist, wenn du nicht weißt ob Multithreading sinnvoll ist, dann lass es lieber sein. Overhead und Synchronisationszeiten sind oft nicht zu vernachlässigen und wenn du nicht aufpasst, dann läuft dein Programm am Ende langsamer als vorher. Allgemein beim optimieren sollte man lieber mit Struktur vorgehen. Das heißt, optimiere nicht einfach drauf los an Sachen bei denen du dir nicht sicher bist. Analysiere deine Software und suche nach Code der sich zu optimieren lohnt. Ein guter Anfang ist da oft ein Profiler. Hiermit kannst du gegebenenfalls Flaschenhälse in deinem Code aufdecken. Dann solltest du auch erst mal gucken ob du so optimieren kannst bevor du wild mit Threads um dich wirfst.