Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Sun Aug 26, 2012 11:20 pm Post subject:
There is not much to explain on it. Really.
RA2 pals are composed of 16 bit colors and saved as one byte R, one byte G and one byte B ending up as 256*3=768 bytes. No header no other junk, just pure data.
So if you wanna read a RA2 PAL just read 3 bytes separately, multiply that values by 4 one after one and use the results as RGB color and vice versa to export. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Would this method export to a correct formatted ra2 palette?
Code:
public static void toRA2Palette (File destFile, Color[] colors) throws IOException
{
if (destFile.isDirectory())
throw new IllegalArgumentException("Arg must point to a file");
if (colors.length > 256)
throw new IllegalArgumentException("To many colors");
BufferedOutputStream out = new BufferedOutputStream (new FileOutputStream(destFile));
for (int i = 0; i < colors.length; i++)
{
out.write(colors[i].getRed() / 4);
out.write(colors[i].getGreen() / 4);
out.write(colors[i].getBlue() / 4);
}
//If the array have less than 256 elements, handle it here:
//... (implement this later)
RA2 pals are composed of 16 bit colors and saved as one byte R, one byte G and one byte B ending up as 256*3=768 bytes. No header no other junk, just pure data.
A small correction. The color system used is not 16-bit. It's not even 8-bit, despite there being one byte per each of the R,G,B values. Only valid values for the colors are in the range 0-63 (0-3F in hex), meaning that it's actually 6-bit color. Why in the hell WW opted for such system, instead of utilizing the entire 8-bit RGB spectrum, is beyond me though.
Rest is correct.
¥R_M0dd€r wrote:
Would this method export to a correct formatted ra2 palette?
I would say yes. Dividing the 8-bit RGB color values by 4 is a quick & efficient way to convert 8-bit RGB color values into 6-bit ones. Leads to slight loss of precision in some cases, naturally. I did it the same way for few tools I've done for my own use and I think so did OS Palette Editor too. _________________ Last edited by Starkku on Mon Aug 27, 2012 12:08 am; edited 1 time in total QUICK_EDIT
Joined: 22 Nov 2010 Location: Iszkaszentgyorgy, Hungary
Posted: Mon Aug 27, 2012 12:06 am Post subject:
Simple. 16 bit colors are actually composed as 5 bit R, 6 bit G and 5 bit B. Back at '97-'98, when GPU memory wasn't as huge as nowadays, having 16 bit or 32 bit displays mattered at performance. Consideing that even YR has graphics code evolved from TD... I don't see that much of a wackyness in it.
The wackyness comes from the sole fact that why the heck they use 6 bits on the R and B channel, then, since that needs some rounding in the end. Maybe the renderer rounds it, I dunno that. Having the render correcting a 18 bit screen to 16 bit sounds stupid, but since it's WW, it's plausible.
The 0-255 range is on 24 bit (32 is RGBA with alpha having as fourth), of course on lessen ones, that does not exist. Some 8 bit setups actually used 3 bit R 3 bit G and 2 bit B.... imagine those color ranges, then. _________________ "If you didn't get angry and mad and frustrated, that means you don't care about the end result, and are doing something wrong." - Greg Kroah-Hartman
=======================
Past C&C projects: Attacque Supérior (2010-2019); Valiant Shades (2019-2021)
=======================
WeiDU mods: Random Graion Tweaks | Graion's Soundsets
Maintainance: Extra Expanded Enhanced Encounters! | BGEESpawn
Contributions: EE Fixpack | Enhanced Edition Trilogy | DSotSC (Trilogy) | UB_IWD | SotSC & a lot more... QUICK_EDIT
Simple. 16 bit colors are actually composed as 5 bit R, 6 bit G and 5 bit B. Back at '97-'98, when GPU memory wasn't as huge as nowadays, having 16 bit or 32 bit displays mattered at performance. Consideing that even YR has graphics code evolved from TD... I don't see that much of a wackyness in it.
Oh yeah, that's what you meant with 16-bit. Well yeah I was aware of the fact that TS/RA2/YR, and I suppose the older games as well had 16-bit graphics display, but it just didn't occur to me that it could be due to that, since as you've put it, it'd have made more sense if the palettes were also in the 6,5,6 RGB scheme. But yeah this is Westwood, normal logic does not need to apply.
Oh and just to clarify if it was unclear, by saying that C&C palette colors are 6-bit, I was referring to how the individual red, green & blue colors only use 6-bit range. I suppose saying that it's 18-bit RGB would've made more sense in a retrospect. _________________ QUICK_EDIT
Also Known As: banshee_revora (Steam) Joined: 15 Aug 2002 Location: Brazil
Posted: Mon Aug 27, 2012 5:11 am Post subject:
Starkku wrote:
The color system used is not 16-bit. It's not even 8-bit, despite there being one byte per each of the R,G,B values. Only valid values for the colors are in the range 0-63 (0-3F in hex), meaning that it's actually 6-bit color. Why in the hell WW opted for such system, instead of utilizing the entire 8-bit RGB spectrum, is beyond me though.
There was some research back in the stone age that concluded that humans were able to distinguish 64 tons of red, green and blue.
I don't know how this research dealt with colours that mixed these channels. QUICK_EDIT
Finally tested my method. It didn't work. OS Palette Editor says "Read beyond end of file".
I assume the file is to big?
Code:
Code:
public void toRA2Palette () throws IOException
{
//Instead of throwing an exception, the color out of range will not be encoded.
// if (paletteColors.size() > 256)
// throw new IllegalStateException("To many colors");
BufferedOutputStream out = new BufferedOutputStream (new FileOutputStream(new File (path)));
ArrayList<Integer> colorList = new ArrayList<>(paletteColors);//paletteColors is a hash set of colors.
for (int i = 0; i < 255; i++)
{
try
{
Color color = new Color(colorList.get(i));
out.write(color.getRed() / 4);
out.write(color.getGreen() / 4);
out.write(color.getBlue() / 4);
}
catch (IndexOutOfBoundsException e)
{
out.write(0);//Write black color if the hash set did not have enough colors.
}
}
out.close();
}
Yeah, I saw that the pal was a lot smaller than the working ones.
I found the problem, I should have added out.write(0) two more times in the catch block. QUICK_EDIT
A small correction. The color system used is not 16-bit. It's not even 8-bit, despite there being one byte per each of the R,G,B values. Only valid values for the colors are in the range 0-63 (0-3F in hex), meaning that it's actually 6-bit color. Why in the hell WW opted for such system, instead of utilizing the entire 8-bit RGB spectrum, is beyond me though.
You can post new topics in this forum You can reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum You cannot attach files in this forum You can download files in this forum