[SOLVED] Quick import sprites: transparency issue

[Monsieur OUXX]

So I've read HERE that when you do a "quick import sprites", it re-uses the setting you used the last time you did a regular sprite import.

So I did this:
- first I imported a sprite the regular way, and left transparency "as-is". This sprite is a bmp file (no alpha) in a 32-bits game, and has pink (transparent) parts.
- I ran the game to check that once used as an object's graphic, the transparent part was, well... transparent, as expected.
- I imported a second sprite using "quick import", added that sprite into a view after the first sprite, and did a "SetView" and "Animate" on the in-game object.
- The first sprite still has transparent parts, but the second sprite's pink parts appear pink on screen instead of transparent.

So, how to I import a whole bunch of sprites with the same transparency settings?

:'(

[Billbis]

I am a bit confused about the first import.
If you leave transparency "as-is" when importing an image with no transparency/alpha channel, but only magic pink, surely the results should have no transparency but magic pink everywhere?
So if their is an issue here, I think is is with the first import?

[Monsieur OUXX]

I didn't understand your reply.
My first import is & 32-bit BMP with no alpha channel, but some parts with "regular" colors, and some other parts that are only made of magic pink. therefore, the parts with colors are opaque, and the parts with magic pink are transparent.

[Billbis]

Sorry for beeing confusing, I am also confused.
I am expecting the "Leave as is" option to display magic pink as ...regular pink, not as fully transparent...

[Khris]

Billbis, "leave as-is" uses Magic Pink for transparency, as opposed to picking another color I guess. The option for "no transparency" is called exactly that.

I can't confirm this; I imported a sprite using leave as-is, then quick imported two more. All had their pink parts become transparent in-game just fine (3.2.1)

[Monsieur OUXX]

Billbis, "leave as-is" uses Magic Pink for transparency, as opposed to picking another color I guess. The option for "no transparency" is called exactly that.

I can't confirm this; I imported a sprite using leave as-is, then quick imported two more. All had their pink parts become transparent in-game just fine (3.2.1)

Dammit.
µCould you try with 3.3.4, just in case?

[Khris]

I tried with 3.3.4 and I might have found the problem, but just by accident.

Since I had already deleted my test sprites from the hard drive, I had to export them from my 3.2.1 game first. I ended up with 3 pngs, and when I imported the first one, I got asked about using its alpha channel. I told AGS no, assigned it to a room object and got no transparency at all; Magic Pink was ignored.
So I opened it in PaintShopPro and saw that it had a single layer (every pixel had 100% opacity though). So I flattened the image, which turned the layer into the background layer. I resaved, reimported, and this time magic Pink was once again turned transparent.

So the problem is not AGS's importing but the exact format of the file. BMP's don't support layers though, are the files all saved as BMPs?

[Monsieur OUXX]

So the problem is not AGS's importing but the exact format of the file. BMP's don't support layers though, are the files all saved as BMPs?

Yes, they are.

- I first made an 8-bit game to generate my palette cycling, then did a "SaveScreenshot" on each frame, which generated BMP files. It generates 8bpp BMP files.
- I created another AGS game (32 bits) which opens these BMP files and saves them back again. I suppose it generates 32bpp files. EDIT: I've just opened them with a Hex editor and I noticed that they're actually 24bpp. But I wouldn't expect that to mess up the import process.
- It's when I then import these BMP files into the 32-bits game that the issue happens: The first one is OK, the following ones (quick import) miss the pink transparency.

[Monsieur OUXX]

I've been running some tests, and AGS definitely fails with those 24-bits BMP's it generated by itself.
However if I generate them with my BMP 2.0 module (which can be found in the forums and does all the encoding brute-force when using the eBmpString mode), then the import works properly afterwards.

It might point to the fact that there's something wrong with the way AGS encodes BMP files.

EDIT: I've found what AGS does incorrectly: When using DynamicSprite.SaveAsFile, it turns indexed color 255,0,255 (magic pink) into 255,1,255 (dirty pink)... Hence ruining the magic pink (the fact that the first sprite worked was just a "lucky" mistake on my side). So the issue has nothing to do with "Quick Import Sprites", but instead is caused by the way AGS approximates RGB values when saving 24bpp files.