Hhckrman101Saves guide: no keys or firmware sentence
| Files | Last commit | Last update |
|---|---|---|
Program cache: an index of its records beside it, and the precompile's records read on several threads hookshot_programs.bin's records follow one another with nothing pointing at them, so every start read each record's 20-byte head, one after the other, across the whole file (4 to 6 GB, 22000 to 40000 records): 8 to 10 s before the first pipeline was built, on a warm start. hookshot_programs.idx now keeps those heads in file order. It is taken when its stamp is the cache's, its sizes fit in the file and the last record's head matches; records past it are read as before, and anything else is a full read with the index written again. Each record's head is checked again when it is loaded. The compute programs and the noted ones that the precompile loads (a few thousand records) are read and parsed on up to 16 threads, each with its own handle on the file, and go into the program table under shader_mu afterwards, in the same order as before. | 1 day ago | |
docs: document the built game's command-line arguments The --user switch was not documented outside the source, so players and developers looking for another save folder could not find it. Document the built game's arguments in the README, link them from the development guide, and list them in the built-in usage line. Assisted-by: DeepSeek V4.1 Flash Co-Authored-By: DeepSeek V4.1 Flash <noreply@deepseek.com> | 1 day ago | |
| 21 hours ago | ||
Saves guide: no keys or firmware sentence | 12 hours ago | |
ci: the Windows builder package and setup in CI, attached to a tag's release with the AppImage A new workflow, Windows builder, makes what a Windows player downloads, without game data: HookshotBuilder-Setup.exe (builder/setup/setup.c, with the llvm-mingw make_setup_parts.py names, SHA-256 checked and cached) and the Hookshot Builder package (dotnet publish -p:Version from the tag, as docs/versioning.md says), split by scripts/make_setup_parts.py. It also compiles the Windows Vulkan back end with the same llvm-mingw (RX_VK_ONLY, as the AppImage's): players build it on their PC, this checks that it still builds. A workflow artifact on every run. setup.c's build line gets -municode (its entry point is wWinMain). What CI cannot make comes from the latest stable release's hookshot-setup.txt (scripts/release_parts.py): the Python, emsdk, CPM and wgpu-native parts as they are (make_setup_parts.py --reuse), the play profile, and the third_party part's prebuilt files (a64emit.dll, lld-link.exe, SDL2.dll, SDL3.dll, zbic.dll) beside the tracked third_party. A fork with no release takes upstream's. On a tag, the parts builder-parts lacks are uploaded there, then the setup (HookshotBuilder.exe) and its list to the tag's release. The AppImage's release step moves to its own job with the same script (scripts/release_upload.sh): the first job to get there makes the release from the tag, the other adds its files, and a -rc tag is still a prerelease that is never latest. The AppImage's play profile comes through release_parts.py too, and never from the release being made. | 1 day ago |