JLI Spieleprogrammierung

[Dietmar Ferstl]

[abc_d]

Ein Thread in einem Forum ist ein Thema. Oder meinst du da was anderes / woher kommt das Zittat eigentlich?
_________________
http://mitglied.lycos.de/sarti/linuxisevil.gif Linux is evil - get the fact.

Never touch a running System - der Systemling

[Jonathan_Klein]

Das ist irgendso ein uraltes Beispiel für eine Spielschleife, von irgendeinen hier im Forum. Hab ich mir vor längeren auch mal geladen, aber nie so richtig verinerlicht.
_________________
https://jonathank.de/games/

[Cyianor]

Von irgendeinem is gut. Das is immer hin von Afe-Gmdg.

Ausserdem ist die Spielschleife gar nicht so schlecht. Aber bei dx lohnen sich threads AFAIK nicht, weil das selbst welche anlegt.

[AFE-GmdG]

Da ich schon sehr lange ein Multiprozessorsystem habe, da mich damals Leute gefragt hatten, wie ma sowas macht - und überhaupt - hatte ich einfach mal eine Spieleschleifenversion mit Multithreadingunterstützung angeboten. Was der einzelne daraus dann macht, war mir zu diesem Zeitpunkt eigendlich egal.
Dass man Multithreading nach Möglichkeit vermeiden soll, stimmte vielleicht früher, aber ich denke, dass in allernächster Zukunft sehr viele Spiele aus folgenden Gründen auf massives Multithreading setzen:
1. Die HT-Technologie von Intel ist noch lange nicht das Ende der Fahnenstange: AMD und Intel haben Prozessoren mit mehr als 16 Prozessorkernen angekündigt, in näherer Zukunft steht wohl für jeden Prozess ein eigener Prozessor(kern) zur Verfügung. Das wiederum ermöglicht massive Leistungssteigerungen, da das zeitaufwendige Prozessswitching entfällt.
2. Man kann unabhängig von der Bildwiederholfrequenz eine Steuerung implementieren, so haben Leute mit langsameren Grafikkarten trotzdem die Möglichkeit weich zu steuern und eventuell besser zu reagieren.
3. Unwichtige, aber trotzdem notwendige Ressourcenarbeiten könnten in Hintergrundthreads geschoben werden. Mann kann z.B. Level dynamisch nachladen, ohne dass der Benutzer einen Ladescreen zu sehen bekommt. Wenn der Spieler in die Nähe eines Ausganges kommt, kann der dahinterliegende Level ja schonmal geladen werden, damit es gleich weitergeht. Manager für Texturen, Objekte usw. sind ebenfalls gute Kandidaten für Hintergrundthreads...

Im allgemeinen sind Multithreading-Programme schwerer umzusetzen (Stichwort Syncronisation) bieten aber Vorteile, die in Singlethreading-Umgebungen nur sehr schwer umsetzbar wären.
_________________

[Fallen]

Das Laden der Levels ist ein wunderbares Beispiel, sonst hätt ich das vermutlich sehr umständlich über Streaming gelöst.

Das Rendering in einen Thread auszulagern könnte da schon problematischer werden da es dort ne menge Deadlocks geben kann.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[Kronos]

Salve,

könnte mir nochmal jemand erklären was Singlethreading/Multithreading ist bzw. was überhaupt ein "Thread" ist?

Vale,

[Jonathan_Klein]

Multithreading ist wenn 2 Prozesse gleichzeitig ablaufen. So kann der eine Prozess z. B. das nächste Level laden, wärden der andere die normale Spielschleife ausführt.
Singlethreading ist wenn beides in einer Schleife abläuft.
Man braucht für Multithreading eigentlich 2 Prozessoern aber man kann das auch bis zu einem gewissen Grad simuleiren (z. B. Windows, meherer Programme gleichzeiti (Multitasking)).
Intels neue Prozessoren mit dem HT kürzel sind für Multithreading glaub ich ganz gut geeignet.

Mehr weiß ich auch nicht, bin kein Profi
_________________
https://jonathank.de/games/

[fowly]

stimmt, intels neue mit ht (hyper-threading) sind für multithreading anwendungen gut geeigenet, oder auch gerade für windows multitasking. der prozessor kann die resourcen also einfach besser auf die aktionen aufteilen, und afaik auch besser mit mehreren prozessoren arbeiten.
_________________
<-- Noch in der Entwicklungsphase: http://www.uranus-entertainment.de -->

Das Spiel zu unserer Schule:

http://www.grabbe-game.de

[Dietmar Ferstl]

Hi,

multithreading wurde mit mehreren Prozessoren bereits von WIN NT4.0
unterstützt.

Das Problem beim Multithreading ist immer dann gegeben, wenn Daten des einen Threads mit den Daten des anderen Threads irgendwie zu tun haben, d.h. einer auch mit den Daten des anderen arbeitet.
Sowas ist nur sehr schwer zu debuggen.

CU
D.

[AFE-GmdG]

Multithreading und Multitasking muss grundsätzlich erst mal voneinander unterschieden werden.
Windows ist ein Multitasking Betriebssystem. Jede Anwendung, Jede Hintergrundanwendung (Services oder Serverprogramme) sind je ein Task. Der Taskmanager zeigt alle Tasks an. (mit ID, Name usw.)
Ein Programm, dass Singlethreaded Kompiliert wurde, belegt *immer* genau einen Task mit einem Thread.
Programme können auch Multithreaded kompiliert werden, dann wird gegen andere WindowsAPI-Funktionen gelinkt, nämlich gegen Funktionen, die Multithread-Sicher sind. Sie sind in der Regel etwas langsamer, da Sicherheitsmechanismen eingebaut sein müssen.
Ein Thread ist also kein eigenständiges Programm, sondern eine eigenständig fungierende Ausführungseinheit. Sie muss mit allen anderen Threads um begrenzte Resourcen konkurieren.

Als Beispiel kann ich folgende Geschichte erzählen:
2 Menschen, die in einer Wohnung leben (ein Task, 2 Threads)
Die erste Person nimmt ein Bad. Die zweite Person kommt nach Hause und will ebenfalls ein Bad nehmen. Die Wanne ist besetzt (Resourcenproblem), so muss die zweite Person auf die erste warten. Die erste Fragt die zweite Person nach einem kleinen Imbiss - sie will erst aus der Wanne, wenn sie (dort) Ihr essen futtert. Die zweite Person will aber unbedingt erst in die Wanne, bevor sie sich um weitere Aufgaben kümmert. Und schon haben wir einen Dead-Lock, eine Situation, die erst dann gelöst werden kann, wenn eine der beiden Personen nachgibt, weil beise sich um die selbe Resource streiten. Übertragen auf Programmresourcen wie Dateien, Schreib- und Lesezugriff, Variablen usw. gibt es bei Multithreading-Programmen viele Fehlerquellen, die nur schwer zu lokalisieren sind, da das Programm an sich ja föllig Fehlerfrei laufen kann.
_________________

[Dietmar Ferstl]

Hallo,

das Prob ist aber, dass man nie weiss, wenn ein Thread wieder "angesprungen" wird. Zumindest habe ich noch keine Möglichkeit gefunden, dies zu kontrollieren.
Oder kennt sich da jemand aus?

D.

[Fallen]

man könnte das durch globale bzw. statische variabeln lösen, ebenfalls ist es ja möglich einem thread variabeln zu übergeben das können genauso gut pointer wie strukturen/klassen sein.

Somit könnte man einen Kontrollmechanismus relativ problemlos einbauen.
_________________
"I have a Core2Quad at 3.2GHz, 4GB of RAM at 1066 and an Nvidia 8800 GTS 512 on Vista64 and this game runs like ass whereas everything else I own runs like melted butter over a smokin' hot 18 year old catholic schoolgirl's arse."

[Dietmar Ferstl]

Hallo,

was nützt dir ein "Kontrollmechanismuss" ?
Entscheidend ist doch die Zeit, die der Prozi "ausserhalb" deines Threads verbringt. Wie willst du denn erzwingen, dass diese Zeit z.B. nur maximal 1 Millisekunde betragen soll?

D.

[Fallen]