Du bist nicht angemeldet.

Werbeanzeige

BlueCobold

Community-Fossil

Beiträge: 10 026

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

11

02.01.2017, 16:18

Du arbeitest so oder so hoffentlich ohnehin mit non-blocking Sockets? Denn wenn nicht, dann stellt sich die Frage gar nicht.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

12

07.01.2017, 14:06

Networking ist ne Sache für sich, hier geht es aber nur um lokale Update & Render Threads.

zeha:
So viel ich weiß, nutzen die meisten modernen Game Engines mehrere Threads, manche sogar mehrere Renderer Threads - obwohl es die Komplexität erhöht.
Für die meisten zählt halt einfach nur die Performance.
AI z.B. kannst du ganz gut parallel berechnen (solange sie keine Abhängigkeiten zueinander haben), irgendwelche Simulationsberechnungen o.ä.
Indie Game-Dev Programmierer beim 2D MMORPG Pentaquin | Pentaquin Foren Vorstellung

13

07.01.2017, 16:14

Klar, wenn man das Rendering an sich in mehrere Threads aufteilen kann, ist das wieder was anderes. Aber was in meinen Augen nicht geht, ist Rendering und Update in verschiedenen Threads zu machen, da diese stets aufeinander warten muessen. Beides fuer sich kann aber sich selbst natuerlich parallelisieren, das ist natuerlich machbar.

dot

Supermoderator

Beiträge: 9 785

Wohnort: Graz

  • Private Nachricht senden

14

07.01.2017, 17:40

Aber was in meinen Augen nicht geht, ist Rendering und Update in verschiedenen Threads zu machen, da diese stets aufeinander warten muessen.

Man kann es pipelinen, also während das Rendering des aktuellen Frame gemacht wird nebenher schon das Update für den nächsten machen... ;)

Schrompf

Alter Hase

Beiträge: 1 204

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

15

07.01.2017, 20:51

Aber was in meinen Augen nicht geht, ist Rendering und Update in verschiedenen Threads zu machen, da diese stets aufeinander warten muessen.


Wie ich bereits schrieb: genau das mache ich bereits. Ich würde Dir also widersprechen wollen.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

16

09.01.2017, 17:03

Dann muesste man doch aber jedesmal den gesamten Spielstatus im Speicher kopieren, denn wenn ich den weiterhin veraendere, kann der Renderer nicht mehr sauber rendern. Also muesste man nach jedem Update eine Kopie des gesamten Spielstandes machen, und diese dem Renderer uebergeben, damit der nur diesen einen Spielstand rendert und im Hintergrund in Ruhe weitergerechnet werden kann. Wenn der Renderer dann soweit ist, dass er wieder den aktuellen Spielstand rendern kann, muss der zu diesem Zeitpunkt aktuellste Spielstand erst wieder kopiert werden.

Oder wie muss man sich das vorstellen?

BlueCobold

Community-Fossil

Beiträge: 10 026

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

17

09.01.2017, 18:29

Du musst lediglich das kopieren, was für das folgende Rendering relevant ist.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

Schrompf

Alter Hase

Beiträge: 1 204

Wohnort: Dresden

Beruf: Softwareentwickler

  • Private Nachricht senden

18

10.01.2017, 07:47

Exakt. Klassisches Pipelining. Der Renderer klappert alle Objekte der Spielwelt ab und erstellt dafür Renderjobs. Ab dann ist der Renderer autark, macht Frustum Calling und Lichtzuordnung usw. Und währenddessen kann schon das nächste Frame simulieren.

Mein Renderer ist wie gesagt noch DX9, daher gibt es in meiner parallelen Task-Verteilung auch eine spezielle Queue für Tasks, die nur im Hauptthread gemacht werden dürfen. Dort packst Du dann auch Eingabe-Verarbeitung und sowas rein. Der kippt dann seine Ergebnisse in irgendnem kleinen Container ab, von wo der nächste Simulationsschritt sich das Zeug holt und einarbeitet. Bedeutet alles natürlich zusätzliche Latenz, also sollte man darauf achten, das alles nicht allzu weit auseinander zu ziehen. Aber Eingabeverarbeitung sind ja auch Mikrosekunden, das muss man jetzt nicht unbedingt parallelisieren. Aber das Schöne an so einem Jobsystem ist ja, dass Du Abhängigkeiten formulieren kannst und damit automatisch erzwingst, dass Job X abgeschlossen ist, bevor Job Y loslaufen kann.
Häuptling von Dreamworlds. Baut aktuell an nichts konkretem, weil das Vollzeitangestelltenverhältnis ihn fest im Griff hat. Baut daneben nur noch sehr selten an der Open Asset Import Library mit.

Werbeanzeige