The speed was actually one of the things that rubbed me wrong from the very begginning. I haven't really gotten too far in breaking apart the program, but a few simple things I figured out so far:
The main message loop calls into a high level "game" routine at every pass. This is what causes it to continuously peg the processor. OOP at its worst.
It uses a 1 millisecond Wait API call just before the redraw. The elapsed time is checked at each pass and calculated to determine whether it is time to draw a frame according to the fps limit. This is what makes it so other programs can preempt and still be snappy. Same calculation done everytime it loops. If you are really going to do it this way calculate once, Wait for a slightly smaller time slice and then check the time once.
Before each frame is drawn the keyboard state is polled about 6 times with GetKeyState, and that is just at the main menu. That API call is not very efficient either.
Actual game movement is also done as a subroutine under the same high level routine. Meaning 10 fps doesn't just make the graphics crawl, each frame represents a single step for all the game objects.
-------
I haven't actually gotten around to hunting for any callback functions yet. Game play is just too much fun. I can still suggest seperating the graphics and the objects and putting each on its own TimerProc.
Game play is much more important. DF definitely has excellent play.
[ April 19, 2007: Message edited by: Veroule ]