A structure that I find works very well when managing entities in games is the world/entity/component pattern. Entities in the world are nothing more than collections of components, where the components have the responsibility to "do something" with the entity.
This post includes a thread pool class for the XNA Framework that works better on the Xbox than the thread pool class in the Compact CLR. The main thread can choose to get notified about task completion with a callback function, or by waiting on a pre-allocated wait handle, or do fire-and-forget on the thread tasks.
In most games, you'll need to know where everything is.
Here is some code that lets you extract the vertices and indices from a loaded XNA Model. You do not need to use any special processor, such as the JigLibX VertexProcessor or some derivative of the ModelProcessor -- it works straight out of the box!
It appears that school, tutorials, or whatever is teaching
about threads a whole lot these days, and most designs I see
from people learning the ropes involves a number of threads.
However, threads cause bugs, and cause extra synchronization
cost that's not easily visible, and not easily redeemable.
Todays assignment is to get a red block on the screen of a Win32 program.
On PC hardware, there are basically three timers that are generally available. Neither of them is very reliable
When you try to map between a linear multiplier (0.0 to 1.0) and a "curve" value, which is exponential, you may be tempted to use exp(x), because it goes between linear and exponential. However, that's not good enough.
Note that what I'm saying is sort of x86-centric, with specific illustration for Pentium II/III, although it'll also work on AMD and even on other platforms (like PowerPC). The more PC/workstation like the platform, the more truth this holds. DSPs with SRAMs aren't anything like this, though -- programmer beware.