Threads in game-rentabel oder nicht?
-
IMHO werden thread in spielen normalerweise nur für animierte ladebildschirme verwendet ...?!
-
Und auf jeden Fall mal für Sound und Netcode (da gehts ja gleich gar nicht ohne). Allerdings macht das die Netzwerk-API meistens selber schon.
Überlege dir, ob du sie brauchst und nicht, wofür du sie hernehmen könntest.
Du könntest sie für alles hernehmen und viel Spaß bei der Synchronisation.Das mit dem Laden ist vielleicht keine schlechte Idee (also das Laden der Dateien in einem eigenen Thread), aber eigentlich auch nicht nötig.
Bei WC3 hätte ich mir einen Thread mehr gewünscht, nämlich, wenn man ein Spiel verlässt und es in dem Spiel massig Einheiten gegeben hat und die Karte schön fett ist, braucht der manchmal nach der Punktetabelle ne halbe Minute bis er wieder im Battle.net ist. Währenddessen sinkt im Taskmanager der RAM-Verbauch ganz rapide, wär mir aber lieber gewesen, ich könnte während dem Aufräumen schon mal wieder was machen.
btw, das wäre glaub ich bei C# automatisch gelöst, zumindest wenn man zum Aufräumen den GC benutzt, wo die finalizer in einem eigenen Thread laufen. Die hätten WC in C# coden sollen. :p
-
Skiron schrieb:
Das Problem ist ja, dass ich nicht weiß, ob ich sie verwenden soll oder nicht!
Ich hab dir doch gesagt, wann ich sie verwenden würde.
Bye, TGGC \-/
-
TGGC schrieb:
Skiron schrieb:
Das Problem ist ja, dass ich nicht weiß, ob ich sie verwenden soll oder nicht!
Ich hab dir doch gesagt, wann ich sie verwenden würde.
Bye, TGGC \-/
TGGC schrieb:
Hast du ein konkretes Problem, wo du sie brauchst? Dann benutz welche.
Woher weiß ich, dass ich bei diesem konkretem Problem Threads brauche/dass Threads die besser lösung sind?
@Optimizer: d.h., das laden der Dateien auf einen Thread auslagern oder jede Datei in einem Eigenen Thread laden?
Fragen wir mal so:
Wo würdet ihr Threads einsetzen, wenn ihr folgendes machen möchtet?
Werden soll das ganze ein Rollenspiel in 3D, wo die Welt am ende auch groß sein könnte!
-
Nein, benutz einfach keine Threads. Du merkst es dann schon, wenn du sie wirklich brauchst.
-
Meine Rede.
Bye, TGGC \-/
-
Threads sind dafür da, langwierige Aufgaben vom Rest zu separieren, damit die responsiveness des User Interface erhalten bleibt. Wie Volkard bereits sagte, kostet die Verwaltung der Threads und das Schützen der Daten auch eine Menge Zeit.
-
Skiron schrieb:
@Optimizer: d.h., das laden der Dateien auf einen Thread auslagern oder jede Datei in einem Eigenen Thread laden?
Um Gottes Willen, WENN, dann natürlich ersteres!!
Ansonsten bist Du ja nur damit beschäftigt Threads zu erzeugen, zu synchronisieren, und zu killen!!
-
Threads sind bei Spielen ganz einfach fehl am Platz. Am Ende alles auf einander "abzu-synchronisieren" ist die Hölle und klappt in den wenigsten Fällen. Im Spiel muss alles am Faden laufen. Da kann man nicht einfach hoffen das Thread "a" die Szene gerade fertiggerendert hat während Thread "b" noch in der Kollisions-Abfrage hängt und Thread "c" die Festplatte nach persönlichen Daten durchsucht
Sinnvoll und sicher ist das eigentlich nur, wenn man zwei vollkommen voneinander unabhängige Aufgaben zu bewältigen hat.
-
Cpp_Junky schrieb:
Threads sind bei Spielen ganz einfach fehl am Platz.
ganz so ist es heute noch, aber nicht mehr lange.
man wird auch in gamez hyperthreading verwenden müssen.
ok, ist ein wenig schwierig. viel spaß dabei.
-
ich werd mich mal TGGC und Optimizer anschließen
du hast mit threads immer noch das prob mit der synchronisation.
also würd ich in einem spiel soweit es geht darauf verzichten ( außer vielleicht für animierte ladebilsschrime ).denk mal nach, was während des spiels unabhängig voneinander gemacht werden kann!?
frame aktualisieren ( bewegungen etc. ), kollisionen, AI, rendern, etc.
das hängt alles voneinander ab und muss in einer bestimmte reihenfolge passiern sonst gibts ein pures chaos.das auf threads aufzuteilen is eine sache, die schon mit ein wenig Code verbunden is.
diese threads aber so zu synchronisieren, dass die auch noch richtig zusammenarbeiten is, denk ich, etwas übertrieben viel arbeit...und ich kann mir nicht vorstellen, dass du den ganzen overhead vom synchronisieren noch durch mehr speed irgendwie wettmachst.
zur zeit siehts so aus.
zur zeit wie gesagt.
