Tilemap Collision Checks [r160.2]

Link to .capx file (required! If link is blocked remove the http and www parts):

dl.dropboxusercontent.com/u/23075162/TileCollisionExample.capx

Steps to reproduce:

1. Make a tilemap with the solid behavior, and a single square object with platform behavior.

2. Create some tiles as terrain, and give the tile you are using a custom collision poly (I used a smaller rectangle.)

3. Run the game in debug mode.

Observed result:

The collision count in the debugger gets extremely high, over 50,000 collisions per second while moving, and ~8000 while still. It is registering over 600 collision tests per tic, when there is only one object for the tilemap to test against. The tilemap may be trying to collide with itself?

Expected result:

The collision count should be much lower - when not using a custom poly for the tile, it sits at around 67/tic.

Browsers affected:

Chrome: yes

Firefox: yes

Operating system & service pack:

Windows 7 64-bit

Construct 2 version:

R160.2

Closing as not a bug:

• everything happens within one collision cell, so the collision checks cannot be further reduced
• you have set a custom collision poly on the tile. This means the tilemap object cannot optimise any of the collision checks and is forced to run tile-by-tile collision checks. You have around 100 tiles, so every collision test must run 100 checks, whereas without a custom poly it could check just 9 rectangles.

Turn off the custom poly and it does 10 times fewer checks. Don't use custom polys where you don't need them!

I'll avoid using these in my project for now, but there's clearly something weird going on beyond just brute-forcing the collisions. In the example capX there is only one sprite object and around 100 tiles, but it's running over 600 checks per tic.

So either the tiles in the tilemap are checking against themselves, or they're checking against the single sprite object six times. Either way, something is off?

I'll avoid using these in my project for now, but it still doesn't seem like the current behavior is working quite right.