spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »xTr1m«

Da beides (entity und task updates) nun theoretisch im simulations thread geschehen, ist das thema ja geklärt. Es gibt auch schon seit einer Weile ein issue für ein Task/Job system. Das ist dein gewollter "Zwischenschritt". https://github.com/Nimelrian/Project-Onyx/issues/11

Wie gesagt, ich würde mir gerne die Möglichkeit offen halten, das auszulagern. Dafür ist aber eben ein bisschen Voraussicht nötig. Irgendwie reden wir auch ein bisschen aneinander vorbei. Es ist meine Absicht die Update calls der Entities von der Simulation LOSZULÖSEN und nicht die Simulation diese callen zu lassen.

Ich glaube, ich baue morgen mal was in der Richtung. Ein bisschen Code könnte das verdeutlichen.

Und zum Thema Task Issue. Ich hatte das eher als User Task interpretiert. Also, der User gibt die Anweisung, es muss Holz gesammelt werden (=Task). Das versucht die Simulation zu erreichen, verteilt darauf hin allerdings eigene Tasks. Wie gesagt, ich versuche morgen mal was zu schreiben

So, hab jetzt schonmal was erarbeitet.



Die Klasse "GameLoop" gibt es noch nicht, allerdings wird das zwangsläufig kommen (die Main ist einfach viel zu überfüllt).
Beim starten wird direkt Simulation in einem neuen Thread gestartet, die alle X Millisekunden geupdetet wird. Diese Simulation hält eine const Referenz auf den "EntityManager" und eine normale Referenz auf den "TaskCollector". Innerhalb des Updates wird eine Liste von neuen Tasks erstellt und an den Task Collector weiter geleitet.

GameLoop updatet den Entitiy Manager. Dieser Manager schaut per polling beim TaskCollector nach, ob er neue Tasks hat, übernimmt diese und verteilt sie an die entsprechenden Entities. Danach werden alle Entites geupdetet.

-------------------------------------------------
Was haltet ihr von diesem Vorschlag? Die einzelnen Bereiche (übergabe der Tasks) müssen natürlich durch entsprechende Mutexes gesichert werden, dürfte aber auch nicht das große Problem werden.
Hab dafür jetzt auch mal einen neuen Branch erstellt (feature/ProperGameSystem). Bin für Vorschläge offen

Das über Polling zu lösen finde ich nicht sehr elegant. Es hat zudem den Nachteil, dass sehr kurzfristige Aufgaben in einem Manager lungern, bis sie gepollt wurden. Dann sind sie eventuell aber schon ausgelaufen. Neue Tasks würde ich immer aktiv pushen/schedulen - und sei es per Events.

Naja, im Endeffekt wird ja nur gepollt, was im letzten update Step erarbeitet wurde (im Moment alle 500ms). Der Manager wird, zumindest bisher, wesentlich öfter geupdatet (typische GameLoop), als die Simulation.
Also wird die Task Liste, die die Simulation erarbeitet hat, direkt im nächsten Update des Managers abgearbeitet.
Sehe da kein zeitkritisches Problem der neuen Tasks.

Ich möchte eben erreichen, dass es eine zentrale Schnittstelle zwischen den Threads gibt, sodass ich nicht die hälfte der Klassen mit mutexen vollballern muss.

Und was genau hält Dich davon ab das eleganter über Events zu lösen statt über Polling? Dann kann der Empfänger der Tasks jederzeit entscheiden, ob er sie sofort mit aufnimmt und abarbeitet oder erst später gesammelt. Polling is nicht umsonst verpönt.

Letztendlich nicht viel, außer dass ich jedes mal den Mutex locken und wieder freigeben muss, wenn ein Event verschickt wird. Oder sehe ich da was falsch?

Soweit ich das immer implementiert habe sind so genannte "Working Queues" für dieses Problem ideal. Einer stellt die Aufgaben rein und der andere holt sie heraus. Da nur der Zugriff auf die Liste gelocked werden muss, ist das recht ideal. Das könnte hier bedeuten, dass der EntityManager Aufgaben in eine Liste legt und der TaskCollector regelmäßig diese Liste abarbeitet.
Ob man jetzt die Aufgabe über ein Event in die Liste oder über einen direkten Funktionsaufruf einträgt ist ja nu letztendlich schnuppe. Auswerten muss die Liste an Aufgaben sowieso irgendjemand.

Zitat von »TrommlBomml«

Soweit ich das immer implementiert habe sind so genannte "Working Queues" für dieses Problem ideal. Einer stellt die Aufgaben rein und der andere holt sie heraus. Da nur der Zugriff auf die Liste gelocked werden muss, ist das recht ideal. Das könnte hier bedeuten, dass der EntityManager Aufgaben in eine Liste legt und der TaskCollector regelmäßig diese Liste abarbeitet.
Ob man jetzt die Aufgabe über ein Event in die Liste oder über einen direkten Funktionsaufruf einträgt ist ja nu letztendlich schnuppe. Auswerten muss die Liste an Aufgaben sowieso irgendjemand.

Genau so soll es auch funktionieren, auch wenn du die Aufgaben ein wenig verdreht hast
Simulation erstellt Tasks, übergibt diese an den TaskCollector und der EntityManager holt sich die Tasks vom Collector. Das Reinstellen und Herausholen ist per Mutex gelockt. Würde ich das per Event machen, müsste ich wesentlich mehr locken.

Nicht vergessen dass wir dazu schon ein Konzept hatten.
Das war aber noch nicht ausreichend genug. Es klingt nur so als wolltest du jetzt teilweise Code nochmal schreiben oder wüsstest hiervon nichts
Diesen anzupassen macht mehr Sinn.

Wie ich es bereits schonmal sagte. Diese Tasks wirken eher nach User Input. Wenn ich mich da vertue, berichtige mich bitte.