fix(radar): Fix Radar pixel color format for non A8R8B8G8 surfaces

[xezon]

• Follow up for perf(radar): Reduce cost of W3DRadar::renderObjectList (by 80%), W3DRadar::buildTerrainTexture (by 25%) and W3DRadar::clearShroud #2138

This change converts ARGB Radar pixel colors into the correct format before writing them into the DirectX surface.

I have not been able to figure out how to get the game to use a non A8R8B8G8 surface on my machine, so I was not able to really confirm that this is a useful change.

But it seems like this is the correct thing to do.

The ARGB_Color_To_WW3D_Color function was mostly generated by Chad Gippi.

[greptile-apps]

Greptile Overview

Greptile Summary

This PR correctly converts ARGB radar pixel colors to the appropriate format before writing them to DirectX surfaces with non-standard pixel formats.

Key changes:

• Added new ARGB_Color_To_WW3D_Color() function to handle color format conversions for 14 different pixel formats (R8G8B8, A8R8G8B8, R5G6B5, A1R5G5B5, A4R4G4B4, R3G3B2, A8, A8R3G3B2, X4R4G4B4, L8, A8L8, A4L4, and X1R5G5B5)
• Modified W3DRadar to query surface format and convert colors before pixel writes in renderObjectList(), buildTerrainTexture(), and setShroudLevel()
• Added m_shroudSurfaceFormat member variable to cache surface format during batch shroud updates

The implementation follows correct bit manipulation patterns for each format, properly scaling color components and positioning them in the target pixel layout. While the PR author notes they couldn't test on non-A8R8G8B8 surfaces, the logic appears sound and handles the A8R8G8B8 case correctly as a pass-through.

Confidence Score: 5/5

• This PR is safe to merge with minimal risk
• The changes implement proper color format conversion with sound bit manipulation logic, maintain backward compatibility for the common A8R8G8B8 format, and follow established coding patterns in the codebase
• No files require special attention

Important Files Changed

Filename	Overview
Core/Libraries/Source/WWVegas/WW3D2/ww3dformat.cpp	Added ARGB_Color_To_WW3D_Color function to convert ARGB colors to various pixel formats
Core/GameEngineDevice/Source/W3DDevice/Common/System/W3DRadar.cpp	Updated radar rendering to convert ARGB colors to correct pixel format before writing to surface

Sequence Diagram

sequenceDiagram
    participant Radar as W3DRadar
    participant Surface as SurfaceClass
    participant Format as ARGB_Color_To_WW3D_Color
    
    Note over Radar: renderObjectList() or<br/>buildTerrainTexture() or<br/>setShroudLevel()
    
    Radar->>Surface: Get_Description(surfaceDesc)
    Surface-->>Radar: Returns surface format info
    
    Radar->>Radar: Get ARGB color
    Note over Radar: argbColor = getColor() or<br/>GameMakeColor(r, g, b, a)
    
    Radar->>Format: ARGB_Color_To_WW3D_Color(format, argbColor)
    Note over Format: Convert ARGB to<br/>format-specific pixel value
    Format-->>Radar: Returns converted pixel color
    
    Radar->>Surface: Draw_Pixel(x, y, pixelColor, bytesPerPixel, pBits, pitch)
    Note over Surface: Writes correctly<br/>formatted pixel to surface

Loading

[greptile-apps]

Additional Comments (1)

1. Core/GameEngineDevice/Source/W3DDevice/Common/System/W3DRadar.cpp, line 1431 (link)

   style: m_shroudSurfaceFormat should be reset to WW3D_FORMAT_UNKNOWN here for consistency with other cleanup

   _{Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!}

_{4 files reviewed, 1 comment}

_{Edit Code Review Agent Settings | Greptile}

[JohnsterID]

I've reviewed the implementation and verified the bit manipulation logic mathematically - the RGB565/ARGB4444 conversions are correct, and the luminance calculation properly follows ITU-R BT.601 standard (77R + 150G + 29B = 256). The function is applied consistently across all radar rendering paths (renderObjectList, buildTerrainTexture, setShroudLevel) and handles edge cases safely by returning 0 for unsupported formats. While the code path may rarely execute on modern hardware (which typically uses A8R8G8B8), this is solid defensive programming that ensures correctness for legacy systems and alternative DirectX configurations with zero performance penalty.

[Skyaero42]

Very good