Done with the following script:
```ruby
Dir["Source/**/*.{h,c,cc,cpp,hpp}"].each do |path|
v = File.read(path)
next if !v.include?("uint32_t") || v.include?("cstdint")
lines = v.lines
line_num = if lines[2].start_with?(" *")
lines.index { |l| l.start_with?(" */") } + 3
else
3
end
lines.insert(line_num, "#include <cstdint>\n")
File.write(path, lines.join(""))
end
```
then fixed-up manually
explode() and implode() both have comments saying they expect the buffers to be zero-init, however new[] default initialises arrays which for char[] leaves them in an implementation defined state. On MSVC the memory is unitialised. To be safe use std::make_unique<T[]>(size_t) as this value-initialises each element of the array.
Changes how dependency options are handled and moves them out of
`CMakeLists.txt`.
Major changes:
1. The static default now takes `TARGET_SUPPORTS_SHARED_LIBS` into account
2. The `DIST` setting no longer affects the static default.
3. The static option is now visible for system dependencies as well.
(it was previously hidden by `cmake_dependent_option`).
4. The auto-detection mechanism for `libfmt` and `SDL_image` only
applies if the setting has not been set.
5. SDL2 on Android is now also linked statically,
resulting in a 1.1 MiB smaller APK.
When using non-system dependencies, the default should always be static,
as there are 2 main use cases for these:
1. Dependencies that we must currently vendor because our forks have
significant changes that are not yet merged/released upstream.
2. Platforms that have no system packages, such as Android and iOS.
In both cases, static linking is the most appropriate default.
`std::make_unique<T[]>(size)` always zero-initalizes the array.
C++20 has `std::make_unique_for_overwrite` to avoid that, while
older C++ versions can use the approach applied here.
- Add file documentation to about 1/4 of the files in Source
- Copy over a lot of the documentation from the sanctuary/notes repo
- Standardise all the existing documentation
- Create a configuration for Doxygen
- Add more documentation (engine.cpp is now fully documented)
Now diablo.h is treated in the same way as all other header files of
Source, as it only contains the declarations of global variables and
functions of diablo.cpp.
Besides consistency, this also enables mods to include diablo.h just
like any other header file without having to include every header file
(and without having to include C++ specific aspects of the now all.h).
Anders Jenbo
Gleb Mazovetskiy
staphen
ephphatha
Vladimir Olteanu
jmechnich
Kalebe Alves
pionere
Samuel-DEVULDER
Xadhoom