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

Change: include fmt.h C++ headers in stdafx.h

This to prevent compilation issues between runs with and without precompiled
headers. Also remove the headers from the rest of the code base as they are
not needed there anymore, although they do relatively little harm.

Feature: Variable GUI scale.

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

Fix 91b8ce07: dedicated servers could no longer create screenshots (#9232)

Although most commands are not useful on a dedicated server,
screenshot commands should be dequeued.

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.

Add: make modal windows update more smooth

Basically, modal windows had their own thread-locking for what
drawing was possible. This is a bit nonsense now we have a
game-thread. And it makes much more sense to do things like
NewGRFScan and GenerateWorld in the game-thread, and not in a
thread next to the game-thread.

This commit changes that: it removes the threads for NewGRFScan
and GenerateWorld, and just runs the code in the game-thread.
On regular intervals it allows the draw-thread to do a tick,
which gives a much smoother look and feel.

It does slow down NewGRFScan and GenerateWorld ever so slightly
as it spends more time on drawing. But the slowdown is not
measureable on my machines (with 700+ NewGRFs / 4kx4k map and
a Debug build).

Running without a game-thread means NewGRFScan and GenerateWorld
are now blocking.

Fix: ensure switching blitter happens in the main thread

This because video-drivers might need to make changes to their
context, which for most video-drivers has to be done in the same
thread as the window was created; main thread in our case.

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.

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.

Add: Option to (dis-)allow accelerated video drivers. (#8819)

The video drivers using the OpenGL backend are currently our only
accelerated drivers. The options defaults to off for macOS builds and
to on everywhere else.

Co-authored-by: Michael Lutz <michi@icosahedron.de>

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.

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.

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.

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

(svn r11734) -Change: Allow ToggleFullScreen to return the result of the operation' attempt. Previously, only visual clues were available.
-Fix[FS#1519]: When you can not use this resolution at full screen, now you'll know that it failed.
As for the reason it did not work, each computer/OS has its reason.