Physics: No PNG support. :(

Welcome to our brand new Clickteam Community Hub! We hope you will enjoy using the new features, which we will be further expanding in the coming months.

A few features including Passport are unavailable initially whilst we monitor stability of the new platform, we hope to bring these online very soon. Small issues will crop up following the import from our old system, including some message formatting, translation accuracy and other things.

Thank you for your patience whilst we've worked on this and we look forward to more exciting community developments soon!

Clickteam.

    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.

    Please login to see this link.

    Edited once, last by Mantis (August 11, 2014 at 3:40 AM).

    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. :)

    Please login to see this link.

    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?

    Please login to see this link.

    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.

    Please login to see this link.

    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: Please login to see this link.

    (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.)

    Please login to see this link.

    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.

    Please login to see this link.

    My examples:
    Please login to see this link.
    Please login to see this link.
    Please login to see this link.

    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.

    Please login to see this link.

    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.

    Please login to see this link.

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

    Please login to see this link.

    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.

    Please login to see this link.

    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.

    Please login to see this link.

    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?

    Check out my Game on Itch.io
    Please login to see this link.

    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.

    Please login to see this link.

    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.

    Please login to see this link.

Participate now!

Don’t have an account yet? Register yourself now and be a part of our community!

Register Yourself Login