In the Win32 API, when windows pass over yours, Windows sends a message to your window indicating a) that a part of the window needs to be redrawn, and b) what area that is. Because of this, there's no need to constantly redraw your window come hell or high water to deal with windows moving across yours, you can just wait and only redraw part of the window if instructed to. There may be some reason outside my experience to do things differently, but if so, I'm not aware of it.
Edit: On the topic of the solution you found: Try enabling the framerate display in in the init file, and experiment with and without that option. You'll almost certainly find that the reason Dwarf Fortress seems to be well-behaved now is that its framerate is lower when you enabled that option.
"SyncToVBlank=1" means enabling vertical sync, which forces the game to only redraw while the monitor is in its vertical blank. This makes more sense if you understand how CRT monitors and TV screens work. Laptop/flat screen LCDs are completely different, and none of this applies. Basically, there's an electron gun inside the tube that has to move across and fire information at every single pixel on the screen, every time the monitor refreshes, to excite the pixels and make them light up. It starts at the top left corner of the screen, and ends at the bottom right. Once it does, there's a period where the gun scrolls back up to the top left, and this period of time is called the vertical blank.
Monitors have a native refresh rate, and they generally just refresh at that rate regardless of what your programs do. This is traditionally 60 frames per second. The software, on the other hand, has a separate frame rate. 60 is the "holy number" that people like to target for software frame rate because it's the traditional monitor refresh rate; drawing more than 60 frames per second is pointless, because you physically can't display things faster than the monitor can refresh the screen. Games are very intense though, and have to do a lot of things between frames. Besides calculating all the graphics, they have to handle user input, AI, and everything else in the game, updating the game state by one tiny step. So sometimes games aren't the full 60 frames per second.
One problem that occurs when you don't have exactly 60 frames per second is tearing. Tearing happens when the software changes what they want displayed while the monitor is drawing, half way across the screen. If your guy moves in that change, you can get, for one tiny fraction of a second, half of them in the previous frame and half in the next one. Because it's so fast, most people don't notice it, but it bothers those who do, and it can become noticeable in faster games.
The solution is vertical sync. By forcing the game to only draw its graphics while the monitor is in its vertical blank, no tearing is possible, because the software frames are synchronized with the monitor refresh. This sounds great until you realize that it makes games which would otherwise pull 50 frames per second (ie, they JUST MISSED the vertical blank deadline, a little bit slower than the monitor) idle so much waiting for the NEXT vertical blank that it drops from 50 to 30 frames per second. Which is fine if you don't notice this, but if you do, it sucks.
How does this affect Dwarf Fortress? The default framerate for DF is 100 frames per second, much higher than your vertical blank. Dwarf Fortress runs this speed because time is counted in frames, not in real time -- the game does everything it has to internally, and then draws, each frame. If the framerate drops, Dwarf Fortress slows down everything in the game. Feeding a very high framerate to DF keeps your dwarves moving at a brisk pace. Enabling vertical sync forces DF to reduce its framerate to the monitor's, thus preventing the game from updating as much as it'd like to, and forcing it to yield back processor time it would otherwise use for thinking about what to do next. It will indeed reduce your processor load, but it's a pretty good bet that if you enable framerate display in the init file, you'll see that the reason the processor load has dropped is because the framerate is lower now than it was before.
[ October 26, 2007: Message edited by: Jonathan S. Fox ]
Author
Topic: Almost 100% processor time at main menu [SOLVED] (Read 2059 times)