| Age | Commit message (Collapse) | Author |
|---|
|
of new + unique_ptr
With std::variant all memory can be figured out at compile time, so the compiler needs to keep track of fewer elements. It also saves out a unique_ptr and its memory management, over a slight impact for resolving a setting.
|
|
constructor
This as using std::string causes much more variables to be tracked, potentially causing problemes for certain compilers in certain situations
|
|
SettingDesc
|
|
saveload macros
This to help variant's constructor to be able to resolve the constructor of the setting
|
|
One UpdateServiceInterval has two parameters to update the service interval for a vehicle type, the other for all vehicle types at once. Rename the latter to help with function resolution for the introduction of variants.
|
|
Rename the zero-parameter NetworkValidateClientName to NetworkValidateOurClientName to make it clearer it is performed on our client name, and to make it a non-overloaded function to aid with the variant being added a few commits later
|
|
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.
|
|
crashes (#9400)
|
|
swedish: 1 change by joeax910
dutch: 9 changes by Afoklala
|
|
|
|
|
|
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.
|
|
english (us): 9 changes by 2TallTyler
|
|
swedish: 1 change by kustridaren
korean: 1 change by telk5093
|
|
|
|
swedish: 12 changes by joeax910
|
|
Resolved by changing calculation to determine the offset based on centring the cargo lines in the available space.
|
|
|
|
When the game-loop is very slow, it was easily possible to start
the loop with _shift_pressed being false, but end with
_shift_pressed being true. This doesn't hurt the game as such,
but for the user this can be very weird: I pressed "Buy Vehicle",
pressed shift a bit later, and I still get a cost indication.
|
|
Creating a thread was not thread-safe. The irony.
The video-driver has a function GameLoopPause() which first checks
if the thread is the game-thread or not. For this it needs access
to this->game_thread. This variable is set in StartNewThread().
However, due to timing, it is well possible GameLoopPause() is
called from the thread well before this->game_thread is assigned.
And so we have a race-condition!
Simply solve this by preventing a thread to start till we are
done with our bookkeeping.
|
|
_exit_game is read by the draw-thread to know when to exit, but
most of the time written by the game-thread.
|
|
|
|
|
|
|
|
|
|
|
|
includes base_station_base.h
|
|
spanish: 3 changes by MontyMontana
hindi: 28 changes by ritwikraghav14
|
|
This makes it easier to spot chunks that have a save_proc that
is a nullptr, but also prevents confusion, where it looks like
the CH_ type of a chunk has influence on how it is being read.
It is not, it is only used for saving.
|
|
Basically it is very similar to Vehicles, where there first is
a type field, followed by data of that type. So this commit makes
it looks like how Vehicles solved that.
This removes a lot of custom "keeping track of length" stuff.
|
|
This adds two byte extra to those chunks, and might feel a bit
silly at first. But in later changes we will prefix CH_ARRAY with
a table header, and then this change shines.
Without this, we could still add headers to these chunks, but any
external reader wouldn't know if the CH_RIFF has them or not. This
way is much more practical, as they are now more like any other
chunk.
|
|
std::vector<bool> is not possible, as .. that is a nice special
case in C++.
This new type will be used in next commit.
|
|
This means that during loading we can validate that what is saved
is also that what is expected. Additionally, this makes all list
types similar to how they are stored on disk:
First a gamma to indicate length, followed by the data.
The size still depends on the type.
|
|
In the end, the code was already doing the right thing, but a few
functions deep, and not really obvious. When validating what objects
can handle SLE_VAR_NULL, it is nicer to just have this obvious.
|
|
Using SL_ARR for this gives us a bit of trouble later on, where we
add a length-field to SL_ARR. This of course is not the intention
of SLE_CONDNULL. So better seperate it.
|
|
The current SaveLoad is a bit inconsistent how long a length field
is. Sometimes it is a 32bit, sometimes a gamma. Make it consistent
across the board by making them all gammas.
|
|
This helps external tooling to understand if a SL_STRUCT should
be skipped when reading. Basically, this transforms an SL_STRUCT
into a SL_STRUCTLIST with either 0 or 1 length.
|
|
This wasn't consistently done, and often variables were used that
were read by an earlier blob. By moving it next to the struct
itself, the code becomes a bit more self-contained and easier to
read.
Additionally, this allows for external tooling to know how many
structs to expect, instead of having to know where to find the
length-field or a hard-coded value that can change at any moment.
|
|
|
|
|
|
file that is downloading
|
|
|
|
|
|
|
|
C-string
|
|
C-string
|
|
|
|
|
|
underflow its buffer
Tagged releases are not affected
|
