Codechange: [OSX] Only keep a total dirty rect for drawing.

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.

Update: Translations from eints
estonian: 62 changes by siimsoni
korean: 1 change by telk5093
russian: 2 changes by Ln-Wolf
finnish: 2 changes by hpiirai

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: [Cygwin] Fix missing uint definition

In file included from src/settingsgen/../string_func.h:30,
from src/settingsgen/settingsgen.cpp:11:
src/settingsgen/../core/bitmath_func.hpp:34:15: error: 'uint' does not name a type; did you mean 'uint8'?
34 | static inline uint GB(const T x, const uint8 s, const uint8 n)
| ^~~~
| uint8

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.

Update: Translations from eints
german: 1 change by Wuzzy2
russian: 11 changes by Ln-Wolf
catalan: 2 changes by J0anJosep
spanish: 14 changes by perezdidac

Fix d437445c: also use std::chrono for the GRFFileScanner modal window

For some reason I only converted one of the two modal windows we
have, and completely forgot the other.

While at it, synchronize the way those two modal windows work
in terms of "next_update".

Fix: [Actions] if SDL2 is installed, it is always picked over SDL1

So no need to install both SDL1 and SDL2, that gives a false idea
of reality.

Fix: [Actions] build our allegro driver too in our CI

This prevents us breaking it without realising.

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

Codechange: use std::chrono to track time in modal windows

Adding to _realtime_ticks in a random place is a bit of a hack,
and by using modern C++, we can avoid this hack.

Add: Indonesia Rupiah as in-game currency (#8616)

The exchange rate is actually more like 19,000, but OpenTTD
doesn't handle such high exchange rates kindly.

Update: Translations from eints
russian: 1 change by Ln-Wolf
polish: 2 changes by yazalo

Fix: Whole status bar instead of money widget refreshed on money change (#8692)

This could result in the rest of the status bar being
redrawn unnecessarily frequently

Fix: Unnecessary status bar redraws when there is no news to show (#8691)

InvalidateWindowData with mode SBI_NEWS_DELETED was called on the
status bar when checking for a new item of news to be shown in the
ticker, even if there is no news queued and no change occurs.

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.

Update: Translations from eints
german: 2 changes by Wuzzy2
slovak: 5 changes by FuryPapaya
dutch: 4 changes by LouisDeconinck
spanish: 1 change by MontyMontana

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.

Fix: framerate window showed a slightly higher rate than actually measured (#8682)

The first point was counted, but also initialized as "last". As
such, it didn't add to "total", but did add to "count", which made
the "count" 1 more than the total actually represents.

Update: Translations from eints
korean: 2 changes by telk5093
indonesian: 11 changes by dimaspaf14
russian: 2 changes by Ln-Wolf
finnish: 3 changes by hpiirai
french: 4 changes by glx22

Update: Translations from eints
korean: 2 changes by telk5093
german: 56 changes by Wuzzy2
finnish: 2 changes by hpiirai
catalan: 2 changes by J0anJosep
polish: 9 changes by yazalo

Update: Translations from eints
slovak: 13 changes by FuryPapaya
catalan: 7 changes by J0anJosep
french: 1 change by arikover

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: [Win32] Increase SDK version for 32-bit target.

Use the same Windows XP target as for 64-bit. Current MSVC version will
not produce a binary that works on anything earlier anyway.

Change: [OSX] When auto-detecting a font, try for sans-serif first.

On a display, especially with small fonts or low pixel sizes, sans-serif
fonts are usually easier to read than serif fonts.

Remove: [OSX] Startup splash screen.

It wasn't displayed anyway as it was never copied to the bundle.

Codechange: [OSX] Split drawing into its own subview.

This allows the drawing backend code to be independent
of any event or command handling.