[BEHAVIOR] Chipmunk Physics

Here's an example that might be handy for anyone making a physics platformer using Chipmunk. It's something I made to try out puzzle mechanics & has a few issues, but it might be worth dissecting to see eg. how 1-way collisions are now possible after rojo's update last week:

https://dl.dropboxusercontent.com/u/523 ... pe_v2.capx

EDIT - tweaked movement to be more like the stock platform behavior

You shouldn't need to use dt anywhere. A fixed timestep of 1/30 is the timestep used per frame. So if the game is running at 60fps then after 60 frames the physics will be 2 seconds along compared to the actual 1 second.

You can specify a variable timestep but that isn't so good with physics, so a fixed timestep is recommended. The drawback is the physics can run faster/slower depending on the screen refresh rate, aka it's not framerate independent. That said you could detect the fps of the game when it starts and set the timestep based on that.

Do I understand this correctly.

If i set my game/level to start with

On start of layout

Stepping mode - Fixed

Fixed timestep - 1/fps

The physics will run at same speed on screens with different refresh rates?

If I leave it at the standard 1/30 does that mean someone with higher fps can finish the level faster?

Giganten

It should, although I'm not sure if "fps" will have a good value at that point. You could wait a second or so first first.

Just leaving the timestep at 1/30 means if the refresh rate is 120 the physics will run twice as fast than if the refresh rate were 60.

Isn't the monitor refresh rate different than fps?

"FPS = Frames per Second = How many distinct images a GPU outputs, per second

Refresh Rate = Number of times a screen is capable of DISPLAYING, per second"

Shouldn't the physics simulation run exactly the same if both are running at 60fps, except one monitor is 60Hz while another is 120Hz?

Prominent

It's the same as far as I know. The browser could cap the fps, but I don't know since I've only ever used 60hz displays.

I found an error:

I get assertion failed: internal error: attempting to set body's angle to NaN: line 52 col 3.

When I tried to add a dampened rotary joint between to physics objects.

Both objects had their rotation disabled. I enabled one object's rotation and the error went away.. So maybe it doesn't need fixing since having a rotary joint between objects that shouldn't rotate wouldn't make sense anyways.

Thought I would mention it though.

R0J0hound , Is there a way to pick a joint based on its index?

For example, I want to loop from 0 to (Chipmunk.jointCount-1), and then pick an object by uid based on Chipmunk.jointOtherUID(loopindex). I tried this, and doesn't seem to work.

I don't really want to have to store a list of joints an object has if I could just cycle through them based on their index.

Prominent

That should work. I'll have to look at it tomorrow to see why it doesn't.

R0J0hound ,

here is a capx showing the problem in a simple scenario.

edit: here's a new capx: http://1drv.ms/1R5XwJ6

edit: it seems to not work if it is inside a post-collide. It works outside of it though. I need a way to do it inside the post-collide- I'm assuming it is a bug?

edit2: also, I just noticed in this case it adds the joint twice since the collision events run for both objects that collide.. If I try to add a condition to check if a joint was added(so that it won't add another), it won't find that joint so it will add the extra joint anyways. I think this is related to the joints being updated at the end of the event cycle. If there were a way to update the joint list sooner or something, it would make things easier to manage.

Prominent

It only doesn't work for joints that were just added in a post collide. It has to do with chipmunk not allowing anything to be added or removed during a pre or post collide, so instead the plugin delays it slightly. The unfortunate drawback is it causes a lot of bugs related to stuff just added in those triggers.

I don't have a simple fix for it, so it's an open issue for now.

R0J0hound , thanks for the explanation. I was looking through your code trying to understand how things connect.

Have you thought about making a tutorial on how to port an existing library to a construct2 plugin/behavior? I'd be really interested, even if it is something simple- just to show how to integrate someone else's code with construct's.

Prominent

I started a topic here about a way to use a third party library without writing a plugin:

There are pros and cons of doing it that way. A pro is you can access everything a library has to offer instead of going through a wrapper that may not allow everything. A con is you're limited to what you can access from events.

Actually making a plugin is similar, but you have to design the ACE's in a way that's usable for C2.

Ah cool, I never thought of doing something like that. Wasn't what I had in mind, but I'll have to try this method out sometime.

Are there any examples of switching between chipmunk physics and standard platform behavior (for player character) as needed? Is this feasible or is it just best to forget it and stick with either no physics at all or try to build everything with physics objects and have them enabled all the time?

Waltuo

I'd recommend just using physics, but you could try it. Whenever you switch between the two be sure to set the velocities from the other behavior.