Difference between revisions of "4/Threading"
From Worms Knowledge Base
CyberShadow (Talk | contribs) (reorder) |
CyberShadow (Talk | contribs) (Some questions answered! Others remain...) |
||
| 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}} | ||
| − | * | + | * Use a single thread for event handling. Long-running synchronous tasks (such as the game engine) will run in separate threads. |
| − | + | ||
=== Modality === | === Modality === | ||
| Line 14: | Line 13: | ||
''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.'' | ||
| − | * | + | * 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: <br><code>MessageBox("Are you sure you want to overwrite this file?", (MessageBoxResult r) { if (r == MessageBoxResult.OK) saveFile(); } );</code> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
=== Display list === | === 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..? |
| − | * | + | |
Revision as of 02:23, 15 August 2010
(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.
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 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:
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..?
