[BEHAVIOR] Chipmunk Physics

R0J0hound

Is it possible to make a physics behavior based game for mobile using your plugin? I'm asking you that because Box2D has a poor performance for mobiles and I just discovered that now :/

Prominent

For the line collision type I'm thinking I'll have the start of the line will be the left-center of the object and the end will be the right-center. That will also take care of the visualization since Behaviors can't draw anything.

—

It should be just as possible as using box2d. That being said I don't know how this compares to box2d in performance on mobile devices.

Prominent

[quote:3dpc5daj]edit2: been trying to use it, but adding forces to objects seems to mess things up. their points seem to become displaced and move all over inaccurate from the object.. weird... :\

Can you provide a capx that does this, I can't reproduce it. It's working here for me.

R0J0hound , here's a capx. don't get confused by the collisions looking off(the polygons are set in a bit on the squares).. But when you just press the up arrow key and allow the player to collide with a box, afterwards, when you try going forwards, the direction is all off-kilter and wobbly so you can no longer go forwards..

[attachment=0:1ty8o84e][/attachment:1ty8o84e]

as for the line thing, that sounds good with the start at left-center and end at right-center, I do that when I have to make lines with sprites anyways, so it makes sense.

—

It should be just as possible as using box2d. That being said I don't know how this compares to box2d in performance on mobile devices.

So mobile devices aren't your goal? Because, regarding to performance, Box2d isn't that great.

—

Mobile devices are not a goal, but there's no reason why it shouldn't work there. My target is first getting all the features working well first with a good design for the events. If i encounter any major problems I'll try to adress them as they come up, and every export platform should benefit from it.

—

Mobile devices are not a goal, but there's no reason why it shouldn't work there. My target is first getting all the features working well first with a good design for the events. If i encounter any major problems I'll try to adress them as they come up, and every export platform should benefit from it.

Alright, thanks for the answer.

Your Behavior is powerful, indeed it will be useful, I'm new to Construct 2, but since I have problem with the XML/AJAX load file plugin which that seems be unable to workaround, I will certainly go back to my old Game Making software..

By the way, thanks for your excellent mods !

Update #7

+Added segment shape

note: no segment/segment collisions possible. This is a limitation of Chipmunk 6.1.1

note2: "segment shape radius" can be positive or negative. If it's positive rounded endcaps are added to either side. If it's negative the endcaps do not extend pass the width of the object.

+Added segment shape radius property.

+Added more expressions:

segmentRadius, area,

comx, comy (center of mass)

+Added descriptions for all the ACEs and change the names of the query conditions to make more sense.

+Bugfixes for:

• polor vectors were treating angles like radians. They needed to be converted in the behavior.

  Prominent

negative or zero sized objects

a few things with changing the mass and making immovable.

some other things I forgot to write down.

-cheers everyone

R0J0hound , been trying out the new version. Seems as if it no longer pins objects together correctly. I try add pin joint, with x y location of where the pin should be based upon object.imagepointX-object.x, but it isn't accurate..

edit: i'm doing more tests.. might be my code since it works with simpler situations.

Prominent

The relative positions for the joints is relative as if the object was unrotated. so if the object's angle was 90 degrees a relative offset of rect(10, 0) would be (sprite.x, sprite.y+90). But also keep in mind as the sprite rotates the point will adjust. I wonder if I should make the offset relative to the sprite's current angle. It might be a bit more intuitive.

R0J0hound , hmm.. I think that is confusing. Here's what I'm trying to do:

[attachment=0:3dm1cfar][/attachment:3dm1cfar]

Basically join objects together if their imagepoints are close enough..

If the joints are being added as if they're at an angle of 0 instead of the current angle, then I'm not sure how to do that easily. I'd have to somehow calculate where the imagepointX would be based upon how many degrees off from zero the object is. Seems like a lot of extra calculations.

Edit: btw, the capx shows that it's not working how I'd expect it to. If you could help me figure out how to make it work, that would be cool.

I think a pivot joint would work better than a pin. You can try the "add pivot joint at xy" action with parameters:

Family2.uid

Family1.ImagePointX(loopindex("points"))

Family1.ImagePointY(loopindex("points"))

Every other joint uses relative locations but that one uses a layout location. I think I'll add a "layout2relative" expression so we can use layout locations for the other joints if needed.

Also according to the chipmunk forums a good way to join objects together is with two joints, a pivot and a gear joint (with a 1.0 ratio). I modified your capx to do that, also for the gear joint it needs a phase of Family2.Angle-Family1.Angle to keep the angle difference of the objects.

Update #8

+Added world2local and local2world expressions to convert coordinates.

+Fixed a few typos in the ACEs

Prominent

Here's another tweak of your capx using the new conversion expressions. There still is some joint fighting when there is more than 1 joint between two objects that can cause the objects to move on their own.

R0J0hound , that looks much improved- can actually see them connecting correctly. Yea, the joint fighting is pretty bad, hope that can be solved. Is that something you'd need to address with how chipmunk is implemented?

edit: actually.. I tried moving all the imagepoints outwards 1 pixel on each sprite so that the polygons won't touch when attached, and it got rid of the fighting syndrome. Works perfectly like this. There's a visible gap between objects, but that can be solved by moving the polygon points inwards instead of moving the imagepoints I think..

Do you know why it would act crazy if the polygons touch? I'm wondering if that is something that needs solving even though this approach works.

Also, it's cool seeing your changes to the events, I saw some new ways of doing things that I hadn't seen before which will make my life easier.