What is a GRP?
In StarCraft, graphics are stored in one of many ways. There are PCX files to store menu backgrounds and race control panel graphics. SMK files are used to store the cinematics and portrait animations. GRP files are StarCraft's format for storing the frames for the graphics of all the units, weapons, spells, doodads, wireframes and several other things. With your knowledge of patching the MPQ, the help of a GRP converter program and also a little bit of wisdom about GRP files, you will be able to change a lot of the graphics in StarCraft.
As the name suggests, GRP is short for "Group." It's called this because GRP files can contain many frames. For example, the GRP file of the Terran Medic has 230 frames, all of these stored in the same GRP file. Each GRP file will contain a different number of frames. The Zerg Lurker has 595 frames, while Psionic Storm only has 14 frames. It all depends on what the GRP file represents.
There are so many ways to edit GRP files, but they all come down to three main activities. Decompiling, editing and compiling. Decompiling a GRP is converting a GRP into all of its source images, and compiling is doing the reverse, that is going from a number of source images and converting them into a GRP. Editing is the part where you create or edit frames for your GRP file. This tutorial will give you instructions on how to use RetroGRP with WinMPQ and your graphics package to perform those three activities. Make sure you got both of these programs to get the examples in this tutorial working. You will also need to setup WinMPQ to use a listfile, UED77's MPQ Listfile is a good enough choice of listfile for the purpose of GRP editing.
RetroGRP is very easy to use and works very well at decompiling and compiling GRPs, but it has a few things to look out for when you use it. First, if you run RetroGRP and you get a message saying "Errrrrror" then just click OK and ignore it. It's not a particularly inviting message, I know. What this is trying to tell you, albeit not doing a very good job of that, is that it can't read anything from StarCraft's MPQ file. Fear not, you won't be using any of RetroGRP's MPQ extracting features in this tutorial, as that is what we use WinMPQ for. So just click OK and ignore it.
In RetroGRP's interface, there are only four buttons you should be concerned about. Those are Load External File, Set Output Directory, Write Out BMPs and Compile to GRP. Here's a picture pointing out where to find these buttons:
Extracting a GRP from the MPQ
You can't decompile a GRP file unless you have a GRP file to start with. One of the most common places that we find GRP files is in StarCraft's MPQ. To be able to find GRP files, the first thing you need to make sure you have is a listfile. The interesting thing about the MPQ format is it has no filenames in it, and so generally if you open up an MPQ in WinMPQ, without a listfile to resolve filenames, you'll just get a list of files with unknown filenames. If this sounds like what you're getting, check out the FAQ question Whenever I open up an MPQ in WinMPQ, all I get is a list of unknowns! to see how to solve this.
Now that you've got filenames displaying, the question is, where do you look to find the GRP files you want? Here is a quick guide on where to look to find GRP files.
* StarCraft original unit graphics will be found in StarDat.MPQ, and Brood War unit graphics will be found in BrooDat.MPQ. * Unit graphics will be stored under unit\terran\*.grp, unit\protoss\*.grp, unit\zerg\*.grp or unit\neutral\*.grp. * Weapon and spell graphics can be found under either unit\bullet\*.grp or unit\thingy\*.grp. * Doodads are generally found under unit\thingy\tileset\<tilesetname>\*.grp. * Command button graphics are stored in unit\cmdbtns\cmdicons.grp. * Wireframes are stored in three different files. Normal large wireframes are stored in unit\wirefram\wirefram.grp. The wireframes used when units are selected in a group are stored in unit\wirefram\grpwire.grp. Wireframes for units in a transport are found in unit\wirefram\tranwire.grp.
That is the quick guide. However, there are 782 GRP files in StarDat.MPQ, and so sometimes searching for a particular GRP file manually takes some time. There is a way to go from a arr\units.dat or arr\weapons.dat ID and go directly to its GRP file name without having to search. Obviously there has to be references from the DAT files to tell StarCraft which graphic file to use for which unit. However, that is another tutorial and so will be explained at a later date.
Once you've found the GRP file you're looking for, extract the GRP file to a place where you will remember and next we'll learn how to decompile it.
Decompiling a GRP file
Decompiling a GRP file is quite straightforward, you just need to follow these steps:
Now you're finished. You can close RetroGRP down and look at your frames in your output folder now. The filenames will come from the source GRP file name. So if you decompiled the Wraith's graphics in phoenix.grp, you will get a bunch of frames called phoenix000.bmp, phoenix001.bmp, phoenix002.bmp up until phoenix016.bmp. You will also notice there is a phoenix.ral file. This is just a text file which RetroGRP uses to keep track of frames in a GRP if you try to compile them again. You'll find about it more in the compiling a GRP section.
Editing GRP Frames
There are some very important things to know about frames in a GRP file if your editing is going to be successful. Two quick facts you need to know are, all the frames in the GRP file must be the exact same size, and RetroGRP frames need to be in 256 color (8-bit) BMP files with RLE (run-length encoding) on.
Also, if you extract a number of GRP files for units, you might notice that a lot of the time, frames come in matching sets of 17. In the first frame, the unit faces north and in the seventeenth frame it faces south, and all the frames in between are of the unit rotating clockwise through the 180 degrees between north and south. Since there are only frames of the unit pointing north, south and east, you probably have already worked out that StarCraft flips the graphics to display graphics pointing west. Not all units are like this though. Only if the images.dat entry for the GRP file has the "GFX Turns" property set to 1 in Arsenal Zero will StarCraft expect sets of 17 rotated frames.
Naturally enough, if your graphics are meant to turn, then you need to make sure your frames come in sets of 17. For some units, there are frames that turn and frames that do not turn, and this works out fine as long as the angled sets of 17 come first in the order of frames. For example, the Templar is a unit that turns, and so it has sets of 17 rotated frames for each of its various poses, but after all the rotating frames it has its death animation frames, and those do not rotate. This works because the non-rotating frames are at the end.
Lastly, you need to know about how the color palette works. The number one fact to remember here is: no color palette is saved in the GRP file, the only thing that StarCraft sees is an array of color indexes. So, unlike what a lot of GRP tutorials say, in this tutorial I'll tell you that it is not important to get the colors exactly the same as you see them in Blizzard's GRP files. In fact, there are many times when I have been editing GRP files where I've used a completely different color palette to the ones that most people are used to. The reason the GRPs still work is because the actual color palette you used is not saved to the GRP file. The only thing that is important is that you get the color indexes right.
The color palette used to interpret each color index is set by the images.dat file for most things. Note that color palettes change slightly depending on the tileset. When you decompile a GRP file, each of the BMP frames that are extracted have RetroGRP's default palette included with them. RetroGRP's default palette does not always suit the graphic, but at the moment it is the only palette we have to use. Someone is yet to still create/extract a palette for explosions, map tiles and a few other things. For units and weapons though, RetroGRP's palette works fine. This is what it looks like:
If you're using Photoshop, bring up the Info palette first and go to Image > Mode > Color Table. Now whenever you hover your mouse over a color, the Info palette will update with the color index and other info about the color your pointer is hovering over. A few of these color indexes are special, and you might find them useful for the GRP you are editing.
* Color #0 is the transparency color. * Colors #8-15 will be converted to the current player's team colors. * Colors #192-193 indicate where to draw the Protoss shields for a wireframe. Color #192 is drawn darker and less obvious than #193, and so in the Blizzard GRPs #193 is used for the main shield and #192 is drawn just inside it. * Colors #208-211 are the Terran/Protoss hit point wireframe colors. * Colors #216-219 are the Zerg hit point organic wireframe colors.
Just a quick note about transparency. Since for the main unit palette, transparency in StarCraft is a boolean on or off, there is no anti-aliasing for StarCraft graphics. So, to make your units seem less jagged, do what Blizzard does and fade or "matte" your edges to a dark color.
The wireframe HP colors are very tricky. If you look hard, you'll notice that each of the four colors at the special indexes #208-211 appear three times in other places on the color palette, most noticeably at 216, 217, 218 and 219. What you will find is, in a lot of graphics programs, if you choose color #208 on the palette and start drawing your wireframe with it, then use your Info palette or something similar, you'll find the actual color that gets drawn on the image is #135. This is because, in RetroGRP's palette, color #208 has the RGB values of 252, 252, 56. The exact same RGB values can be found at indexes 216 and 135. To deal with the situation of the same color appearing multiple times in the same color palette, most graphic design programs just take the first index that matches the color you're drawing with, which happens to be #135. In this palette, the color would be right, but the index would be wrong, and so you'd most probably find your wireframe would not change with your unit's health.
One way to fix this is to edit the color table and change the colors at #208-211 to unique colors, or the #216-219 colors if that is what you're using. To change a color in the color table in Photoshop, open the color table by going to Image > Mode > Color Table and double click on a color to change it. Remember, the color palette you use is not saved to the GRP file, so even if it looks funny in your editor, it will give you the correct color indexes and therefore the correct colors when you play StarCraft.
Compiling GRP Frames
To compile a GRP, RetroGRP needs to have a list of images to use for frames, and it also needs to know what to save the compiled GRP as. RetroGRP lets you specify these parameters in a RAL file. You might have noticed a RAL file when you were extracting GRP frames that was created by RetroGRP. This can be used to save time. But it is not necessary to get RetroGRP to create you a RAL file for compiling GRPs, otherwise things would be very restrictive. Often you will be editing RetroGRP's RAL file, and sometimes you might even be creating your own from scratch. It is useful to look at this just to learn what a RAL file needs in it. Here's the RAL file RetroGRP creates for the Terran Barracks GRP, tbarrack.grp:
tbarrack.grp tbarrack000.bmp tbarrack001.bmp tbarrack002.bmp tbarrack003.bmp tbarrack004.bmp tbarrack005.bmp tbarrack006.bmp tbarrack007.bmp tbarrack008.bmp
The structure is quite simple. On the top line is the filename. When you compile a GRP, RetroGRP will save it to your output directory with this filename, except it will be prepended with an "x_". So because this RAL file has tbarrack.grp on its top line, when I use this RAL file to compile frames, the resulting file will have the filename x_tbarrack.grp. After the filename, all of the frame BMP files are listed, one per line. These filenames refer to files the same folder as the RAL file.
So to compile a GRP file from your frames:
* Either create a RAL file for your frames, or if you based your graphics editing on a GRP file you extracted, you can use the RAL file RetroGRP created for you when you extracted the GRP. You will have to edit the RAL file if you want to change frame filenames. * Run RetroGRP. * Click Set Output Directory and choose the folder where you want the final GRP to be created. * Click Compile to GRP and choose the RAL file you're going to use. * RetroGRP will compile your GRP and save it to the output folder you selected. Remember it will just have the filename you specified in the RAL file, just with an "x_" at the start.
Where to from here?
Now you know how to edit GRP files, what should you learn next? Let me give you a situation.
You can probably imagine that, during the lifetime of a Terran Medic, the frames for the Terran Medic will not be played in sequence, and some of them will often be repeated. For instance, the frames of the medic walking will be played over and over again while the medic walks, and the same happens when the medic is healing. However, the frames for the medic's death will only ever be displayed once. There will also be sounds that need to be synchronised to the display of particular frames. For all of this to work, the order in which the frames are displayed and when each of the sounds must be played is controlled by the scripts\iscript.bin file, the powerhouse of sprite animation in StarCraft.
So, editing GRP files is just half the battle. To really take control of animation means you will need to combine your GRP converting skills with scripts\iscript.bin editing skills. Learning about the ins and outs of scripts\iscript.bin will also lead you onto leading a lot about other graphic-controlling files.
Thank you to Jeremy Bake, a.k.a. RetroActive for creating the program RetroGRP which was used in this tutorial, and also to ShadowFlare for creating WinMPQ. Credits also go to UED77 for putting together that ever-so-useful listfile. Thank you to the Starchitects, the people who have given me the reasons to create this tutorial, and most of all, thank you to you for taking the time to read this tutorial.
Want access to cool stuff? As a member you can: