let em start off by saying that its great that you did all this with flcikster, erm, flickster maker guy. Shouldnt these firax people fix there own mistakes!? anyway.... when i put the animation together for the special ops guy, someone from LWC. everything looks wonderful, except, the brightgreen that was supposed to be the shadow is acutally showing up, instead of being the shadow.
HELP w/ new flicster
- Thread starter smazza
- Start date
I had the same problem... here's what Moeniir (FLICster guy) said:
Let me know if that works... I'm waiting until I get home to try it.
Also, about this:
Firaxis is working on something for us... no word on when it will be released. Moeniir just beat them to the punch... three cheers!
Let me know if that works... I'm waiting until I get home to try it.
Also, about this:
Firaxis is working on something for us... no word on when it will be released. Moeniir just beat them to the punch... three cheers!
Moeniir
Mr FLICster
Thanks for the post Zippo.
It comes down to the palette. A palette is just a list of colors, like a lookup table. With 8 bit graphics (which is how the units are stored, even though the game runs at 16bit) the palette is a list of 256 colors, numbered 0 to 256. The bitmap, or picture data, is a list of what colors go in each pixel, right? Well, the data for this is the palette index.
So. When you open a FLC that you split with flicster, you see the unit on a hot-pink (fuscia? magenta?) background. The pink is the transparency color. Only, its not really the color, but it's palette position. If you edit the palette, you will see that pink color is the last color there... color 255. All pixels that use color #255 will be transparent. Same with the shadows - palette positions 248-254 indictate shadowing - this appears bright green in some flics, red in others.
The problem is this - in most of the original FLCs (and the splits made from them), All the un-needed palette positions (the picture uses less than 256 different colors, so some of the positions aren't really needed) are getting filled with the same color as the transparency color. Now, when a program like Paint Shop loads the picture, the 'shadow' parts of the picture contain the index for say, 254. But if that exact same shade of green is also in the palette at, say position 200, well, Paint shop may replace the 254's in the picture with 200's. This is called Palette Optimization, and it is a Very Bad Thing, at least for us.
Now, I know that Animation Shop does this by default. The readme contains instructions for preventing this, during the save options dialog (same place you pick the PAL file, be sure you choose 255 colors). But even if you follow those dirs, I'm not sure PSP won't do it to you too.
One possible solution I'm thinking about is for FLICster to edit the Palettes when splitting the files. I can make a list of all the palette entries not used anywhere in the picture, and change them to various shades of something else, as long as my new colors don't show up in the picture either. This should prevent palette optimization, as it ensures 256 unique colors (assuming none of the civ-specific colors overlap in a single palette).
Let me know how the original idea in Zippo's post works. I'll try to work on some palette de-optimizing code (WOW - the programmer in me loves the irony of writing a DE-optimizer) tonite or this weekend - but I'm also hard at work on the next major release version of FLICster, which will be alot different and should make alot of these issues moot.
Hope this has helped... and be sure to post your units when done!
It comes down to the palette. A palette is just a list of colors, like a lookup table. With 8 bit graphics (which is how the units are stored, even though the game runs at 16bit) the palette is a list of 256 colors, numbered 0 to 256. The bitmap, or picture data, is a list of what colors go in each pixel, right? Well, the data for this is the palette index.
So. When you open a FLC that you split with flicster, you see the unit on a hot-pink (fuscia? magenta?) background. The pink is the transparency color. Only, its not really the color, but it's palette position. If you edit the palette, you will see that pink color is the last color there... color 255. All pixels that use color #255 will be transparent. Same with the shadows - palette positions 248-254 indictate shadowing - this appears bright green in some flics, red in others.
The problem is this - in most of the original FLCs (and the splits made from them), All the un-needed palette positions (the picture uses less than 256 different colors, so some of the positions aren't really needed) are getting filled with the same color as the transparency color. Now, when a program like Paint Shop loads the picture, the 'shadow' parts of the picture contain the index for say, 254. But if that exact same shade of green is also in the palette at, say position 200, well, Paint shop may replace the 254's in the picture with 200's. This is called Palette Optimization, and it is a Very Bad Thing, at least for us.
Now, I know that Animation Shop does this by default. The readme contains instructions for preventing this, during the save options dialog (same place you pick the PAL file, be sure you choose 255 colors). But even if you follow those dirs, I'm not sure PSP won't do it to you too.
One possible solution I'm thinking about is for FLICster to edit the Palettes when splitting the files. I can make a list of all the palette entries not used anywhere in the picture, and change them to various shades of something else, as long as my new colors don't show up in the picture either. This should prevent palette optimization, as it ensures 256 unique colors (assuming none of the civ-specific colors overlap in a single palette).
Let me know how the original idea in Zippo's post works. I'll try to work on some palette de-optimizing code (WOW - the programmer in me loves the irony of writing a DE-optimizer) tonite or this weekend - but I'm also hard at work on the next major release version of FLICster, which will be alot different and should make alot of these issues moot.
Hope this has helped... and be sure to post your units when done!
This note might save you some time... when you are changing that shadow color, you only have to change the palette for the FIRST frame. After you save the palette, just go into AS and use the replace color feature (so long as the old shadow color isn't anywhere else in the animation) and it should work great! It did for me
