Remove: officially mark Vista as no longer supported (#11531)

It is very likely Vista hasn't been working for years, but the
amount of users that use an OS that has been EoL for over 11 years
is very small, so reports happen rarely.

Codechange: automatic adding of _t to (u)int types, and WChar to char32_t

for i in `find src -type f|grep -v 3rdparty/fmt|grep -v 3rdparty/catch2|grep -v 3rdparty/opengl|grep -v stdafx.h`; do sed 's/uint16& /uint16 \&/g;s/int8\([ >*),;[]\)/int8_t\1/g;s/int16\([ >*),;[]\)/int16_t\1/g;s/int32\([ >*),;[]\)/int32_t\1/g;s/int64\([ >*),;[]\)/int64_t\1/g;s/ uint32(/ uint32_t(/g;s/_uint8_t/_uint8/;s/Uint8_t/Uint8/;s/ft_int64_t/ft_int64/g;s/uint64$/uint64_t/;s/WChar/char32_t/g;s/char32_t char32_t/char32_t WChar/' -i $i; done

Fix 07add7a9: [Win32] use full monitor resolution for fullscreen (#10985)

On Windows in fullscreen you cannot reach the top with
the cursor for the halve of the height of your toolbar.

Additionally, on Win10 in fullscreen you can see the actual toolbar.

Codechange: remove queue_wrap / last_position from mouse movement

No backend uses it anymore, so also no longer any need to support
it.

Feature: Variable GUI scale.

GUI scale is now variable from 100% to 500%, and no longer restricted to
powers-of-2.

Codechange: use _cur_palette the same in all the drivers

It was a bit of a mixed bag. With this change, gfx.cpp is in
control who accesses _cur_palette from the video-drivers.

Feature: allow a toggle to enable/disable vsync

Vsync should be off by default, as for most players it will be
better to play without vsync. Exception exist, mainly people who
play in fullscreen mode.

Fix #8930: [Win32] Don't handle printable keys on keydown if an edit box is in focus.

Handle printable input only when the matching WM_CHAR message is incoming.
Without an edit box, do the handling in keydown as usual to support hotkeys.

Add: [Video] move GameLoop into its own thread

This allows drawing to happen while the GameLoop is doing an
iteration too.

Sadly, not much drawing currently can be done while the GameLoop
is running, as for example PollEvent() or UpdateWindows() can
influence the game-state. As such, they first need to acquire a
lock on the game-state before they can be called.

Currently, the main advantage is the time spend in Paint(), which
for non-OpenGL drivers can be a few milliseconds. For OpenGL this
is more like 0.05 milliseconds; in these instances this change
doesn't add any benefits for now.

This is an alternative to the former "draw-thread", which moved
the drawing in a thread for some OSes. It has similar performance
gain as this does, although this implementation allows for more
finer control over what suffers when the GameLoop takes too
long: drawing or the next GameLoop. For now they both suffer
equally.

Codechange: don't set the window position when changing blitter

There really is no need to make an extra call to the OS in
these cases.

Remove: [Video] no longer draw in a thread

Drawing in a thread is a bit odd, and often leads to surprising
issues. For example, OpenGL would only allow it if you move the
full context to the thread. Which is not always easily done on
all OSes.
In general, the advise is to handle system events and drawing
from the main thread, and do everything else in other threads.
So, let's be more like other games.

Additionally, putting the drawing routine in a thread was only
done for a few targets.

Upcoming commit will move the GameLoop in a thread, which will
work for all targets.

Fix #8784: using alt+enter didn't update the fullscreen toggle visibly (#8820)

Basically, the window was not invalidated, so it was never redrawn.
This made it look like it wasn't working, but it really was.

Add: settings to limit your fast-forward game speed

By default this setting is set to 2500% normal game speed.

Codechange: [Video] make the prototype of PollEvent() the same for all drivers

Additionally, call it from the draw-tick.

Fix #6319: [Win32] don't use clipping; draw whole screen every frame (#8726)

When we clip the region that is only been redrawn, something
weird happens on Windows. When pushing 60 frames per second on a
60Hz monitor, it appears that the clipped region is often shown
of another frame, instead of the current.

Examples of this are:
- pause the game, move your mouse to the left, and at the right
speed it totally disappears.
- fast aircrafts seem to be in several places at once, weirdly
lagging behind.
- in title screen, moving your mouse gives you the idea it is
jumping places, instead of smooth movements.

In the end, if you do nothing, everything is correct, so it is
eventually consistent. Just when we are firing many BitBlt in
a clipped region, the in-between is not.

What goes wrong exactly, I honestly do not know. On every frame
that we push to the DC is a mouse painted, but visually it
sometimes appears like it is not. Recording with external software
shows it really is there.
It is also not our eyes playing tricks on us, as the first example
makes it really clear the mouse pointer really is not painted.

And to be clear, with the mouse this is easiest reproduceable,
as high-speed objects are influences by this most. But this happens
for all movement that redraws small regions.

Either way, not using clipped regions resolves the issue completely,
and there appears to be little to no penalty (I failed to measure
any impact of drawing the full screen). So better have a good game
than fast code, I guess?

Codechange: deduplicate tick-handlers of all video drivers

They were all identical, so better put this in a single place
hoping it is less likely to break.

Change: [Win32] Remove force_full_redraw and display_hz settings

These were special settings only for the win32-drivers, and
introduced in the very first version we track.

Time kinda had caught up with those variables, so it is time to
say farewell.

force_full_redraw was most likely a debug functionality "in case
our dirty-rect fails". This should no longer be needed.

display_hz was cute, as it had a max of 120. That is kinda
out-dated information, but I also doubt anyone was really using
this.

Codechange: be consistent in what CheckPaletteAnim() does and when it is called

Additionally, make sure this is a class method. Later commits
will make use of this.

Codechange: be consistent in naming the paint function Paint()

Also move this function to be a class member. This to allow
further deduplicating of code in a later commit.

Codechange: [Win32] make fast-forward check the same as with other drivers

It was of all the drivers the only one doing this slightly different.
When trying to unify more code, that was rather annoying.

Fix: [Win32] run InteractiveRandom() once every tick, not once every message

Win32 was the only video driver doing this. It is just a bit too
much random.

Fix: [Win32] now we are drawing on a tick, no longer use WM_PAINT

WM_PAINT hits when-ever Windows feels like, but always after we
marked the screen as dirty. In result, it was lagging behind,
giving a sub-60fps experience.

With the new draw-tick there is no longer a need to be driven by
WM_PAINT, so it is better anyway to drive the drawing ourself. As
an added bonus this makes the win32 driver more like the others.

Fix: during switching of game-mode, drawing could show closed windows that shouldn't be closed yet

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.

Feature: configurable refresh-rate and change default to 60fps

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.

Change: sleep till the next tick in the main loop

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.

Change: allow video-drivers to miss deadlines slightly

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.

Add: draw the screen at a steady pace, also during fast-forward

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.

Codechange: track _realtime_tick more accurate

_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.

Codechange: switch all video drivers to std::chrono for keeping time

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).

Add: [Win32] Automatic zoom level suggestion for Win32 video driver.

The zoom level suggestion is based on the DPI scaling set in Windows.
We use 150% scaling as the threshold for 2X zoom and 300% scaling
as the threshold for 4X zoom.

Codechange: [SDL2/Win32] Be consistent how 0bpp blitters are not allowed

Sometimes it returned an usererror(), sometimes Start() failed.
Now it always fails on Start(), so nothing else has to check again
what blitter is used.

AfterBlitterChange() can never change to a 0bpp, so it is sufficient
to guard this with an assert().

Codechange: [Win32] Use _local_palette for most operations

Other drivers do this too, and this makes the world a bit more
the same.

Codechange: [Win32] use CSleep() instead of Sleep() like everywhere else

Functional it is identical. Just helps future-us when searching
for sleeps.

Doc: some comments for the win32 video driver (#8409)

Co-authored-by: Niels Martin Hansen <nielsm@indvikleren.dk>

Codechange: Replace custom thread code with C++11 thread objects.

We assume a conforming C++11 compiler environment that has a valid <thread>-header.
Failure to run a real thread is handled gracefully.