- Rename LoadHotkeysLegacyFormatPreservesValidScrollAndFirstCastConsumesIt to LoadHotkeysLegacyFormatPreservesValidScrollSelection to better reflect actual test behavior
- Remove pfile_read_player_from_save_preserves_valid_spell_selections test as it's covered by other tests and is nice-to-have rather than critical
- Keep core logic tests: IsPlayerSpellSelectionValidChecksSpellSources, IsPlayerSpellSelectionValidRejectsInvalidSelections
- Keep important regression/integration tests: pfile_read_player_from_save_clears_invalid_spell_selections, LoadHotkeysLegacyFormatSanitizesInvalidSelections, DiabloRewritePersistsSanitizedSpellSelectionsFromHellfireSave
Treat only the exact legacy hotkeys blob size as the old format and validate the new-format header and payload before reading them. Keep the legacy scroll regression test aligned with actual scroll availability so the first cast path is verified after load.
Recognize legacy hotkeys blobs by their exact payload size so the loader does not misinterpret them as the newer header-based format. Update the legacy scroll regression test to validate selection preservation against engine-backed scroll availability without depending on UI redraw side effects.
Add a regression test that loads a valid scroll selection from legacy hotkeys data and verifies the first cast path still works with normalized spellFrom state by consuming the scroll.
Also replace legacy hotkeys test helper casts from int8_t to int32_t for clearer and safer intent when serializing SpellID values.
Introduce SyncPlayerSpellStateFromSelections and call it in hotkey load paths so queued/executed spell metadata and spellFrom are reset consistently after sanitization.
This centralizes post-load spell-state normalization, removes duplicated per-call-site resync code, and adds writehero regression tests for missing hotkeys data and legacy 4-slot hotkeys format handling.
Expose ValidatePlayer directly instead of routing load-time validation through a one-off wrapper.
Add a persisted-state regression test that rewrites a Hellfire-origin save under Diablo and verifies invalid spell selections stay cleared after saving and reloading hotkeys.
Turns out, `add_custom_target`'s `DEPENDS` argument can only
refer to outputs of custom commands in the same directory (i.e. the same
CMakeLists.txt scope).
Interestingly, this worked with all generators except parallel
make, so perhaps there some ongoing work in CMake to allow
cross-directory `DEPENDS`.
Works around this limitation by moving tests to the same scope
(`CMakeLists.txt` file) as assets.
Tricks the compiler into skipping expensive
`uninit var analysis` (`-Wmaybe-uninitialized`) by using
a struct with state rather than separate variables for `best` /
`bestDiff`.
This has no performance impact.
Also optimizes lookup a bit further and moves some code that
does not need to be inlined to the cpp file.
```
Benchmark Time CPU Time Old Time New CPU Old CPU New
-----------------------------------------------------------------------------------------------------------------------------------
BM_GenerateBlendedLookupTable_pvalue 0.0002 0.0002 U Test, Repetitions: 10 vs 10
BM_GenerateBlendedLookupTable_mean +0.0237 +0.0237 2092090 2141601 2091732 2141291
BM_GenerateBlendedLookupTable_median +0.0237 +0.0237 2092104 2141662 2091669 2141319
BM_GenerateBlendedLookupTable_stddev -0.6414 -0.5834 664 238 538 224
BM_GenerateBlendedLookupTable_cv -0.6497 -0.5930 0 0 0 0
BM_BuildTree_pvalue 0.0002 0.0002 U Test, Repetitions: 10 vs 10
BM_BuildTree_mean +0.0410 +0.0410 4495 4679 4494 4678
BM_BuildTree_median +0.0403 +0.0402 4494 4675 4493 4674
BM_BuildTree_stddev +0.9515 +0.9359 7 14 7 14
BM_BuildTree_cv +0.8746 +0.8596 0 0 0 0
BM_FindNearestNeighbor_pvalue 0.0002 0.0002 U Test, Repetitions: 10 vs 10
BM_FindNearestNeighbor_mean -0.0399 -0.0398 1964257108 1885966812 1963954917 1885694336
BM_FindNearestNeighbor_median -0.0397 -0.0396 1963969748 1886074435 1963650984 1885803182
BM_FindNearestNeighbor_stddev -0.3380 -0.3443 1217360 805946 1225442 803469
BM_FindNearestNeighbor_cv -0.3105 -0.3171 0 0 0 0
OVERALL_GEOMEAN +0.0077 +0.0077 0 0 0 0
```
Also renames lua/lua.hpp to lua/lua_global.hpp.
The previous name broke version auto-detection in sol2, which involves
calling `__has_include(<lua/lua.hpp>)`.
1. There is no need to store the light table width as it is always 256.
2. Use a fixed-extent `std::span` rather than a pointer for readability.
This should optimize to the exact same code.
Adds separate benchmarks for building the tree vs lookup
BM_GenerateBlendedLookupTable 2247062 ns 2246554 ns 312
BM_BuildTree 6842 ns 6840 ns 102200
BM_FindNearestNeighbor 2535103632 ns 2534784320 ns 1 items_per_second=6.61879M/s
Gets rid of `orig_palette`, we now always have only 2 palettes:
1. `logical_palette`
This palette has color cycling / swapping applied but no global
effects such as brightness / fade-in.
2. `system_palette`
This palette is the actual palette used for rendering.
It is usually `logical_palette` with the global brightness setting
and fade-in/out applied.
Additionally, we now keep the k-d tree around and use it to
update single colors.
The colors that are color-cycled / swapped are never included
in the k-d tree, so the tree does not need updating on color
cycles/swaps.
Uses a k-d tree to quickly find the best match
for a color when generating the palette blending
lookup table.
https://en.wikipedia.org/wiki/K-d_tree
This is 3x faster than the previous naive approach:
```
Benchmark Time CPU Time Old Time New CPU Old CPU New
-----------------------------------------------------------------------------------------------------------------------------------
BM_GenerateBlendedLookupTable_pvalue 0.0002 0.0002 U Test, Repetitions: 10 vs 10
BM_GenerateBlendedLookupTable_mean -0.7153 -0.7153 18402641 5239051 18399111 5238025
BM_GenerateBlendedLookupTable_median -0.7153 -0.7153 18403261 5239042 18398841 5237497
BM_GenerateBlendedLookupTable_stddev -0.2775 +0.3858 2257 1631 1347 1867
BM_GenerateBlendedLookupTable_cv +1.5379 +3.8677 0 0 0 0
OVERALL_GEOMEAN -0.7153 -0.7153 0 0 0 0
```
The distribution is somewhat poor with just 3 levels, so this can be improved further.
For example, here is the leaf size distribution in the cathedral:
```
r0.g0.b0: 88
r0.g0.b1: 10
r0.g1.b0: 2
r0.g1.b1: 32
r1.g0.b0: 27
r1.g0.b1: 4
r1.g1.b0: 12
r1.g1.b1: 81
```