When drawing an 8bpp screen buffer, palette resolving was done for each
dirty rectangle. In areas with high activity, this would mean a pixel might
have been resolved multiple times. Also, if too many individual updates
were queued, the whole screen would be refreshed, even if unnecessary.
All other drivers only keep one overall dirty rect, so do it here as well.
The higher your refresh-rate, the more likely this is. Mostly you
notice this when creating a new game or when abandoning a game.
This is a bit of a hack to keep the old behaviour, as before this
patch the game was already freezing your mouse while it was changing
game-mode, and it does this too after this patch. Just now it
freezes too a few frames earlier, to prevent not drawing windows
people still expect to see.
Most modern games run on 60 fps, and for good reason. This gives
a much smoother experiences.
As some people have monitors that can do 144Hz or even 240Hz, allow
people to configure the refresh rate. Of course, the higher you
set the value, the more time the game spends on drawing pixels
instead of simulating the game, which has an effect on simulation
speed.
The simulation will still always run at 33.33 fps, and is not
influences by this setting.
Sleep for 1ms (which is always (a lot) more than 1ms) is just
randomly guessing and hoping you hit your deadline, give or take.
But given we can calculate when our next frame is happening, we
can just sleep for that exact amount. As these values are often
a bit larger, it is also more likely the OS can schedule us back
in close to our requested target. This means it is more likely we
hit our deadlines, which makes the FPS a lot more stable.
Before, every next frame was calculated from the current time.
If for some reason the current frame was drifting a bit, the
next would too, and the next more, etc etc. This meant we rarely
hit the targets we would like, like 33.33fps.
Instead, allow video-drivers to drift slightly, and schedule the
next frame based on the time the last should have happened. Only
if the drift gets too much, that deadlines are missed for longer
period of times, schedule the next frame based on the current
time.
This makes the FPS a lot smoother, as sleeps aren't as exact as
you might think.
During fast-forward, the game was drawing as fast as it could. This
means that the fast-forward was limited also by how fast we could
draw, something that people in general don't expect.
To give an extreme case, if you are fully zoomed out on a busy
map, fast-forward would be mostly limited because of the time it
takes to draw the screen.
By decoupling the draw-tick and game-tick, we can keep the pace
of the draw-tick the same while speeding up the game-tick. To use
the extreme case as example again, if you are fully zoomed out
now, the screen only redraws 33.33 times per second, fast-forwarding
or not. This means fast-forward is much more likely to go at the
same speed, no matter what you are looking at.
_realtime_tick was reset every time the diff was calculated. This
means if it would trigger, say, every N.9 milliseconds, it would
after two iterations already drift a millisecond. This adds up
pretty quick.
On all OSes we tested the std::chrono::steady_clock is of a high
enough resolution to do millisecond measurements, which is all we
need.
By accident, this fixes a Win32 driver bug, where we would never
hit our targets, as the resolution of the clock was too low to
do accurate millisecond measurements with (it was ~16ms resolution
instead).
We never change the real screen resolution on OSX. As such, offering a list
of resolutions is pointless. Instead of that, offer the user a list of
commonly used window sizes up to the current screen size.
