Game runs at a locked 60 fps

[StalkyBoi43815]

If the game could run at unlimited framerates, it would perform a lot better, look smoother and be more responsive. That's it.

[laochailan]

While the engine is efficient enough to run at much higher framerates, our logic is locked to 60fps. Some kind of locking of this type is necessary to ensure the movement of the bullets is completely deterministic and players playing on different fps get exactly the same bullet positions at a given game frame.
Changing that logic framerate would require rewriting most of the game code, so it is not really feasible for us. This also means that inputs will not become more reactive than 1/60 s.

It is theoretically possible to decouple the visual framerate from the logic framerate and fill the missing frames by interpolating bullet positions. For many bullets and all the backgrounds this would likely look fine.

There are some bullets however that move in ways that are not smooth like zigzag patterns or warping around. Naively interpolating them might look janky, but maybe there is a way to catch these cases automatically.

[StalkyBoi43815]

players playing on different fps get exactly the same bullet positions at a given game frame

This happens all the time on competitive online shooters, where it actually matters. Yet nobody blames the game engine, because everyone knows that little advantage isn't going to win you games. It's just not even an excuse. And in my opinion, the devs should have built the game with unlocked framerates from the start, but I know diddly squat about coding, so I might be wrong on some matters. All I know is that this 60 fps lock plague seems to only affect Touhou games, official or not. Literally almost every single game released in the last few years has the option to run at certain set framerates or even unlocked ones. Except for Touhou games, which have been around for decades. ZUN had so long to fix this but he hasn't because nobody seems to care, for some reason.

[laochailan]

As far as I know, even in the games you mention there are logic frames (aka ticks) at a more or less fixed tick rate. These are the discrete time intervals at which bullets are created and destroyed and collisions are calculated. In online games, the server is doing these calculations and has the final say of what happened, irrespective of the player frame rate.

Then what is done in modern games is to decouple rendering from that and have a frame rate that can fluctuate based on the speed of hardware and monitor. Ideally we would have built Taisei from the ground up to make this easy, but alas we did not, and there are also some fundamental reasons that make it more difficult in Taisei than in a first-person shooter.

The question is how do you describe bullet trajectories. In a shooter, bullets move mostly in straight lines, maybe bent by gravity or slowed by air drag. It is straight-forward to write this in terms of “laws of physics” (aka differential equations) and simulate the trajectory at pretty much arbitrary fps in a very simple way. So in the competitive shooter for example, the server sends one of its ticks over the network and your computer simulates the bullet trajectories fitting to your framerate in a smooth way.

In danmaku shooting games, we not only have bullets in much more curvy ways, but we also want the freedom and flexibility to code their trajectories in whatever crazy ways we can think of. Finding a “law of physics” that results in each trajectory we want is not so easy and simulating that law, if it exists can be tricky as well.
So instead our level of description for the trajectory is like a chain of positions. It is very flexible but has the drawback of a discrete resolution in time.
If you know vector vs raster graphics, it is a bit like that just in the time direction.

But as I said above, I think there is a way to implement higher framerates using interpolation and the issue is left open. we may do it at some point.

This is just to give an explanation for the strange coincidence that all Touhou like games are locked at a specific framerate.

[Akaricchi]

To expand on lao's excellent answer, another good reason why a completely deterministic game loop is desirable is because it makes replays very efficient and almost trivial to implement. The way they work is by storing a very limited set of starting conditions (stage id, player position and resources, RNG seed, etc.) and a complete history of player inputs timestamped with frame numbers. Simply replaying this sequence is then enough to recreate the exact game state at any point in time, thanks to the game's inherent determinism.

If we allowed the frame time to vary, that scheme would collapse. A valid replay would have to store the frame time value for every single frame to keep the game state in sync, and even then it would be impossible to actually play it back smoothly, because we have no control of the playback frame times. It's equivalent to injecting an unpredictable, uncontrollable random factor into every single time-dependent calculation in the game, which surely sounds like a bad idea for any kind of game.

Which is why most games actually run their logic on a fixed time step, as lao already pointed out. Networked multiplayer games (speaking from my experience with Quake-based shooters here) benefit from an inherent separation of client- and server-side logic. The server runs at a fixed frame rate, while the clients are free to calculate inconsequential things like smooth animations at their own, variable frame rate. In such games, even though the server frame rate usually stays fixed at runtime, often it can be adjusted, and doing so affects the game even if it was coded to properly account for variable frame times. These effects are subtle, but not subtle enough to go completely unnoticed by players (again, speaking from my experience running some very casual Nexuiz public servers). The way these games implement client-side replays (aka "demos"), by the way, is by capturing all network traffic from the server. This is much less storage-efficient than simply replaying inputs, but they have to do this because the clients obviously don't have enough data to simulate the entire game.

Many casual single-player games do not have a replay feature and some of them can get away with a variable logic time step. Usually this leads to funny/game-breaking physics bugs when the game is allowed to run at extremely high or low frame rates.

But a lot of single-player games do actually decouple their logic from visuals and run the logic at a fixed frame rate for consistency. They have to employ some kind of motion interpolation to achieve that smooth "FPS independent" look. The price of that is extra latency, at least one logic-frame of it. To interpolate between two game states, you necessarily have to compute both of them before you can display the interpolated result. A frame of unavoidable input lag is acceptable for many games, but seems like a harder pillow to swallow for a game where precise movement is important. There's a reason why every remotely serious player installs vpatch for the older Touhou games.

To come back to competitive online shooters for a bit, they are in a unique position because they have to contend with much worse network latency already. And they are desperate to employ every trick imaginable to hide it. The clients not only interpolate the data they get from the server, they often extrapolate it too. In some cases this results in jerky motion and rubber-banding, but the game wouldn't be playable without it.

---

Now actually concerning Taisei: the only viable path to unlocked framerate is interpolation, as @laochailan had already explained in his first reply. Bullets warping around is something we already have to deal with, because we actually employ interpolation for collision detection already. The way it's dealt with currently is when something teleports a bullet, it must change its tracked "old position" as well. This is a manual process, but these cases are limited and it works. That's the easiest problem to solve though, as visual presentation is too tightly coupled with the game state right now. Fixing that would require some engine re-architecting, but probably not a whole rewrite of the game the way that changing the time step would. It's something I'm willing to attempt, eventually, after the extra stage is finally done.

If I were to make a Taisei 2, though, I think I would actually stick with the game logic being hard-coded to assume a specific framerate, rather than follow the conventional wisdom of coding for a variable deltatime but having it fixed in practice. I would just use something like 120 or 144 rather than 60. Most other types of games derive a lot of their gameplay from static level design and/or emergent interactions between their systems. But in a Touhou-style shmup, the gameplay loop is linear and everything is on rails. Literally all of the level design comes down to sequences of tightly timed events and controlled bullet trajectories. Everything is time-based, and when your fundamental indivisible unit of time is some ugly fraction like 0.016666…, let alone an opaque deltatime variable, timings become difficult to reason about and synchronize. Pretty much every part of "high level" stage code now has to consider deltatime, which is not always straightforward, but always easy to get wrong or miss entirely. The chances of implementing it correctly approach 0%, and at that point the usefulness of "framerate indepedent" logic is questionable at best.

[StalkyBoi43815]

I wasn't aware that single-player games separate logic from framerate. One single frame of delay doesn't sound that bad, as most people have 59 or 119 or 143 to enjoy. While I understand why you chose to lock the game at 60 fps from the start, maybe you could have added more framerate options somehow, binding game logic to 120, 144, 240 etc, and then storing it in the replay or something? I don't know, I don't code. Thank you all for the great explanations to layman me.

[HybridDog]

Maybe to make the game look more smooth, the rendered frames could be synchronised with the display refreshes with VK_EXT_present_timing, if it doesn't use VK_EXT_present_timing already.
https://docs.vulkan.org/features/latest/features/proposals/VK_EXT_present_timing.html

The advantage of having more than 60 FPS is, in my experience, a significantly reduced motion blur.
Camera movements, scrolling backgrounds and scrolling text becomes very blurry with 60 FPS sample-and-hold displays because the image stays for 1/60 s intervals in the same place while the eye smoothly moves and its retina integrates incoming light.
Here's an example where the "Q-52" text is unreadable on my display while the picture moves: https://testufo.com/photo
With a 60 Hz LCD with backlight strobing or a 60 Hz CRT display, the game could be playable without motion blur and would look as smooth as a game with very high FPS.

The lower latency caused by a higher refresh rate is unimportant as far as I know because if the latency doesn't jitter, humans should easily predict it like they have no problems with the latencies caused by the inertia of their extremities when doing common body movements.

It's equivalent to injecting an unpredictable, uncontrollable random factor into every single time-dependent calculation in the game, which surely sounds like a bad idea for any kind of game.

Luanti has a noisy server-side delta time even though the client runs asynchronously. I think in that game following real-time is more important than determinism and with a fixed step, it would be unable to catch up if there's a lot lag.

[Akaricchi]

Maybe to make the game look more smooth, the rendered frames could be synchronised with the display refreshes with VK_EXT_present_timing, if it doesn't use VK_EXT_present_timing already.

That's a Vulkan thing. Our primary renderer is still OpenGL, which doesn't have a direct equivalent, and is generally quite opaque with its presentation control. We technically have a Vulkan renderer through SDL-GPU, but it doesn't support VK_EXT_present_timing. That would have to be implemented in SDL.

That said, if you have a high refresh rate monitor, you should enable VRR (AKA FreeSync, G-SYNC, or whatever marketing term). The game will be perfectly smooth with that on, given that the framerate is stable and your compositor can directly scanout the game window. Usually that requires the game to be fullscreen with no overlays (e.g. desktop notifications) displaying over it, but that's normally what you want anyway. Almost every monitor on the market supports VRR these days, and it's impossible to make a 60 FPS game really fluid without VRR if the refresh rate isn't a multiple of 60 anyway.

Luanti has a noisy server-side delta time even though the client runs asynchronously. I think in that game following real-time is more important than determinism and with a fixed step, it would be unable to catch up if there's a lot lag.

Sure, "for any kind of game" is a bit of a dramatic over-generalization. But Luanti is not a fast-paced action game or an arcade shooter, and is not concerned with replay consistency the way something like Taisei is. Different goals.