Also would like to say that a cross platform game engine like corona NEEDS to be time based especially considering the widely varying performance in android handsets. So this really isn’t a feature request so much as a bug in architecture and implementation. The good news is that I think they could merely set a timer to see how long the draw cycle has taken and adjust the physics time step appropriately. 60 fps should take roughly 16 ms per frame and that’s what the time step is hardcoded to (when your project is set to 60 fps). Well when it’s slower, say it it takes 23 ms for whatever reason, then adjust the time step to 23 ms. [import]uid: 8545 topic_id: 15627 reply_id: 60654[/import]
From the Box2D manual (http://www.box2d.org/manual.html#_Toc258082968) we can learn that:
“Generally physics engines for games like a time step at least as fast as 60Hz or 1/60 seconds. You can get away with larger time steps, but you will have to be more careful about setting up the definitions for your world. We also don’t like the time step to change much. A variable time step produces variable results, which makes it difficult to debug. So don’t tie the time step to your frame rate (unless you really, really have to).”
And from posts like this http://www.koonsolo.com/news/dewitters-gameloop/ we can learn that physics simulation and graphic rendering should be split to maintain proper gameplay.
But it would sacrifice the simplicity of Corona Box2D implementation. I hope Ansca stuff will come up with good solution. [import]uid: 96906 topic_id: 15627 reply_id: 60666[/import]
I think whatever they are doing to accomplish framerate independent physics here would be nice. Hopefully something like this is possible in corona.
http://actionsnippet.com/swfs/qbox_FRIM.html [import]uid: 8545 topic_id: 15627 reply_id: 60693[/import]
The test files I received were passed on to the team. It is being looked into.
As soon as I have a response for you guys I will post it up asap.
[import]uid: 84637 topic_id: 15627 reply_id: 60697[/import]
Hey FRIMers, I thought I’d share this while we’re waiting on a response from Ansca. It’s by no means a solution of any kind but it may help someone in limited situations in the meantime.
While prototyping different objects for our current project we’ve found that eliminating unnecessary collisions helps a bunch. We’ve got a plunger-type object that springs out of the wall whenever the hero runs into it. It moves along a single axis and only interacts with the hero. We spawned 20 of these things in a line and almost cried when we saw the performance hit on device. Long story short, we realized since the object were close together the physics bodies were actually touching and the result was A LOT of non-stop collisions. We shrunk the physics bodies a couple of pixels so that they were no long touching and it ran as smooth as it did on the simulator. We’ve got over 200 hundred physics objects on screen at a time, but since they are only interacting with the hero and are not colliding in between, there really is no performance hit.
On the other hand, we’re also prototyping a monster (Mr. Squiggles) that has 6 tentacles. Each tentacle consists of 20 jointed segments. It looks very cool on the simulator, but needless to say it’s a major show stopper on device since every single segment is colliding non-stop. Whenever my kids ask me what Mr. Squiggles does I have to tell them that all he does right now is kill performance.
Anyway, hope this helps someone. Also hope we hear some good news from Ansca soon!
[import]uid: 40137 topic_id: 15627 reply_id: 61433[/import]
@mmathias6410 Not sure exactly what your game is doing but as long as physical objects are not moving or being touched by a moving object they are supposed to “sleep”. Sleeping physical objects have much reduced overhead.
Unfortunately I think this is another aspect of Corona’s Box2D implementation that isn’t working quite right either. I’ve found that many times dynamic objects simply never sleep even if they have never been touched or moved. Playing around with the value of gravity I found I could make previously non-sleeping objects sleep, but in my case changing the gravity affected too many other aspects of the game to be a useful workaround. Perhaps it would work in your case.
[import]uid: 9422 topic_id: 15627 reply_id: 61441[/import]
+1 for time based physics [import]uid: 2927 topic_id: 15627 reply_id: 65746[/import]
@pagodawestgames
Bullet example from Corona SDK example is not good example to show the difference of 30/60 fps, as it uses applyForce which is time dependent. Use code below and there is almost no difference between 30/60 fps.
[code]
local function throwBrick()
n = n + 1
bricks[n] = display.newImage( “brick.png”, -20, 140 - (n*20) )
physics.addBody( bricks[n], { density=3.0, friction=0.5, bounce=0.05 } )
– remove the “isBullet” setting below to see the brick pass through cans without colliding!
bricks[n].isBullet = true
bricks[n].angularVelocity = 100
–bricks[n]:applyForce( 1200, 0, bricks[n].x, bricks[n].y )
bricks[n]:applyLinearImpulse(40, 0, bricks[n].x, bricks[n].y )
end
[/code] [import]uid: 9058 topic_id: 15627 reply_id: 67290[/import]
@Andriy Pertsov that may be a better technique for that one specific example, but the fact remains, we really need an way to make use of time-based physics instead of frame-based. [import]uid: 49447 topic_id: 15627 reply_id: 67292[/import]
@producerism
I understand that, I just wanted to show that sometimes it could be simpler to change code rather than demand a feature from developers. I prefer they make features like In-App Purchases for Android, Kindle Fire & Nook Tablet support etc., which may help earn money 
[import]uid: 9058 topic_id: 15627 reply_id: 67463[/import]
@Andriy Pertsov Have you seen eaguirre’s liquid simulation?
It’s unusable on a device because it gets about 5fps. That’s just one example, but there are many. If that kind of thing were possible with Corona all it would do is expand Corona’s subscriber base. Ansca is severely limiting Corona’s potential by not implementing this.
We all want In-App Purchase for Android and Kindle Fire & Nook Tablet support, but to imply it’s an either or situation is disingenuous. Ansca does not only work on one thing at a time.
Nobody here is demanding anything. We all appreciate the hard work and the resulting progress from the people at Ansca. If you look at where they were a year ago it’s quite amazing how far they’ve come. I think what people are reacting to here is the total lack of any kind of response or update from Ansca on this particular issue. It’s been over a month now since we last heard from Danny, unless he’s been communicating via email with others on this thread. If that’s the case, can someone please post any updates they’ve received? [import]uid: 40137 topic_id: 15627 reply_id: 67467[/import]
@mmathias6410
I do not want to argue. My point was to not wait for grace from Corona developers, but try to use what you have, because sometimes it’s possible to achieve goal by changing own code, not by a new feature. Also I pointed out that Bullet example is a bad example.
I play with eaguirre’s liquid simulation and tested it on iPod Touch 3gen. I gain 45 fps on device without drawing and fill functions, only physics simulation. So physics performance is not a problem and it’s good enough. The main problem of Corona SDK is rendering performance. [import]uid: 9058 topic_id: 15627 reply_id: 67478[/import]
@Andriy, I don’t think any of us want to argue, this is just a technical discussion among fellow devs
The main problem of Corona SDK is rendering performance.
I completely agree with you, and encourage everyone here that would like the rendering improved, to please chime in here:
http://developer.anscamobile.com/forum/2010/09/03/bitmap-manipulation#comment-67482
I believe that’s the only feature request thread about it. There are plenty of forum topics, but no feature requests. So again, please give it a +1 or additional insight.
So physics performance is not a problem and it’s good enough.
I really, really have to strongly disagree with you here. While I do agree that improving the rendering performance would in turn help with physics issues, it’s a far cry from the feature being requested in this very thread.
You’re point is very valid - don’t wait for Corona updates and work around the problems for now. But since this is the feature request thread, I believe this is the exact (and only) place to bring this issue up.
I believe that box2d is platform agnostic, or at least moreso than the device rendering process (bitmap data access/manipulation). For that reason alone, a semi-fixed physics timestep is probably a lower-hanging fruit to have fixed. Notice that the rendering issue (bitmap data) has been on the feature roadmap for well over a year… so it’s probably a bit more complicated since each device renders graphics differently. However, the box2d code would more or less be the same, save for any device-specific optimization in the the actual math and interpolation.
There are loads of ways to implement semi-fixed timesteps in box2d, this article provides a very good explanation, along with the code to do it.
http://gafferongames.com/game-physics/fix-your-timestep/
(and here is an Obj-C/iOS implementation: http://www.cocos2d-iphone.org/forum/topic/9737#post-56466) [import]uid: 49447 topic_id: 15627 reply_id: 67489[/import]
@producerism
I don’t think any of us want to argue, this is just a technical discussion among fellow devs
Oh, than it’s OK, I just afraid of arguing
I understand that this thread is the only way to request such a feature, but in my experience, unfortunately, Corona developers are not quick in implementing users’ requests. So I hoped to help somebody, if he has problem like in Bullet example (using forces instead impulses etc.).
Time based physics really needful when you try to achieve really exactly same behavior of physics objects on any device. But most of physics games do not need such precision.
I’m voting for TBP, as to have a choice is always good (but limits lead to creativity ). [import]uid: 9058 topic_id: 15627 reply_id: 67496[/import]
@Andriy Pertsov I don’t want to argue either. I understand where you’re coming from and I can appreciate that. However, I think everyone on this thread has tried many, many different approaches and we’re all running up against the same barrier.
Anyway, I downloaded eaguirre’s liquid sim code again. I commented out the fill() call and changed the # of balls to spawn from 200 to 400(ie added more water).
Running on the Simulator – not even a device – it started out at 60 fps and dropped all the way to 8 fps. (With the original 200 balls it only drops to 15 fps on the Simulator.)
After several minutes, once all the balls settle, the fps is back up to 60.
Then I ran it again with the physics draw mode set to “Debug” and got the exact same result.
I don’t know how you got 45 fps on an iPod Touch 3gen, but I’d love to see a video of it. Also would love to know if you got a drop in frame rate or it was a constant 45. The fluctuation in the frame rate is the real problem as currently implemented because the physics sim is tied to it. Hell, I’d be happy with 30 if it was constant. But if I’m at 30 and by adding (in this case) water I drop to 20, the game is unplayable at that point just from a QA perspective, even if it still is technically functional.
[import]uid: 40137 topic_id: 15627 reply_id: 67503[/import]
@mmathias6410
Concerning eaguirre’s liquid sim - turned off all rendering, it was just physics, with only 100 ball - it was min 45 fps (jumping to higher) on ipod 3g. I’ll do not make video of this, sorry.
However, I think everyone on this thread has tried many, many different approaches and we’re all running up against the same barrier.
I saw there was one example that TBP is needed - it was post with Bullet example. I made it to work same on 30 and 60 fps. I do not see any other example or approach which shows that without TBP it’s not possible to make something. I just wanted to help, as in some cases - you do not have to wait for this feature to be implemented. [import]uid: 9058 topic_id: 15627 reply_id: 67510[/import]
@Andriy
I do not see any other example or approach which shows that without TBP it’s not possible to make something.
I can provide another good example. I’m currently making a top-down shooter game, which is using physics to handle collisions, projectiles, etc (gravity turned off, so I’m really just using it for collisions and easy use of trajectories/forces/static objects/etc.)
However, sometimes when a lot is going on, the entire game slows down, because the way box2d has been implemented, forces every single frame to render while catching up - while the optimum behavior for this particular game, would be to skip the rendering for those missed frames, and only calculate the physics data.
For my purpose, accuracy isn’t much of an issue - it’s has more to do with keeping the animation looking smooth, and not choppy. So that is a completely different reason for wanting a semi-fixed timestep.
I can imagine there are plenty other reasons as well, including accuracy with bullets/CCD (constant collision detection) as you mentioned.
If you (or anyone else) could provide a workaround to my particular issue, I’d love to hear it. I believe though, that since I’m using the physics engine to take care of movement, I’m stuck with this issue for now. I am working around it, but it would be great if there was just a flag I could set, so that Corona would just call the physics timestep independent from the rendering step. [import]uid: 49447 topic_id: 15627 reply_id: 67514[/import]
LOL. producerism…are we working on the same project? JK. Felt like I just read a synopsis of the last 5 months of my life! [import]uid: 21331 topic_id: 15627 reply_id: 67518[/import]
**@Andriy
I do not see any other example or approach which shows that without TBP it’s not possible to make something.**
Just to add to what producerism said: any time you have approximately 30 or more physics objects colliding at once is when you need TBP.
Our first game was basically a large number of physics objects colliding constantly. We were able to stretch the number of physics objects to 40 at a time as long as none of them had to move much, but usually 30 was the solid limit.
Anything made up of a large number of smaller objects, like the liquid sim or multiple ropes or tentacles will not work without TBP because all of those smaller objects are constantly colliding with each other.
@producerism and TheRealTonyK
I guess we are all making similar type games and hitting the same wall!
[import]uid: 40137 topic_id: 15627 reply_id: 67544[/import]
Glad to see this issue gaining some traction with corona users. I’m curious what corona thinks? I submitted a demo awhile ago. Hopefully they have a good fix for us. [import]uid: 8545 topic_id: 15627 reply_id: 67637[/import]