The player can now cycle between;
-Standard: Health and Status bars display only on mouse hover.
-Show On Damage: Health shows on damaged actors, Status always shows.
-Always Show: Health and Status bars are always displayed.
- Create an overload that renders a line in one color, as this allows most existing calls to be simplified. This also allows a slight performance improvement by only normalizing the components once.
- Introduce a DrawLineStrip method. This improves performance by allowing the color components to be normalized once for the whole strip, and only needing to calculate vertices once per point rather than twice since we can reuse the last result.
- Made Array.IndexOf available via extension method.
- Made ToHashSet extension method.
- Change collections queried often via Contains into sets.
- Avoid Count() extension if Count or Length property exist.
- Made Count() > 0 checks and variations calls to Any() instead.
- Don't call ToList/ToArray if there is no benefit to materializing the sequence.
- If the sequence does benefit from materialization, follow this general pattern:
- Collection queried often via Contains use ToHashSet to speed up lookups.
- Short lived variables use ToList. This is because ToArray requires an extra copy to output the final size.
- Collections persisted into fields or for a long time use ToArray to minimize memory overhead.
The HardwarePalette will now grow its palette buffer and texture in power-of-2 increments. This avoids it having to allocate memory for a full 256x256 texture up front. In practice the default mods use 22 or 23 palettes so a 32x256 texture is used. This means both the buffer and texture save neatly on memory. Additionally, HardwarePalette.ApplyModifiers sees a nice speedup as it has to transfer a much smaller amount of memory from the buffer to the texture.
To facilitate this change, the MaxPalettes constant is no more. Instead the PaletteReference deals with the calculation of the index and this is passed into the appropriate methods.
The OrderBy overload that takes an int generating key selector is faster than the one that requires a custom comparer. We extract a function from the ScreenZPosition function that determines the Z position of a WPos with an offset, but does not account for the tileset height. For the ordering function this is fine as only the relative magnitude of the comparison keys matter, so we don't need to spend time adjusting for the tileset height, as that won't affect the sort.