The games slow down. Until recently, most Japanese games were tightly tied to 30hz or 60hz logic, and would speed up or slow down if forced (willfully or not) to run at different frequency. This is not strictly a Japanese games phenomenon, but I've seen it mostly in PC ports of Japanese developed games for consoles.

To me, that's bad software design. 40 years ago, developers used to sync their logic to the refresh cycles of the target machine's display. That's amazing, but also something that should not happen in 2018 (or 2010 or 1998).

Isn't that the reason for the Turbo button?

For the younglings: it was a physical button to underclock the CPU on old PCs.

https://en.m.wikipedia.org/wiki/Turbo_button

Yes, but the turbo button is and should remain a relic of the past, rather than a cornerstone of modern gaming design.

Eh, it’s extremely difficult to write a physics engine that behaves predictably with variable timesteps. Likely impossible at the extremes.

The framerate of the physics simulation can be decoupled from the frame rate of the rendering loop. For example, you can aim for a 30fps steady timestep simulation and a vsync-capped rendering. you can then use interpolation methods for quick-and-dirty calculation to smooth the movement to match the rendering timestep.

My ignorance on this subject is a vast abyss, but reality seems to work OK with this, because "subjective" and "objective" time can be decoupled. The world doesn't really care if your video camera takes a snapshot every 1/30th or 1/60th of a second, it'll keep doing whatever it is doing at its own pace.

Can't a virtual world be built with the same principles?

They can and they are. Take for example Forza Motorsport, the physics engine, i.e. How the cars react to different road conditions updates at 360 hz while the graphics updates at 60 hz.

May be real world is simulated with 5.39e44 fps, so you won't feel the difference between 30 fps or 60 fps camera. You can't simulate virtual world with similar performance yet.

No it isn't. You might need to set a minimum time step to avoid instability but a variable time step is trivial.

The only place it might cause issues is if you need it to be deterministic, e.g. for multiplayer.

I read that comment and initially had the same response as you. But on re-reading it is good advice, and one shouldn't focus on edge cases in language, when IRL we would probably all be in furious agreement.

Obviously for most models it is simple to adapt to variable simulation periods without instability, either by microstepping (which commonly occurs anyway because the natural simulation freq is much faster than 60Hz), or because the process is just solving a stable DE or doing basic physics over a different period.

For debugging it is often much easier to run physics at a fixed rate. You do get different results at different rates due to numerical precision issues and error accumulation.