Physics: No PNG support. :(

Why is this? This is a very necessary feature in my opinion. I have spent ages getting a graphic ready and my artist would also typically create PNG. It's a great format for smooth images. Alpha channels are not the enemy. If an alpha channel is right at the edge of the object (where the alterable transparency takes place), it does not affect the object itself and the alpha channel could just be ignored. GIF is archaic and few modern devs like it. Colours are limited, file sizes are higher and transparency looks horrible and jaggy.

This should have been expressed since I've spent hours investigating why my objects were falling and now I've discovered why. Whilst it might be true that you can layer a second GIF active under the PNG, this isn't a smart approach and creates unnecessary bloat. This is 2014. I'm sorry to rant, but the physics are really outdated without PNG support.

wait what? I'm still new to fusion but i believe you can use physics with pngs...

create an active object and import you assets (png or whatever) and that's it, just apply the physics to the active object.

I should have clarified. It does have basic PNG support, but PNG to PNG fails as far as I can see. Probably a bug? I shouldn't have written no PNG support in hindsight. It seems to work with actives I've created without importing a PNG, but many objects I will use will be PNG. If I'm wrong here, I'd like an example file because I'd like to get this working ASAP. :)

Okay, I might have found a solution here, but I have a question. What purpose does the background physics movement serve when you're placing ground objects anyway?

I overcame this by create a collision active object and a PNG graphics overlay active object. The collision should not be a png, will have the physics movements and will represent the extents of the collision. The PNG will not have any movements as it's simply an overlay that we position with events.

Then you can use
ID of PNG = ID of collision
> Set Position of PNG at 0,0 from collision
> Set Angle of PNG to Angle of collision

It works with flawlessly in combination with spread IDs, if you're going to assign your own IDs you'll need to use ForEach loops to sync the objects.

Let me know what solutions you come up with.

Yes, my problems were not solved in the end. I have created several ground objects, but I can't seem to get them to work fully. However, if I disable creation of the ground objects, the 200x200 wood images still work with the background physics movement. However, the sand below does not. It's more complex, though. But still, I would expect some level of collision. I imported both PNG and GIF versions of the sand and neither worked. However, I created white GIF collisions of the bike frame and two wheels. I tried bouncing ball on the frame. Strangely, the left and right bounce with the frame a little bit into the wood and the top/bottom bounce much higher than the wood itself. Take a look at my progress if you like: https://www.sendspace.com/file/v3tvxj

(Note: I enabled the second ground physics at the bottom, but the top are disabled. Also, you'll notice some strange things like weird anti-gravity partway down. I haven't figured out the cause yet.)

When you import a graphic into Fusion's image editor, it is no longer in the format you imported. So what format of image you import does not matter in this situation... gif, png, jpg... doesn't matter. Fusion converts it to either bmp or raw or something... I don't remember... but no file formats are kept once it's imported.

So your issue has nothing to do with PNG at all... which explains why your problem is happening with importing both png and gif.

I'm at work so I can't check your project but I'm sure someone else will gladly help out in time. Just letting you know... again, Fusion doesn't maintain image formatting once you import.

I think he's trying to say that because PNGs have semitrasparency, Fusion incorporates the semi-transparency into the physic's object's boundaries, causing incorrect collision zones.

Fusion should only use non-transparent zones for it's collision detection. That way, drop shadows or outer glows wouldn't be treated as physics objects.... but it looks like Clickteam haven't put much thought into this yet.

It is as Ryan says, Konidias. That's what I was trying to convey. MMF2 must have some kind of 32-bit RGBA format to allow partial transparency (alpha channel), rather than plain old 24-bit (RGB). I would not think it is raw uncompressed data. That would make large projects astronomical in size.

Quote:

---

Originally Posted by Ryan

I think he's trying to say that because PNGs have semitrasparency, Fusion incorporates the semi-transparency into the physic's object's boundaries, causing incorrect collision zones.

Fusion should only use non-transparent zones for it's collision detection. That way, drop shadows or outer glows wouldn't be treated as physics objects.... but it looks like Clickteam haven't put much thought into this yet.

---

I wish people didn't always rush to criticise Clickteam like this, it's very frustrating when we do put a lot of thought into our products...

Regarding alpha on physics objects - if we made it use opaque areas of the image only, you would never be able to make a see through object (for instance a gem or ice block or similar). This would be very limiting for a lot of people. Just because a scenario would best suit one or a few or even most users, it doesn't mean it's the best one or there aren't other factors to consider... we have to think about all of these things and try to create solutions which work best for a broad range of use cases.

There is some further improvement to be done on the collision maps, but that doesn't mean we haven't thought about it!

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".

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.

Quote:

---

Originally Posted by Ryan

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

---

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.

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.

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?

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.

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.

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.

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

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

Could you post a very simple example please so that we can take a look? (that would be much easier for us) Thanks!

I send you an example:

http://www.mediafire.com/download/r5...ddyExample.mfa

Hmm, the problem is not with the apha channel, it seems it's because the shoe has a platform movement. With any other movement it works. I'll check why.

Ok. Thank you very much. May be a bug.

Hi !
Is there any solution to this ?

Still not working.

Attachment 17640

I'm not sure this is easily modifiable. The problem is due to the fact objects with a Physics - Platform movement (like the shoe) have a specific, fixed collision shape, unlike the other movements where you can choose between different shapes. This was done intentionnally and I'm not sure we can change this. Sorry.

Just make a custom platform movement using a static physics object, then you can have a custom shape collision.

OK. Thank you.