Difference between revisions of "4/Threading"

From Worms Knowledge Base

Jump to: navigation, search
(reorder)
(One True Event Loop)
 
(3 intermediate revisions by the same user not shown)
Line 7: Line 7:
 
* Fibers would solve synchronization and modality problems, unfortunately they are not very portable and not currently implemented in D. (It's still possible to use them using OS primitives.)
 
* Fibers would solve synchronization and modality problems, unfortunately they are not very portable and not currently implemented in D. (It's still possible to use them using OS primitives.)
 
{{gap}}
 
{{gap}}
* Level of separation of individual UI windows?
+
* Use a single thread for event handling. Long-running synchronous tasks (such as the game engine) will run in separate threads.
* How much will threading / message passing affect performance, compared to a single-threaded solution?
+
* SDL and network event loops run in separate threads, sending messages to event handling thread?
 +
** How does the network thread handle ''sent'' data?
 +
** Is this a good idea for single-core CPUs?
  
 
=== Modality ===
 
=== Modality ===
Line 14: Line 16:
 
''Here, "modal" means "the call to show this dialog is blocking, and the calling code will resume running only after said dialog is closed". Confirmation message boxes are an example.''
 
''Here, "modal" means "the call to show this dialog is blocking, and the calling code will resume running only after said dialog is closed". Confirmation message boxes are an example.''
  
* Having logic and user interface run in separate threads allows simple usage of modal dialogs, e.g. message boxes
+
* Modal dialogs will not be used.
* However, using modal dialogs does not allow more than one independent modal dialog per thread, because dialogs must be closed in the reverse order they're opened due to the order of the thread's call stack. This implies that modal dialogs ''must'' be modal for the entire thread. Thus:
+
** Not using modal dialogs isn't so bad in D, considering that it supports anonymous functions (lambdas). The code could look something like: <br><code>MessageBox("Are you sure you want to overwrite "~fileName~"?", (MessageBoxResult r) { if (r == MessageBoxResult.OK) saveFile(fileName); } );</code>
** Every window which wants to display modal dialogs must have its own thread, or
+
** Modal dialogs are app-modal, or
+
** Modal dialogs are not used.
+
*** Not using modal dialogs isn't so bad in D, considering that it supports anonymous functions (lambdas). The code could look something like: <br><code>MessageBox("Are you sure you want to overwrite this file?", (MessageBoxResult r) { if (r == MessageBoxResult.OK) saveFile(); } );</code>
+
  
 
=== Display list ===
 
=== Display list ===
  
* When, and in which thread does the game's display list (scene) get constructed?
+
* Constructing the display list is a fairly cheap operation. The game engine should construct its display list (or meta-display list, since some visual elements do not depend on game logic) after every logic frame.
* Retained mode, for better hardware-accelerated performance?
+
** Tweened rendering..?
** OpenGL doesn't seem to support retained mode rendering, but Direct3D does
+
 
 +
== External links ==
 +
* [http://gamedev.stackexchange.com/questions/8765/one-true-event-loop One True Event Loop] on Game Development StackExchange

Latest revision as of 17:30, 8 March 2011

(Up to 4)

Threading

  • Having the game engine run in its own thread is a huge plus by itself. Game lag won't have to also mean UI lag.
  • Combining SDL and network event loops in a single thread would be complicated.
  • Fibers would solve synchronization and modality problems, unfortunately they are not very portable and not currently implemented in D. (It's still possible to use them using OS primitives.)

 

  • Use a single thread for event handling. Long-running synchronous tasks (such as the game engine) will run in separate threads.
  • SDL and network event loops run in separate threads, sending messages to event handling thread?
    • How does the network thread handle sent data?
    • Is this a good idea for single-core CPUs?

Modality

Here, "modal" means "the call to show this dialog is blocking, and the calling code will resume running only after said dialog is closed". Confirmation message boxes are an example.

  • Modal dialogs will not be used.
    • Not using modal dialogs isn't so bad in D, considering that it supports anonymous functions (lambdas). The code could look something like:
      MessageBox("Are you sure you want to overwrite "~fileName~"?", (MessageBoxResult r) { if (r == MessageBoxResult.OK) saveFile(fileName); } );

Display list

  • Constructing the display list is a fairly cheap operation. The game engine should construct its display list (or meta-display list, since some visual elements do not depend on game logic) after every logic frame.
    • Tweened rendering..?

External links

Personal tools