| Age | Commit message (Collapse) | Author |
|---|
|
ThreadSanitizer rightfully notices that the game-thread could
update the palette while the draw-thread is copying it for local
use. The odds of this are very small, but nevertheless, it does
carry a very good point.
It wouldn't hurt the application in any way, but it might cause
visual glitches on the screen.
|
|
It was a bit of a mixed bag. With this change, gfx.cpp is in
control who accesses _cur_palette from the video-drivers.
|
|
_exit_game is read by the draw-thread to know when to exit, but
most of the time written by the game-thread.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
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.
|
|
|
|
By default this setting is set to 2500% normal game speed.
|
|
|
|
Adding to _realtime_ticks in a random place is a bit of a hack,
and by using modern C++, we can avoid this hack.
|
|
|
|
|
|
|
|
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).
|
|
|
|
|
|
|
|
|
|
ago (#7844)
The 'DoDrawString' was removed with this commit: f11300d
|
|
|
|
|
|
|
|
|
|
|
|
|
|
text layout code.
|
|
instead of heap allocated.
This reduces memory allocations and heap fragmentation.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
This switch has been a pain for years. Often disabling broke
compilation, as no developer compiles OpenTTD without, neither do
any of our official binaries.
Additionaly, it has grown so hugely in our codebase, that it
clearly shows that the current solution was a poor one. 350+
instances of "#ifdef ENABLE_NETWORK" were in the code, of which
only ~30 in the networking code itself. The rest were all around
the code to do the right thing, from GUI to NewGRF.
A more proper solution would be to stub all the functions, and
make sure the rest of the code can simply assume network is
available. This was also partially done, and most variables were
correct if networking was disabled. Despite that, often the #ifdefs
were still used.
With the recent removal of DOS, there is also no platform anymore
which we support where networking isn't working out-of-the-box.
All in all, it is time to remove the ENABLE_NETWORK switch. No
replacement is planned, but if you feel we really need this option,
we welcome any Pull Request which implements this in a way that
doesn't crawl through the code like this diff shows we used to.
|
|
(#7273)
|
|
Adds an option in the "Game Options" next to "Interface Size" called "Font Size". Available options are normal, double, and quad.
|
|
|
|
|
|
Select foreground colour depending on the brightness of the background.
Previously all cargo labels were rendered using black text, even
the background cargo colour was dark/black.
As an example: FIRS coal was black text on a black background.
|
|
|
|
sprites.
|
|
|
|
conversions in initializer lists.
|
|
a file no its own. (Cif)
|
|
failed for dashed lines. (noticed by adf88)
|
