Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
Tags
(+1)

I knew superficially the concept of V-sync, but I didn't know that it only worked with fractions (/2). It makes sense when you think about the concept, which makes me understand the benefit and complexity of Free/G-Sync.

In the medium term, the way this game behaves on the Web won't matter so much, since the final version will have to compile an executable to be able to put it on Steam.

However, if I manage to get a publisher for the consoles, a port of the game would probably be done with a Unity browser running the HTML version of the game.

Anyway, maybe the V-sync is still in the executable. Would working with max frame 0 (unlimited) be a bad practice?

The monitor you used to test the game here at itch, is it 60hz?

(+1)
  • "The monitor you used to test the game here at itch, is it 60hz?"

Yes, my monitor is 60hz. As far as I am able to tell, 60hz is the general industry standard for computer monitors. While many high-end gaming hobbyists have a fondness for the fidelity of 75hz, 120hz, and 144hz monitors, the vast majority of software users and game players use monitors or TVs with a refresh rate of 60hz, which has been the NTSC industry standard for decades.

For context: the 60hz standard existed before video games or home computers; it was originally the American standard for AC (alternating current) electric grid frequency. CRT monitors used this as their refresh rate because it was easy to synchronize.

  • "Anyway, maybe the V-sync is still in the executable. Would working with max frame 0 (unlimited) be a bad practice?"

If the game's coding is going to be mostly or entirely Frame-based, it is probably a bad practice to export with an unlimited max frame rate. If the game's coding is going to be mostly or entirely Time-based, it will matter a lot less.

With Frame-based coding, non-standard refresh rate users are always going to experience problems until they set their monitors to 60hz, but I personally think limiting the frame rate is the correct course of action in this scenario. If the frame rate is unlimited, this can result in insanely high speeds (a game designed for 60fps running at 144fps, for example). If the frame rate is limited, this will result in slowdown, with one exception: 120hz monitors will experience a perfect 60fps. While this is probably a matter of preference, I think a bit of slowdown is preferable to a theoretically large speed-up.

There are no great solutions to this problem. I think a lot of this comes from mismanaged hype on the part of manufacturers of high-end computer monitors. Additionally, this is mostly a result of GDevelop's "Web-First" design philosophy, and while I would personally like it if there was native support for disabling VSync in desktop distributions, I do not currently expect them to devote resources to that, especially while they're still developing the experimental 3D engine.

(+1)

I did see somewhere that the 60hz limitation was because of NTSC and powerline frequency (hence why I made that bad multimeter joke earlier). I personally like higher frequencies, but it's not my main concern.

I'll decide exactly what I'm going to do, but I'm going to avoid frame-based programming, to minimize these complications. However, I will continue with tests at 60fps to be closer to the experience most players have.

I'm going to have to come back to the topic of performance at some point, to avoid what happened in your experiment happening, the box method is something I'll be resorting to for sure.

Thanks again for this great conversation, it was a good learning experience! If I manage to finish this project as I want, your name will be in the thanks in the credits and I will give you a game key :)

If at some point you are launching a commercial game, talk to me too, depending on the situation, I can help a little with the promotion.

(+1)

Thank you for your time. This was an insightful conversation.