HitTest with transparent pngs.

bryanv

From what I can tell there is no way to ignore touches on the transparent portion of a png. This is making development pretty tough. I've seen someone suggest making polygons and doing a point test against those but the overhead for that is unreasonable. Can we expect to see a better solution to this problem soon?

GregBUG

tnt collision system... soon... avaible ....

techdojo

@bryanv - There's no guarantee that a copy of the image will exist in memory, it might just get loaded directly into VRAM and then the local copy removed.

If this is something that is vital to your app, then ideally you'd need to export any images you want to check as raw data (ie not compressed like .PNG's) so that you can create your own local "map" and then just pick up the individual element yourself.

You could probably make the process even easier by pre-processing the image down to an 8bit byte per pixel image before exporting it and then using a fixed value (usually 0) to represent an empty pixel in the image.

bryanv

Ah, so I could simplify an image to a black and white bitmap and read this file as data into an array and check that way. Although I could do this as a batch process, it is still not ideal. It would be great to have Gideros support transparent hit tests. I've seen quite a few requests for it, how can we get this feature towards the top of the backlog?

techdojo

I think @GregBUG's collision engine would probably be a better choice for you.

bryanv

I'll look into it, but the feature I'm requesting is fairly common in most SDKs. I think it would save people a lot of work.

techdojo

To be fair - I don't think it is that common, since the vast majority of rendering takes place in hardware these days and it's generally accepted that texture atlases are the way to go it's rare you'll see a raw bitmap left lying around in main memory (at least not in any system that values efficiency anyway) when it's not needed.

I have seen it in a couple of flash engines but that's software rendering.

This is why most "old skool" 2D game programmers would just use a bounding box that's slightly smaller than their sprite to give the "illusion" of a decent collision which in the vast majority of cases would be good enough and efficient enough to keep the frame rate up.

What's your specific need for this - maybe someone can suggest a different way to handle the problem?