Physics behavior with a varied frame rate

I posted the example cap here:

Summary: The frame rate drastically changes the physics behavior. Things start to look ugly when the frame rate is low.

Are there any plans to have the code FPS fixed with the graphical end varied and 'v-syncable'?

You can set a minimum speed to avoid game-breakage.

You can set a minimum speed to avoid game-breakage.

But this slows the game down.

In the past I have used MMF. They have a "machine independent speed" option. This allowed the events to run at a constant speed but the graphics were able to vary. So the Game would always run the same on every PC, just not necessarily look as smooth.

The problem with that was that the game didn't run at the same speed on some machines, it ran WAY faster than normal.

MMF is fundamentally designed to be framerate dependent. You pick your framerate (eg. 50fps) and 'machine independent speed' skips drawing if it can't hit that rate. Since you need to get the logic running at a fixed rate to make a framerate dependent game keep running at the same speed, if your computer still can't hit that framerate, the whole game slows down anyway, kind of defeating the point of the option. As far as I know, you can't V-sync and have machine independent speed on in MMF (or if you can, your game will change speed depending on the framerate, I guess).

If you turn on V-sync in Construct, it won't skip drawing the screen, but instead the value of timedelta increases since it's taking longer to process frames. This can result in objects 'tunnelling' through each other, or physics going a bit funky, at very low framerates. The solution is to use the minimum framerate option. It does make the game run in slow-motion if your CPU can't keep up, but so would 'machine independent speed' if it were in Construct, and hey, you can't do an infinite amount of processing and keep the same framerate.

Physics is processed on the CPU so the CPU will be the cause of the slowdown. In this case drawing the screen takes a comparitively little amount of time, so skipping drawing the screen won't solve this problem. You need to use less CPU!

I know if I make certain objects/effects invisible the frame rate will stay at a steady 60fps even on the slowest machine I have. So in my case the graphics are the bottle neck.

I understand the advantages of the timedelta system, but the ability to skip frames as an alternative would still be very nice.

Thanks for the explanation!

If you want to control it, then I would suggest using Timescale(); adjust it as necessary when your frame rate lowers. Just an idea.

overide timedelta is what you need. its under advanced options in the layouts properties i thinks.

So in my case the graphics are the bottle neck.

Then have options to allow the user to turn off effects if their computer can't handle them. It's a well known issue physics doesn't work well with large timedeltas.

I understand the advantages of the timedelta system, but the ability to skip frames as an alternative would still be very nice.

Frame skipping is for frame-based logic.

You CAN do frame-skipping if you reallyreallyreally want it.

Here's how:

*EDIT* UPLOADING WORKING .CAP TOMORROW *EDIT*

then put all your logic inside a loop that recalculates for each 'elapsed' frame.

Then you're ready to welcome unsmoothness into your life. You know, if you reallyreallyreally want to.

edit: don't smite me ashley

I still recommend using timedelta with a minimum FPS setting, calculated with your max speed and minimum object size so things can't go trough each other. But if you INSIST, here's how to do frame-based logic in construct with frameskipping: http://www.udec.cl/~jfuente_alba/frameskip.cap

Shows frameskip. Has a fixed FPS of 5, change it to see how frameskipping behaves under different conditions.

Note how setting no fixed FPS or setting 60FPS the animation still looks choppy, as it is frame based and limited to the set maximum.

I've set it up to run at 30fps with frameskipping, change the in the events 30 to set it to other speeds.

EDIT: Remember, if your game has complex events slowing it down, this won't help at all. It may even freeze, as you'll be looping and making it slower each time.