tweak(drawable): Decouple physics and fade timing from render update

[bobtista]

• Related to Enemy stealthed units/buildings reveal animation flicker or animate too quickly at higher render FPS #1719

Drawable physics and visual fades advance once per render frame, so their speed and behavior change with FPS.

This change decouples them from the render update, with two mechanisms:

Physics (spring-damper pitch/roll, wheel suspension, wobble, recoil): now calculated on logic frames only, with the rendered transform linearly interpolated between the previous and current logic frame. The spring math is a feedback system, so scaling the integration step with FPS changes the dynamics (less overshoot and wobble at high FPS). Running it at the fixed logic rate with the retail constants keeps the behavior identical to retail at 30 fps regardless of render FPS, and the interpolation keeps the motion smooth. The rendered tilt trails the simulation by one logic frame (~33 ms).

Linear fades (drawable fade in/out, decal opacity): open-loop accumulators with no feedback, so these are simply scaled by the logic/render ratio in the render update.

m_timeElapsedFade changes from UnsignedInt to Real to accumulate fractional steps; Drawable xfer version bumped to 9 for it (non-retail-compatible saves only).

Rocket-Buggy movement at 30fps
https://github.com/user-attachments/assets/c389aa0e-356e-4992-a251-f75ece0708bd

Rocket-Buggy movement at 120fps
https://github.com/user-attachments/assets/927e18dc-e532-4d5a-97be-210cd00eafea

Todo:

• Compare Rocket Buggy physics with retail at different frame rates
• Before/after video
• Replicate to Generals

[Caball009]

Can you show a video how it looks before and after?

I'd recommend replicating to Generals as the very last thing you do for any PR. It's easier for the PR creator and reviewer(s).

[xezon]

I remember I worked on this before and it was difficult to get perfectly right and then paused this. I still have the WIP branch. I would be surprised if this change fixed it with no problems at all.

For easy test, take a GLA Buggy and compare its physics with Retail at different FPS. If it is not matching, then there is work left to do.

[bobtista]

I remember I worked on this before and it was difficult to get perfectly right and then paused this. I still have the WIP branch. I would be surprised if this change fixed it with no problems at all.

For easy test, take a GLA Buggy and compare its physics with Retail at different FPS. If it is not matching, then there is work left to do.

Oh that's right, I remember watching this, there's some buggy jank addressed is in episode 0844. I was just trying to apply changes similar to your decouple stealth fade one for remaining frame based logic, hadn't started testing yet. I'll convert to draft and assume there's more to do

[bobtista]

I remember I worked on this before and it was difficult to get perfectly right and then paused this. I still have the WIP branch. I would be surprised if this change fixed it with no problems at all.

For easy test, take a GLA Buggy and compare its physics with Retail at different FPS. If it is not matching, then there is work left to do.

Can you push the latest to your WIP branch?

[xezon]

https://github.com/xezon/CnC_Generals_Zero_Hour/tree/xezon/wip-drawable-update

[bobtista]

When I increase render FPS and update physics every render, the buggy doesn't wabble or wheelie as much. At higher render FPS we're getting effectively like a higher resolution of the damped spring math, so less overshoots, less wobble, but same total force is applied. Claude says it's called the Euler integration of a damped spring.

I think it makes sense to only calculate it at logic frames, and we interpolate so it's smoother visually. Otherwise we're messing with the spring math to approximate the overshoots from before, and it's purely visual right? Anyway - I just tested, and it looks right to me.

Note the other changes in this PR don't have this overshoot feedback kind of issue, so they all should work with calculations on render frames. Eg Linear fades like opacity

I've implemented this approach and restored the Generals changes (can replicate once this is approved).

[greptile-apps]

Greptile Summary

This PR decouples drawable physics and fade timing from the render frame rate. Physics (spring-damper pitch/roll, wheel suspension) now advances only on logic frames with the rendered transform linearly interpolated between steps, while open-loop fade accumulators are scaled by the logic-to-FPS ratio so fades run at the same wall-clock speed regardless of render FPS.

• Physics interpolation (applyPhysicsXform): previous state is snapshotted before each logic-frame update; all render frames lerp between prev and current using Get_Fractional_Sync_Milliseconds() / MSEC_PER_LOGICFRAME_REAL, clamped to [0, 1].
• Fade timing (updateDrawable): m_timeElapsedFade changed from UnsignedInt to Real; incremented by getActualLogicTimeScaleOverFpsRatio() each render frame; decal opacity scaled the same way.
• Save migration: xfer version bumped to 9; the backwards-compatibility path correctly reads a UnsignedInt from old saves and casts it to Real only in XFER_LOAD mode, avoiding the truncation-on-save issue.

Confidence Score: 5/5

• Safe to merge. The interpolation and fade-scaling logic is straightforward, the save-file migration correctly guards the Real-to-UInt cast behind XFER_LOAD, and the clamp on t prevents out-of-range matrix transforms at any framerate.
• The physics interpolation is well-bounded (prev/current both initialized to zero, t clamped to [0,1]), the fade accumulator change is mechanically correct with the existing termination condition, and the xfer migration path correctly avoids truncating m_timeElapsedFade during SAVE. No logic defects or data corruption paths were identified.
• No files require special attention.

Important Files Changed

Filename	Overview
Generals/Code/GameEngine/Include/GameClient/Drawable.h	Adds four prev* interpolation fields to PhysicsXformInfo (all zero-initialized), and changes m_timeElapsedFade from UnsignedInt to Real; both changes are consistent with the .cpp implementation.
Generals/Code/GameEngine/Source/GameClient/Drawable.cpp	Implements physics interpolation (save prev state → calc new state → lerp by fractional sync time) and scales fade/decal opacity accumulators by the logic/fps ratio. Save version bumped to 9; migration path for older saves handles XFER_LOAD guard correctly, fixing the previously noted save-truncation issue.
GeneralsMD/Code/GameEngine/Include/GameClient/Drawable.h	Identical header changes to the Generals counterpart — new prev* physics fields and m_timeElapsedFade type change to Real.
GeneralsMD/Code/GameEngine/Source/GameClient/Drawable.cpp	Mirror of the Generals .cpp changes with no divergence; physics interpolation and frame-rate-scaled fading are applied identically in Zero Hour.

Sequence Diagram

sequenceDiagram
    participant RenderLoop
    participant applyPhysicsXform
    participant PhysicsXformInfo
    participant updateDrawable

    note over RenderLoop: Each render frame

    RenderLoop->>applyPhysicsXform: call per Drawable

    alt "Logic frame (Get_Sync_Frame_Time() != 0)"
        applyPhysicsXform->>PhysicsXformInfo: save current → prev (pitch/roll/yaw/Z)
        applyPhysicsXform->>PhysicsXformInfo: calcPhysicsXform() → update current
    end

    applyPhysicsXform->>applyPhysicsXform: "t = Get_Fractional_Sync_Milliseconds() / MSEC_PER_LOGICFRAME_REAL"
    applyPhysicsXform->>applyPhysicsXform: "interp = lerp(prev, current, t)"
    applyPhysicsXform->>RenderLoop: apply interpPitch/Roll/Yaw/Z to matrix

    RenderLoop->>updateDrawable: call per Drawable
    updateDrawable->>updateDrawable: "fadeTimeScale = getActualLogicTimeScaleOverFpsRatio()"
    updateDrawable->>updateDrawable: "m_timeElapsedFade += fadeTimeScale"
    updateDrawable->>updateDrawable: "m_decalOpacity += m_decalOpacityFadeRate * scale"

Loading

_{Reviews (3): Last reviewed commit: "bugfix(drawable): Replicate fade save fi..." | Re-trigger Greptile}

[bobtista]

@xezon are you ok with copying the zero hour changes to Generals here? Greptile is right that they used different approaches, and I don't see the benefit in keeping or trying to tweak the Generals' one vs using ZH's interpolation

[bobtista]

Greptile Summary

This PR decouples drawable physics and visual fade calculations from the render update so they advance at a consistent rate regardless of frame rate. The two game versions take meaningfully different approaches: Generals multiplies each physics delta by a timeScale ratio at the call site, while Zero Hour (GeneralsMD) runs physics exclusively on logic ticks and interpolates the rendered transform between frames using saved previous state.

• Generals (Drawable.cpp): Spring-damper rates, position integration, overlap Z, bounce/wobble/recoil kicks, wheel suspension, and fade timers are all multiplied by TheFramePacer->getActualLogicTimeScaleOverFpsRatio(). Type fields m_timeElapsedFade, m_framesAirborneCounter, and m_framesAirborne are promoted from integer to Real; xfer version bumped to 7 with backward-compatible load path.
• Zero Hour (Drawable.cpp): applyPhysicsXform saves previous pitch/roll/yaw/Z before each logic tick, then linearly interpolates to the fractional sync time for rendering. Xfer version bumped to 9 with corresponding backward-compatible load path. Wheel and fade paths also receive timeScale scaling within the logic-tick call.

Confidence Score: 3/5

The Generals physics path has a correctness problem in pitchRate damping that produces wrong behavior at low framerates; the Zero Hour path is significantly cleaner and unaffected.

In calcPhysicsXformTreads and calcPhysicsXformWheels (Generals only), the damping formula 1.0f - 0.5f * timeScale turns negative at timeScale greater than 2.0 (~15 fps equivalent), flipping pitchRate sign rather than attenuating it. This causes a brief but visible chassis kick in the wrong direction at low frame rates. The Zero Hour implementation avoids this via the interpolation approach. The xfer versioning and backward-compat load paths look correct in both codebases.

Generals/Code/GameEngine/Source/GameClient/Drawable.cpp — the pitchDamp formula in calcPhysicsXformTreads (line ~1665) and calcPhysicsXformWheels (line ~1908).

Important Files Changed

Filename Overview
Generals/Code/GameEngine/Source/GameClient/Drawable.cpp Physics decoupling via per-site timeScale multiplication; contains the pitchDamp linear approximation bug that can flip pitchRate sign at ~15 fps or below, plus multiple redundant timeScale queries per function.
GeneralsMD/Code/GameEngine/Source/GameClient/Drawable.cpp Uses a more robust physics-on-logic-tick + render-interpolation approach; minor style nit with compressionFactor2 naming; xfer versioning bump to 9 with correct backward-compatibility handling.
Generals/Code/GameEngine/Include/GameClient/Drawable.h Type changes for m_framesAirborneCounter, m_framesAirborne (Int to Real) and m_timeElapsedFade (UnsignedInt to Real) to support fractional frame accumulation.
GeneralsMD/Code/GameEngine/Include/GameClient/Drawable.h Same type changes as Generals header, plus new m_prev* fields (prevTotalPitch/Roll/Yaw/Z) added to PhysicsXformInfo to support the interpolation approach, zero-initialized in constructor.

Flowchart

mermaid %%{init: {'theme': 'neutral'}}%% flowchart TD A[Render Frame] --> B{WW3D Sync Frame?} subgraph Generals["Generals - scale-at-site approach"] B -->|Yes - logic tick| C[calcPhysicsXform with timeScale applied to every delta] B -->|No - extra render frame| D[applyPhysicsXform uses last calculated values as-is] C --> D end subgraph ZeroHour["Zero Hour - save/interpolate approach"] B -->|Yes - logic tick| E[Save prevTotalPitch/Roll/Yaw/Z then calcPhysicsXform at fixed 30 fps rate] B -->|No - extra render frame| F[Interpolate between prev and current state using fractionalMs / LOGIC_FRAME_MS] E --> F end D --> G[Apply transform to matrix] F --> G Loading %%{init: {'theme': 'neutral'}}%% flowchart TD A[Render Frame] --> B{WW3D Sync Frame?} subgraph Generals["Generals - scale-at-site approach"] B -->|Yes - logic tick| C[calcPhysicsXform with timeScale applied to every delta] B -->|No - extra render frame| D[applyPhysicsXform uses last calculated values as-is] C --> D end subgraph ZeroHour["Zero Hour - save/interpolate approach"] B -->|Yes - logic tick| E[Save prevTotalPitch/Roll/Yaw/Z then calcPhysicsXform at fixed 30 fps rate] B -->|No - extra render frame| F[Interpolate between prev and current state using fractionalMs / LOGIC_FRAME_MS] E --> F end D --> G[Apply transform to matrix] F --> G mermaid %%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%% flowchart TD A[Render Frame] --> B{WW3D Sync Frame?} subgraph Generals["Generals - scale-at-site approach"] B -->|Yes - logic tick| C[calcPhysicsXform with timeScale applied to every delta] B -->|No - extra render frame| D[applyPhysicsXform uses last calculated values as-is] C --> D end subgraph ZeroHour["Zero Hour - save/interpolate approach"] B -->|Yes - logic tick| E[Save prevTotalPitch/Roll/Yaw/Z then calcPhysicsXform at fixed 30 fps rate] B -->|No - extra render frame| F[Interpolate between prev and current state using fractionalMs / LOGIC_FRAME_MS] E --> F end D --> G[Apply transform to matrix] F --> G Loading %%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%% flowchart TD A[Render Frame] --> B{WW3D Sync Frame?} subgraph Generals["Generals - scale-at-site approach"] B -->|Yes - logic tick| C[calcPhysicsXform with timeScale applied to every delta] B -->|No - extra render frame| D[applyPhysicsXform uses last calculated values as-is] C --> D end subgraph ZeroHour["Zero Hour - save/interpolate approach"] B -->|Yes - logic tick| E[Save prevTotalPitch/Roll/Yaw/Z then calcPhysicsXform at fixed 30 fps rate] B -->|No - extra render frame| F[Interpolate between prev and current state using fractionalMs / LOGIC_FRAME_MS] E --> F end D --> G[Apply transform to matrix] F --> G
Prompt To Fix All With AI

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

---

### Issue 1 of 3
Generals/Code/GameEngine/Source/GameClient/Drawable.cpp:1663-1667
**Linear pitchDamp approximation goes negative at low framerates**

`pitchDamp = 1.0f - 0.5f * timeScale` produces a negative value whenever `timeScale > 2.0f` (i.e., roughly below ~15 fps). When that happens and `m_pitchRate > 0.0f`, the multiplication flips the sign of `pitchRate` instead of damping it — the wheel chassis momentarily kicks in the wrong direction. The correct frame-rate-independent equivalent of "multiply by 0.5 every 30-fps frame" is `powf(0.5f, timeScale)`, which stays positive for all positive `timeScale` values and matches exactly at `timeScale = 1.0`. The same pattern appears again in `calcPhysicsXformWheels` around line 1908.

### Issue 2 of 3
Generals/Code/GameEngine/Source/GameClient/Drawable.cpp:1638-1758
**Redundant `getActualLogicTimeScaleOverFpsRatio()` calls within a single function**

`calcPhysicsXformTreads` queries `TheFramePacer->getActualLogicTimeScaleOverFpsRatio()` four separate times using four different local variable names (`overlapTimeScale`, `timeScale`, `hitRecoilTimeScale`, and a second `overlapTimeScale` in a different scope). All four will return the same value during a single render update. Computing it once at the top of the function and reusing it would be both more efficient and easier to follow. The same pattern repeats in `calcPhysicsXformWheels` with `bounceTimeScale`, `timeScale`, `wheelAngleTimeScale`, and `compressionTimeScale`.

### Issue 3 of 3
GeneralsMD/Code/GameEngine/Source/GameClient/Drawable.cpp:2472-2474
The `2` suffix on `compressionTimeScale2` and `compressionFactor2` is unnecessary — these variables are in their own local scope within `calcPhysicsXformMotorcycle`, so they don't conflict with the same-named variables in `calcPhysicsXformWheels`.

```suggestion
		// TheSuperHackers @tweak Wheel compression dampening is now decoupled from the render update.
		const Real compressionTimeScale = TheFramePacer->getActualLogicTimeScaleOverFpsRatio();
		const Real compressionFactor = 0.5f * compressionTimeScale;

Reviews (1): Last reviewed commit: ["Replicate to generals"](https://github.com/thesuperhackers/generalsgamecode/commit/77e6dadca3b80e82d7cc67d9916bb5cbd959084a) | [Re-trigger Greptile](https://app.greptile.com/api/retrigger?id=18986562)

Both gone - the Zero Hour side no longer queries the ratio inside the physics functions at all (they run on logic frames now), and the Generals side will be replaced with the same approach once agreed.

[bobtista]

Found three problems while re-reviewing this, all fixed now:

1. The interpolation divisor was getLogicTimeStepMilliseconds(), which is the per-render-frame logic advance (16.7ms at 60fps), not a full logic step. FractionalSyncMs accumulates by that same amount, so t reached 1.0 after a single render frame and the result was a one-frame-delayed step, not interpolation. It divides by MSEC_PER_LOGICFRAME_REAL now.
2. Wheel angle smoothing and wheel compression dampening still multiplied by the render ratio, but calcPhysicsXform* only runs on logic frames now, so they ran at half speed at 60fps. Reverted to the retail math.
3. Weapon recoil is a one-shot impulse per shot, not a per-frame accumulation, so scaling it by the render ratio just weakened recoil at high fps. Reverted.

With those fixed the spring math always steps at the logic rate with retail constants regardless of render fps, so the buggy behaves like retail at 30fps by construction — tested at [30 / 60 / uncapped]. One caveat: the rendered tilt lags the sim by one logic frame (~33ms) because it interpolates prev→current, so a frame-by-frame retail comparison will show that offset.

I still want others' thoughts on copying this approach to Generals - the timeScale-at-call-site version there changes the spring dynamics with fps (step size alters the overshoot), which is exactly what your buggy test catches.

[bobtista]

Can you show a video how it looks before and after?

I'd recommend replicating to Generals as the very last thing you do for any PR. It's easier for the PR creator and reviewer(s).

Buggy movement at 30fps
https://github.com/user-attachments/assets/c389aa0e-356e-4992-a251-f75ece0708bd

Buggy movement at 120fps
https://github.com/user-attachments/assets/927e18dc-e532-4d5a-97be-210cd00eafea

[bobtista]

Can this get some love?

[Caball009]

Would you mind including larger videos with more detail?