Baughn: Would it be realistic to decouple the screen drawing from the engine speed by essentially double-buffering and using a separate thread to update the screen? The real idea would be to prevent slow rendering from slowing down the game further, and to some extent make the specification of G_FPS to be irrelevant because it can just redraw as fast as possible and still let the game run at full speed.
The idea I have is:
Have a memory graphics buffer the game writes directly to, this buffer is locked while the game is writing to it, and unlocked while the game is simulating. (This depends on there being such a distinction...?) When the graphics rendering thread wants to render, it takes a lock on the game's graphics buffer, of course blocking until it gets that lock. When the graphics thread has taken the lock, it makes a copy of the buffer to a "front buffer" and releases the game graphics buffer lock again, letting the game simulation continue; this lock-copy-unlock should barely take any time, seeing the buffer can't be much more than a few kb large. The graphics thread now has a private copy of the game screen, and can spend as much time as it likes rendering the display, while the game engine is free to simulate as many frames it can in the meanwhile.
Keyboard and mouse input is a separate issue here, since what the user views might be several game frames behind the input. It should probably go to some input queue the game reads directly, maybe running in a third thread, or maybe running in the game engine thread.
Changes to the graphics window should be sent to the game engine when the graphics engine unlocks the game graphics buffer after copy.
The issue I'm proposing the solution to here is that I can may get 80-100 simulation-FPS and 20 graphics-FPS when G_FPS set to 20, but get 30-40 FPS if I set G_FPS to 50. Decouple rendering from simulating completely, and that should never be an issue again.
It would also (temporarily) shut up people complaining that DF doesn't use their dual-core CPU's