Max FPS - Is it possible?

So what other reasons are there for a fixed framerate? Perhaps there are some, but I don't see "achieving perfect smoothness" as one of them.

Collision checking changes considerably at a rate higher than 60fps. This has already made me face situations where the character makes a "higher" jump in a very specific situation, which depended on the collision check with an object.

Despite that, at the moment I'm experiencing big problems in the physics behavior where the maximum FPS limit would be of great help. The framerate independent mode changes the strength of the object according to the processing, while the fixed mode, despite its equal path, changes its speed. Object speed can get very fast at high framerates.

For me it is also the physics. While it is mostly fine, in more complicated scenarios (multiple joints, constant forces like wind) it is hard to ensure that everything works (especially if the contraptions are more complicated). Often, it can be ensured that the target devices are able to do 60fps, but fixed mode is still not an option, because 90hz/120hz devices exist. In these cases it would be awesome to ensure that the maximum is 60fps.

It is understandable that this is a technical limitation in browsers at the moment.

The only final curiosity I have, is, if GDevelop and I guess Phaser can have max FPS, then is there something underlying that disallows C3 to have the same feature?

Would it be correct to say that these products achieve a max FPS cap in a "hacky" way, rather than a more stable way due to browsers not having this?

I wonder if there are ANY cons to having a max FPS cap implementation similar to GDevelop or Phaser.

Beyond this, I think there's not much else to discuss about this topic until browsers allow this.

Browser makers are emphatic that game-like content should be v-synced (i.e. scheduled with requestAnimationFrame). They are clear that normal JavaScript timers are not suitable for scheduling rendering and preferably shouldn't be used for that. So on this basis alone I think using JavaScript timers counts as hacky.

It looks like Chrome 107 just shipped 8ms aligned timers, which could have broken existing uses of fixed FPS. It would be interesting to know if Gdevelop/Phaser still work with that implemented.

Further if you can only rely on JS timers running every 8ms, then you can only achieve a regular 62.5 FPS, which doesn't match common display refresh rates. So I'm not sure how this could be implemented without causing some degree of jank. And then browser makers may well further tighten timer restrictions in future breaking any content trying to use timers for rendering, which they are reserving the right to by saying rendering content shouldn't be done on timers. So it seems like maintenance could be difficult too.

I don't think a fixed framerate is a magic bullet that will solve everyone's cases, although it might throw in an extra tool to the toolbox if you want to make a tradeoff like accepting janky display for a more predictable physics simulation. But even a fixed FPS isn't guaranteed - if the system can't keep up with the performance, then the FPS will drop anyway. So I still generally think the best approach is to put effort in to figuring out any problems that happen with v-sync and trying to fix it so v-sync works in more cases.

Thank you for the detailed explanation, very informative.