Compiler wierdness

[Lazy]

After a few days of on/off work I have for the most part figured out the half-life sprite file format.
It would have been done faster except I kept missing the fact that even the first frame has a frame header instead of using the sprite header, anyway...

Here is what I have so far...

// Should be at the start of the file, identifies this as a sprite
const int HL_SPR_IDENTITY = ( int ) ( 'P' << 24 ) + ( 'S' << 16 ) + ( 'D' << 8 ) + ( 'I' );

// Half-life sprite file structure...
// ---------------------
// Header 42 bytes
// Palette 768 bytes
// Frame header 20 bytes
// Image data ( frame header->width * frame header->height )
// ...
// If you have more than one frame...
// Frame header 20 bytes
// Image data ( frame header->width * frame header->height )
// ...
// ... ect...

// Half-life sprite rendering modes, these determine how sprites are
// rendered by the engine.
enum hl_sprite_rendermodes_e {
   SPR_MODE_NORMAL = 0, // Normal rendering
   SPR_MODE_ADDITIVE,   // Black ( RGB 0, 0, 0 ) is transparent
   SPR_MODE_INDEXALPHA, // Last color in palette is the sprite's in-game color
   SPR_MODE_ALPHATEST   // Last color in palette is transparent
};

// Half-life sprite types, these determine how the sprite rotates
// when viewed by a player in-game.
enum hl_sprite_type_e {
   SPR_TYPE_ROTATE_Y_ONLY = 0,   // Sprite does not rotate on the X axis
SPR_TYPE_ONE_WAY,			 // Sprite faces one way and does not rotate ( NOTE: Not 100% sure on this )
SPR_TYPE_ROTATE_XY,		 // Sprite rotates to face the player on both the X and Y axis
SPR_TYPE_ONE_WAY2,		 // Odd, same as SPR_FACE_ONE_WAY except in a different direction
SPR_TYPE_ROTATE_XY2		 // Hmm, this seemingly does the same thing as SPR_FACE_ROTATE_XY
};

// Half-life sprite header.
// Still under research.
#pragma pack( 2 )
#pragma pack( show )
typedef struct hl_sprheader_s {
   char sprIdentify[ 4 ];  // 4 Character non null terminated file id. Should contain "IDSP"
   int iVersion;		   // Sprite version number. Should be 2.
   int iSpritetype;		// Type of sprite
   int iRendermode;		// Sprite render mode. See hl_sprite_rendermodes_e.
   int iUnknown4;		  // Offset? Actually no, it's something else...
   unsigned int iWidth;	// Width of sprite
   unsigned int iHeight;   // Height of sprite
   int iFramecount;		// Number of frames in sprite
   int iUnknown5;
   int iUnknown6;
   unsigned short iUnknown7;
} hl_sprheader_t;

// This structure seems to appear at the start of a new frame within the sprite.
// NOTES:
// This is a complete structure!
// Only alter when new type/use information is found.
typedef struct hl_sprframe_s {
   int iUnknown1;		  // Always seems to be 0
   int iUnknown2;		  // Always seems to be C0 FF FF FF
   int iUnknown3;		  // Always seems to be 1
   unsigned int iWidth;	// Width of frame
   unsigned int iHeight;   // Height of frame
} hl_sprframe_t;

There are quite a few unknowns but it doesn't look like they're needed to display the sprite.
But the problem I had was with the main sprite header ( hl_sprheader_t ).
What would happen is I added an unsigned short to the end of it because there are 2 still unknown bytes before the palette.
However, MSVC decided that it would make the short into 4 bytes.
That really threw everything off since the first 2 bytes of the palette were getting read into the header.

I guessed and found a solution with #pragma pack but it still doesn't feel right, can someone explain what is going on and if it will happen on a different compiler aswell?

[mirv]

(If I'm reading right...possible not considering I don't have my glasses on, am tired, and hungry) - I ran across a similar problem documented by Epic (for loading of their psk and psa files). For msvc at any rate, pragma was used, as by default it packs structs to 4byte sizes (i.e it'll pad data in the struct to the closest 4bytes). Not sure on what gcc does.
Another method I've used to ensure padding doesn't affect it is a little long-winded, but works. Simply read it all in a byte array, and use a few array offsets & memcpy. Takes a tad longer, more code, more complex, etc, but gives more precise control.

[Whistler]

there is a "struct member alignment" or something like that in the project options, not sure if it's problem with that.

[Lazy]

I see, but that has to be the dumbest thing I've had to deal with in a while.
What about someone expecting their struct to be say 42 bytes and the compiler makes it 44 instead, it drove me nuts because I thought I screwed up while figuring out the headers.
But some odd idea had me printf out the result of sizeof( hl_sprheader_t ) to check the size so I could look at it in the hex editor.

2 More quick things...

1. Since I more or less figured out the file format, am I free from valve's sdk license? ( never looked at the hlsdk for this, only created sprites in a hex editor )
2. Everything written more than 1 byte at a time has to be swapped if running on a machine with a different endianness? And if so, how do you tell which it was created on?

Thanks for the help so far.

[Whistler]

"1. Since I more or less figured out the file format, am I free from valve's sdk license? ( never looked at the hlsdk for this, only created sprites in a hex editor )"

If no significant part of your code is based on Valve's code, then I don't think Valve's license apply to your code. The file format itself AFAIK is not restricted.

[Pierre-Marie Baty]

I have absolutely no clue.
Perhaps you should ask this in the HLCoders mailing list ?

[Lazy]

I doubt they'd help someone who took time to figure out their file format just to get around licensing.

Besides, they don't respond/act on emails anyway.
I emailed them a hlds bug about a week ago and it still exists and I never got a reply.