Introduces a dual-backend SerializationManager: Tool mode keeps reading/writing BigFile over SQL as before, Game mode now reads a Sasquatch file instead - a flattened, mmap'd counterpart to a BigFile produced ahead of time by Sasquatch::WriteFrom or the new SasquatchPacker CLI tool. The backend is picked at compile time via a new BIGFOOT_TOOL_MODE option (mirrors the existing BIGFOOT_OPTIMIZED/BIGFOOT_NOT_OPTIMIZED pattern); SaveAsset only exists in Tool mode, since a running game never writes back to its own asset pack. Also adds SerializationManager::LoadAssets (Game-mode only): loads a batch of UUIDs by decoding them across multiple threads instead of one at a time, layered by HardReference depth so a reference target is always fully registered before anything decodes a reference to it. This required making HardReference/SoftReference resolution genuinely thread-safe (it mutates ContainerHandle ref counts and AssetLibrary's UUID index/unreferenced-set from inside Unpack()) via atomic ref counts and targeted mutexes, validated by dedicated concurrency tests exercising real thread contention. BigFile itself is faster too: prepared statements are now pooled per query text instead of recompiled on every Request (pooled rather than cached-as-one because LoadAsset recurses and a naive cache would corrupt an in-flight statement), and PRAGMA mmap_size is enabled. Benchmarked against real Asset<T> objects (AssetsForBenchmarking) through the full Pack/Unpack/HardReference pipeline: Sasquatch's raw storage layer hits ~31 GiB/s (mmap ceiling), and the new parallel LoadAssets reaches ~18 GiB/s end-to-end versus ~1.3 GiB/s for the existing sequential LoadAsset loop. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Bigfoot
A multiplatform 3D game engine
Goals
The goal is to build a multiplatform, API agnostic, 3D engine. Since this is a learning project, I don't aim to provide a viable option to build actual commercial games with it. This also means that I am providing the project as is, with no support whatsoever.
Building
Requirements
- ConanV2
- Vulkan SDK (If you target Vulkan)
- CMake
- Git
- Python3
Additional requirements for Linux
Note: you can modify the conan profile used to overcome these requirements. But I provide no support for anything else than what's listed here
Additional requirements for Windows
- MSVC
Note: you can modify the conan profile used to overcome these requirements. But I provide no support for anything else than what's listed here
Generating the dependencies for Bigfoot
Use generate_dependencies.sh or generate_dependencies.bat (depending on your platform). These scripts will download/build/install any necessary dependency, using Conan. The recipes used will come from my own conan recipe center
You will need to provide the 'force' or 'missing' parameters to these scripts. I'd recommand for a first run to use 'force' to build all dependencies, and on subsequent runs to use 'missing' to build only missing parameters
./generate_dependencies.sh force
or
./generate_dependencies.sh missing
You can customize these scripts to opt-out of some Bigfoot features
'Just' modify these lines to disable them (I promise to one day modify the script to do it from the command line)
-o bigfoot/*:build_tests=True -o bigfoot/*:tracy=True -o bigfoot/*:build_tools=True -o bigfoot/*:vulkan=True
- build_tests: Enable/Disable the tests
- tracy: Enable/Disable profiling using Tracy
- vulkan: Enable/Disable Vulkan renderer (No point disabling it, since for now only Vulkan is available in Bigfoot)
Generating Bigfoot
Use generate_bigfoot.sh or generate_bigfoot.bat (depending on your platform) to generate the build files for Bigfoot.
You will then be able to use either Visual Studio (Windows) or Ninja (Linux) to build BigFoot