We really need a way to cap dt at a lower value

For a while now, I've noticed that my game runs very poorly at low framerates. It becomes basically unplayable at anything less than 45fps, mainly because of the collision issues.

I'd really like the game to be at least playable at lower framerates, and this could be fairly easily achieved by having the game slow down instead of 'dropping frames'. Technically, this could easily be achieved by allowing us to cap dt at a lower value in the project settings - currently, it's capped at 0.1 I believe, which is crazy high. I'd probably cap it at 0.03 or 0.02 (60fps dt = 0.016) for optimal gameplay.

Is there a reason this can't be implemented?

Seconding this. Watching high-speed bullets fly through walls on older systems is something I wish could be avoided :p

You could change the timescale depending on the fps value (if fps between 10 and 30, set timescale to 30/fps) I think.

Aphrodite That could potentially work but I feel like a straight cap would be simpler.

Dropping frames is much different than slowing the game down.

It is pretty much the definition of v-synced games.

Sounds like it would be useful

I'd like to give this thread a bump. This feature would help immensely with lag spikes which are unfortunately a pretty common occurrence for a lot of C2 games.

I've been talking with Aurel who just released The Next Penelope on Steam. Apparently certain streaming softwares kill the FPS on the game, and without a low dt cap the game goes out of control, whereas simply slowing down the gameplay would be far better. (the setting timescale relative to fps is a very messy solution, specifically in that case)

Posting so this comes up on egosearch.

I'd be interested in knowing the reasons for the current magic number, and the arguments (or rather the science behind it) for and against its reduction.

Apparently certain streaming softwares kill the FPS on the game, and without a low dt cap the game goes out of control, whereas simply slowing down the gameplay would be far better. (the setting timescale relative to fps is a very messy solution, specifically in that case)

If you use a lot of shader effects, streaming destroys performance. It's strange.

I remember being a real pain and asking for a 30 fps option a while ago (or, more precisely, it became a 1/2 vsync render option when I understood how c2 runs in the browser). I don't think c2 is mech'd to be able to be able to successfully vary the dt and diverge from what the browser engine is doing. I might be wrong, and it would not be the first time, but but the last attempt to provide an option in c2 to run at 1/2 vsync was a proper failure (after much nagging by me and few others, I recall...).

I would dearly love for us to have a fraction-of-vsync option, where game logic can take more time to do required maths before a draw call, but I don't think it is possible within c2.

I see similar weird behavior on my embryonic game when I test it on an old laptop - it's almost as if the event system breaks down under relatively high cpu load.

I used to have a system that monitored dt and set multipled it by an arbitrary scale of my own devising...

Basically I would scale anything dt related by this in order to perceptually slow down the game while running at low fps.

I also used it in a physics game in order to stop the built in limit of 30fps from changing timestep... then I realized it can be changed in the behavior without a problem (exposed a new property yay)

EDIT: It was called 'set half framerate mode'. Here we go: https://www.scirra.com/construct2/releases/r150

Actually, at one point Ashley caved and added in a 30fps mode...which was promptly removed in the next beta, due to a host of unforeseen issues. Can't find it right now, but I think it was sometime in the middle of 2014. I've seen the code in the engine as of a few months ago, commented out. The function name escapes me.

I think it could be enabled pretty easily, but who knows what issues it would cause.

Outside of using the stepping mode of the CustomMovement behavior, I run into collision problems with standard movement behaviors a lot because of the fact that the game loop is locked at a maximum of 60 ticks a second. The standard max fall speed of the Platform behavior is set to 1000 pixels per second, my frame-rate hovers between 50-60fps, which means anywhere from a 16 to 20 pixel Y-displacement on a single tick. It gets even worse if you're trying to determine if the collision was top-to-bottom, or a side-collision, etc. If you're doing a low-res pixel art game, a single character sprite might not be much bigger than 16x32.

Even resizing the browser or putting a different application's window in front of the active tab can cause it to dip by 5-10 frames. I don't know how internally how Construct separates rendering and logic loops but I really wish that the logic loop itself could run unrestricted.

While exposing more of the internal update mechanisms can sometimes be useful, I would argue that all the physics-related issues should be considered a separate problem.

The tunnelling effect people encounter when using physics behaviours and collisions is a well-known problem, and fiddling with timesteps is not the best solution to it. It might help in certain situations, but it's not a robust approach. The "proper" way to deal with this is to have continuous collision detection, with swept surfaces (point > raycheck, sphere > capsule check, box > swept box, etc.), and broad/narrow phases.

I haven't used the physics in C2 yet, but if the built-in functionalities are not satisfactory, that's what we should be asking for. Which doesn't conflict with the idea of having more control over the game timesteps.

As TiAm pointed out Ashley did do a 30fps, however it was a basic 30fps implementation. That design was based on working with the vsync and wasn't friendly. Ashley was never committed to the belief that there is any value in running less than 60fps so there is no way he is going to put the effort in for any modifiable fps.... of course let's selectively ignore that a large number of fantastic looking PS3/Xbo360 games ran at 30fps.... as is always ignored because it validates the point of 30fps.

However even if you can't run at less than 30fps, doesn't mean you can't take advantage of better control FPS in the logic update. If the logic update could be run with at a variable fps with a dt accumulator. Then that would solve the problem. And while this was suggested, the response was "Saw no value".

My suggestion. These discussions will go now where so not a lot of point of contstantly asking. your best solution is to just make a new set of plugins with a controllable dt, and logic update by custom kernel.