So I’ve been messing around with Codea’s physics engine and what I’ve noticed is that it only updates at the beginning of the draw function. My question is if there is any way to force a physics update instead of having to wait till the end of draw().
@CyborgSquirrel The draw function runs at 60 times per second and so does the physics engine. You can adjust physics.iterations to change how things work, but you won’t see any change until the draw function executes. What are you trying to do that you want to alter the physics engine. To answer your question, you can’t manually update the physics engine.
Well, I’ve been trying to make an “evolution simulator” type program just like this guy https://youtu.be/GOFws_hhZs8 did in processing with the help of Codea’s physics engine. The problem with that is that there doesn’t seem to be any way to speed the physics updates up, which means that if I ever want to see any evolution happen, I need to wait for agesss… I guess the only way out is to either write my own physics engine(probably not happening), find a physics engine on the internet, rise the maximum frame rate of the program somehow or give up.
@CyborgSquirrel I watched your video and I’m not sure what each of those creatures are trying to do. I assume they’re moving under some kind of rule based on their connections. It’s possible you don’t need to use the physics engine since I don’t see how they’re reacting to each other. Without understanding what’s happening or what’s supposed to happen, I can’t give you more information. But with Codea running at 60 iterations per second, I think it should be more than fast enough.
@CyborgSquirrel We could potentially support this with some kind of timeScale() function which would allow you to speed up or slow down the simulation speed of Codea. So if you set it to 10 you would run Codea at 10x the speed (still 60fps but it would attempt to do 10 physics steps and DeltaTime would be 10 times as big each frame).
This would need to be added in a future update though.
@John Isn’t that what physics.iterations does. You can change the number of velocity and/or position iterations per time step. The default is 10 (velocity) and 8 (position). So if you set it to 100 and 80, wouldn’t that be like running it at 10x.
@John After rereading the documentation, I was thinking this backwards. Physics.iterations doesn’t increase the speed of the time step, just how many calculations it does in a time step.
As @John says, you’d need an api to adjust the scale, I dug into the export to xcode and box 2d stuff from a similar question back in 2014 and wrote this comment at the time:
Looking in the Codea runtime it looks like what it does is pass in the DeltaTime (time for the frame), then the physics engine will do a 1/60 step how ever many times it needs to catch up to the deltatime (ie if framerate is currently slower that 60fps it’ll sometimes do 2 or more steps). So it’s locked to the speed of time on the ipad.
@Simeon I guess what TLL could consider is allowing you to set a physics parameter which gives a multiplier to deltatime when it’s accumulating in the PhysicsManager. That way rather than controlling step, you’d having a setting of 1.0 ie realtime, but you could change it to 5.0 being 5x realtime etc. It’d still do physics steps at 1/60s so the accuracy would be the same, it’d just slow processing. And the current iterations feature could let you drop accuracy for speed.
Of course that’s based on the old runtimes, but I presume the new exports/Codea itself are similar under the hood.
So based on that setting a timescale would effectively just throw a multiplier onto the feed of DeltaTime into the Box2d time accumulator…
I play some Kerbal Space Program and I think that’s how their time acceleration works, and as you step it up you start getting inaccuracy and weirdness because they reduce their equivalent of the iterations (step size). (That is until non physics time warp which is then a totally different beast).