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?
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.
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.
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.
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.
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.
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.
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.
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.
_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.
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).
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.
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.
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.
We never change the real screen resolution on OSX. As such, offering a list
of resolutions is pointless. Instead of that, offer the user a list of
commonly used window sizes up to the current screen size.
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).
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.
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.
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.
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().
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).
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>
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.
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.
CMake works on all our supported platforms, like MSVC, Mingw, GCC,
Clang, and many more. It allows for a single way of doing things,
so no longer we need shell scripts and vbs scripts to work on all
our supported platforms.
Additionally, CMake allows to generate project files for like MSVC,
KDevelop, etc.
This heavily reduces the lines of code we need to support multiple
platforms from a project perspective.
Addtiionally, this heavily improves our detection of libraries, etc.
Since the move to C++11, building for pre 10.7 is not possible with the native
Apple tools. Also, due to bitrot, the file doesn't even compile anymore. While
this could be fixed, it shows that this subdriver is basically never used anymore.
Since the C++11 move, getting OpenTTD to compile and run for anything
below 10.7 basically requires building a custom compiler and libc++.
Also, the QuickDraw subdriver crashes on more modern OSX version. While this
is fixable, keeping the driver around is probably pointless.
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.
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
A conforming compiler with a valid <mutex>-header is expected.
Most parts of the code assume that locking a mutex will never fail unexpectedly,
which is generally true on all common platforms that don't just pretend to
be C++11. The use of condition variables in driver code is checked.
