Rule #1 of aligning data is to declare large struct/class members before smaller ones, so the individual members are aligned. Assuming your ints are 32 bits, they are all misaligned because of your 1st WORD declaration. Some compilers may try to fix this, but I wouldn't rely on them for this stuff.

It sounds like you're talking about making the entire struct an alignable size, which helps if you create an array of these structs, but if not then padding out the struct won't do much except waste space. And you can't actually have any struct be 13bits. It will, at an absolute minimum, be rounded up to byte alignment, 16bits.

Nowadays, with the 'ram is cheap' theory, you have to really look at why you would use 8 or 16 bit values over 32bit ones. Granted they should use less space (although I believe the compiler CAN still pad it out), it is slower for the CPU to handle 8/16 bit math than 32bit math. Modern CPUs are simply structured to work in 32bits, and other types of usage take a performance hit. I am certainly not a believer in the 'cheap ram' theory (good god WORD, how much ram to you waste!), but in games speed comes first, and 32bit values are fast. I try to keep all often used vars of 32bit size (and definately aligned!), such as coords, and usually try to keep flags and such that are used a few times per frame of type BYTE when possible. It seems to be a good tradeoff.

Rock

All things must be divisible into even bytes which is why an array of 2 bit structures will take the same space as an array of 1 byte structures, the machine can only address bytes. Rock2000 did hit on something though, without optimization a declaration like:
struct x
{
int xflags:3;
int count;
int yflags:2;
};
would take AT LEAST 6 bytes (even though it could be rewritten to fit in 5), and on some platforms it would actually have to be padded to TWELVE bytes, because often ints must be aligned on addresses divisible by
four.

Even if the struct was rewritten, it would still take 6 or 8 bytes due to the alignment rules for ints. The general rule is, worst case, data must be aligned on a boundry that is divisible by its size (so on 64 bit platforms pointers must be aligned on 8 byte boundries).

If your curious...just use sizeof(tagTile) without manually adding the nPadding field and you'll see what pading the compiler will force on you anyway.

Another note...this pading occurs no matter wheither you declare arrays of the struct, or just one, because the compiler must compute the sizeof() value...and the value can't change arbitrarily from one module to the next...so be careful to turn the compiler's pading on or off for ALL of your modules, or you won't be able to link them.

[This message has been edited by Xai (edited October 17, 1999).]

You are on the wrong side of optimisation, when you use [int x : 1] the compiler generates just an BYTE and has to generate lengthy code to access the one bit in this BYTE.
I suggest that you try to avoid these construts and use the base C/C++ types you have to use (for this example an bool).
Alingment is a very crucial thing in compilers, on 32Bit systems (all Pentiums, newer Apple machines), the compiler tries to align the structs and classes to a DWORD(4 Byte) to get better results when copying and accessing data. But this is done internally. The best you can do is make the structs multiples of DWORDs long, to get the best results.
By the way an int is in Win32 4 Bytes long. The right size for a register.

Aidan