bugfix(textureloader): Fix faulty texture reduction implementations

[xezon]

Merge with Rebase

• Relates to Binarystream texture is not drawing in Generals #1990

This change attempts to fix the faulty implementations related to texture reduction.

It has 3 commits:

The first commit removes some dead code, streamlines some variable names and simplifies some code related to texture reduction in the 3 texture load classes: TextureLoadTaskClass, CubeTextureLoadTaskClass, VolumeTextureLoadTaskClass

The second commit removes the texture reduction code from TextureLoadTaskClass::Begin_Uncompressed_Load because the reduction was always 0 as far as I could see and the game never reduced TGA texture size.

The third commit fixes and streamlines the texture reduction code in TextureLoadTaskClass::Begin_Compressed_Load, CubeTextureLoadTaskClass::Begin_Compressed_Load, VolumeTextureLoadTaskClass::Begin_Compressed_Load. The former logic was incoherent and nonsensical. The new logic does work in so far that the binary stream texture in Generals would render correctly with an auto reduction to the lowest mip to satisfy the original 1:8 texture aspect ratio limit. No new issues have been observed. Texture reduction from Options Menu also still works.

TODO

• Add pull ids to commit titles

[greptile-apps]

Greptile Summary

This PR refactors the texture reduction logic in textureloader.cpp by extracting shared helpers (Get_Requested_Reduction, Validate_Reduction, Apply_Reduction, Apply_Reduction_With_Depth) and applying them uniformly across all three load task classes. It removes dead uncompressed-load reduction code and fixes the previously broken hardware-limit reduction path.

• New helpers centralise reduction clamping, hardware-limit scanning, and mip-count validation, eliminating duplicated per-class code.
• Begin_Uncompressed_Load is simplified by hardcoding Reduction = 0, and Load_Compressed_Mipmap's loop is replaced with a single right-shift.
• A post-Validate_Texture_Size mutation of Width/Height before Apply_Reduction leaves Width != orig_width for hardware-oversized textures, causing incorrect mip dimensions in Load_Compressed_Mipmap.

Confidence Score: 3/5

Safe for normal textures within hardware limits; the hardware-limit reduction path in all three Begin_Compressed_Load functions is broken due to Width being clamped before Apply_Reduction sets Reduction.

For most textures in Generals (power-of-two DDS within hardware limits), Validate_Texture_Size leaves Width unchanged and the mip-loading path works correctly. When a texture exceeds hardware dimension limits, Width is clamped in-place and Load_Compressed_Mipmap computes incorrect mip surface dimensions, corrupting the DDS-to-D3D surface copy for the exact scenario this PR intends to fix.

Core/Libraries/Source/WWVegas/WW3D2/textureloader.cpp - specifically the Begin_Compressed_Load methods at lines 1493-1495, 2087-2089, and 2427-2430.

Important Files Changed

Filename	Overview
Core/Libraries/Source/WWVegas/WW3D2/textureloader.cpp	Refactors texture reduction into shared helpers applied across all three load task classes; a post-Validate Width mutation breaks the Width>>Reduction invariant used in Load_Compressed_Mipmap for hardware-oversized textures.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[Begin_Compressed_Load] --> B[Get_Texture_Information]
    B --> C[Width = orig_width]
    C --> D[Validate_Texture_Size Width - may clamp Width]
    D --> E[Apply_Reduction from orig_width sets Reduction]
    E --> F[D3D Texture at reduced_width = orig_width >> Reduction]
    F --> G[Load_Compressed_Mipmap]
    G --> H[width = Width >> Reduction]
    H --> I{Width == orig_width?}
    I -->|Yes| J[CORRECT: width = reduced_width]
    I -->|No - hardware clamped| K[WRONG: width != reduced_width]

Loading

_{Reviews (3): Last reviewed commit: "bugfix(textureloader): Fix faulty implem..." | Re-trigger Greptile}