Staredit Network > Forums > Modding Assistance > Topic: Understanding starcraft palette
Understanding starcraft palette
Mar 8 2022, 7:31 pm
By: andreasvz  

Mar 8 2022, 7:31 pm andreasvz Post #1



Hello together,

I found this topic while my research about the Starcraft file format. There's a lot of know-how in this forum and I learned a lot by reading it.

First maybe as explanation I'm not interested in modding the Starcraft Game, but spend my work into the opensource game Stargus. Therefore I create a clone of the very old unmaintained branch.
Here: https://github.com/andreas-volz/stargus

Meanwhile I learned a lot:
https://github.com/andreas-volz/stargus/wiki/File-Format-Overview

...and wrote many new parsers for the game:
https://github.com/andreas-volz/stargus/tree/master/src/kaitai

The status of stargus is still very alpha stage. But I plan to change to support the .dat files and hope this will give a dramatic feature increase.

But anyhow currently I'm fighting to understand the palette secrets.

Currently some palettes are hard coded from the former developers:
https://github.com/andreas-volz/stargus/blob/master/src/Palette.cpp

I changed meanwhile the complete palette code to be able to load from the pcx palettes (e.g. tunit.pcx).

But I've a problem to understand how it works with color palettes in case I have those grp files:

(1) unit\\thingy\\o022.grp
or
(2) unit\\thingy\\flamer.grp

For (1) Stardat says it has "Drawing property function = 13". If I use that Cmdicons_Palette[] from Palette.cpp array it just works. But I couldn't find the PCX file with that "yellow palette" in the beginning. Any ideas?

For (2) this grp file has in Stardat written "ofire.pcx". But if I just use ofire.pcx palette than I get strange colors. If I use Orange_Palette[] and some strange undocumented image conversation in the code it works. (https://github.com/andreas-volz/stargus/blob/master/src/Grp.cpp#L219)

You don't have to step into my code and understand it. Just that shows me there must be some more magic behind the palettes.

First question: Am I welcome in this forum to understand and talk about the starcraft format for my purpose of stargus development?

Concrete: Could you help me to find out how to load o022.grp and flamer.grp (as example) with correct colors?

regards
Andreas



None.

Mar 8 2022, 8:35 pm DarkenedFantasies Post #2

Roy's Secret Service

Quote from andreasvz
For (1) Stardat says it has "Drawing property function = 13". If I use that Cmdicons_Palette[] from Palette.cpp array it just works. But I couldn't find the PCX file with that "yellow palette" in the beginning. Any ideas?
Cmdicons use unit\cmdbtns\ticon.pcx.

Quote from andreasvz
For (2) this grp file has in Stardat written "ofire.pcx". But if I just use ofire.pcx palette than I get strange colors. If I use Orange_Palette[] and some strange undocumented image conversation in the code it works. (https://github.com/andreas-volz/stargus/blob/master/src/Grp.cpp#L219)

You don't have to step into my code and understand it. Just that shows me there must be some more magic behind the palettes.
If you look closely, you'll notice the PCX images also use the same in-game palette (aka "Gamebasic", or "SC_Unit_Palette" in your code), which is identical to the tileset palettes (aka "Terrain_Palette" in your code) except for the tileset-specific colors being omitted (highlighted as #2323FF). The PCX files are lookup tables telling the game which colors to use from the in-game palette. For example, in the case of tunit, the game code replaces the pixels in the grp that have a palette index between 8-15 (highlighted as magenta shades in the "unit palette") with the 8 colors found in tunit according to the player and index offsets.

The ofire.pcx table works in the same way, just that it's a 2-dimensional table instead of 1 like tunit. The horizontal aspect is the entire tileset palette, and the vertical aspect is the color index with which flamer.grp has been indexed with. So, for example, pixels that have the index of 3 in the GRP that are found above a pixel of index 127 in-game will be replaced with the color found on Row 4 Column 128 in ofire.pcx.

Quote from andreasvz
Could you help me to find out how to load o022.grp [...]
I think o022.grp & co. use the game\tselect.pcx table.




Mar 8 2022, 11:07 pm andreasvz Post #3



Quote
For example, in the case of tunit, the game code replaces the pixels in the grp that have a palette index between 8-15 (highlighted as magenta shades in the "unit palette") with the 8 colors found in tunit according to the player and index offsets.

Player colors are understood.

Quote
Quote from andreasvz
Could you help me to find out how to load o022.grp [...]
I think o022.grp & co. use the game\tselect.pcx table.

Ok, let me first step into this case. I still don't get it complete.

If I open tselect.pcx with gimp I see this image and palette index:

https://gcdnb.pbrd.co/images/yNbSTRyUrQT8.png

I know that the resulting circle must be green. Are there some special color index for the circle selector to replace?



None.

Mar 8 2022, 11:56 pm DarkenedFantasies Post #4

Roy's Secret Service

If you extract the o022.grp frame as a BMP image, you will see that the image is composed only of palette indexes 0 through 8. Which palette you apply to it doesn't matter, only the index values are important; "Drawing Function 13" tells the game to use the tselect.pcx table for color remapping. So like player color, pixels indexed as 1 in the GRP will refer to the first pixel in tselect, which is index 184 in the tselect palette, which then refers to that index in the in-game palette, and so on for the other 7 indexes. Index 0 is skipped because it's the "transparent" color and doesn't need to be remapped as it's index 0 everywhere. Some flag in the game memory would determine if the selected unit is own/ally/enemy (say 0 for own, 1 for ally, and 2 for enemy) and would thus determine the offset in tselect.pcx (green/yellow/red). The offset size (8) is likely hardcoded, but not sure.




Mar 9 2022, 10:08 pm andreasvz Post #5



If you extract the o022.grp frame as a BMP image, you will see that the image is composed only of palette indexes 0 through 8. Which palette you apply to it doesn't matter, only the index values are important; "Drawing Function 13" tells the game to use the tselect.pcx table for color remapping. So like player color, pixels indexed as 1 in the GRP will refer to the first pixel in tselect, which is index 184 in the tselect palette, which then refers to that index in the in-game palette, and so on for the other 7 indexes. Index 0 is skipped because it's the "transparent" color and doesn't need to be remapped as it's index 0 everywhere. Some flag in the game memory would determine if the selected unit is own/ally/enemy (say 0 for own, 1 for ally, and 2 for enemy) and would thus determine the offset in tselect.pcx (green/yellow/red). The offset size (8) is likely hardcoded, but not sure.

Ok, understood. I wrote some more code and now I could tselect.pcx to load those grp files with correct palette.

Quote
Cmdicons use unit\cmdbtns\ticon.pcx.


Also working. Even that I had to learn in case of ticon.pcx it has 16 index colors and not only 8 as in tselect.pcx.

Quote
The ofire.pcx table works in the same way, just that it's a 2-dimensional table instead of 1 like tunit. The horizontal aspect is the entire tileset palette, and the vertical aspect is the color index with which flamer.grp has been indexed with. So, for example, pixels that have the index of 3 in the GRP that are found above a pixel of index 127 in-game will be replaced with the color found on Row 4 Column 128 in ofire.pcx.

This I don't understand yet. Here as explanation the image opened in Gimp:

https://pasteboard.co/gMZNaYIYDXv7.jpg

The size is 256x63 pixels. The first row has exactly the same pixel order as the palette indices. Could you give me please another example than the one above that may help me to get understanding.

Much thanks so far!



None.

Mar 10 2022, 1:50 am DarkenedFantasies Post #6

Roy's Secret Service

Going left-to-right (columns) are a representation of the in-game color palette, and is 256 pixels wide because it is a 256-colors palette. Going top-to-bottom (rows) is the gradient for the "transparent" overlays like the orange flames and explosions, and is 63 pixels tall because, if for example you extract flamer.grp as a BMP image, you will see that it's composed of indexes 0 through 63 (index 0 is skipped so ofire.pcx is not 64px tall). Similarly to tselect, "Drawing Function 9" tells the game to use one of the remapping tables such as ofire.

When an image using flamer.grp appears in-game, the game basically samples the pixel indexes of the terrain/units/images beneath it and cross-references them with those of the flamer image. For example, if one pixel on the flamer image is index 8 in the GRP, and the visible pixel beneath is index 64, the game will use the color found at Row 8 Column 65 in ofire.pcx. The game will reference the palette index of that pixel in ofire.pcx to color the pixel in-game according to the color found at that index number in the tileset palette (which would be ashworld.wpe in the case of your GIMP image).




Mar 10 2022, 10:05 pm andreasvz Post #7



Ok, I could now load a 2 dimensional palette from ofire.pcx and apply it to e.g. unit\\thingy\\tbangx.grp. At the moment I choose a specific selected column or increment the row per each column (just as test).

https://pasteboard.co/3xJPKwPerlT8.png

Ok, the improvement compared to the standard palette at least it's an orange fire. :-)

But if I understand you correct the engine does really at runtime look which e.g. units pixel is beneath and create so a transparency effect. Yes?

This might be a problem as the stratagus engine uses pre-generated PNG files as input. I don't think it could change palettes in such a dynamic way. I think they use only full pixel transparency. But I'm in contact with the developers.

Post has been edited 1 time(s), last time on Mar 10 2022, 10:10 pm by andreasvz.



None.

Mar 11 2022, 8:38 am andreasvz Post #8



The stratagus engine supports 32-bit RGBA PNG transparency. So I must think about how to pre-generate explosion graphics with alpha value or change the engine to support this "palette transparency" effect.



None.

Mar 24 2022, 7:51 pm andreasvz Post #9



After lot of experiments I understand palettes a little better. I've some Grp files which I don't understand how to proper use a palette.

e.g. unit\\neutral\\geyser.grp

If I look in StarDat it says "0-Normal Draw" and "0-No Remapping". So I used the default palette (e.g. tunit.pcx) then the result looks strange:

https://pasteboard.co/4FiUFxpH838N.png

I could imagine that I need a special tileset palette. But I thought this is used only if "9-Use Remapping" is set. Do I need always to map every palette from tileset wpe for "0-Normal Draw"?



None.

Mar 25 2022, 9:57 am UndeadStar Post #10



I don't know things about palettes, but would not the geyser use a "terrain" or "doodad" palette instead of "unit" ?




Mar 25 2022, 12:22 pm Voyager7456 Post #11

Responsible for my own happiness? I can't even be responsible for my own breakfast

I think Farty would be able to provide more detail, but from what I recall there's a portion of the basic palette that is *always* replaced with the corresponding row(s) in the tileset palette.



all i am is a contrary canary
but i'm crazy for you
i watched you cradling a tissue box
sneezing and sniffling, you were still a fox


Modding Resources: The Necromodicon [WIP] | Mod Night
My Projects: SCFC | ARAI | Excision [WIP] | SCFC2 [BETA] | Robots vs. Humans | Leviathan Wakes [BETA]


Mar 25 2022, 7:26 pm andreasvz Post #12



Ok, I assumed to apply a terrain palette. But there're two questions. First is I assume the terrain palette applies from #200 to #254. I've to learn how - but ok I assume it's possible.

But how do I find that units that use palette index from that area? By color analysis? I've to ask this as I pre-generate the PNG files for the stratagus engine for each terrain. And lot of units don't use pixels from #200-#254 and are compatible with every terrain and could be saved in a common folder.



None.

Mar 25 2022, 11:04 pm andreasvz Post #13



More concrete questions:

From old code I found out how to load .wpe files. If I load them as 4x8byte RGBX data and convert to 3x8byte RGB palette and apply with standard mechanism to a Grp (e.g. Cbattle.grp) it looks not so wrong. :-)

https://pasteboard.co/vEeLTaBl9mlM.jpg

But for what is that last color byte in .wpe palette data? The reason why that isn't used is not documented in the code.There still some pixels which look not 100% perfect so I assume it's still an error in.

see here list of terrain wpe files:
ashworld-nc.wpe badlands-nc.wpe install.wpe jungle.wpe
ashworld.wpe badlands.wpe jungle-nc.wpe platform.wpe

Why is there sometimes a -nc-wpe? When to use which?



None.

Mar 25 2022, 11:54 pm DarkenedFantasies Post #14

Roy's Secret Service

Unlike most other units, the geyser frames were rendered with tileset-specific colors included. What you see as bright blue pixels are the colors "missing" from the palette you're using, which are the indexes that are unique to each tileset palette (badlands.wpe, ashworld.wpe, etc). In the geyser's case, each frame is tied to a different tileset (as a result of the "playframtile" opcode in iscript). The first frame is the one displayed on Badlands maps, the second frame is for Space Platform, third for Installation, and fourth for Ashworld. Since the other tilesets don't have a respective frame, the first frame is used by default though it is still colored using the Jungle/Desert/Ice/Twilight palettes.

Indexes between 1-13 and 200-254 are the tileset-specific colors. To be clear, there aren't actually separate "unit" and "terrain" palettes in-game, so it would be more accurate to say that indexes 0, 14-199, and 255 are shared between tilesets, and unit graphics are thus only rendered using an external palette that has the tileset-specific colors excluded (masked out as the bright blue colors).

Some units (e.g. Siege Tank (tank mode), Ion Cannon, Crashed BC, Protoss Temple, Khaydarin Formation) were rendered with the tileset colors included (either intentionally or by mistake), which is why they looks pristine on a specific tileset, but for example are smeared with orange pixels in Desert; the orange pixels are the ones using tileset-specific indexes.

Quote from andreasvz
But for what is that last color byte in .wpe palette data?
As far as I'm aware, nothing.

Quote from andreasvz
Why is there sometimes a -nc-wpe? When to use which?
I don't know what uses the -nc palettes, but they only have the cycling colors excluded (animated water waves). Could possibly be deprecated stuff that never got cleaned up from the release version. There is a video setting in the F10 menu for disabling color cycling, but it doesn't switch to the -nc palette, it simply freezes the animation.




Mar 26 2022, 9:31 pm andreasvz Post #15



Quote
The first frame is the one displayed on Badlands maps, the second frame is for Space Platform, third for Installation, and fourth for Ashworld.

Ah cool, learned something again.

Quote
In the geyser's case, each frame is tied to a different tileset (as a result of the "playframtile" opcode in iscript).

Until now I don't parse iscript data file. The animations/graphics in stargus are hard coded. Need to read more information from the data files and improve this.

For your interest this is how to looks at the moment. Still a long way to go:

https://youtu.be/tSp-9iJ4npE



None.

Mar 26 2022, 9:50 pm O)FaRTy1billion[MM] Post #16

👻 👾 👽 💪

Quote from andreasvz
Why is there sometimes a -nc-wpe? When to use which?
I don't know what uses the -nc palettes, but they only have the cycling colors excluded (animated water waves). Could possibly be deprecated stuff that never got cleaned up from the release version. There is a video setting in the F10 menu for disabling color cycling, but it doesn't switch to the -nc palette, it simply freezes the animation.
-nc tileset files are used by staredit, so you can basically just ignore them entirely.

Quote from andreasvz
Until now I don't parse iscript data file. The animations/graphics in stargus are hard coded. Need to read more information from the data files and improve this.
You don't really need to parse the iscript to get the geyser frame, just make it display the appropriate frame depending on tileset.

Quote from andreasvz
But for what is that last color byte in .wpe palette data?
4th byte in wpe isn't used for anything. I've used the 4th byte when rendering to store the palette index for the remapping palette lookup, rather than as an alpha channel, but I don't think this will work for you since you said you're using RGBA transparency. Instead, if you download this pack of palette files and go to the WPE directory, you can use ofire-edit.wpe, bfire-edit.wpe, gfire-edit.wpe and bexpl-edit.wpe which do have an appropriate alpha value in the 4th byte. They may not be perfect because they're basically just an average of all the tables for each tileset and the color & transparency is estimated from the results.


In the geyser's case, each frame is tied to a different tileset (as a result of the "playframtile" opcode in iscript). The first frame is the one displayed on Badlands maps, the second frame is for Space Platform, third for Installation, and fourth for Ashworld. Since the other tilesets don't have a respective frame, the first frame is used by default though it is still colored using the Jungle/Desert/Ice/Twilight palettes.
If you get geyser.grp from BrooDat.mpq it will have frames for all 8 tilesets

EDIT:
Also, I believe this to be a complete list of tileset-specific grps:
Code
"geyser.grp":
{
0 = "badlands.wpe",
1 = "platform.wpe",
2 = "install.wpe",
3 = "ashworld.wpe",
4 = "jungle.wpe",
5 = "desert.wpe",
6 = "ice.wpe",
7 = "twilight.wpe"
}

"badlands.wpe":
{
"terran\\tank.grp", // probably ???
"neutral\\cbattle.grp",
"thingy\\tileset\\badlands\\hdrock01.grp",
"thingy\\tileset\\badlands\\hdrock02.grp",
"thingy\\tileset\\badlands\\hdrock03.grp",
"thingy\\tileset\\badlands\\hdrock04.grp",
"thingy\\tileset\\badlands\\hdrock05.grp",
"thingy\\tileset\\badlands\\hdrock06.grp",
"thingy\\tileset\\badlands\\hdrock07.grp",
"thingy\\tileset\\badlands\\hdrock08.grp",
"thingy\\tileset\\badlands\\hdtree01.grp",
"thingy\\tileset\\badlands\\hdtree02.grp",
"thingy\\tileset\\badlands\\hdtree03.grp",
"thingy\\tileset\\badlands\\hdtree04.grp",
"thingy\\tileset\\badlands\\hdvent01.grp",
"thingy\\tileset\\badlands\\hgtree01.grp",
"thingy\\tileset\\badlands\\lcshop01.grp",
"thingy\\tileset\\badlands\\lcshop02.grp",
"thingy\\tileset\\badlands\\lcshop03.grp",
"thingy\\tileset\\badlands\\lcshop04.grp",
"thingy\\tileset\\badlands\\lcshop05.grp",
"thingy\\tileset\\badlands\\lcshop06.grp",
"thingy\\tileset\\badlands\\lcshop07.grp",
"thingy\\tileset\\badlands\\lcshop08.grp",
"thingy\\tileset\\badlands\\lcshop09.grp",
"thingy\\tileset\\badlands\\lcshopaa.grp",
"thingy\\tileset\\badlands\\lcsign01.grp",
"thingy\\tileset\\badlands\\lcsign02.grp",
"thingy\\tileset\\badlands\\lcsign03.grp",
"thingy\\tileset\\badlands\\lcsign04.grp",
"thingy\\tileset\\badlands\\lcsign05.grp",
"thingy\\tileset\\badlands\\lcsign06.grp",
"thingy\\tileset\\badlands\\lcsign07.grp",
"thingy\\tileset\\badlands\\lcsign08.grp",
"thingy\\tileset\\badlands\\lcsign09.grp",
"thingy\\tileset\\badlands\\lcsignaa.grp",
"thingy\\tileset\\badlands\\lcsignbb.grp",
"thingy\\tileset\\badlands\\lcsigncc.grp"
}


"platform.wpe":
{
"neutral\\ion.grp",
"thingy\\tileset\\platform\\dish01.grp",
"thingy\\tileset\\platform\\dish02.grp",
"thingy\\tileset\\platform\\dish03.grp",
"thingy\\tileset\\platform\\glob01.grp",
"thingy\\tileset\\platform\\glob02.grp",
"thingy\\tileset\\platform\\glob03.grp",
"thingy\\tileset\\platform\\lbsign01.grp",
"thingy\\tileset\\platform\\lbsign02.grp",
"thingy\\tileset\\platform\\lbsign03.grp",
"thingy\\tileset\\platform\\lbsign04.grp",
"thingy\\tileset\\platform\\lbsign05.grp",
"thingy\\tileset\\platform\\lbsign06.grp",
"thingy\\tileset\\platform\\lbsign07.grp",
"thingy\\tileset\\platform\\lbsign08.grp",
"thingy\\tileset\\platform\\refinery.grp",
"thingy\\tileset\\platform\\spthin01.grp",
"thingy\\tileset\\platform\\towr01.grp",
"thingy\\tileset\\platform\\towr02.grp",
"thingy\\tileset\\platform\\tree01.grp",
"thingy\\tileset\\platform\\tree02.grp"
}


"install.wpe":
{
"thingy\\tileset\\install\\\clplat1t.grp",
"thingy\\tileset\\install\\\clplate1.grp",
"thingy\\tileset\\install\\\clplate2.grp",
"thingy\\tileset\\install\\\crdoor1.grp",
"thingy\\tileset\\install\\\dcfan1.grp",
"thingy\\tileset\\install\\\dcfan2.grp",
"thingy\\tileset\\install\\\dcgun1.grp",
"thingy\\tileset\\install\\\dcgun2.grp",
"thingy\\tileset\\install\\\dicran1.grp",
"thingy\\tileset\\install\\\dicran2.grp",
"thingy\\tileset\\install\\\dicran3.grp",
"thingy\\tileset\\install\\\dicran4.grp",
"thingy\\tileset\\install\\\didoor1.grp",
"thingy\\tileset\\install\\\digear1.grp",
"thingy\\tileset\\install\\\digear2.grp",
"thingy\\tileset\\install\\\dihatc1.grp"
}

"ashworld.wpe":
{
"thingy\\tileset\\ashworld\\hasroc01.grp",
"thingy\\tileset\\ashworld\\hasroc02.grp",
"thingy\\tileset\\ashworld\\hasroc03.grp",
"thingy\\tileset\\ashworld\\hasroc04.grp",
"thingy\\tileset\\ashworld\\hasroc05.grp",
"thingy\\tileset\\ashworld\\hasroc06.grp",
"thingy\\tileset\\ashworld\\lalroc01.grp",
"thingy\\tileset\\ashworld\\lalroc02.grp",
"thingy\\tileset\\ashworld\\rock01.grp",
"thingy\\tileset\\ashworld\\rock02.grp",
"thingy\\tileset\\ashworld\\rock03.grp",
"thingy\\tileset\\ashworld\\rock04.grp",
"thingy\\tileset\\ashworld\\rock05.grp",
"thingy\\tileset\\ashworld\\rorock01.grp",
"thingy\\tileset\\ashworld\\rorock02.grp",
"thingy\\tileset\\ashworld\\rorock03.grp"
}

"jungle.wpe":
{
"neutral\\khyad01.grp",
"neutral\\temple.grp",
"thingy\\tileset\\jungle\\dd025.grp",
"thingy\\tileset\\jungle\\dd026.grp",
"thingy\\tileset\\jungle\\dd027.grp",
"thingy\\tileset\\jungle\\dd028.grp",
"thingy\\tileset\\jungle\\dd029.grp",
"thingy\\tileset\\jungle\\dd030.grp",
"thingy\\tileset\\jungle\\dd031.grp",
"thingy\\tileset\\jungle\\dd055.grp",
"thingy\\tileset\\jungle\\dd056.grp",
"thingy\\tileset\\jungle\\dd075.grp",
"thingy\\tileset\\jungle\\dd076.grp",
"thingy\\tileset\\jungle\\dd077.grp",
"thingy\\tileset\\jungle\\dd078.grp",
"thingy\\tileset\\jungle\\dd079.grp",
"thingy\\tileset\\jungle\\dd080.grp",
"thingy\\tileset\\jungle\\dd081.grp",
"thingy\\tileset\\jungle\\dd091.grp",
"thingy\\tileset\\jungle\\dd203.grp",
"thingy\\tileset\\jungle\\dd204.grp",
"thingy\\tileset\\jungle\\dd205.grp",
"thingy\\tileset\\jungle\\dd206.grp",
"thingy\\tileset\\jungle\\dd207.grp",
"thingy\\tileset\\jungle\\dd209.grp",
"thingy\\tileset\\jungle\\dd210.grp",
"thingy\\tileset\\jungle\\dd211.grp",
"thingy\\tileset\\jungle\\hdrock01.grp",
"thingy\\tileset\\jungle\\hdrock02.grp",
"thingy\\tileset\\jungle\\hdrock03.grp",
"thingy\\tileset\\jungle\\hdrock04.grp",
"thingy\\tileset\\jungle\\jubush01.grp",
"thingy\\tileset\\jungle\\jubush03.grp",
"thingy\\tileset\\jungle\\jubush05.grp",
"thingy\\tileset\\jungle\\ldtree01.grp",
"thingy\\tileset\\jungle\\ldtree02.grp",
"thingy\\tileset\\jungle\\ldtree03.grp",
"thingy\\tileset\\jungle\\ldtree04.grp",
"thingy\\tileset\\jungle\\tree01.grp",
"thingy\\tileset\\jungle\\tree02.grp",
"thingy\\tileset\\jungle\\tree03.grp",
"thingy\\tileset\\jungle\\tree04.grp"
}


"desert.wpe":
{
"thingy\\tileset\\desert\\HDbant.grp",
"thingy\\tileset\\desert\\hdbbroke.grp",
"thingy\\tileset\\desert\\hdbgas.grp",
"thingy\\tileset\\desert\\HDBmed.grp",
"thingy\\tileset\\desert\\HDBMoss.grp",
"thingy\\tileset\\desert\\HDBTent.grp",
"thingy\\tileset\\desert\\HDLbox01.grp",
"thingy\\tileset\\desert\\HDMachn2.grp",
"thingy\\tileset\\desert\\HDPlnt03.grp",
"thingy\\tileset\\desert\\JGBcomm.grp",
"thingy\\tileset\\desert\\jgbfact.grp",
"thingy\\tileset\\desert\\jgbgas.grp",
"thingy\\tileset\\desert\\JGBgen.grp",
"thingy\\tileset\\desert\\JGBRed.grp",
"thingy\\tileset\\desert\\jgbroke.grp",
"thingy\\tileset\\desert\\JGBsgn.grp",
"thingy\\tileset\\desert\\jgbtent.grp",
"thingy\\tileset\\desert\\JGPlnt01.grp",
"thingy\\tileset\\desert\\JGPlnt02.grp",
"thingy\\tileset\\desert\\LDBaz.grp",
"thingy\\tileset\\desert\\ldbgas.grp",
"thingy\\tileset\\desert\\ldbgren.grp",
"thingy\\tileset\\desert\\ldbneon.grp",
"thingy\\tileset\\desert\\ldbsuky.grp",
"thingy\\tileset\\desert\\LDBTent.grp",
"thingy\\tileset\\desert\\LDLbox01.grp",
"thingy\\tileset\\desert\\LDMachn1.grp",
"thingy\\tileset\\desert\\LDneon.grp",
"thingy\\tileset\\desert\\LDPlnt04.grp",
"thingy\\tileset\\desert\\sarlacc.grp"
}


"ice.wpe":
{
"thingy\\tileset\\ice\\hdbld01.grp",
"thingy\\tileset\\ice\\hdbld02.grp",
"thingy\\tileset\\ice\\hdbld03.grp",
"thingy\\tileset\\ice\\hdbld04.grp",
"thingy\\tileset\\ice\\HDPipes.grp",
"thingy\\tileset\\ice\\HDradarl.grp",
"thingy\\tileset\\ice\\HDradarR.grp",
"thingy\\tileset\\ice\\hdradr02.grp",
"thingy\\tileset\\ice\\hdrock01.grp",
"thingy\\tileset\\ice\\HDRock02.grp",
"thingy\\tileset\\ice\\HDSpire.grp",
"thingy\\tileset\\ice\\hdstre01.grp",
"thingy\\tileset\\ice\\hdstre02.grp",
"thingy\\tileset\\ice\\hdstre03.grp",
"thingy\\tileset\\ice\\HDSTre04.grp",
"thingy\\tileset\\ice\\hdtwr01.grp",
"thingy\\tileset\\ice\\hdtwr02.grp",
"thingy\\tileset\\ice\\jgant1.grp",
"thingy\\tileset\\ice\\ldbld01.grp",
"thingy\\tileset\\ice\\ldbld02.grp",
"thingy\\tileset\\ice\\LDBTre01.grp",
"thingy\\tileset\\ice\\LDBTre02.grp",
"thingy\\tileset\\ice\\ldbtre03.grp",
"thingy\\tileset\\ice\\ldbtre04.grp",
"thingy\\tileset\\ice\\LDComm.grp",
"thingy\\tileset\\ice\\LDDish.grp",
"thingy\\tileset\\ice\\LDDtre01.grp",
"thingy\\tileset\\ice\\lddtre02.grp",
"thingy\\tileset\\ice\\LDRck01.grp",
"thingy\\tileset\\ice\\LDRck02.grp",
"thingy\\tileset\\ice\\LDRdr01.grp",
"thingy\\tileset\\ice\\LDRdr02.grp",
"thingy\\tileset\\ice\\LDRdr03.grp",
"thingy\\tileset\\ice\\ldsmrock.grp",
"thingy\\tileset\\ice\\ldthing.grp",
"thingy\\tileset\\ice\\RJBTree1.grp",
"thingy\\tileset\\ice\\RJBTree2.grp",
"thingy\\tileset\\ice\\rjbtree3.grp",
"thingy\\tileset\\ice\\rjbtree4.grp"
}

"twilight.wpe":
{
"thingy\\tileset\\twilight\\JTree01.grp",
"thingy\\tileset\\twilight\\JTree02.grp",
"thingy\\tileset\\twilight\\JTree03.grp",
"thingy\\tileset\\twilight\\JTree04.grp",
"thingy\\tileset\\twilight\\jtree05.grp",
"thingy\\tileset\\twilight\\ldarch.grp",
"thingy\\tileset\\twilight\\lddrill.grp",
"thingy\\tileset\\twilight\\LDxel01.grp",
"thingy\\tileset\\twilight\\ldxel02.grp",
"thingy\\tileset\\twilight\\ldxel03.grp",
"thingy\\tileset\\twilight\\LDxel04.grp",
"thingy\\tileset\\twilight\\LDxel05.grp",
"thingy\\tileset\\twilight\\LDxel06.grp",
"thingy\\tileset\\twilight\\LDxeltur.grp",
"thingy\\tileset\\twilight\\rstatue.grp"
};
I'm not really sure which one tank matches with because it works with most of them. I picked badlands because it is sort of a default and also it seemed to show some shadow detail that didn't seem present on other tileset palettes.

Post has been edited 2 time(s), last time on Mar 26 2022, 10:42 pm by FaRTy1billion.



TinyMap2 - Latest in map compression! ( 7/09/14 - New build! )
EUD Action Enabler - Lightweight EUD/EPD support! (ChaosLauncher/MPQDraft support!)
EUDDB - topic - Help out by adding your EUDs! Or Submit reference files in the References tab!
MapSketch - New image->map generator!
EUDTrig - topic - Quickly and easily convert offsets to EUDs! (extended players supported)
SC2 Map Texture Mask Importer/Exporter - Edit texture placement in an image editor!
\:farty\: This page has been viewed [img]http://farty1billion.dyndns.org/Clicky.php?img.gif[/img] times!

Mar 28 2022, 8:06 pm DarkenedFantasies Post #17

Roy's Secret Service

Quote from O)FaRTy1billion[MM]
I'm not really sure which one tank matches with because it works with most of them. I picked badlands because it is sort of a default and also it seemed to show some shadow detail that didn't seem present on other tileset palettes.
Badlands is the closest match, but it's not perfect. It looks to me like it might've been rendered with an older version of the badlands palette sometime during development because of how some of the pixels are clashing with the surrounding colors, most notably the black pixels on the body and the brighter yellow pixels on the turret mount. When attempting to repair the graphic for myself, I had to manually recolor the tileset-specific indexes using the siege mode graphic as a reference to get a better end result (as opposed to purely reindexing the image with gamebasic).




Apr 6 2022, 9:16 pm andreasvz Post #18



Somehow if I understood one specific palette the next one shows up that is so different from the others. :-)

wirefram.grp
tranwire.grp
grpwire.grp

I assume (from name) that it must be something with game\\twire.pcx palette. There're 24 palette positions. But what is the logic of that wireframe images?

And it seems Starcraft colors the wireframe images by some "damage logic":

https://liquipedia.net/commons/images/1/16/TvT.png

So some parts are green/red/yellow. Any ideas how Starcraft decides which part of the image has which color by damage level?

regards
Andreas



None.

Apr 7 2022, 4:46 am DarkenedFantasies Post #19

Roy's Secret Service

The *fram.grp images are colored with palette indexes 192-193 for the shields outline, 208-211 for the normal wireframe style (with random coloring), and 216-219 for the heatmap style (like zerg).

According to the amount of missing health/shields, these pixels are remapped to the following positions in twire.pcx (beginning with full HP from the left):

192 (inner shields): 3, 4, 5, 6, 7, 8, 9, 2
193 (outer shields): 4, 5, 6, 7, 8, 9, 2, 2
208-211 (wireframe sections): 1, 0, 10
216 (bright inner heatmap): 0, 1, 1, 19, 19, 14
217 (dark inner heatmap): 1, 18, 18, 11, 11, 6
218 (bright outer heatmap): 18, 20, 20, 10, 13, 7
219 (dark outer heatmap): 10, 12, 16, 16, 6, 8

Positions 15, 17, and 21-23 in twire.pcx appear to be unused, at least under normal circumstances.

Quote from andreasvz
So some parts are green/red/yellow. Any ideas how Starcraft decides which part of the image has which color by damage level?
Each unit has a random number assigned to it which determines the pattern in which it will be colored. However, I don't know what the algorithm is for which index gets colored and whatnot.




May 13 2022, 10:39 pm andreasvz Post #20



Thanks for all your information. This helped me to implement more features in the Stargus data exporter tool and also new needed features in stratagus upstream.

I documented in the project intern Wiki what I learned here:
https://github.com/andreas-volz/stargus/wiki/Starcraft-Palettes

If I need to learn more I'll ask more. :-)

If you have feedback or corrections based on this page I'd like to hear.



None.

Options
  Back to forum
Please log in to reply to this topic or to report it.
Members in this topic: None.
[09:37 pm]
GGmano -- maybe its not about the size i guess since its now above 6000 and was saved
[09:05 pm]
GGmano -- just seems like 6000kb is an obstacle not sure
[09:05 pm]
GGmano -- idk it could also be about the map size its like above 6k kb map wont be saved,, 6000kb of triggers no sounds im aware sounds can go beyond that size
[08:51 pm]
GGmano -- heres link for the new release http://www.staredit.net/topic/18475/#1
[08:51 pm]
GGmano -- i now released it after deleting triggers 3 times sadly
[08:50 pm]
GGmano -- 100k i think
[03:39 pm]
Oh_Man -- how many trigs u got?
[09:34 am]
GGmano -- there must be a limit for one player on triggers but also a max trigger in total i think
[09:33 am]
GGmano -- after deleting alot og triggers i now have to reduce it even more
[09:33 am]
GGmano -- damn my file still too big but it doesnt crash only gives message that it cant save to disk,, freaking sad that i wanted to do more stuff but im limited here
Please log in to shout.


Members Online: Oh_Man