Whenever I get stuck on a maths problem I search the forum for "problemname" & author="R0J0hound", & usually find my answer

The last example he posted here might be helpful:

As long as your sprites are all orthogonal you could use the isOverlappingAtOffset tests on lines 7-10 to work out which way to mirror the current velocity, & it should work even if you hit a corner.

CrudeMik About optimizing collisions, read this: https://www.scirra.com/blog/ashley/6/co ... on-in-r155

IsOverlapping & OnCollision both use collision cell optimization, so there's no need to filter down the number of checked instances. From that blog: "If Is overlapping (or On collision) comes after another condition which has picked certain instances, it can no longer use collision cells."

In the events you've shown, the 'asteroids OnCollision with ass_destroyer' is fine, but as you said the 'family asteroids IsOverlapping family asteroids' is expensive if it runs every tick. But I think you've only got that happening at the start. So I'm not sure where the problem is.

I dunno, I'm sure its possible but then you'd need 2 layers per fragment which can't be good. Why not just make a vector prototype, then move on to unity or another engine later if it's any good. For textures, i think an engine with normal mapping is a must.

Just noticed the gif with textures, very nice. So when you blow up an asteroid, you're spawning random chunks? Probably the best approach, but might cause physics spazzing if sprites are overlapping. This might be an interesting approach, needs to be vector though (using the canvas & polygon plugins):

[attachment=0:32ryo0h2]Untitled-1-01.png[/attachment:32ryo0h2]

It'd be nice if a neighbor-sensitive sprite thing was possible: http://www.saltgames.com/2010/a-bitwise ... -tilemaps/

Each asteroid would be like a floating tilemap/array of sprites. Probably impossible in c2 though, especially for collisions.

Crudemik - great stuff, but you can move development back from unity now we have better physics

R0J0hound does the javascript port of chipmunk have the autogeometry feature?

I would do this: for each projectile, test if it's current array/tilemap/grid square contains a block; if a block exists, then do an overlap test (with only that block) so you can check for the triangle shapes.

Got it Rojo, that makes sense & it works now. I think Chipmunk could do with a new 'bond' or 'superglue' joint which uses the pivot/gear combo.

CrudeMik - that's not grappling. THIS is grappling <img src="{SMILIES_PATH}/icon_e_wink.gif" alt=";)" title="Wink">

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

Seems you're the only one I'm in there most evenings if you need a tester, but as a regular weekly day/time what would be best for you?

Roid rage I had a go at making something like this & also had trouble with joints. I think I found a bug too, so...

R0J0hound check out the capx below (sorry for not simplifying it). If you enable event 3 then the ContactPointX/Y expressions in event 21 don't seem to work (the hull_damage sprite gets spawned off screen somewhere).

Strangely this happens if you put any actions in the foreach asteroid event.

Also the pin joint doesn't work as expected. Instead you get a freely rotating pivot. Maybe this is how chipmunk works & you need 2 pins to lock a pair of objects together?

So If I understand well your message I can do something like this :

Create a two dimensional array with a width about 100 and a height about 60, then I fill this array with my block X and Y coordinates and I set the block UID at this index.

Then I can do : block pick by UID = (array.at(someX,someY)) ?

And that would work with the expected performances ?

You only need to fill the array with the block UIDs. You choose which array element to set according to the blocks xy position, using something like this:

[attachment=0:znm5miv9][/attachment:znm5miv9]

For performance, as rojo explained you eliminate the need for many (many as in 16 million ) comparisons. Providing this is a desktop game you should be fine, mobiles maybe not.

So it'd be just like working with a tilemap & you'd be using equivalent expressions to tilemap's 'tileToPositionX/Y' & 'positionToTileX/Y'.

tileToPositionX's equivalent would be something like: (array.x * gridsize) + (gridsize/2)

positionToTileX would be like in the image above: floor(block.x/gridsize)

here you go:

EDIT - don't use dt

[attachment=0:yk7uh39h][/attachment:yk7uh39h]

I've been enjoying watching your prototypes & love the sound design in all of them (Attract especially, which I tried to rip-off until discovering that keyboards don't like multiple keypresses).

If you wanted to make your game fully procedural, you could try Yann's polygon plugin - - to generate the asteroids. That would also allow you to split them, which might make an interesting mechanic where you use the laser to carve up specific shapes.

Other ideas:

-let the player zoom out to a macro view & see what's in the neighborhood for planning (fuel, collision interactions).

-have some global affector to the levels like a swirling gravitational field (like the orbit levels in osmos), or a neaby sun where you use line of sight to heat the ships, & shadow casting to see where the cool spots are.

-if this is physics based then i recommend rojo's chipmunk plugin over the native one - it lets you do raycasting, query individual collision points, make any kind of joint...