tweak(fps): Decouple logic time step from render update #1451

xezon · 2025-08-12T21:45:31Z

Merge with Rebase

Relates to Replicate relevant GenTool fixes and improvements #850
Resolves Separate game logic from framerate #279

This change has several commits to fix and improve several aspects in regards to the render frame time in relation to the logic time step.

The frame limiter has been reimplemented with a high accuracy counter for more accurate FPS capping.

The following systems are now decoupled from the render update:

non-network logic update
WW3D::Sync
Scripted camera movement time step
Drawable time step
Camera shaker time step
Camera zoom and rotation time step

There are way more things that could be decoupled but for starters this appears to be good enough and usable.

To control the Logic Time Scale FPS and Render FPS the following default key mapping are added:

Key mapping	Action
CTRL + Numpad+	Increase Max Render FPS with preset values
CTRL + Numpad-	Decrease Max Render FPS with preset values
Shift + CTRL + Numpad+	Increase Logic Time Scale FPS by 5
Shift + CTRL + Numpad-	Decrease Logic Time Scale FPS by 5

Changes to the FPS are currently NOT saved to Options.ini and the game still applies its frame rate adjustements in Skirmish, Campaign and similar as usual. By default, the game behaves as originally and this feature is currently entirely opt-in with the key mappings.

TODO

Replicate in Generals

GeneralsMD/Code/GameEngine/Include/Common/MessageStream.h

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp

GeneralsMD/Code/GameEngine/Source/GameClient/InGameUI.cpp

GeneralsMD/Code/GameEngineDevice/Source/W3DDevice/GameClient/W3DDisplay.cpp

GeneralsMD/Code/GameEngine/Source/GameClient/InGameUI.cpp

Mauller · 2025-08-13T08:16:37Z

You need to update your new 'm_logicTimeScaleFPS' from the game speed option in SkirmishGameOptionsMenu.cpp the idea was to allow the game to run faster. But since the logic and FPS were tied together, they just increase the FPS cap in the original implementation.

This will also have a knock on effect that the FPS cap will also need to be increased to match the increased logic rate.

	GameWindow *sliderGameSpeed = TheWindowManager->winGetWindowFromId( parentSkirmishGameOptions, sliderGameSpeedID );
	Int maxFPS = GadgetSliderGetPosition( sliderGameSpeed );
	setInt("FPS", maxFPS);

Mauller · 2025-08-13T08:21:28Z

GeneralsMD/Code/GameEngine/Include/Common/GameEngine.h

@@ -100,9 +108,15 @@ class GameEngine : public SubsystemInterface
 	virtual ParticleSystemManager* createParticleSystemManager( void ) = 0;
 	virtual AudioManager *createAudioManager( void ) = 0;				///< Factory for Audio Manager

-	Int m_maxFPS;																									///< Maximum frames per second allowed
+	Int m_maxFPS; ///< Maximum frames per second for rendering
+	Int m_logicTimeScaleFPS; ///< Maximum frames per second for logic time scale


It would be better to rename m_maxFPS to make it more relevant to the rendering FPS.

m_maxRenderFPS for example.

For the logic one, it would be better to have the naming match the rendering.

m_maxLogicFPS etc.

I did not intent to rename m_maxFPS for this change to have a bit less diff.

m_maxLogicFPS is not the correct terminology for this. Logic FPS is what we currently refer to as enum LOGICFRAMES_PER_SECOND=30.

m_maxLogicFPS is not the correct terminology for this. Logic FPS is what we currently refer to as enum LOGICFRAMES_PER_SECOND=30.

It's the currently set max logic frame rate, LOGICFRAMES_PER_SECOND is the default maximum value. But since we can / need to be able to vary the current max logic frame rate, it makes sense to call it that for the variable.

m_logicTimeScaleFPS is conceptually not equivalent to LOGICFRAMES_PER_SECOND or m_maxLogicFPS. It effectively is a ratio that scales the logic fps.

I expect it will be possible to change LOGICFRAMES_PER_SECOND at runtime to any value above 0.

m_logicTickRate might be a better name for these instead of using logicTimeScale since time scale implies a period of time instead of a rate of action.

I do not see that logic tick rate is a better name. Logic time scale is accurate, because time scale 2 means that the game runs twice as fast. If we can avoid changing the name, then that would be good, because it will take a while to rename everything.

But this is never set to a value that acts as a multiplier, it's set to a specific Tick rate / frames per second. That is then used to cap the update of the game logic.

Which is why the naming does not look correct to me on the surface compared to what you might have in mind.

The value Int m_logicTimeScaleFPS is a multiplier in disguise. It is synonymous to Real m_logicTimeScaleRatio, just with a different unit. As we can see in the GameEngine class interface, the time scale ratio can be inferred from the fps value.

GeneralsMD/Code/GameEngine/Include/Common/GameEngine.h

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp

xezon · 2025-08-13T08:41:07Z

You need to update your new 'm_logicTimeScaleFPS' from the game speed option in SkirmishGameOptionsMenu.cpp the idea was to allow the game to run faster. But since the logic and FPS were tied together, they just increase the FPS cap in the original implementation.

No. This change does not intent to touch it yet as described in the pull request description. For now, the new limits are only accessible with the new key mappings and the game still applies its fps limits as it always did.

The reason for that is, this change is already big enough and I do not want to risk breaking anything yet. It is a more careful rollout.

Mauller · 2025-08-13T08:43:16Z

You need to update your new 'm_logicTimeScaleFPS' from the game speed option in SkirmishGameOptionsMenu.cpp the idea was to allow the game to run faster. But since the logic and FPS were tied together, they just increase the FPS cap in the original implementation.

No. This change does not intent to touch it yet as described in the pull request description. For now, the new limits are only accessible with the new key mappings and the game still applies its fps limits as it always did.

The reason for that is, this change is already big enough and I do not want to risk breaking anything yet. It is a more careful rollout.

So this is a breaking change then as it breaks the game speed adjustment in skirmish.

xezon · 2025-08-13T08:44:32Z

So this is a breaking change then as it breaks the game speed adjustment in skirmish.

Can you elaborate? When I tested, by default, it did not change behavior.

Mauller · 2025-08-13T08:47:02Z

So this is a breaking change then as it breaks the game speed adjustment in skirmish.

Can you elaborate? When I tested, by default, it did not change behavior.

The game speed adjustment is there to allow the game logic to tick faster than 30 frames, but this was tied to FPS at the same time in the original implementation. it was never about allowing a higher framerate.

If you are only increasing render FPS limit then the game logic won't be running faster for the faster game speed.

xezon · 2025-08-13T08:50:57Z

It does, because Logic Time Scale FPS is disabled by default. Unless I made a mistake or the new key mappings are pressed in game, the default game behaviour should be the exact same. I suggest to give this a test in game.

GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/CommandXlat.cpp

Mauller · 2025-08-13T08:58:18Z

It does, because Logic Time Scale FPS is disabled by default. Unless I made a mistake or the new key mappings are pressed in game, the default game behaviour should be the exact same. I suggest to give this a test in game.

Ah i see now, i thought you had the logic frame rate locking always enabled.

aliendroid1 · 2025-08-13T12:48:29Z

Are the key mappings hard coded?

xezon · 2025-08-13T13:56:28Z

The default key mappings are. They can be overriden in CommandMap.ini

WWB2-account · 2025-08-13T15:56:47Z

It would be good to investigate how this change interacts with already existing ways to change game speed and FPS. There are scripts that do very similar things as this PR.

This change has the potential to break every single script in all maps in the history of the game if we're not careful. Investigation of internal script timers, frame counters and more is probably needed to verify this doesn't break anything. Changing scripts in general should be done with utmost consideration.

Additionally, I can imagine that in some cases the game logic should not be increased beyond a specific value. Examples are cinematic intros in campaign maps (eg. ZH USA 01), or maps with many audio events like Generals' Challenge maps. In such cases the logic should have a custom cap specifically tied to that map, likely specified in the map.ini.

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp

xezon · 2025-08-14T18:05:10Z

It would be good to investigate how this change interacts with already existing ways to change game speed and FPS. There are scripts that do very similar things as this PR.

The default behavior of scripts is not changed.

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp

GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/LookAtXlat.cpp

WWB2-account · 2025-08-14T18:57:42Z

It would be good to investigate how this change interacts with already existing ways to change game speed and FPS. There are scripts that do very similar things as this PR.

The default behavior of scripts is not changed.

True, but the fact remains that some scripts might interact with render frames while others interact with logic frames. Now that they are decoupled people with different settings will get different results (and potentially get mismatches if they play COOP, AOD, or even multiplayer skirmish. That should not be. It should be checked where this could happen.

xezon · 2025-08-14T20:14:50Z

True, but the fact remains that some scripts might interact with render frames while others interact with logic frames. Now that they are decoupled people with different settings will get different results (and potentially get mismatches if they play COOP, AOD, or even multiplayer skirmish. That should not be. It should be checked where this could happen.

The Network logic update is unchanged. No mismatch.

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp

Mauller · 2025-08-15T10:10:01Z

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp

+{
+	if (TheNetwork != NULL)
+	{
+		return TheNetwork->getFrameRate();


This only works at the moment because the networking module caps the value returned by this to 30, but not for the right reasons.

Need to cleanup a lot of the networking side still but what you put should work okay for the time being.

Int minFps; Int minFpsPlayer; getMinimumFps(minFps, minFpsPlayer); DEBUG_LOG_LEVEL(DEBUG_LEVEL_NET, ("ConnectionManager::updateRunAhead - max latency = %f, min fps = %d, min fps player = %d old FPS = %d", getMaximumLatency(), minFps, minFpsPlayer, frameRate)); if ((minFps >= ((frameRate * 9) / 10)) && (minFps < frameRate)) { // if the minimum fps is within 10% of the desired framerate, then keep the current minimum fps. minFps = frameRate; } if (minFps < 5) { minFps = 5; // Absolutely do not run below 5 fps. } if (minFps > TheGlobalData->m_framesPerSecondLimit) { minFps = TheGlobalData->m_framesPerSecondLimit; // Cap to 30 FPS. }

The connection manager sets the value and the networking uses this FPS value for setting the logic rate so it's quite a mess overall.

msg->setRunAhead(newRunAhead); msg->setFrameRate(minFps); //DEBUG_LOG(("ConnectionManager::updateRunAhead - new run ahead = %d, new frame rate = %d, execution frame %d", newRunAhead, minFps, msg->getExecutionFrame())); sendLocalCommand(msg, 0xff ^ (1 << minFpsPlayer)); // Send the packet to everyone but the lowest FPS player.

…pdate (#1451)

GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/LookAtXlat.cpp

…update (#1451)

Mauller · 2025-08-17T15:13:13Z

GeneralsMD/Code/GameEngine/Source/GameClient/InGameUI.cpp

+		// TheSuperHackers @tweak The camera rotation and zoom are now decoupled from the render update.
+		const Real fpsRatio = (Real)BaseFps / TheGameEngine->getUpdateFps();
+		const Real rotateAngle = TheGlobalData->m_keyboardCameraRotateSpeed * fpsRatio;
+		const Real zoomHeight = (Real)View::ZoomHeightPerSecond * fpsRatio;


Not in this PR, but i wonder if we should make the zoom and camera rotate rates user adjustable at some point?

Probably. I also think zooming is way too slow. It moves like snail.

if it feels better, maybe we could have a followup PR to double the value like we did for the scrolling? before any user adjustable additions.

xezon added this to the Important features milestone Aug 12, 2025

xezon added Bug Something is not working right, typically is user facing Enhancement Is new feature or request Major Severity: Minor < Major < Critical < Blocker Gen Relates to Generals ZH Relates to Zero Hour Rendering Is Rendering related labels Aug 12, 2025

xezon force-pushed the xezon/decouple-logic-render branch from 2b88c43 to 1036d47 Compare August 12, 2025 21:59

xezon commented Aug 12, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Include/Common/MessageStream.h Outdated Show resolved Hide resolved

xezon commented Aug 13, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp Outdated Show resolved Hide resolved

xezon commented Aug 13, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/GameClient/InGameUI.cpp Outdated Show resolved Hide resolved

xezon commented Aug 13, 2025

View reviewed changes

GeneralsMD/Code/GameEngineDevice/Source/W3DDevice/GameClient/W3DDisplay.cpp Outdated Show resolved Hide resolved

xezon commented Aug 13, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/GameClient/InGameUI.cpp Outdated Show resolved Hide resolved

Mauller reviewed Aug 13, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Include/Common/GameEngine.h Outdated Show resolved Hide resolved

Mauller reviewed Aug 13, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp Outdated Show resolved Hide resolved

Mauller reviewed Aug 13, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/CommandXlat.cpp Outdated Show resolved Hide resolved

bugfix(fps): Fix inaccurate frame rate cap (#1451)

1d49449

xezon force-pushed the xezon/decouple-logic-render branch from 1036d47 to a9147d6 Compare August 14, 2025 17:57

Mauller reviewed Aug 14, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp Outdated Show resolved Hide resolved

Mauller reviewed Aug 14, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp Outdated Show resolved Hide resolved

xezon force-pushed the xezon/decouple-logic-render branch from a9147d6 to a0d1f04 Compare August 14, 2025 18:19

Mauller reviewed Aug 14, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp Show resolved Hide resolved

xezon force-pushed the xezon/decouple-logic-render branch 2 times, most recently from 9faaab8 to 4bb9f4e Compare August 14, 2025 18:34

Mauller reviewed Aug 14, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/LookAtXlat.cpp Outdated Show resolved Hide resolved

Mauller reviewed Aug 15, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/Common/GameEngine.cpp Show resolved Hide resolved

Mauller reviewed Aug 15, 2025

View reviewed changes

roossienb mentioned this pull request Aug 15, 2025

Create a page of all newly introduced configuration options TheSuperHackers/GeneralsWiki#68

Open

xezon added 5 commits August 15, 2025 19:06

tweak(fps): Decouple non-network logic update from render update (#1451)

461c301

tweak(fps): Decouple WW3D::Sync from render update (#1451)

37fa668

tweak(fps): Decouple scripted camera movement time step from render u…

b541cae

…pdate (#1451)

tweak(fps): Decouple drawable time step from render update (#1451)

f422b4e

bugfix(fps): Decouple camera shaker time step from render update (#1451)

579f189

xezon force-pushed the xezon/decouple-logic-render branch from 4bb9f4e to 95f1a50 Compare August 15, 2025 17:07

Mauller reviewed Aug 17, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/LookAtXlat.cpp Outdated Show resolved Hide resolved

Mauller reviewed Aug 17, 2025

View reviewed changes

GeneralsMD/Code/GameEngine/Source/GameClient/MessageStream/LookAtXlat.cpp Outdated Show resolved Hide resolved

bugfix(fps): Decouple camera zoom and rotation time step from render …

3bf9396

…update (#1451)

xezon force-pushed the xezon/decouple-logic-render branch from 95f1a50 to 3bf9396 Compare August 17, 2025 15:04

Mauller reviewed Aug 17, 2025

View reviewed changes

tweak(fps): Decouple logic time step from render update #1451

Are you sure you want to change the base?

tweak(fps): Decouple logic time step from render update #1451

Uh oh!

Conversation

xezon commented Aug 12, 2025

TODO

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Mauller commented Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xezon Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

xezon Aug 17, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

xezon commented Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Mauller commented Aug 13, 2025

Uh oh!

xezon commented Aug 13, 2025

Uh oh!

Mauller commented Aug 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

xezon commented Aug 13, 2025

Uh oh!

Uh oh!

Mauller commented Aug 13, 2025

Uh oh!

aliendroid1 commented Aug 13, 2025

Uh oh!

xezon commented Aug 13, 2025

Uh oh!

WWB2-account commented Aug 13, 2025

Uh oh!

Uh oh!

Uh oh!

xezon commented Aug 14, 2025

Uh oh!

Uh oh!

Uh oh!

WWB2-account commented Aug 14, 2025

Uh oh!

xezon commented Aug 14, 2025

Uh oh!

Uh oh!

Mauller Aug 15, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Mauller commented Aug 13, 2025 •

edited

Loading

xezon Aug 13, 2025 •

edited

Loading

xezon Aug 17, 2025 •

edited

Loading

xezon commented Aug 13, 2025 •

edited

Loading

Mauller commented Aug 13, 2025 •

edited

Loading

Mauller Aug 15, 2025 •

edited

Loading