[Request] BBox intersect detection.

I use BBox quite regularly and It would be nice to see a plugin that handles BBox instead of only XY and collision boxes. I'd gladly donate or pay for some neat BBox tools.

Practical uses.

Detecting overlap of objects.

Sometimes you don't want use the regular collision boxes to detect overlap. BBox can come very handy then. I use it all the time, but current the event sheet way is not very friendly way of do it, as it involves a very heavy piece of code, and I'm pretty sure a plugin/behaviour would handle that much better. Currently I'm doing this:

Pick by evaluate: Sprite1.BboxLeft < Sprite2.BboxRight & Sprite1.BboxRight > Sprite2.BBoxLeft & Sprite1.BboxTop < Sprite2.BboxBottom & Sprite1.BboxBottom > Sprite2.BBoxTop.

It would be nice to be able to both pick any overlapping sprites, or just detect any overlap and return true without picking.

I don't know if it's possible, but it would be good if you could even detect overlap on sprites within a family, only checking against other sprites within the family, as I havn't figured out a way to do that using events. You can't check family1 against family1 as it's always true, checking against itself.

I found this piece of code but don't know is useful: I wouldn't even know where to start to make a behaviour myself. Otherwize i would do it.

var overlap = !(rect1.right < rect2.left ||

rect1.left > rect2.right ||

rect1.bottom < rect2.top ||

rect1.top > rect2.bottom)

Any help appreciated and would have gladly pay for it, if you give me a reasonable price for the request.

What's wrong with the built-in collision system? It does that kind of check internally, but even faster, because it uses collision cells.

Ashley Sometimes you have a collision polygon set at a certain shape for some reason, and want to detect a sprite overlap, but they don't detect because the collision polygons are not completely square at the Sprite edges. An ugly workaround - Create another sprite on top with a Square collision box pin it to the object, and wholla! you've doubled the spritecount, and icreased collision checks. I find BBox very useful also, since you can't really get X &Y positions of idividual collision polygon points.

Index based multiple collision boxes per object could also work. That may be even better.

sprite1.colBox(0) is overlapping sprite2.colBox(2)

EDIT: To explain further one of the main uses could be for z-Ordering. Instead of having Zorder to run every tick it would seem smart if you could have it trigger once only on any BBox overlap. For me et least on developing for mobile Zordering is one of my main resource hogs at the moment, so I would like to bring it down further to allow for other good stuff instead.

For now this chunk of events was the most resource friendly way I could do it, and it's just slightly better than running the zOrder every tick. What it does: If there's any moving objects on screen, first picks within radius (Line of sight is supercheap distance picking), then Checks BBox overlap, and then if any BBox overlap is off in Zorder (higher Y but lower Z or opposite) then trigger the Zorder Once.

I sort on average once every 2-5 seconds (if there is any overlap/zorder that needs fixing), but the whole event chain there is just slightly cheaper than running Zorder every tick.

Create another sprite on top with a Square collision box pin it to the object

This is our officially recommended workaround to needing multiple collision polygons, and uses the existing collision engine which is well-optimised, so I think you may as well do that.

[quote:2jq29n0f]For me et least on developing for mobile Zordering is one of my main resource hogs at the moment, so I would like to bring it down further to allow for other good stuff instead.

Have you tried the new "Sort Z order" action in the latest beta? That should be significantly faster than previous approaches.

This is our officially recommended workaround to needing multiple collision polygons, and uses the existing collision engine which is well-optimised, so I think you may as well do that.

I havn't tested this yet, but I will try it out, to see if I get any improvements I don't know if it would be a mobile friendly approach.

[quote:3all9cg9]

Have you tried the new "Sort Z order" action in the latest beta? That should be significantly faster than previous approaches.

Yep that's what I'm working against to beat. Even the new improved zOrdering it's still my 3rd biggest resource hog on Mobile, after Draw Calls and engine, so I'm trying to optimize it further. I would approximate it's using around 15-20% of the entire game logic. (Not counting draw calls and engine)

Turning off Z-ordering completely gives me around that much less CPU usage for the event sheet, so for me 20% just for sorting is still unacceptable. I would be a happy man if I could get it down to let's say <5-10%.

My game is still running extremely well, on midrange phones at almost constant 60fps, but I'm not done yet and still have some things to add, because I'm working on the limit of what a midrange phone can handle, I would be happy to cut the cost of the zOrdering even further.

If i understand correct, 'System > Z order' adresses only the picked objects.

So, you should be able to pick player & objects in an area arround the player, and that should make the z-ordening drastecaly faster.

True ?

99Instances2Go System > Z order only set's a global value.

When the global value is 1. I'm running the new action Sort Z order by : variable and then setting global value to 0 again, so I'm only sorting 1 tick.

The main thing is actually the the lower part of the event chain, detecting if something with a High Y has lower Z order or oppisite. That tells me that it's not sorted correctly. And will set the global value to 1, to initate the sort. But running only that little check is so heavy on performance that i have to filter it this way first with the whole event chain first :p that's where BBox comes in, If the BBoxCheck is false, it's not even gonna go ahead with the Y vs Z check.

I'm trying to limit the ammounts of Y vs Z checks to only check objects that are actually overlapping any moving objects. If i checked the Y vs Z for everything on screen I'm using way too much resources to be useful. I only need to check the Y vs Z for any moving objects that are overlapping any other object in the Zorder family.

In my mind the optimal way to sort Z order would be.

1. Detect overlap between moving objects and objects in the zOrder family. if there's any overlap ...

2. Check if any of those overlaps are sorted incorrectly. object 1.Y < object2.Y but object1.Z > object2.Z (not sorted correctly sorting).. so

3. Pick overlapping objects, and sort them correctly.

You don't need to pick or even bother to sort anything that is not overalpping, and you only need to sort 1 tick if there is any error in sorting, not every tick.

That's what I'm trying to achieve, but doing it with event's is just slightly cheaper than having the new zOrder run every tick.

The problem (in my eyes & opinion) in 'that' is the 'overlap' check with a family.

Speaking about the loops behind the scenes.

(i know you know all that, so excuse me for building the argument from nothing)

I you check an object overlapping a bunch of other objects, then you actualy start a loop (simular to 'for each) that evaluates each object in that bunch and ads/substracts that object (member of a family/instance) to/from the SOL.

So, first off, there is a loop. And using a family, that loop can get big. On top, if you check overlap between an instance/famely and another instance/famely, that loop is a nested loop. Evaluating 10 instances with 10 instances gives you allready an iteration of 100, just to check the overlaps.

Besides that, checking 1 overlap is also no more then a loop. It runs trough the boundarys and checks that with the other boundarys.

As a result, checking overlaps (but also collissions) is a time consuming thing, and in your case, it can even be slower then just z-order the whole darn layer.

What i suggested is a bit differend in some ways.

Pick a bunch of objects with a 'pick by comparing' based on distance loops also trough the whole family, but without the 'overlap loop'. It is fast. The filterd SOL is also done only once, You perform the same loop when you actual do the z-ordening, in probaly the same tick.

With only a few objects in the SOL, the z-ordening is awwsome fast. Even every tick should not have a big impact.

Hope i made my point, the general point, i have no idea if that is applicable in your project.

What i suggested is a bit differend in some ways.

Pick a bunch of objects with a 'pick by comparing' based on distance loops also trough the whole family, but without the 'overlap loop'. It is fast. The filterd SOL is also done only once, You perform the same loop when you actual do the z-ordening, in probaly the same tick.

With only a few objects in the SOL, the z-ordening is awwsome fast. Even every tick should not have a big impact.

Hope i made my point, the general point, i have no idea if that is applicable in your project.

I've tried all kind of approaches. So far, the current list of events in my previous post, seems to be the cheapest way i could do it, but it's not cheap enough.

Just using:

"is On Screen" -> Sort Z order by "variable" every tick

Is just slightly more heavy than my overlap approach. (Thanks to LOS Behaviour, which is super cheap for filtering by distance, faster than any event condition approach)

I'm gonna try out the workaround approach as well, using dummy objects, to see if it's any better. But for now. 15-20% of my game mechanics just for handling z-ordering just feels too much for mobile. There must be a smarter cheaper way :p

By try and error we fall and run.