[C++] Remove FPS Limit Using DirectX StepTimer

[hasanmacit 828]

This is the hidden content, please

• Sign In
• or
• Sign Up

Alternative download links →

This is the hidden content, please

• Sign In
• or
• Sign Up

 

With this system, we will get rid of the hard-coded 60 fps limit of Metin2. Please comment any recommendations and improvements. Here is an example showcase from my game:

 

Edited December 14, 2025 by hasanmacit
Better explanations

[Filachilla 66]

I just skimmed through it quickly, but this: m_isFixedTimeStep(false) -> m_isFixedTimeStep(true)

False is not suitable for games. It should be enabled, so it should be true instead..
There's a lot more, I'll get back to you later if you're interested, but this caught my attention right away.

[hasanmacit 828]

8 hours ago, Filachilla said:

I just skimmed through it quickly, but this: m_isFixedTimeStep(false) -> m_isFixedTimeStep(true)

False is not suitable for games. It should be enabled, so it should be true instead..
There's a lot more, I'll get back to you later if you're interested, but this caught my attention right away.

I'll check it. Thanks for your comment. Let me know if you see anything else.

[juunze59 0]

+

 

[Anielle Noir 137]

I have to point this out: spawn around 100 active players around your character and then test it again. You will quickly see the FPS dropping to 20 or even lower because of skill effects, animations, particles, and everything else being processed around those players.

Simply uncapping the FPS is not enough. If you want this to work properly, you also need to rewrite or adapt everything that is frame-dependent: skill effects, .ani images, animations, particles, affects, packet processing, and basically anything whose timing or execution was originally tied to the frame rate.

I know you already implemented real-time FPS handling, but the original client has a lot of other logic indirectly tied to frame processing. Testing alone on an empty map will not expose most of these problems.

In my case, with over 600 players in Map1, I had to change a lot of the underlying logic for skills, affects, animations, effects, .ani images, packets, and other frame-rendered/frame-processed systems. Cached effects can start generating or processing significantly more work, packet processing becomes much heavier, and sometimes the client can even enter a "Not Responding" state because too much work is being processed during a single frame, especially considering how much of the game still runs on a single core.

There is a lot more rewriting involved than simply removing the FPS cap. I honestly don't understand why so much of the original logic was designed around frame-dependent behavior in the first place. I've already spent about a week rewriting parts of it and I still haven't completely finished.

There is also another issue with skills and particle effects. Once you unlock the game from the original FPS behavior, some particles can cover a larger area while having a shorter visible lifetime. Their movement, lifetime, emission, and other timing-related behavior need to be converted from frame-based calculations to proper time-based calculations while still preserving the exact appearance they had at the original 60 FPS.

A good way to test this is to implement a 60 FPS / 120 FPS toggle using the same rendering pipeline. Switch between them repeatedly and compare everything around the character. The goal should be for the game logic, animations, particles, skills, effects, and networking behavior to remain practically identical regardless of whether the client is running at 60 or 120 FPS.

Also run debug builds at both 60 FPS and 120 FPS for around 10 minutes in a populated area. You will start noticing how different the original frame-based logic behaves once the FPS is unlocked.

If you only uncap the FPS and test it alone on an empty map, many of these issues remain invisible until actual players start reporting them.