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 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?
dP
Jonathan G Rennison
Patric Stout
Charles Pigott
Michael Lutz
translators
milek7