Prev: ilk #flashobject = void???
Next: endsprite
From: Darrel Hoffman on 22 Apr 2008 10:30
I'm guessing I must be missing an Xtra or something, but whenever I use a
Background Transparent ink on a bitmap, it looks fine in Authoring mode, but
in the projector, I get ugly white pixels all around the part that's
supposed to be transparent. I tried putting various Xtras into the
project's Xtra's folder to no avail, can't figure out which one it's
supposed to be. It's either that, or maybe the images are being compressed
somehow and the pixels that are supposed to be pure white (transparent) are
instead being messed up to be just off-white, and thus not transparent.
Either way, I absolutely need to fix this - any ideas?


From: Darrel Hoffman on 22 Apr 2008 15:53
That's not the problem I'm having at all - I'm talking straight BMPs, no
alpha, with Background Transparent ink. If I want good alpha, I use PNGs.
(PSD files suck for alpha because they have it pre-multiplied, and you end
up with a halo if it's against a different color.) But this isn't about
alpha, it's about the Background Transparent ink, which works perfectly fine
in the Authoring environment, but is killed in Projector. Isn't there any
way to force it not to compress the graphics on compile and wreck the
transparency in the process?


From: Mike Blaustein on 22 Apr 2008 16:10
There is an option in the Property Inspector for the bitmap member. On
the Bitmap tab. It is "Compression". If you set it to "Standard", then
it will not compress it.
From: Sean Wilson on 22 Apr 2008 16:44
What was being suggested, and it's a sensible option, is to avoid using
bgTransparent inks by importing 32-bit images with transparency where
required (that is, where the ink setting would otherwise be making the
image transparent).

Is it possible that your members are being compressed when published?
When you look at the Bitmap tab in the PI for any of your troublesome
members, what are the settings for imageCompression and imageQuality? At
the least, try setting Compression to Standard.
From: Darrel Hoffman on 23 Apr 2008 00:42
> What was being suggested, and it's a sensible option, is to avoid using
> bgTransparent inks by importing 32-bit images with transparency where
> required (that is, where the ink setting would otherwise be making the
> image transparent).

But doesn't that basically multiply the amount of memory needed for each
graphic cast member by 50%? I mean, there's a lot of them, and Director
executables are pretty bloated as it is, there's no sense in just adding all
that data when there's an ink setting (Background Transparent) specifically
designed to do exactly that. At any rate, I never use straight PSD files in
Director, because pre-multiplied alpha always looks terrible against any
background color other than the one that's built into the image. PNGs are
not only much smaller, but they consistantly look much better against any
background. But that's not an issue here, because I *want* a hard-edged
transparency in this case, there's absolutely no need for a full 8-bit
grey-scale alpha channel to be tacked onto every image when all I want is
0/1 invisible/visible.

> Is it possible that your members are being compressed when published? When
> you look at the Bitmap tab in the PI for any of your troublesome members,
> what are the settings for imageCompression and imageQuality? At the least,
> try setting Compression to Standard.

All I found was the global setting, so right now I'm not compressing ANY
images - and my EXE size just doubled. Though it does work now, just more
bloated than I'd like. I think I may need to selectively set the
compression settings for those sprites which have no need for transparency
vs. those which do...


 |  Next  |  Last
Pages: 1 2
Prev: ilk #flashobject = void???
Next: endsprite