Physics: No PNG support. :(

[Ryan]

If all pixels are semi-transparent
- build a collision box based on the semi-transparent pixels
Else
- build a collision box based on only the non-transparent pixels

Or have a checkbox in the objects properties: include semi-transparency in object boundaries

Anyone working with pngs currently has to come up with messy workarounds, I know it might be harsh but if Clickteam did think of it they didn't think it was important enough to fix before the launch of Fusion 2.5. IF they tried building a game using PNGs they would experience the need for this kind of feature. By not putting thought into it maybe I should have said they "didn't but much thought into it from a user's perspective".

[Simon]

Well that's a reasonable suggestion, but it's not what you said to begin with is it! You didn't suggest a feature with an alternative, just one absolute setting in the opposite direction to the current situation.

Fusion should only use non-transparent zones for it's collision detection.

[Ryan]

I agree, my thoughts weren't with the users who want collision boxes on semi-transparent objects.

I think any developer would start with wanting collisions on non-transparent objects, then occasionally wanting semi-transparent objects. Therefore the first immediate need is support for non-transparent objects.

If I had moved my development further along I would have encountered the second scenario, but I couldn't move my development further because I couldn't get past the first obstacle.

[Mantis]

Perhaps a few options for how Box2D handles the alpha layers? This way, we could select what applies to various scenarios. Strange, I subscribed to this thread and thought I'd get e-mail notifications. I guess not. Anyway, will you please look into a fix for this? I will have to instruct my graphic artist to not use alpha channels for my game's bikes and boring jaggy GIF transparency instead, which is a real shame. I'd probably pay a little if it would prioritise this issue...

Also, I am aware of the crude workaround I can use and I appreciate the suggestion, but I think this is a serious problem so I think I'll do that as a last resort and halt development of this current game if there's any chance of a fix any time soon.

[DaveC]

By crude workaround are you referring to using invisible physics objects for collision detection while positioning+setting angle of your alpha sprites to the base objects...? is that really so bad?

[Ryan]

It has a lot of overheads because you're using a For-each loop to position all your objects every frame. This would be a performance hit, especially on mobile devices.

If you use the spread ID method, as soon as your objects get destroyed the links are broken and the animation overlays can start to be randomised. It's not optimal.

[Mantis]

Especially since I'm using a 720p resolution which is high for mobiles and the bikes are quite high-res, plus there's physics for some inanimate objects. The overhead is a problem, unfortunately.

[buddyhudson]

I have got the same problem and I hate it very much. Clickteam should give us an example please to correct this problem. Please Clickteam help us.

[Jeff]

Buddyhudson can you upload an example of the problem you are having?
I think something else might be happening.

[buddyhudson]

The problem is what the objects collide whith the alpha zones and not respect the form of the objects.