The define kCGBitmapByteOrder32Host changed (around SDK 12?)
into an enum, which means an old #ifndef was triggering,
overwriting the value to 0. Sadly, 0 means Order16Big, causing
RGBA to become GRAB, which results in strange colours.
As we no longer support PPC, drop that piece of code completely.
They all now access a std::string_view, instead of a "const char *"
or std::string (in some cases).
Additionally, GetCharAtPosition and friends now return an index
instead of a "const char *", as it makes for a more clear interface.
Touchbar support was introduced in 10.12.2. There's no need to limit
support to 10.15+, as the convenience class NSButtonTouchBarItem is
easily replicated.
The enum values still have the exact same numerical values, but the 10.12
SDK introduced more explicit names (e.g. like NSEventTypeApplicationDefined
instead of NSApplicationDefined) for several enum constants.
Use them when available.
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.
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.
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>
MainLoop() is used to bootstrap OSX, where later a callback is
done to GameLoop() to execute OpenTTD. All other video drivers
don't need that, so what is in GameLoop is in MainLoop for all
other drivers. This is rather confusing. So, instead, name
GameLoop MainLoopReal to be more in sync with the other drivers.
