Question about pick [sprite] vs tilemap

That's quite interesting. Can you attach the two capx ?

About my project, I'm now trying to stick to tilemaps (and arrays to store additionnal informations for each tile) rather than spawning some blocks. I'm not sure yet which method I'll use.

If I use some sprites only for destroyed blocks (just to set a timer behavior and maybe one or two variables), I'll have I think 100; 200 or 300 sprites at the same time instead of 4000 so it could be fast enough.

Storing my data (including my timers for each destroyed tile) into an array would, I think, give better performances, thought it's more complicated to handle with events.

I'll try to do some tests with both methods.

That's quite interesting. Can you attach the two capx ?

Its just a single CAPX, you just have to enable/disable different parts. I added commentary to it, so you can see which one controls what. Not that its that hard to figure out. But just so you don't think both should be enable at the same time.

[attachment=0:fokh2r5m][/attachment:fokh2r5m]

Another solution that might work if you need sprite objects, is to create them when something interact with them, and that way you replace the tiles with objects. That way you can probably reduce the amount of objects needed at one given time.

That's cool.

Do you know why the overlap events is faster than the collision one ?

Aside from this, I made three tests about my stuff with tiles (6480).

When the left mouse button is down, it constantly destroys the tiles in a 6 tiles radius and set a timer for each tile, which value depending how far the tile is from the mouse coordinates.

1) Only with a small array : I fill an array when clicking and set my timers in it. When a tile respawns, its reference is removed from the array. Worst performances.

2) With sprites spawned only when a tile is destroyed. Sprites contains each destroyed tiles timer and they are picked up regarding their XY coordinates (the same as the current tile). Bad performances, not as much as the array solution.

3) With sprites as the previous ones but with a big array, as the sprites UID are stored in it and so they are picked up by UID. Excellent performances.

That's cool.

Do you know why the overlap events is faster than the collision one ?

To be honest, I have no clue according to the manual, even though its not an in-depth explanation they should do the exact same thing.

But did a test of "On collision", "Overlapping" and "Overlapping with optimization" all screenshots are taken after its started so it changes a little bit up and down.

As you can see, the "on collision" and "Overlapping" is practically the same in the one named "Low object count", however the CPU util and FPS is highly different. Strangely enough if you look at the Collision checks /sec, its only 43513 for the "On collision" while its 80812 for the "Overlapping" even though the approx. collision checks per tick is higher for "On collision" than overlapping. Regarding the optimized one, there is not a lot to add, think the numbers speaks for it self, and it have no problems with such a low number of objects.

On the "High object count" however things goes really from for "On collision" the performance was so bad, that it couldn't even register the amount of collision checks. However the CPU again goes to max and the FPS drops massively. Where as the "Is overlapping" gives a lot better performance, however still uses a lot of CPU and also take a quite big hit to the FPS. And with the "optimized" version it is barely noticeable, except it also uses a lot of CPU, however it doesn't hurt performance FPS wise.

So what exactly is going on with the "On collision" I don't know, because I would assume that "Is overlapping" is doing the same amount of checks as it does, at least according to the manual. And the optimized version as you know, is based on that it only cares about which object it can collide with that are also the closest, so it logically reduces the amount of checks needed to be made each ticks by a lot.

But would probably need Ashley to explain it, because I don't think its possible to find the answer in the manual at least. So its just something to be aware of I think, if performance drops, you should make sure to at least not use "On collision"