Meaning of the unknown values in the TD shp header.

[Blade]

For those who don't know, the Shp header looks something like:

 

struct ShapeHeaderStruct {

  word FrameCount;

  word Unk1;

  word Unk2;

  word Width;

  word Height;

  word MaxFrameSize;

  word Flags;

}

 

This is pretty much the same as the WSA header where the two unknown entries are the X and Y position in a 320x200 canvas that the top left of the animation should be drawn from, but of course shp files can be drawn anywhere. Why then do they seem to have random values that differ between many shp files?

 

This has bothered me for a while as the game doesn't seem to use the read values from the file at all, so what do they mean? Well, it turns out that all shp files started life drawn on a 320x200 image surrounded with a bounding box (probably the rendered output form whatever 3d program they were created in). The WW shp creating tool would detect the bounding box and crop the image and would record the original X and Y position of the top left pixel in the shp header.

 

"Wait a minute!" I hear you cry, "How can you possibly know that"? Well it is something of an inference, but the two pieces of evidence are that 1. The TS/RA version of the shp tool was leaked and can do the cropping I describe and 2. There is an example of an uncropped shp image available along with its correctly cropped version to compare. The French and German versions of aftermath (and the 3.03 patch) contain a faulty uncropped version of carr.shp, the unused helicarrier unit. Compared against the corrected English version you can see that the unknown header values in the correct version match the location of the top left pixel where it would have been cropped in the uncropped version.

 

All of this is of course somewhat useless. The game doesn't seem to use the information and so custom shp files don't need to set these values to anything particular. The only real use might be figuring out where units and structures were in the original 3d scene when it was rendered for anyone that wanted to recreate the models and scene exactly. Other than that it simply serves to solve another mystery of these old data formats.

[Allen262]

I guess that is good to know? It is one of many mystery put to rest.

[Nyerguds]

Doesn't the actual compression format already have that though? I remember it only storing a cropped image, and containing an X and Y value to paint the decompressed image on the final SHP frame.

 

On a related note, Dune II supports SHP files with different sizes per frame. Do you have any idea of the C&C format also allows that, somehow?

 

Oh, and where is that leaked tool? I never heard about that.

[Blade]

http://www.ppmforums.com/viewtopic.php?t=38429 is the thread where you can find the leaked tool for TS/RA2 format shp files.

 

Only the RA2 format has info on where to draw a frame, it saves the overall dimensions that the shp should be drawn to, but can save smaller dimensions and sub frame position for each frame.

 

The Dune2 format is more like a collection of individual images, each with their own header, the TD format has all the dimension information in the file header, frames only have info on what compression format they use. As a result all frames must be the same size.

 

The information in the TD X and Y fields appears to be completely ignored in at least RA (though I suspect the same is true of TD and SS as well), it is overwritten in memory by information related to how the game is buffering the image as far as I can tell. The values set in the file appear to only be leftover from the processing of the original images used to generate the shp.

[Nyerguds]

Interesting. Thanks for elaborating

 

Ah yes, of course. Tomsons' thread. I remember now. That wasn't any image-to-SHP tool though, but a straight 3D-model-to-SHP one O_o

[Blade]

Its an image to shp tool, it expects the models to be rendered out first to pcx IIRC.