feat(math): Route game logic math through WWMath with 3-mode deterministic support

[Okladnoj]

Rework of #2602, incorporating review feedback:

• GameMath via FetchContent (per @stephanmeesters, @OmniBlade recommendation)
• Trig.cpp preserved, redirected to WWMath instead of deleted (per @xezon request for standalone change)
• 3 math modes: VC6 (x87 inline asm), CRT (standard library), GameMath deterministic (per @Mauller recommendation)
• USE_DETERMINISTIC_MATH unconditional for non-VC6 — missing gmath.h is now a compile error instead of silent fallback to x87/CRT
• Clean history from main

CI: win32 + vc6 ✅, replay checks ✅

Open question: Replay checks pass both with and without USE_DETERMINISTIC_MATH, even though golden replays were recorded with an x87 build. The replays may not contain MSG_LOGIC_CRC messages, meaning the check only validates absence of crashes rather than game state CRC parity. If anyone has insight on this — please share.

Testing results

Cross-platform deterministic math parity verified with SimulationMathCrc::runBenchmark — computes CRC over 10 000 iterations of sin/cos/tan/atan2/sqrt/pow across a fixed input set.

System	Compiler	Math Library	CRC	Perf (10 000 iters)
Win32 x86	MSVC (modern)	fdlibm (deterministic)	🟩 76B53840	~6 ms
macOS ARM64	Apple Clang	fdlibm (deterministic)	🟩 76B53840	~11 ms
Win32 x86	MSVC (modern)	system math (native)	🟦 E8B6385A	~3 ms
macOS ARM64	Apple Clang	system math (native)	🟦 E8B6385A	~5 ms
Win32 x86	VC6 (legacy)	x87 CRT (no fdlibm)	🟧 B7B83850	~17 ms
Win32 x86	VC6 (legacy)	system math (native)	🟥 8BB5B841	~5 ms

• 🟩 cross-platform deterministic parity achieved (Win32 modern = macOS ARM64)
• 🟦 native system math match (Win32 modern = macOS ARM64)
• 🟧 VC6 deterministic (x87 CRT, separate group — fdlibm not supported)
• 🟥 VC6 native (x87 CRT, separate group)

Key fix: -ffp-contract=off in cmake/compilers.cmake — prevents Clang from emitting FMA instructions (fmadd) that skip intermediate rounding, breaking bit-exact parity with MSVC's /fp:precise default.

[greptile-apps]

Greptile Summary

This PR routes all game-logic floating-point math through a new WWMath dispatch layer that supports three modes: VC6 x87 inline assembly (legacy), CRT fallback (non-deterministic), and GameMath fdlibm (cross-platform deterministic). The GameMath library is pulled via FetchContent, and -ffp-contract=off is added for Clang to prevent FMA contraction that would break bit-exact parity with MSVC.

• Core dispatch layer (wwmath.h): ~80 new static WWINLINE wrappers under #if USE_DETERMINISTIC_MATH / #else guards; USE_DETERMINISTIC_MATH is set via __has_include("gmath.h") in the header rather than CMake.
• Breadth of call-site migration: ~80 files across Generals/ and GeneralsMD/ replace bare CRT calls (sqrtf, fabs, atan2, etc.) with WWMath::*_Origin counterparts, and Trig.cpp is preserved but redirected to the new deterministic wrappers.
• Diagnostic tooling (SimulationMathCrc): renamed to appendSimulationMathCrc_Deterministic, a new _Native baseline function added, and a runBenchmark helper exposed for performance/CRC comparison.

Confidence Score: 5/5

The change is safe to merge; all findings are non-blocking style and benchmark-clarity issues that do not affect runtime correctness.

The core dispatch logic in wwmath.h is correct, the __has_include guard reliably activates USE_DETERMINISTIC_MATH only when gmath.h is on the include path, Trig.cpp redirection is clean, and CI passes on both win32 and VC6. The _Native benchmark precision change and the global include_directories in gamemath.cmake are worth addressing but do not affect game correctness or build reproducibility for the currently defined targets.

cmake/gamemath.cmake (global include_directories side-effects) and SimulationMathCrc.cpp (_Native baseline precision) are worth a second look, but neither blocks the PR.

Important Files Changed

Filename	Overview
Core/Libraries/Source/WWVegas/WWMath/wwmath.h	Core dispatch layer: adds ~80 deterministic wrappers via USE_DETERMINISTIC_MATH guards; double overloads narrow to float before gm_* call (acknowledged in comments); __has_include detection is correct for non-VC6 targets.
Core/GameEngine/Source/Common/Diagnostic/SimulationMathCrc.cpp	Splits CRC into _Deterministic and _Native paths; adds runBenchmark; _Native uses double-precision CRT whereas the original code used float-precision, so the benchmark native CRC baseline differs from the pre-PR calculate() output; mixed tabs/spaces in runBenchmark body.
Core/GameEngine/Include/Common/Diagnostic/SimulationMathCrc.h	Adds runBenchmark declaration and defines RUN_MATH_BENCHMARK_REPLAY400_FLAG to 0; the macro is never referenced anywhere in the PR, leaving dead code in the public header.
cmake/gamemath.cmake	Fetches GameMath at a pinned commit; uses global include_directories instead of target-scoped include; FORCE on GM_ENABLE_INTRINSICS cache variable silently overrides user settings; cache description mismatched to variable name polarity.
cmake/compilers.cmake	Adds -ffp-contract=off for Clang only; correctly scoped inside the non-MSVC branch; well-commented rationale for FMA prevention.
Core/Libraries/Include/Lib/BaseType.h	Replaces bare sqrt calls in Coord2D/Coord3D/ICoord2D/ICoord3D::length() with Sqrt() from trig.h; float call sites are lossless, but ICoord2D/ICoord3D integer coordinates can exceed float-mantissa range before narrowing (acknowledged by prior review thread).
Core/Libraries/Source/WWVegas/WWMath/CMakeLists.txt	Links core_wwmath against gamemath as a PUBLIC dependency for non-VC6 builds; correctly guarded with IS_VS6_BUILD check.
Core/GameEngine/Source/GameLogic/AI/AIPathfind.cpp	Replaces fabs/sqrt with WWMath::FAbs_Origin/Sqrt_Origin throughout pathfinding; all call sites use float-width values so narrowing in deterministic mode is lossless.
Generals/Code/GameEngine/Source/Common/System/Trig.cpp	Redirects Sin/Cos/Tan/ACos/ASin to WWMath::*_Trig wrappers and adds Sqrt(double) forwarding to WWMath::Sqrt_Origin; game title header previously flagged is now fixed.
GeneralsMD/Code/GameEngine/Source/Common/System/Trig.cpp	Identical changes to Generals/Trig.cpp; correctly retains Command & Conquer Generals Zero Hour game title per project convention.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    CS[Call site e.g. sqrtf, atan2, sinf] --> WW[WWMath wrapper]
    WW --> Q{USE_DETERMINISTIC_MATH?}
    Q -->|YES - non-VC6 + gmath.h found| GM[GameMath fdlibm\ngm_sqrtf / gm_sinf ...]
    Q -->|NO - VC6 or no gmath.h| CQ{MSVC x86?}
    CQ -->|YES| X87[x87 inline asm\nfistp / fcos / fsin]
    CQ -->|NO| CRT[CRT functions\nsqrtf / sinf / atan2f]
    GM --> DET[Deterministic CRC\nbit-exact Win32 = macOS ARM64]
    X87 --> VC6[VC6 group CRC]
    CRT --> NAT[Native CRC]
    DET --> CALC[SimulationMathCrc::calculate]
    NAT --> BENCH[SimulationMathCrc::runBenchmark]
    VC6 --> BENCH

Loading

Prompt To Fix All With AI

Fix the following 5 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 5
Core/GameEngine/Include/Common/Diagnostic/SimulationMathCrc.h:21-24
`RUN_MATH_BENCHMARK_REPLAY400_FLAG` is defined to `0` and never referenced anywhere in the PR. A permanently-zero macro in a public header is dead code — if it's a future placeholder it should at least be a comment, or be added in the PR that actually uses it.

```suggestion
class SimulationMathCrc
```

### Issue 2 of 5
Core/GameEngine/Source/Common/Diagnostic/SimulationMathCrc.cpp:75-90
**`_Native` baseline uses different precision than the original code**

The original `appendSimulationMathCrc` called `WWMath::Sin(0.7f)`, `log10f(2.3f)`, `powf(...)` — all float-precision. The new `appendSimulationMathCrc_Native` calls `::sin(0.7)`, `::log10(2.3)`, `::pow(...)` — double-precision CRT with a `(float)` cast at the end. Because double-precision intermediate results are rounded before the final `(float)` cast, the `crcNat` produced here will differ from whatever CRC the game produced before this PR. If the intent is to provide a "what did the old code produce" baseline, float-precision calls (`sinf`/`log10f`) should be used instead.

### Issue 3 of 5
Core/GameEngine/Source/Common/Diagnostic/SimulationMathCrc.cpp:111-150
**Mixed tabs and spaces in `runBenchmark`**

The outer loop and local variable declarations use 4-space indentation, but the `if (i == 0)` blocks inside both loops are indented with a tab character. This creates invisible inconsistency that editors with different tab-stop settings will render differently. The existing surrounding code uses spaces exclusively.

### Issue 4 of 5
cmake/gamemath.cmake:16
**Global `include_directories` pollutes all targets**

`include_directories(${gamemath_SOURCE_DIR}/include)` adds the GameMath include path to every target in the project, not just those that link `core_wwmath`. Any translation unit in an unrelated target can now silently `#include "gmath.h"`, and if the `__has_include` guard in `wwmath.h` resolves positively it will activate `USE_DETERMINISTIC_MATH` in contexts that are not linked against `gamemath`, turning `gm_*` calls into unresolved symbols at link time. `target_include_directories(gamemath INTERFACE ...)` — or relying on the transitive `PUBLIC` link from `core_wwmath` — would scope the include path correctly without global side-effects.

### Issue 5 of 5
cmake/gamemath.cmake:3
The `CACHE BOOL` description says "Disable intrinsics…" while the variable is named `GM_ENABLE_INTRINSICS` (enable). A developer reading `cmake-gui` or `ccmake` will see a confusing inversion. The description should match the variable's polarity.

```suggestion
set(GM_ENABLE_INTRINSICS OFF CACHE BOOL "Enable GameMath intrinsics (OFF required for cross-arch deterministic math)" FORCE)
```

_{Reviews (8): Last reviewed commit: "style(math): Fix indentation of if state..." | Re-trigger Greptile}

[Okladnoj]

Here is what replay playback looks like at the moment.

I’m testing this on a separate branch:
https://github.com/Okladnoj/GeneralsGameCode/okji/test/deterministic-math-v2

I slightly adjusted the CI there so I can run Win32 and get access to the game resources.

[Skyaero42]

You did not review the changes you made with AI. It has issues that you should fix before asking it to be reviewed.

[Okladnoj]

reviwed all changes

[xezon]

This change does too many things. It is better to first consolidate trig and wwmath and maybe other sources of math, before going into gamemath territory.

[Okladnoj]

This change does too many things. It is better to first consolidate trig and wwmath and maybe other sources of math, before going into gamemath territory.

@xezon Hey! I understand your point, but the reason I didn't fully consolidate trig and wwmath in this PR is exactly to avoid doing too many things at once.

As we saw in PR #2602, fully removing trig.h and replacing it with WWMath across the codebase touches over 120 files. Mixing a massive 120+ file architectural refactoring with a core feature addition (GameMath) made the previous PR extremely difficult to review and broke compilation for some standalone utilities, because trig.h is used outside of just game math.

That's exactly why I chose this "routing" approach for this PR. By keeping the trig.h interface intact and just routing its internal implementation to WWMath, we achieve the deterministic math goals with a much smaller and safer footprint.

Perhaps the best option would be to test this PR first, and if everything is fine — merge it. And only after that, we can focus on a second PR dedicated purely to the architectural cleanup (removing trig.h across all 120+ files)?

[Okladnoj]

Hi @xezon! I have addressed all your review feedback points and updated the PR.

CI Status:
The CI is completely green. I ran the benchmarks on both Win32 and VC6 with the latest changes, and the CRC results perfectly match our previous deterministic baselines (76B53840 for deterministic, E8B6385A for native).

To save you from hunting through all the comment threads, here is a consolidated list of the answers and solutions to your review points:

• Function_Name convention / Naming inconsistencies
  Fixed. Renamed all math wrappers to use the _Origin and _Trig convention. The _Trig suffix also cleanly resolves conflicts with legacy EA names (e.g., ACos_Trig vs Acos).
• Move #define next to #include gmath
  Fixed.
• Redundant VC6 guard
  Fixed — removed the outer #if !(defined(_MSC_VER)...) guard, kept only __has_include. VC6 doesn't support __has_include, so the block is naturally skipped.
• "origin" terminology
  "Origin" means the original EA code called bare CRT functions (sqrt, acos, sinf...). The suffix explicitly marks which exact CRT function was used originally. These are not just type variants — they are different precision math paths.
• Missing gm math variants / CeilfOrigin identical to Ceil
Ceil(float) and Floor(float) are original EA code used only in rendering (visrasterizer.cpp). Determinism isn't needed there. However, CeilfOrigin(float) is a game logic wrapper that routes to gm_ceilf. Therefore, they are not identical.
• C++ overloads instead of f suffix
  Overloads are dangerous here. GameMath only provides float functions (the double version always narrows). With overloads, the compiler silently picks the version by argument type and could inadvertently change the precision path. Explicit names protect against this.
• No @fix prefix in CMake / What is ODR? / Line breaks / iters typo
  Fixed.
• Benchmark in GameLogic::update()
  Moved the auto-benchmark out of the replay loop. It is now a simple compile-time flag. (Did not prepare an ImGui stub since ImGui does not exist in the project).
• VS6 exclusion necessary in CMake?
  Yes, it is necessary. VC6 doesn't support <stdint.h> and long long required by GameMath. Removing the exclusion will break the build.
• Sqrt(double) intentional in BaseType.h?
  Yes, intentional. Coord3D::length() is used in game logic and participates in CRC — it must be strictly deterministic.