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

Discussion and feedback on Construct 2

Post » Fri Jan 23, 2015 2:40 am

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)
Posts: 564
Reputation: 5,153

Post » Fri Jan 23, 2015 7:42 am

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.
Don't lose your work. Backup your game with Dropbox.
Posts: 1,106
Reputation: 9,202

Post » Fri Jan 23, 2015 2:46 pm

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.
Posts: 232
Reputation: 6,274

Post » Fri Jan 23, 2015 4:09 pm

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.
Game Producer & Independent Developer - http://raphaelgervaise.com
Posts: 237
Reputation: 2,232

Post » Fri Jan 23, 2015 4:17 pm

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.
Posts: 2,455
Reputation: 15,028


Return to Construct 2 General

Who is online

Users browsing this forum: Yahoo [Bot] and 18 guests