Difference between revisions of "4/Threading"
From Worms Knowledge Base
CyberShadow (Talk | contribs) (fibers?) |
CyberShadow (Talk | contribs) (hmm) |
||
| Line 5: | Line 5: | ||
* Having logic and user interface run in separate threads allows simple usage of modal dialogs, e.g. message boxes (you don't have to specify class-level callbacks, but rather call a function and check the return value, like with the Windows MessageBox API) | * Having logic and user interface run in separate threads allows simple usage of modal dialogs, e.g. message boxes (you don't have to specify class-level callbacks, but rather call a function and check the return value, like with the Windows MessageBox API) | ||
* Combining SDL and network event loops in a single thread would be complicated. | * Combining SDL and network event loops in a single thread would be complicated. | ||
| + | |||
| + | === Notes === | ||
| + | * 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.) | ||
| + | * 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: | ||
| + | ** 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: <code>MessageBox("Are you sure you want to overwrite this file?", (MessageBoxResult r) { if (r == MessageBoxResult.OK) saveFile(); } );</code> | ||
=== Questions === | === Questions === | ||
* Level of separation of individual UI windows? | * Level of separation of individual UI windows? | ||
* When, and in which thread does the game's display list (scene) get constructed? | * When, and in which thread does the game's display list (scene) get constructed? | ||
| + | ** Retained mode, for better hardware-accelerated performance? | ||
| + | *** OpenGL doesn't seem to support retained mode rendering, but Direct3D does | ||
* How much will threading / message passing affect performance, compared to a single-threaded solution? | * How much will threading / message passing affect performance, compared to a single-threaded solution? | ||
| − | |||
Revision as of 17:04, 11 August 2010
(Up to 4)
Arguments
- 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.
- Having logic and user interface run in separate threads allows simple usage of modal dialogs, e.g. message boxes (you don't have to specify class-level callbacks, but rather call a function and check the return value, like with the Windows MessageBox API)
- Combining SDL and network event loops in a single thread would be complicated.
Notes
- 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.)
- 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:
- 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:
MessageBox("Are you sure you want to overwrite this file?", (MessageBoxResult r) { if (r == MessageBoxResult.OK) saveFile(); } );
- Not using modal dialogs isn't so bad in D, considering that it supports anonymous functions (lambdas). The code could look something like:
Questions
- Level of separation of individual UI windows?
- When, and in which thread does the game's display list (scene) get constructed?
- Retained mode, for better hardware-accelerated performance?
- OpenGL doesn't seem to support retained mode rendering, but Direct3D does
- Retained mode, for better hardware-accelerated performance?
- How much will threading / message passing affect performance, compared to a single-threaded solution?
