MaskWireBits always returns its input unchanged if the input
has only 0 or 1 track bits set.
Having only 0 or 1 track bits sets (i.e. non junction tiles)
is by far the most common case.
Examining the state of neighbouring tiles and the subsequent
masking logic is relatively expensive and can be omitted in this case.
It didn't sit well to me, how I wrote the commit initially. First
casting a variable into another, only to write it back into the
originally feels wrong.
This flow makes a bit more sense to me.
Otherwise that might cause calls to the video-driver, which are
already shut down by now. This causes, depending on the video-driver
crashes or weird effects.
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.
gui_zoom was never clamp'd between zoom_min/zoom_max.
zoom_min controls how zoomed-in we load sprites. For a value of 1,
no quad-sizes sprites are loaded. If gui_zoom would be 0, meaning
it wants quad-sized sprites to display, it was printing random
stuff to the screen, which could or could not result in crashes.
Otherwise both the draw-thread and game-thread can do it both
at the same time, which gives rather unwanted side-effects.
Calling it from the draw-thread alone is sufficient, as we just
want to create some unpredictable randomness for the player. The
draw-thread is a lot more active (normally) than the game-thread,
so it is the best place of the two to do this.
Additionally, InteractiveRandom() mostly has to do with visuals
that are client-side-only, so more related to drawing than to
game.
v->tile for aircrafts is always zero when in the air. Only when
it starts its landing (or take-off) patterns it becomes a sane
value.
So instead, base the news on the last x/y coordinates of the plane.
english (us): 18 changes by 2TallTyler
korean: 17 changes by telk5093
german: 13 changes by danidoedel, 4 changes by Wuzzy2
finnish: 17 changes by hpiirai
catalan: 17 changes by J0anJosep
lithuanian: 33 changes by devbotas
spanish: 17 changes by MontyMontana
portuguese (brazilian): 20 changes by Greavez
polish: 9 changes by yazalo
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.
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>
chinese (traditional): 5 changes by benny30111
estonian: 1 change by siimsoni
italian: 1 change by AlphaJack
ukrainian: 4 changes by StepanIvasyn
tamil: 37 changes by Aswn
portuguese (brazilian): 19 changes by Greavez
Reworked how the screenshot command works while keeping it backwards
compatible. It can now more freely understand arguments, and has
the ability to make SC_DEFAULTZOOM screenshots.
In other words, it should only (!) return true if A comes for B.
This promise was broken for the situation where two values are
identical. It would return true in these cases too. This is of
course not possible: if two values are identical, neither come
before the other. As such, the sorter was not imposing strict
weak ordering relations.
libstdc++ handled this scenario just fine, but libc++ crashes
badly on this, as it allowed comparing of [begin, end] instead
of [begin, end).
libc++ considered this not a bug (and by specs, they are correct;
just this way of crashing is of course a bit harsh):
https://bugs.llvm.org/show_bug.cgi?id=47903
english (us): 4 changes by 2TallTyler
italian: 4 changes by troccoli
serbian: 251 changes by nkrs
german: 6 changes by ebla71, 2 changes by Wuzzy2
romanian: 3 changes by ALEX11BR
russian: 11 changes by Ln-Wolf
ukrainian: 2 changes by StepanIvasyn
lithuanian: 15 changes by devbotas
spanish: 2 changes by perezdidac
The bootstrap has the _switch_mode to SM_MENU, and never leaves
this mode. Neither is it considered a modal window (while in some
sense it really is). So .. we need to add another "draw anyway"
exception, to make sure bootstrap is being drawn.
By default this setting is set to 2500% normal game speed.
(cherry picked from commit c3dc27e37e)
# Conflicts:
# src/gfx.cpp
# src/gfx_func.h
# src/settings_type.h
# src/video/cocoa/cocoa_v.mm
# src/video/video_driver.cpp
# src/video/win32_v.cpp
When you are downloading a map, all the commands are queued up
for you. Clients joining/leaving is done by the network protocol,
and as such are processed immediately. This means that by the
time you are processing the commands, a client that triggered
it, might already have left.
So, all commands that do something with ClientID, shouldn't
error on an invalid ClientID when DC_EXEC is set, but
gracefully handle the command anyway, to make sure the
game-state is kept in sync with all the clients that did
execute the DoCommand while the now-gone client was still
there.
Additionally, in the small chance a client disconnects between
the server validating a DoCommand and the command being
executed, also just process the command as if the client was
still there. Otherwise, lag or latency can cause clients that
did not receive the disconnect yet to desync.
(cherry picked from commit 2d9062bfc1)
Send all clients in the queue every game-day a packet that they
are still in the queue.
(cherry picked from commit 13889b6554)
# Conflicts:
# src/network/network_server.cpp
Strictly seen, there are "N" people -waiting- in front of you
in the queue, but it is nicer to show "N + 1" for the person that
is currently downloading the map. Avoids it showing:
"0 clients in front of you". That just feels a bit off.
(cherry picked from commit 3677418225)
Remove caching from vehicle group object. and recalculate it whenever
required instead.
(cherry picked from commit 6b8f9b50b9)
# Conflicts:
# src/vehicle_gui.cpp
When you are downloading a map, all the commands are queued up
for you. Clients joining/leaving is done by the network protocol,
and as such are processed immediately. This means that by the
time you are processing the commands, a client that triggered
it, might already have left.
So, all commands that do something with ClientID, shouldn't
error on an invalid ClientID when DC_EXEC is set, but
gracefully handle the command anyway, to make sure the
game-state is kept in sync with all the clients that did
execute the DoCommand while the now-gone client was still
there.
Additionally, in the small chance a client disconnects between
the server validating a DoCommand and the command being
executed, also just process the command as if the client was
still there. Otherwise, lag or latency can cause clients that
did not receive the disconnect yet to desync.
Strictly seen, there are "N" people -waiting- in front of you
in the queue, but it is nicer to show "N + 1" for the person that
is currently downloading the map. Avoids it showing:
"0 clients in front of you". That just feels a bit off.
swedish: 60 changes by kustridaren
norwegian (bokmal): 12 changes by buzzCraft
czech: 82 changes by PatrikSamuelTauchim, 1 change by tomas-vl
italian: 86 changes by AlphaJack, 9 changes by federico1564S
german: 16 changes by ebla71
romanian: 10 changes by ALEX11BR
ukrainian: 3 changes by StepanIvasyn
spanish: 1 change by MontyMontana
SendError() notifies all clients of the disconnect. This calls
CloseConnection() at the end, which also notified the clients
of the disconnect. Really no need to do it twice.
The status NETWORK_RECV_STATUS_SERVER_ERROR is only set by
SendError(), so in case that is the status, don't let
ClientConnection() send another notification.
CheckCompanyHasMoney() was also executed when not using DC_EXEC,
resulting in an error about shortage of money instead of the
estimation.
This mostly is a problem for AI players, as they will have no
way to know how much it would have cost.
Basically, follow_track.hpp contains a fix for half-tiles, but
this wasn't duplicated for when trying to find a depot and in
a few other places. This makes sure all places act the same.
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.
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.
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.
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
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.
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".
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).
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.
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 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.
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
Patric Stout
Matt Kimber
Didac Perez Parera
Jonathan G Rennison
stormcone
translators
Tyler Trahan
frosch
sean
PeterN
Michael Lutz
dP
Eddi-z
TELK
Lastorder
Limyx826
Charles Pigott
Owen Rudge
Niels Martin Hansen
SamuXarick
Joe Stringer
Tegas Aziz
Wuzzy
Yourself
glx22
milek7