Matching makepanda, this avoids symbol conflicts and may have optimization benefits.
This is a temporary hack until CMake 3.24 is released, which offers a cleaner way of doing this.
We are already using target_link_options, and while it's possible to keep supporting older versions, it doesn't sound worth it. I can revert this out if someone gives me a really good reason to.
Fixes#1276
Also let's consistently use the term "assets" for all the application data (and not the gaming-specific term "game files") and use the term "data" for package data only
7-zip archives will only be created if 7-zip is available during the build phase. When 7-zip is unavailable, ZIP archives will be created as a fallback.
Benchmarks:
- Default ZIP compression: ~23.5 seconds, 162 MB
- 7-zip compression: ~7.5 seconds, 108 MB
- 7-zip compression, --lzma set: ~44 seconds, 88 MB
- 7-zip compression, solid archive: ~5 minutes, 83 MB (not implemented)
Closes#1261
The previous system was causing a lot of lock contention when transforms are modified in the Cull thread.
The new implementation doesn't use a linked list or lock at all, but a simple atomically incrementing integer that indicates that the prev transforms have changed. set_transform() reads this and backs up the prev transform the first time a transform is modified after reset_all_prev_transforms() is called.
Use Sleep(0) instead. Sleep(0) is not guaranteed to yield, which is a problem, but Sleep(1) can easily take up to 16 ms, which is really unacceptable except in very low-priority thread. But really, you shouldn't be relying on force_yield() for anything except with the SIMPLE_THREADS model.
There is also SwitchToThread(), but in fact it is even weaker than Sleep(0).
Adds patomic_signed_lock_free, patomic_unsigned_lock_free, and patomic_flag with wait/notify methods modelled after C++20. Implemented using futexes, falling back to a mutex+condition variable hash table if not supported. (Currently the hash table has a fixed size of 64, which we could increase if necessary, but we really shouldn't even have a fraction of that number of simultaneously sleeping threads...)
Other atomic types are unaffected at the moment, in part because futexes are really restricted to 32-bit ints on Linux anyway
