Configured for a max line length of 120 characters.
psf/black is very opinionated and purposely doesn't leave much room for
configuration. The output is mostly OK so that should be fine for us,
but some things worth noting:
- Manually wrapped strings will be reflowed, so by using a line length
of 120 for the sake of preserving readability for our long command
calls, it also means that some manually wrapped strings are back on
the same line and should be manually merged again.
- Code generators using string concatenation extensively look awful,
since black puts each operand on a single line. We need to refactor
these generators to use more pythonic string formatting, for which
many options are available (`%`, `format` or f-strings).
- CI checks and a pre-commit hook will be added to ensure that future
buildsystem changes are well-formatted.
For us, it practically only changes the fact that `A<A<int>>` is now
used instead of the C++03 compatible `A<A<int> >`.
Note: clang-format 10+ changed the `Standard` arguments to fully
specified `c++11`, `c++14`, etc. versions, but we can't use `c++17`
now if we want to preserve compatibility with clang-format 8 and 9.
`Cpp11` is still supported as deprecated alias for `Latest`.
EngineDebugger is the new interface to access the debugger.
It tries to be as agnostic as possible on the data that various
subsystems can expose.
It allows 2 types of interactions:
- Profilers:
A subsystem can register a profiler, assigning it a unique name.
That name can be used to activate the profiler or add data to it.
The registered profiler can be composed of up to 3 functions:
- Toggle: called when the profiler is activated/deactivated.
- Add: called whenever data is added to the debugger
(via `EngineDebugger::profiler_add_frame_data`)
- Tick: called every frame (during idle), receives frame times.
- Captures: (Only relevant in remote debugger for now)
A subsystem can register a capture, assigning it a unique name.
When receiving a message, the remote debugger will check if it starts
with `[prefix]:` and call the associated capture with name `prefix`.
Port MultiplayerAPI, Servers, Scripts, Visual, Performance to the new
profiler system.
Port SceneDebugger and RemoteDebugger to the new capture system.
The LocalDebugger also uses the new profiler system for scripts
profiling.
Otherwise any verbose/info/warning debug message from Vulkan would
raise an error, confusing users about the severity of the message.
Cf. #36185, #36790.
- Removed platform-specific implementations.
- Now all semaphores are in-object, unless they need to be conditionally created.
- Similarly to `Mutex`, provided a dummy implementation for when `NO_THREADS` is defined.
- Similarly to `Mutex`, methods are made `const` for easy use in such contexts.
- Language bindings updated: `wait()` and `post()` are now `void`.
- Language bindings updated: `try_wait()` added.
Bonus:
- Rewritten the `#ifdef` in `mutex.h` to meet the code style.
Namely, move the drive dropdown to just the left of the path text box and don't include the former
in the latter.
This improves the UX on Windows.
In the UNIX case, since its concept of drives is (ab)used to provide shortcuts to useful paths, its
dropdown is kept at the original location.
Main:
- It's now implemented thanks to `<mutex>`. No more platform-specific implementations.
- `BinaryMutex` (non-recursive) is added, as an alternative for special cases.
- Doesn't need allocation/deallocation anymore. It can live in the stack and be part of other classes.
- Because of that, it's methods are now `const` and the inner mutex is `mutable` so it can be easily used in `const` contexts.
- A no-op implementation is provided if `NO_THREADS` is defined. No more need to add `#ifdef NO_THREADS` just for this.
- `MutexLock` now takes a reference. At this point the cases of null `Mutex`es are rare. If you ever need that, just don't use `MutexLock`.
- Thread-safe utilities are therefore simpler now.
Misc.:
- `ScopedMutexLock` is dropped and replaced by `MutexLock`, because they were pretty much the same.
- Every case of lock, do-something, unlock is replaced by `MutexLock` (complex cases where it's not straightfoward are kept as as explicit lock and unlock).
- `ShaderRD` contained an `std::mutex`, which has been replaced by `Mutex`.
- Renames PackedIntArray to PackedInt32Array.
- Renames PackedFloatArray to PackedFloat32Array.
- Adds PackedInt64Array and PackedFloat64Array.
- Renames Variant::REAL to Variant::FLOAT for consistency.
Packed arrays are for storing large amount of data and creating stuff like
meshes, buffers. textures, etc. Forcing them to be 64 is a huge waste of
memory. That said, many users requested the ability to have 64 bits packed
arrays for their games, so this is just an optional added type.
For Variant, the float datatype is always 64 bits, and exposed as `float`.
We still have `real_t` which is the datatype that can change from 32 to 64
bits depending on a compile flag (not entirely working right now, but that's
the idea). It affects math related datatypes and code only.
Neither Variant nor PackedArray make use of real_t, which is only intended
for math precision, so the term is removed from there to keep only float.
In the vast majority of cases, this will be a false positive error
thrown by Vulkan-Loader when a Linux system has Vulkan ICDs for both
32-bit and 64-bit. The error is of the form:
```
ERROR: [Loader Message] Code 0 : /usr/lib/libvulkan_intel.so: wrong ELF class: ELFCLASS32
ERROR: [Loader Message] Code 0 : /usr/lib/libvulkan_radeon.so: wrong ELF class: ELFCLASS32
```
The loader dlopen's the 32-bit ICDs first, raises this error, and then
happily goes on to try and use the 64-bit ICDs.
Upstream report: https://github.com/KhronosGroup/Vulkan-Loader/issues/262Fixes#36185.
