[BEHAVIOR] Chipmunk Physics

kmsravindra

You should be able to do it by scrolling to the object and settig the layout or layer angle to be the same as that object.

Thanks — I am trying to understand more about the utility expressions "Worldtolocal" and "localtoworld" and a use case context for the same...can you throw some light on that?

kmsravindra

Those two expressions were for use when adding joints. They aren't needed now since I since came up with a better solution.

Basically what they do is this.

"World" is just your standard xy coordinates on the layout.

"Local" is just a position relative to an object's location and rotation. If you're familiar with 3d programs the idea is similar. For example a local position of (100, 0) will always be 100 pixels in front of wherever the sprite is facing.

Good to know that! Thanks for your response.

R0J0hound

Hi! Do you know how to integrate chipmunks and rts, for units not to walk on top of each other? Thx! ***

megatronx

Probably the same way as with the physics behavior. All physics objects will push out of each other. I haven't tried it so I don't know if there is any fighting between the behaviors that might make the objects jitter.

megatronx

Probably the same way as with the physics behavior. All physics objects will push out of each other. I haven't tried it so I don't know if there is any fighting between the behaviors that might make the objects jitter.

I tired setting it up myself, but I can't get it to work. :< Units either fall or overlap each other.

megatronx

I guess it doesn't then. The solution would be to move it with physics instead of letting the pathfinder movement do it. You'll have to use the Sprite.pathfinding.nodexAt and nodeyat expressions to get the points along the path and come up with a way to move along it with physics. That way physics will be in full control of the object's motion and can keep the objects from overlapping.

That's the idea at least. I don't have any working example.

I just tried and found a way to pull the physics object, I posted it in your other thread megatronx

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.