For gamedev, how to have a precise physics/timing loop without locking framerate?

[octopod]

This is kind of a conceptual question that I tried asking myself but still don't fully understand.

So as you may or may not know, many games that feature precise platforming, logic, or etc. tend to lock their games at 60fps or something similar to that. Examples of this are Dark Souls, Super Meat Boy, N++, Dustforce (all precise platforming games), Touhou games and pretty much every Cave bullet-hell game in existence, Street Fighter, Skullgirls, Super Smash Bros. (fighting games), and some rhythm games too. The idea is that the frame-lock gaurantees a constant time between frames of which to calculate logic in a precise way, which I kind of understand for physics, timings, and things like that.

A while ago I tried making a small bullet-hell based game in Unreal Engine, but I found out that the patterns I scripted don't play out as accurate as I thought they'd be. Sometimes there'd be unnatural gaps during a sequence of bullets, and things like that. Turns out this is because of how fast the frame-rate varies, which is messing with the times bullets spawn. If I locked the framerate, this kind of thing wouldn't be a problem, but I'm trying to find a way to do it [I]without[/I] messing with the framerate.

[URL="http://gamedev.stackexchange.com/questions/1589/when-should-i-use-a-fixed-or-variable-time-step"]This question on gamedev.stackexchange[/URL] offers some pretty good insight on what the difference between variable-fps and fixed-fps is.

I suppose the more specific question in my case is how to separate the update loop into the update loop and a logic/tick loop.

[SteveS]

Substepping.

[Philly c]

You could run the game at a fixed rate and interpolate the positions of objects purely for rendering purposes, but there are several disadvantages to that:
1: It introduces latency in multiple ways which you would want to get as low as possible in the genres of game you list.
2: It will subtly mess with the feel of the game, for example the behaviour of input will change depending on the rendering rate to the games update rate, and objects positions will be slightly out from where they actually are, which is a similar problem to:
3: It messes with frame timing which is arguably important for the genres you listed. Any game which runs with a variable frame rate will mess with frame timing because of the mismatch between time between frames and the time that the game has been shown to have updated. The only way around that is simply to bruteforce fps and bring the error down in to the low milliseconds.

Fixed frame rate pros:
1: It's possible to reduce latency to as low as you can reasonably expect it to go by pushing the game update as close as possible to the vsync where it will actually be displayed.
2: Running on a monitor with the same refresh rate and vsync gives you perfect frame timing and the lowest latency which will make the game feel right.
3: You can fine tune the games behaviour and expect to see it play out deterministically.
Cons:
1: It's obvious but no variable frame rates could be a con to some of your players. A lot of people wrongly think that variable frame rates is the best way to run a game even though it is actually a comprimise. Nonetheless they expect it.
2: No higher frame rates. You could always design your game to run at like 240 updates per second. That will match up with several common monitor refresh rates, but it could increase the requirements of your game way too much. It also comprimises lower render rates, for example at 60 fps you would skip 3 updates a frame.

As a sidenote there are many other things people talk about, like messing with the timesteps and running the game and physics and rendering all separately at different rates and timesteps but frankly the precise behaviour of how all of these things interact is so incomprehensible that I can't recommend it for any games let alone the genres you're thinking of.