Touching object: collision performance

I just did a weird discovery today for something I am not sure why it is applied that way.

I make isometric like levels where upon touching things the player is able to move there.

(1000+ objects on a layout)

For the Level I have various elements such as: floorslabs, stairs, etc.

I generally put these in a "clicklevel" family, and in a loop for player control I have "Is touching object" combined with distance checking from the player to the touch. (compare 2 values, distance(p.x,p.y,touch.x,touch.y) > x) (see image)

Now, when being in touch, I noticed, the mere ~10 collision check per tick goes up to ~500, causing a bit of performance dent, nothing disturbing, but a huge number in relation to the optimized ~10.

I was wondering why it goes up to ~500, so I tried some things, one of them was adding a "Is on screen" event in the "is touching" and distance check.

Suddenly my collision checks dropped from ~500 to ~80 per tick.

Why is the "Is on screen" influencing the touch event. ?

Is it because of the distance check ? It should not, because that is in relation to another object.

I would guess that the "Is touching" is taking ALL Clicklevel family objects in consideration.

And adding the Is on screen limited that ?

IF, that is the case, would this not be a weird mechanic, seeing as one would not be able to click outside of the viewport to start with ?

Unless you can actually measure a performance impact from 500 collision tests, which isn't many, then does the answer actually matter at all?

Unless you can actually measure a performance impact from 500 collision tests, which isn't many, then does the answer actually matter at all?

The debugger shows that ....

In my set up it doesnt matter ... as I optimize everything a lot ...

For many, this could be a hidden performance waste

500 a tick still isn't very much - most of them will just be instant-reject bounding box tests, which is negligable CPU time. I meant could you measure that this affected the CPU or FPS rate?

'Is on screen' will reduce the collision tests to just those instances on-screen since conditions are run in top-to-bottom order, but the "is on screen" check is probably about as expensive as the collision test, which is why I doubt it makes any material difference. You're just moving a similar amount of work to a different place which isn't measured by the "collision checks/sec" reading.

Ashley, Hmm, you are right, I just checked the processing performance, it is about the the same.

I do however notice that with it enabled I consistently get a slightly better frame rate.

Thanks for the replies

I'd be more worried with the draw the inverted is touching hud can have.

I'd be more worried with the draw the inverted is touching hud can have.

~25 checks per tick

It's been my experience that inverted used as not touching with multiple objects can really drop the fps.

A simple Boolean solves everything.

It's been my experience that inverted used as not touching with multiple objects can really drop the fps.

A simple Boolean solves everything.

Hmm, I have not experienced that, and I use the not touching thing in several situations.

In this situation the touching of the HUD objects enables/disables actions, as the objects are buttons.

With the need to leave the direction/click location, determining player angle, intact, I need that particular inverted touch there, preventing the target x,y being set if you use the HUD buttons.

Couldn't trigger once stop it once it first become true for that object??

If not touching trigger once while true?

Couldn't trigger once stop it once it first become true for that object??

If not touching trigger once while true?

Nope, the player has the ability to continually hold down the touch/mouse and the player and will continue to walk in that direction and angle

Really I am trying to still figure out what places trigger once work and don't work

Really I am trying to still figure out what places trigger once work and don't work

Quite a few actually.

During an event that potentially runs continuously, which needs an action executed just once, sub event it with a trigger once.