[bnunu]

Summary

Starting a system link game on Blood Gulch in the Windows build (a default build, with assertions) stops on colour range asserts:

• bitmap_utilities.c (0x95D): rgb_colors_interpolate's result, a structure decal's random tint;
• rasterizer_xbox_transparent_geometry.c (lines 1256-1258): a transparent shader stage's animated constant colour.

Both blend two valid colours by a factor in [0, 1]. The native builds' x87 code (-mfpmath=387, since c1fa519) can carry such values, and periodic_function_evaluate's 255*(1.0f/255.0f), at more than single precision, a hair past 1.0. Under #ifdef HALO_LINUX the blends are now pinned to [0, 1] before the asserts, and periodic functions return values in [0, 1].

The same asserts also stopped campaign maps with otherwise unmodified sources. That was seen at c1fa519; the files and compiler flags involved haven't changed since. Release builds (--release) skip assertions, so they don't stop, but they draw with the same out-of-range values.

port/linux/README.md lists the three files with the other HALO_LINUX-only edits.

Byte matching

Everything is under #ifdef HALO_LINUX. All 621 MSVC objects compare identical to main's, section by section: code, data, relocations and symbols.

Testing

• Windows build: a system link game on Blood Gulch starts and plays past the point where it stopped before.

🤖 Generated with Claude Code

[bnunu]

Closing: this worked around colour values that the x87 maths pushed a hair past 1.0. 13d1ae2 (Re-enable SIMD on Windows) put Windows back on SSE single-precision maths, and on the current main a 128-machine Blood Gulch game (host, a real client and 126 stand-ins) runs without these asserts firing. The system link work continues in #2, which no longer includes this commit.