bugfix(bgfx): Expand the A1R5G5B5 terrain atlas to BGRA8 off Windows

[githubawn]

WW3D_FORMAT_A1R5G5B5 maps to bgfx::TextureFormat::BGR5A1, which is not a native GLES format. Emitting it leaves bgfx to convert during upload, over-reading the source buffer, and what reaches the screen is the terrain atlas — the game's only large A1R5G5B5 surface — as coloured speckle across the ground.

Fix

Expand A1R5G5B5 to BGRA8 up front, exactly as the A4R4G4B4 path beside it already does. Three linked places all need it, which is why a partial change appears to do nothing:

1. GetBgfxTextureUploadFormat() expanded A4R4G4B4 but not A1R5G5B5
2. IsTerrainAtlasTexture() only accepted BGR5A1, so expanding the format alone would have silently cost the terrain its tile-aware mip chain and fallen back to a generic one
3. UploadTerrainAtlasMips() hardcoded BGR5A1 and uploaded raw 16-bit data

The atlas is filtered as 16-bit throughout — that is what the tile-aware mip builder works on — so every level, authored or generated, is widened just before it is handed to bgfx. CopyTextureLevel already knows how to widen A1R5G5B5, so it is asked for the upload format outright and the mip builder's 16-bit input comes from the source snapshot, avoiding a second allocation.

Platform impact

All of it sits behind !defined(_WIN32); Windows keeps the native 16-bit upload byte for byte.

Testing

Verified on the Emscripten/WebGL build: the shell map's sand and rock rendered as coloured speckle before and correctly after. Not runtime-verified on Android GLES or desktop GL, though they take the same non-Windows path.

[bobtista]

This needs to follow backend behavior rather than host OS. In the pinned bgfx, Emscripten maps BGR5A1 to GL_RGBA/GL_UNSIGNED_SHORT_5_5_5_1 and still advertises BGFX_CAPS_FORMAT_TEXTURE_2D, so a caps-only check would miss WebGL. On other renderers, the cap can correctly indicate that native BGR5A1 upload is unavailable.

Please expand on Emscripten or when native BGR5A1 2D support is absent; !defined(_WIN32) unnecessarily expands native Metal and desktop GL uploads.

Please also revise the WebGL explanation: the pinned bgfx source shows an A1R5G5B5-versus-RGBA5551 packed-layout mismatch while the upload remains 16 bpp, and I do not see evidence of a source-buffer over-read on this path.

[bobtista]

This bypasses CopyTextureLevel’s pitch normalization and unconditionally reads 2 * mipWidth bytes from every source row. A short-pitch snapshot passes the existing validation, and both this copy and the new ExpandA1R5G5B5ToBGRA8 can then read past the final row. The adjacent A4R4G4B4 expander has the same inherited weakness, but this change should not add another instance. Please either require Pitch >= 2 * width, or clamp and zero-fill consistently in both places. Clamping alone is insufficient because prev.resize() may preserve pixels from the preceding level. On the native BGR5A1 path, continuing to seed prev from mem->data preserves the previous pitch-normalized behavior.