60fps Game is choppy and looks stuttering on 120hz monitor?

What is the resolution in your game?
I noticed the same when I upgraded my monitor. I then upscaled my game to 1280x720 and that solved it

I am not completely sure, but Linky had some ideas in my older thread:

Thread

Ghosting/Flickering on low resolutions

I just got a new better monitor. This new clarity made it obvious there is significant ghosting/flickering when moving around - especially when moving diagonally.

The game runs at 480 x 270 and is scaled up. The issue is resolved if I increase the native resolution to at least 1280 x 720.
Is it possible to increase the native resolution and at the same time scale all the objects?

I don't think I can simply scale all my objects like the image below, as I don't think the tilesets from the tilemap…

willy

February 7, 2024 at 8:46 PM

It could also be that you have a different issue from me

Quote from Outcast

I always develop my game in 60fps for PC (Steam) and I have had a monitor running in 60hz for the longest time. However I recently upgraded to a 120hz monitor and when I continued development of my game I was very surprised when I booted the project up because it looks extremely unsmooth, choppy and "stuttery" when I run it on my 120hz monitor, especially when scrolling. It really feels like playing a game in very low uneven fps and is extremely unpleasant to look at.

How can I make my game look good and smooth on 120hz monitors? From what I understand 120hz monitors is becoming more and more common, and even 144 or 240hz.

If I change the fps to 120 this makes the game smooth again (though I need to adjust some values that are dependent on the fps), but the problem then is that it becomes much more performance heavy to run in 120fps vs 60fps so then it could become slow because it cant reach a stable 120fps all the time (and if going higher like 144 or 240 it would be even worse).

Is there a way to still run the Please login to see this link. in 60fps on a 120hz monitor or higher but still have the game look smooth?

Yeah, high refresh rate monitors can make 60fps feel choppy since the frame timing doesn’t line up well. You could try enabling V-Sync or adaptive sync to smooth it out, or have the game present each frame twice to match 120Hz. It’s all about finding that balance without pushing performance too hard.

Adaptive Vsync is something you do in your GPU driver settings. So it's something your users can try, but it's not something you can do on the Fusion end.

If you change the game's native fps to 120, then you can still code certain things to happen at slower intervals, to keep things performant. That's what I do. So I make vital things like my main character's movement code and camera code happen every frame (ie. 120 times per second) to keep things as precise and smooth as possible. But where it won't impact final quality, I make other events trigger every 2nd frame (ie. 60 times per sec) or even less often, like every 3rd, 4th or 10th frame.

For example, it's a waste to check every single frame whether an enemy has collided with the player, since most of the time the enemy won't even be near the player. Instead, I do a broad check every 10 frames to see whether the enemy is in the general vicinity of the player. Only if that check returns true do I start doing more frequent and precise collision checks. Similarly, many of my cosmetic elements (eg. fog, particles, background critters) are only processed every Xth frame.

Some things are processed much less frequently than that. I have some 'safety net' error checking routines to check whether, for example, an enemy has somehow gotten stuck inside some geometry. I only run checks like this every 100 or 300 frames. It would be wasteful to run them more often since they are very rare and/or purely hypothetical occurrences.

Quote from Volnaiskra

Adaptive Vsync is something you do in your GPU driver settings. So it's something your users can try, but it's not something you can do on the Fusion end.

If you change the game's native fps to 120, then you can still code certain things to happen at slower intervals, to keep things performant. That's what I do. So I make vital things like my main character's movement code and camera code happen every frame (ie. 120 times per second) to keep things as precise and smooth as possible. But where it won't impact final quality, I make other events trigger every 2nd frame (ie. 60 times per sec) or even less often, like every 3rd, 4th or 10th frame.

For example, it's a waste to check every single frame whether an enemy has collided with the player, since most of the time the enemy won't even be near the player. Instead, I do a broad check every 10 frames to see whether the enemy is in the general vicinity of the player. Only if that check returns true do I start doing more frequent and precise collision checks. Similarly, many of my cosmetic elements (eg. fog, particles, background critters) are only processed every Xth frame.

Some things are processed much less frequently than that. I have some 'safety net' error checking routines to check whether, for example, an enemy has somehow gotten stuck inside some geometry. I only run checks like this every 100 or 300 frames. It would be wasteful to run them more often since they are very rare and/or purely hypothetical occurrences.

Interesting. How do you "limit" such events to run only every X frames ? Do you use an alt. variable for that ( e.g. subtract 1 at each frame, and when the alt. value = 0 then perform the events or activate a group of events ), or is there a more elegant ( that is: built in ) way to do it ?

The trick is to use MOD:

Please login to see this picture.

To make it easier for myself, I have a little system set up for this in my VACCiNE tool, where the following altVals will be 1 at the appropriate intervals (and 0 at all other times):

Please login to see this picture.

This way I don't need to repeatedly type the MOD formula out, but just check for the altVal with a very simple condition like this:

Please login to see this picture.

Some of the larger numbers (eg. 353, 503) are purposefully prime numbers. My thinking there is that if I make something expensive happen every 500th frame, it may stack with other expensive things that are occurring elsewhere every 2nd/5th/10th/20th frames and potentially cause a microstutter as that particular frame takes significantly longer to process than its neighbours. By making that expensive thing happen every 503rd frame instead, it theoretically lowers the probability of such a microstutter.

What an interesting concept ! Thank you Volnaiskra for sharing this