Could be but I thought all RGB's were DWORDs - it's just that the BMP format puts a 0 in what would be the alpha channel.
So 24-bit color is still 32-bit except there are 8 bits that are not used. But since it's easy to do a rep stosd using DWORDs or 4 bytes, even though 8 bits are not used, they are still written to and/from disk/memory.
Code:#define RGBA(r,g,b,a) (DWORD)( (r<<24) + (g<<16) + (b<<8) + (a) ) #define ARGB(r,g,b,a) (DWORD)( (a<<24) +(r<<16) + (g<<8) + (b) ) #define RGBX(r,g,b) (DWORD) (r<<24) + (g<<16) + (b<<8) ) #define RGB(r,g,b) RGBX(r,g,b) #define RGBH(r,g,b,h) (RGBA(r,g,b,h)) #define HRGB(r,g,b,h) (ARGB(r,g,b,h)) void FastCopy32(DWORD *Source,DWORD *Dest,DWORD Length) { asm { mov esi,Source mov edi,Dest mov ecx,Length rep movsd //To account for Length not being a factor of 4 - hanging bytes and ecx,03h rep movsb } }
Something like that. So from the assembly version you can see that even though we call it 24-bit color, it's still using 32-bits of information. Which is why I thought instead of just discarding the 8 bits, and if you do not need alpha, then put your height in those 8 extra bits. This will give you heights from 0 to 255. But you can scale these later using fixed point arithmetic or simple bit shifting and this will give you a much larger range. Ranges from 0 to 65535 should be all you need to accurately represent terrians. 0 to 255 is a bit limited and sometimes the changes in heights are quite noticeable. So just expand the data type, scale the heights, and save this information in your height map in memory. But on disk there is no need to save an unsigned short to disk when you can pack the byte equivalent of the height into the RGB structure.
Also remember that bitmaps are stored in order BGR, not RGB.
