— le Canapin I think you should rewrite this to use tilemap for everything. Your slowdowns are probably to do with having separate sprite instances for each block.

As a quick fix, you could try replacing the 'pick by evaluate' condition in your 'getblocksinradius' function with something like 'block is overlapping explosion' (collision testing is probably more efficient than evaluating an expression for each block instance).

But still I think you need to be using only a single tilemap, not lots of sprites. If I get time later I'll make a capx to test this...

Nice system. The performance should be fine, just loop through the tiles in a square that bounds your explosion radius. You could have a set of jagged-edge sprites around the holes instead of slopes, & could probably get away with a larger tile size in that case (since you're faking extra detail & won't see squares).

Leaufai this might help: http://chipmunk-physics.net/forum/viewt ... f=1&t=1660

I'm often in need of some fresh eyes on a control scheme or level that I'm working on, & with playtesting I find a chatroom to be a better venue for feedback & discussion than a forum.

So is anyone interested in arranging a regular time each week for testing their games or seeing what other c2 users are up to in the chat?

I'd propose sunday afternoon or evening UTC (which would be after midday EST). What do you think?

The irc chat is here:

with an irc client: irc://irc.esper.net/construct

from your browser: http://client00.chat.mibbit.com/?server ... 3construct

Chipmunk starts to use more cpu as the balls settle (which they shouldn't be doing). The settling becomes more pronounced as the object count increases.

Chipmunk's default settings for putting an object to sleep seem too aggressive. I sometimes get floating physics sprites when an object underneath is knocked away, worse for circle collision shapes since their contact area is lower.

A fix is to adjust idle speed threshold and/or sleep time threshold. Maybe try an idle speed threshold of 0.5s at first. If things are still settling too soon then lower it, or try a sleep time threshold of 2s.

You can disable sleeping altogether by setting sleep time threshold to 'Infinity'.

R0J0hound - the collisions in chipmunk seem more imprecise than c2's physics. I noticed the 'set fixed timestep' action defaults to 1/30, so does this mean the physics calculations are being done around every 2nd frame?

The capx shows what i mean - the red box with chipmunk clips into the floor on collision then moves back up, while the c2 physics box just stops dead:

Your demo is playable on desktop too with only a few glitches, & I think it's going to make a great mobile game. I was compelled enough to play through all the levels which were well-designed & ramp up in difficulty nicely. Some ideas:

• The immovable metal crates could be more visually distinct from the wooden moveable crates. Maybe make them look more like parts of the scenery, like girders or rock, & less like crates.

• Are you going to add a destruction effect when you click on something? That would make clicking much more satisfying & fit with the mining theme.

• As an extra mechanic, how about explosive crates that explode if you destroy an adjacent object? I know you've already got the skulls as things to avoid, but some TNT crates could also play a role in solving the levels (by moving things from their physics impulse) as well as being obstacles.

That could be it, I can't see it though - I found another solution that seems to work so my brain has given up on me I appreciate the idea though.

What I'm doing is storing the rope's start & end positions for the last frame, then when it overlaps a collision box I lerp a ray backwards from the rope to its previous position. Once the ray isn't overlapping the box & is overlapping a corner test sprite, you pick that corner (or if there's more than one, pick the closest to the rope's start).

With some optimized lerping, it never takes more than 5 loop steps to find the corner, even over large distances.

R0J0hound this is brilliant, exactly what i'm after, thank you!

Prominent you might already have tried these, but for checking internal points there's the Pick overlapping point condition, & for moving them back out the Custom Movement behavior has lots of 'push out solid' options.

Here's an example of what I'm using it for (excuse the bugs):

https://dl.dropboxusercontent.com/u/523 ... index.html

At the moment you can only hook the green boxes while stationary, but I'd like to be able to have 2 moving objects hooked together.

I'm using a simple method to detect when a swinging rope should wrap around a solid, shown in the topmost image below:

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

note - you'll have to scroll down to see the 2nd example

After the rope collides, a corner tester sprite is placed at each corner of each overlapping solid, & its angle is set away from the pivot. Then it's just a case of picking the corner whose angle most opposes the swing direction, eg. if the rope swings anticlockwise you pick the sprite angled most clockwise to the rope.

This works for a fixed pivot, but if you have a pair of freely moving physics objects linked together then the above rule no longer applies. In the lower picture imagine the dotted grey lines as the rope's position last frame. They show situations where the rope could intersect while rotating clockwise or anticlockwise, but the same corner as in the top picture would be the wrap point.

I've been trying to think of some collision rules as elegant as the first situation but can't come up with anything. Any ideas?

R0J0hound - a couple of things:

1. Are the single contact points of the green boxes below an expected behavior?

[attachment=1:3pql80c7][/attachment:3pql80c7]

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

2. Could you give a quick explanation or example of how to use the hexadecimal numbers for collision layers?

Thanks