The new algorithm is a lot less code, slightly faster, and results
in a smaller binary (-40 KiB on rg99).
The previous algorithm filled all the pixels around every solid pixel.
The new algorithm only fills pixels that will be visible.
We first collect the outline pixels into an array (which may contain a
small amount of duplicates). Then, we render the entire array in a
single loop. This turns out to be slightly faster than rendering inline,
at the cost of ~4 KiB of stack (basically free).
To collect the pixels, we go through the CLX sprite, keeping track
of the solid runs in the current row, and the filled pixels on the line
above and the line below.
To be able to quickly test the pixels above and below, we introduce a
new data structure, `StaticBitVector`. It is similar to a bitset,
except the size is determined at runtime (capacity is fixed),
and it supports quick updates of entire subspans.
We may want to migrate this to 1 file per monster but for now the
migration is as close to the hard-coded version as possible.
Sprites that are used by multiple monsters are only loaded from disk
once.
The code that the gmock macros end up generating appears to obscure the type mismatch so there's no warning (in msvc on my system anyway) no matter what types are involved, for clarity the comparison ends up being between std::pair<int, unsigned int> and testing::Pair<int, testing::AllOf<testing::Matchers<unsigned int>>>
```lua
local render = devilutionx.render
local function drawGreet ()
render.string("Hello from " .. _VERSION, 10, 40)
end
Events.OnGameDrawComplete.Add(drawGreet)
```
Also added an iterator based API, though it's not useful for this use-case. Might be nice in the future?
The field/record iterators is single-pass input iterators with shared state.
To avoid rescanning fields unnecessarily parseInt currently can only be called once, it would be possible to make these iterators bidirectional with a bit of extra state (holding onto the start pointer)
Co-authored-by: Gleb Mazovetskiy <glex.spb@gmail.com>