Hi,
I can’t seem to find a way to slow the timesteps down in box2d in corona.
I’m trying to simulate the “bullet time” effect from Max Payne. I.e. everything slows down for 2 or 3 seconds before returning to normal.
It’s not a case of just reducing gravity as all motion in x and y needs to slow by the same amount.
(it’s a top down game anyway with g=0)
Thanks
Mal [import]uid: 13964 topic_id: 19966 reply_id: 319966[/import]
As far as I know, fixed timesteps, or access to the timesteps in general, are still not available through the corona API yet. It’s something many of us are hoping for. [import]uid: 49447 topic_id: 19966 reply_id: 77802[/import]
Thanks - I guess for now the only way to do this might be to multiply all vectors by 0.5 to slow it down and x2 to return to normal - I’ll have a play, but this is a real shame to not have that level of control with box2d…
Cheers,
Mal [import]uid: 13964 topic_id: 19966 reply_id: 77869[/import]
If it’s just for a quick effect, you could pause physics, make a “clone” of the scene by instantiating all new objects, etc. and then just using transitions for the “slowed down” effect. Then, when the effect is over, destroy all of those items, show the original scene and resume physics again. Or something like that.
I agree it would be a million times easier to just get access to the timestep (and other box2d settings), and this is just another good example of why.
I highly recommend chiming in on this thread, which is a feature request for exactly that:
http://developer.anscamobile.com/forum/2011/09/27/time-based-physics-implementation [import]uid: 49447 topic_id: 19966 reply_id: 77877[/import]
wow… just saw this in the latest build notes:
Physics: adds convenience methods for conversion between MKS and Corona units: physics.toMKS( unitName, value ) and physics.fromMKS( unitName, value ) to convert to MKS and from MKS units, respectively. ‘unitName’ can be “length”, “velocity”, or “angularVelocity”. Also, adds physics.setTimeStep( dt ) where ‘dt’ is in seconds. Pass ‘dt’ of 0 to get an approximate time-based physics (the error will be the desired frame interval, e.g. 1/30 sec). Pass ‘dt’ of -1 to get default behavior (frame-based).
sounds like it’s finally arrived! I can’t wait to test this out… [import]uid: 49447 topic_id: 19966 reply_id: 77952[/import]
I was just about to post here the physics.setTimeStep( dt ) news too.
[import]uid: 110373 topic_id: 19966 reply_id: 77966[/import]
Exciting news! So, does this mean… when a project’s fps is set to 30 (i.e., the project uses default fps setting) and include physics.setTimeStep( 0 ), the physics world will appear/behave very much the same as frame-based physics when there’s no lag?
Let me rephrase… let’s say, Project A uses physics.setTimeStep( 0 ), and Project B uses physics.setTimeStep( -1 ) (default), and both A and B use default fps setting of 30… would there be no visual difference between A and B when B isn’t impacted by frame-based delay?
I’m not entirely sure what “(the error will be the desired frame interval, e.g. 1/30 sec)” means, though…
Naomi [import]uid: 67217 topic_id: 19966 reply_id: 77987[/import]
Wow. If physics.setTimeStep does what I think/hope it does I will need to change my undies! It *seems* like they’ve Anscafied the whole timestep mess into an elegantly simple solution. Hopefully there will be a blog post from Walter to clarify. [import]uid: 9422 topic_id: 19966 reply_id: 78001[/import]
Cool. Just tried it. It is much better. Not perfect, but much much better.
Ben [import]uid: 28534 topic_id: 19966 reply_id: 78002[/import]
For “slow-mode” it’s now as simple as this!
[lua]physics.setTimeStep( .001 )[/lua]
Since the timestep can be set dynamically, it looks like you could even “ease-in” to the slowmode, and then ease back out of it.
Looking forward to playing with this a bit more myself! [import]uid: 49447 topic_id: 19966 reply_id: 78048[/import]
@Naomi - physics.setTimeStep( 0 ) did not work for me on test devices (iPhone4 and iPad). The result was worse than before with jerky/choppy motion and a large number of frames skipped at a time.
However physics.setTimeStep( 1/30 ) achieved what you are describing with only a very minimal amount of lag compared to before.
I have not messed with setScale in conjunction with this yet as I usually leave it at the default. [import]uid: 40137 topic_id: 19966 reply_id: 78064[/import]
Edit: @mmathias6410, I saw your post here too with additional thoughts. Appreciate it!
@mmathias6410, thank you so much for sharing your test result with physics.setTimeStep function and how you set its dt parameter. So… 1/30 results in roughly the same as rendering the position of physics objects at 30 fps. I’m wondering what fps setting you specify in your config.lua – do you use default setting of 30 fps?? I’m trying to understand why physics.setTimeStep( 0 ) exaggerated the jerky/choppy motion.
Thanks again!
Naomi [import]uid: 67217 topic_id: 19966 reply_id: 78091[/import]
Yes, fps = 30 in my config.lua.
No idea why physics.setTimeStep( 0 ) did not work well on device, but the Daily Build notes were not exactly detailed so maybe there’s more to it. [import]uid: 40137 topic_id: 19966 reply_id: 78098[/import]
In my case I’m trying to maintain 60 fps. Based on mmathias comment I tried physics.setTimeStep( 0.01666 ) (1/60) but that seemed to bring back some of the artifacts from frame based physics. i.e. - slow motion when the physics simulation can’t keep up with the framerate.
physics.setTimeStep( 0 ) actually did more of what I was expecting/hoping for from time-based physics; When the simulation can’t keep up with the framerate objects “skip” ahead to where they should be in the time passed, irregardless of framerate. As mmathias pointed out this can make the simulation look jerky, but in my case that is much preferred to the entire game going into slow-motion.
[import]uid: 9422 topic_id: 19966 reply_id: 78105[/import]
Documentation always lags the code checkin, so bear with us 
To clarify, physics.setTimeStep( -1 ) and physics.setTimeStep( 1 / fps) are equivalent. Both give you the same behavior you get by default: the physics simulation timestep is the same as the desired frame interval.
physics.setTimeStep( dt ) for positive values of ‘dt’ set the timestep in seconds (not milliseconds). Generally, this should be <= 1/fps (e.g. less than/equal to 1/30 or 1/60).
physics.setTimeStep( 0 ) gives you as close to a time-based (as opposed to frame-based) simulation as you can get. However, you’ll still get skipped frames, if the time it takes to run the simulation takes too long, so it won’t make any fundamental issues with your app go away if you already have those
Also, note that the time precision is not guaranteed, meaning it will simulate to the nearest multiple of the desired frame interval (e.g. nearest 1/30 sec for 30fps). This corresponds to the next to last algorithm in (i.e. the code snippet right *before* the “The final touch” section): http://gafferongames.com/game-physics/fix-your-timestep/ [import]uid: 26 topic_id: 19966 reply_id: 78110[/import]
Thank you so much, Walter, for taking the time to explain how this works. Appreciate it!
Naomi [import]uid: 67217 topic_id: 19966 reply_id: 78117[/import]