Physics: "Apply force" not framerate independent?

For questions about using Classic.

Post » Sat Jan 03, 2009 5:49 pm

Hi, I'm a user of MMF who is just checking out Construct to see what kind of opportunities it offers.
I was just messing with the Physics behavior and made a little cannon that shoots physics-enabled balls wherever you click.

Before starting with Construct I read a bit about TimeDelta and how it should be used in games. However, the wiki says that all the built in behaviors are designed to work the same no matter what the frame rate is, meaning that there is no need to use TimeDelta in events for it.

So I have my gun create a ball and apply a force of 600 towards my mouse pointer. Works great when it's V-synced at 60 fps. Then I decided to try it at unlimited framerate mode. It runs at about 250 fps, about 4x the normal frame rate on my computer, and a problem was introduced. The ball now fired at what I estimate is about 1/4 its original power.

I thought to myself that I needed to apply TimeDelta to my event. So I changed my value to 32000*TimeDelta, which gave about an equivalent force on V-synced. However, very oddly, I go back to Unlimited mode and once again I lose force, in fact I lose force worse than before.

Additionally, if I go into fixed framerate and set it to about half the V-sync (30 fps), I get a gun that fires with twice the power, with or without TimeDelta.

Am I doing this wrong or is it a bug? How can I get my physics to work the same no matter what the frame rate?

(I can upload the .cap if anyone wants to see it)
B
8
S
3
G
5
Posts: 72
Reputation: 1,774

Post » Sat Jan 03, 2009 6:26 pm

you have to divide by timedelta, because time delta is a value that goes lower as the framerate goes higher (i think, but that doesnt matter dividing works) so when you are at high framerates and you multiply you are infact making the value smaller, and viseversa for low framerates.
B
60
S
8
G
7
Posts: 1,952
Reputation: 8,426

Post » Sat Jan 03, 2009 8:24 pm

That makes sense, and I just tried it but as the framerate fluctuates (on unlimited) the strength of the shot fluctuates a bit. It's not a disaster but really, shouldn't it work the same no matter the rate?

EDIT: I should note though that the shot strength is pretty close on both Vsync and Unlimited now, so that's good.
B
8
S
3
G
5
Posts: 72
Reputation: 1,774

Post » Sat Jan 03, 2009 9:24 pm

Holy shit, Timmy? Haven't seen you in a while.
B
2
S
2
G
4
Posts: 110
Reputation: 1,670

Post » Sat Jan 03, 2009 10:19 pm

[quote="Mr. Ksoft":3vthtgeq]That makes sense, and I just tried it but as the framerate fluctuates (on unlimited) the strength of the shot fluctuates a bit. It's not a disaster but really, shouldn't it work the same no matter the rate?

EDIT: I should note though that the shot strength is pretty close on both Vsync and Unlimited now, so that's good.[/quote:3vthtgeq]

well, timedelta wont always work excactly the same, but you should set up your game so that minute fluctuation doesnt affect it.

also note your games fps wont be jumping by 300 or more.
B
60
S
8
G
7
Posts: 1,952
Reputation: 8,426

Post » Sun Jan 04, 2009 8:36 am

I'm still a little unsure as to why you would need to divide by TimeDelta. Maybe it is because the force applied determines the acceleration of the ball. In that case wouldn't you want TimeDelta*TimeDelta in the denominator? (Since acceleration is meters / second / second)
B
3
S
2
G
4
Posts: 271
Reputation: 2,017

Post » Sun Jan 04, 2009 10:37 am

I certainly wish physics values were scaled to pixels per second ;) Maybe it would help the situation :D
*bugs devs some more*
B
3
S
2
G
5
Posts: 351
Reputation: 2,377

Post » Sun Jan 04, 2009 1:22 pm

Yeah, I can get Physics going in pixels-per-second when I figure out the math, but it would change every existing .cap...

You divide by timedelta because you want to apply a total-force-per-second, not a force-per-frame. For example (picking easy numbers), say you want to apply 10 newtons/second of force. At 1 fps, that's 10 / 1 = 10 newtons per frame. At 2 fps, that's 10 / 2 = 5 newtons per frame, which adds up to 10 newtons per frame again.

Physics itself is a bit fussy about floating point precision and framerates. Generally it's stable in the 30-120fps range. Outside of that I think you'd start getting weird rounding errors in the timestep.
Scirra Founder
B
373
S
218
G
84
Posts: 23,444
Reputation: 186,078

Post » Sun Jan 04, 2009 1:48 pm

Well beta is the time to make drastic changes ;) If you're planning to that is.
In any case, you're a champ Ash :D

Also that divide thing intrigues me, although what sort of senario would it be useful in? I'm not the greatest math mind around
B
3
S
2
G
5
Posts: 351
Reputation: 2,377

Post » Sun Jan 04, 2009 11:55 pm

[quote="Arcticus":1yffrm75]Well beta is the time to make drastic changes ;) If you're planning to that is.
In any case, you're a champ Ash :D

Also that divide thing intrigues me, although what sort of senario would it be useful in? I'm not the greatest math mind around[/quote:1yffrm75]

well imagine you want timescaling in your gun game, and you give bullets a physics behaviour, theyd move normal speed at normal time when you shoot them, and then if you slow down time and shoot theyll move at a scale speed.

if you were to use multiply by timedelta, your bullets wouldnt even shoot out at slow timescale, and the same goes for framerate.

its useful if your game will probably run into lag at some points and you dont want the physics becoming wacky because of this.
B
60
S
8
G
7
Posts: 1,952
Reputation: 8,426

Next

Return to Help & Support using Construct Classic

Who is online

Users browsing this forum: No registered users and 1 guest