Time based physics implementation

Solar2D Daily Builds and Public Releases
#1

Currently have an app using box2d and set to 60 fps and every once in awhile it bounced to ~45 fps, but when this happens the app just slows down (not skipping frames). I really noticed this when I went to change my app to 30 fps. The physic simulation was completely different.

Has anybody else noticed the physics implementation feels like it’s actually a frame based implementation? This may actually be a bug, but I thought I would give the benefit of the doubt. [import]uid: 8545 topic_id: 15627 reply_id: 315627[/import]

#2

A perfect example of this would a pure physics simulation run on my really old Droid that supposed to run at 60 fps, but but the phone runs at 30 fps. The simulation runs a pretty much half speed. It should run at full speed but show half of the frames. I can’t think of the virtue of running half speed but showing all of the frames. Maybe someone from Corona could lend a hand here? [import]uid: 8545 topic_id: 15627 reply_id: 57693[/import]

#3

I actually posted this exact problem a few days ago, with no real resolution. I think at the very least we could get a response from Ansca on the status of this if no workaround is available. [import]uid: 87279 topic_id: 15627 reply_id: 57708[/import]

#4

Yeah that would be a huge help. Corona people, could you shed some light on whether this should be a feature request or whether we should file this as a bug? I’m pretty sure it’s actually a bug because it’s nearly impossible to have an application run at a steady framerate and with the current implementation the motion of objects will speed up/slow down with framerate. [import]uid: 8545 topic_id: 15627 reply_id: 57837[/import]

#5

Leave this with me and I will get an answer for you guys [import]uid: 84637 topic_id: 15627 reply_id: 57856[/import]

#6

I asked that question here 10 months ago and never got an official response.

Unfortunately I think the answer is going to be that it’s not a bug, but “the way box2D works in Corona.” The only work around I’ve found is to use every trick in the book to keep framerate steady. That may or may not be possible depending on what your app is doing. 60 fps is going to be a challenge to maintain unless your app isn’t doing much graphically, and impossible on certain phones. In practice I’ve found that fluctuations between 50-60 fps aren’t that noticeable.

[import]uid: 9422 topic_id: 15627 reply_id: 57902[/import]

#7

Posted this on our original thread, but will also post it here for safety. We have filed this issue as a bug in the FogBugz Database under case #8292. [import]uid: 87279 topic_id: 15627 reply_id: 57975[/import]

#8

There are a bunch of solutions to this issue for users of other implementations of box2D, such as “frim” for quickbox 2D, but they all rely on adjusting the physics timestep. Being able to adjust the timestep also provides a simple way to switch between 30 and 60 fps and have physics act nearly identically between the two.

Unfortunately we don’t have access to box2D’s timestep in Corona SDK. Ansca, please please please please let us adjust the timestep! It could potentially solve a slew of issues with the current implementation.

In terms of a Corona bug, I wonder if Corona perhaps *isn’t* adjusting the timestep depending on if you set 30 fps vs. 60 fps in config.lua. That would explain the huge differences seen in even the Ansca physics demos when the framerate is changed.

Danny, any chance you can find out what Corona does internally with box2D timestep when setting the framerate at 60 vs 30?

[import]uid: 9422 topic_id: 15627 reply_id: 58052[/import]

#9

If you guys email a few test case examples to me: Danny [at] anscamobile [dot] [com] I will forward them onto the team and we will investigate this.

Thanks [import]uid: 84637 topic_id: 15627 reply_id: 58054[/import]

#10

We would be quite happy to forward on some sample code, however, simply adding fps = 60 to the end of the config.lua for any of the Ansca provided physics samples with the Corona SDK can provide ample proof of the problem explained here as well.

This is most prominently displayed in the ‘Bullet’ physics test - the speed at which the bullets travel and the way in which the cans fall. At 30 the first bullet penetrates through the entire pyramid of cans, whereas at 60, the bullets are travelling far slower and the first barely makes it half way into the pyramid. [import]uid: 87279 topic_id: 15627 reply_id: 58062[/import]

#11

Just an update, I created a small sample project and sent it to Danny. It’s set to run at 60fps and spawns 2000 physics objects. It’s meant to overpower and run slower than 60 fps on a device. It runs at ~4 fps but shows every single frame of the 60 fps simulation. So a simulation that should take 3 seconds takes 40+ seconds.

The obvious issue is that if framerate in a 60 fps project drops to 45 fps momentarily, then the actual simulation won’t account for that and the objects on screen will slow down. Ultimately it will just feel like a chunky experience. A time based physics implementation, that doesn’t assume a constant framerate, would have skipped frames and finished the simulation in roughly 3 seconds. [import]uid: 8545 topic_id: 15627 reply_id: 58274[/import]

#12

It’s key to note that not only is the motion slowed but also the trajectory of physics objects is changed as well, so not only can a game become chunky and sluggish, but also certain mechanics can be potentially broken when levels are designed to anticipate physics behaving in a certain way.

I found a great online example that enables one to compare frame rate independent physics vs dependent at various frame rates.

http://actionsnippet.com/swfs/qbox_FRIM.html [import]uid: 87279 topic_id: 15627 reply_id: 58283[/import]

#13

That online example is appropriate to this issue because it is also using a box2D implementation, in this case for Actionscript. With FRIM off it exhibits the same problems experienced using Corona. FRIM on fixes things up nicely even with horrible framerates.

There are discussions and even code examples online showing how to implement FRIM, but it requires access to box2D’s timestep, which we currently don’t have access to under Corona.

[import]uid: 9422 topic_id: 15627 reply_id: 58316[/import]

#14

+1
This is a must ! [import]uid: 89702 topic_id: 15627 reply_id: 59493[/import]

#15

Hi Danny, did you and/or the team find out anything in your investigations yet?

One other related issue to add to the mix. I’ve noticed in my game a big difference in the results of a physics simulation between the simulator and device. It seems like more than just some math differences between processors. I see results where applying a force to an object is 30% more powerful on the simulator than on the device. It makes tuning levels very difficult since I have to make a bunch of best guess changes on the simulator and then port the changes all the way to the devices to see how close I got, then back and forth again and again. Very time consuming since I have to wait for the entire app to build on Ansca’s servers for each iteration.
[import]uid: 9422 topic_id: 15627 reply_id: 60339[/import]

#16

Hi. I have also encountered this issue in my new game. From my experience in Cocos2D you must explicitly call world update and therefore you can implement time based physics.

Here it seems we are locked to frame based physic.

Any tip from Ansca how to workaround it would be great. [import]uid: 96906 topic_id: 15627 reply_id: 60597[/import]

#17

+1! [import]uid: 40137 topic_id: 15627 reply_id: 60613[/import]

#18

I have to give this a huge

+1

edit: wanted to include some more feedback than just an upvote for this issue. From what I can tell after a fair amount of testing, for doing lots of continuous collision detection, the physics library is the way to do. Because of that, I’m using physics for the sole purpose of collision detection (I just set gravity to 0,0). I’m also using setLinearVelocity and other box2d functions for movement, instead of using move(), transitions, adjusting x/y manually, etc.

However this also means it’s much harder (if possible at all) to implement my own “frame skipping” by using a delta or something similar. Without frame skipping, the options are to either optimize (sometimes that means stripping content), or change the game design to account for it. Neither of those are the ideal solution though.

If it’s not feasible to open up more of the box2d api in the near future, it would be great if there were at least an option as simple as
[lua]physics.isFrameSkippingEnabled = true[/lua] [import]uid: 49447 topic_id: 15627 reply_id: 60628[/import]

#19

This hit me pretty hard as well. I locked the amount of bullets to 4, but this slowdown caused variable registers to become out of sink with the simulation causing more than the allowed number of bullets on screen, which in turn snowballed into unplayable… I am normally afraid to push the system now and consistently strip out content because of it…yucky…

edit: mega +1 for physics.isFrameSkippingEnabled = true
[import]uid: 21331 topic_id: 15627 reply_id: 60644[/import]

#20

Yeah I sent Danny an example that clearly showed that the physics implementation is in fact frame based. As far as I know they are now reviewing it and will get back to us in this post soon? It has been awhile though. [import]uid: 8545 topic_id: 15627 reply_id: 60649[/import]