Fix: [SDL] remove hint to avoid hardware acceleration (#11790)

This hint was once needed because of the way we handled surfaces.
But as OpenGL already uses a hardware surface, we already had to
fix all the issues that comes with it. As that is generic code,
this hint is no longer actually needed. Further more, recent SDL
versions break because of it on Wayland.

Fix: [Emscripten] config not saved on exit game (#11248)

When changing a Game Option and pressing Exit Game, the changes
were not actually stored. This because the post-mainloop code
was never executed for Emscripten.

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

Codechange: remove queue_wrap / last_position from mouse movement

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

Fix: [SDL] unify the way X11 and Wayland handle mouse events

Basically, we drop RelativeMode completely, and use the same trick
as used by the Windows driver: read all motion events till the last
one, and use that as value.

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.

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.

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.

Codechange: [SDL2] Allow several places to hook into the SDL driver

This allows future subdrivers to use these to manage their
own flow.

Codechange: [SDL2] Move functions and variables to class-scope

This allows future subdrivers to override them.

Codechange: [SDL2] Move SDLSurface code to its own function

This increases readability, and allow future subdrivers to not
use SDLSurface to draw.

Codechange: [SDL2] Split Start() in a few more functions

This makes it a bit easier to follow what is going on, and
allow future subdrivers to hook into a few of these functions.

Reworked the code slighly while at it, to return early where
possible.

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.

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

Fix: [SDL2] simplify what to redraw to prevent tearing (#8685)

When there are a lot of rects to redraw, of which one of the last
ones is almost the full screen, visual tearing happens over the
vertical axis. This is most visible when scrolling the map.

This can be prevented by using less rects. To simplify the situation,
and as solutions like OpenGL need this anyway, keep a single rect
that shows the biggest size that updates everything correctly.

Although this means it needs a bit more time redrawing where it
is strictly seen not needed, it also means less commands have
to be executed in the backend. In the end, this is a trade-off,
and from experiments it seems the approach of this commit gives
a better result.

Fix 52317bb7: [SDL2] ensure we don't try to blit out of bounds (#8684)

During resizing, there can still be dirty-rects ready to blit based
on the old dimensions. X11 with shared memory enabled crashes if
you try to do this. So, instead, if we resize, reset the dirty-rects.

This is fine, as moments later we mark the whole (new) screen as
dirty anyway.

Change: [SDL2] Remove unneeded delay of redrawing the screen

In testing, I could find no reason why this statement is here.

The comment is rather unclear (it states what it does, but not
why it would be needed).

This line of code was introduced with f4f40448, which gives no
further insight on why it would be needed to have it here.

As such, let's remove it and see if anyone else reports any
problems with it. If so, this commit can be reverted and a more
clear comment should be added what this line of code is dealing
with (the WHY, not the WHAT).

Codechange: [SDL2] Name paint function Paint(), like other drivers do

This reduces confusion when reading different drivers.

Fix 30e69c51: palette was not marked dirty when creating a new

This means the code depended that the caller did this for us
before MakePalette() is executed, which is neither a
requirement nor a promise the code makes.

Fix #8029: [SDL2] disable draw-thread on wayland SDL video driver (#8648)

When the wayland SDL video driver is used, an EGL context is
created in the main thread. It is not allowed to update this
context from another thread, which is exactly what our draw-thread
is trying.

The other solution would be to move all of SDL into the
draw-thread, but that would introduce a whole scala of different
problems.

The wayland SDL backend is significantly faster than the
X11 SDL backend, but there is a performance hit nevertheless.

Codechange: Apply coding style (#8640)

* Fix: Missing or needed spaces

* Codechange: Remove space

* Codechange: Remove space

* Codechange: More missing spaces

* Codechange: Missing spaces

* Codechange: Remove space

* Codechange: Remove space

Codechange: [SDL2] Use MakeDirty() to force a redraw

The original code is "strictly correct", but just reads really
weird, and we use MakeDirty() in several other places instead too.

Codechange: [SDL2] Rework how palette is updated

It now follows more what the Win32 driver does, and has far less
exceptions and special casing.

MakePalette creates the Palette and prepares surface.
UpdatePalette updates the Palette.
CheckPaletteAnim checks if UpdatePalette needs to be called and
marks the whole screen dirty so DrawSurfaceToScreen will do a
full redraw.

Fix: [SDL2] Display why SDL_CreateWindow() failed in case it does

All SDL_NNN errors print SDL_GetError, except for this one place.

Codechange: [SDL2] Split away CreateMainWindow from CreateMainSurface

This makes the code a bit more readable, as both intentions are
more clear, and there is less nesting in the main function.

Codechange: [SDL2] reworked FindResolutions to be more like the rest

There was no default resolution fallback, and the code was different
from the win32 driver. It is now named the same and much more
similar.

Codechange: [SDL2] remove include-protection

This is already done by CMake: if SDL2 is not detected, this file
is not included.

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

Add: [Emscripten] use "relative mouse mode" with SDL2

This mode doesn't wrap the mouse constantly, but requests SDL
to lock the mouse pointer. This is needed, as with Emscripten
you are not allowed to change the mouse poisition (only to lock
it into place).

Add: support for emscripten (play-OpenTTD-in-the-browser)

Emscripten compiles to WASM, which can be loaded via
HTML / JavaScript. This allows you to play OpenTTD inside a
browser.

Co-authored-by: milek7 <me@milek7.pl>

Codechange: unroll the SDL2 main loop

This commit prepares for the next commit, as Emscripten needs to
have a way to trigger a single iteration of the main loop. To
keep the real changes more clear, this commit only unrolls the
loop, and makes no changes to the logic itself.

Fix #8104: Always add WINDOW_RESIZABLE flag to SDL2 (#8211)

This fixes a bug that can reproduced with these steps:
* Start openttd in fullscreen mode
* Turn off fullscreen mode
* Try to resize the window. The window can't be resized.

Fix: [SDL2] Correct name of the video driver in debug log

SDL_GetVideoDriver(0) returns name of first video driver included in
the library, not the driver currently used.
SDL_GetCurrentVideoDriver() does what we want here.

Fix #7783, Fix #7816: [SDL2] Fix input handling in edit context

In particular this fixes handling of the shift key

Change: [SDL2] Add an "unprintable" flag to struct VkMapping

SDL_Keysym::sym is not suitable for checking whether the character
is printable or not

Fix: [SDL2] Page down key not handled

SDLK_PAGEUP and SDLK_PAGEDOWN are not sequential
They must have separate entries in _vk_mapping

Fix: [SDL2] Detection of backtick scancode

SDL_Keysym::scancode is a SDL_SCANCODE_* constant, not a raw scan code

Fix #7784: up/down/home/end key behavior in SDL2

Closes #7784.

Codechange: Don't use SDL_CreateRGBSurfaceWithFormat()

This function requires libSDL 2.0.5 or higher. It looks like we don't
need to use it, and can just use the original SDL_CreateRGBSurface(),
with the masks set to 0, to trigger the default 8-bit format, which is
SDL_PIXELFORMAT_INDEX8.

Closes #7785

Note: this code path is activated by using an 8-bit blitter, like:

./bin/openttd -b 8bpp-simple