png-8 and animation

When i have a png-8 format sprite, transparency works fine.

However when I have a png-8 format sprite with animation, the transparency fails.

Any way to fix this while maintaining png-8 format?

Thanks

Maybe you'll find it usefull.

http://www.scirra.com/forum/viewtopic.php?f=3&t=7400

Ah so its a bug?

In my case it was. Use gif for color table, or png24

Ah so its a bug?

No, you should be using 32 bit images for everything.

> Ah so its a bug?

>

No, you should be using 32 bit images for everything.

Why should we? It a feature that expected to be implemented. Looks more than incompleted feature or bug rather than we should use 32bit. On-the-fly convert would be better than just ignoring alpha? </IMHO>

Would you rather the devs waste their time making a feature to convert non 32 to 32, since all images are saved internally as png32?

Or have them work on existing real bugs, or new features.

There are literally hundreds of apps that can convert those images beforehand.

Hey I'm not talking about "real" and "unreal" bugs. It's about simplicity of using construct. Would be great adding one of those tips, that you see when using any panel for the first time (for ex. when you set "fixed" fps rate you getting warning tip) for the (in this case) sprite object something like "For internal calculations Construct using PNG32" to prevent further confusing about file types.

Further more even Wiki is making you confuse about it.

Quote from this page

http://sourceforge.net/apps/mediawiki/construct/index.php?title=Picture_Editor

[quote:1afisseu]From left to right the items on the Menu Bar are as follows:

New: ...

Open: Open an existing image file. Supported file types are .png, .jpg, and .bmp. The Picture Editor will correctly automatically apply alpha channel information for .png images, so images with transparency will be imported correctly

Save: ...

No word about it's 32bit-ness.

P.S.

And btw construct is for people with gamedev experience and without game experience. So it's a bug at min 50% sureness), it's like I have png - it doesn't work. Wiki sais it does. I go posting on "Help'n'Support"

Would you rather the devs waste their time making a feature to convert non 32 to 32, since all images are saved internally as png32?

Or have them work on existing real bugs, or new features.

There are literally hundreds of apps that can convert those images beforehand.

It should either

1) not accept png-8 all together and give a warning

2) give a warning that says animations dont work with png-8

3) get animations to work properly with png-8

4) transparently convert everything internally to png-8

Problem is that it does none of the above. If i need to convert it, at least tell me the moment I import a png-8 image.

Problem is that it does none of the above. If i need to convert it, at least tell me the moment I import a png-8 image.

That's what i'm talking about. Just one simple warning and future confusing is gone forever.

Still not really a bug. Little quirks like that are best described as "features".

Yes there should be some mention of it on the wiki, but just like the program, the documentation is unfinished. The devs are allowing users to sign up to edit it BTW.

There is also a bug tracker if you feel really strongly about it.

On the other hand, this is one of the things I was trying to emphasize in this post:

We are so close to 1.0, better make it consistent than confusing the user.