We won't be able to make it fully self-descriptive (looking at you
MAP-chunks), but anything else can. With this framework, we can
add headers for each chunk explaining how each chunk looks like
in detail.
They also will all be tables, making it a lot easier to read in
external tooling, and opening the way to consider a database
(like SQLite) to use as savegame format.
Lastly, with the headers in the savegame, you can freely add
fields without needing a savegame version bump; older versions
of OpenTTD will simply ignore the new field. This also means
we can remove all the SLE_CONDNULL, as they are irrelevant.
The next few commits will start using this framework.
Basically, this changes "SaveLoad *" to either:
1) "SaveLoadTable" if a list of SaveLoads was meant
2) "SaveLoad &" if a single entry was meant
As added bonus, this removes SL_END / SLE_END / SLEG_END. This
also adds core/span.hpp, a "std::span"-lite.
This struct is defined in geometry_type but not used by any geometry-related
code, only for subsidy code where both parameters are cast from int to
NewsReferenceType.
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.
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.
The last use was for storing a list of memory blocks. As the way these lists are accessed is very
specific, it is easier to just write an explicit destructor instead of trying to exactly match the behaviour.
DropDownListItem are strongly managed using std::unique_ptr to ensure leak-free handling. Appropriate use
of move-semantics make intent a lot clearer than parameter comments and allows the compiler to generate
copy-free code for most situations.
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.
glx22