Re: [FreeWRL-develop] Testing update

[doug s. <hig...@ho...>]

>> Further, I commented the code that was writing the header file of the
>> bmp file and that seemed to generate more stable results across runs.
>> At least I don't have any bit differences between runs.
>
> The header issue is puzzling to me. I should have zeroed the header, and put only useful stable numbers in it. There are a few gotchas that I didn't look into: struct alignment -if a compiler pads a struct to an even 8 bytes then I write out the struct as a binary blob I'll get padding, which is bad. And intel vs motorola byte ordering - I'm not sure how to fix that.
>
> 64 BIT VS 32 BIT, INTEL VS MOTOROLA
>


When I look at other code, they have a technique for writing binary ints in a standard way:
charbuf[0] = (my32bitint & 0x000000ff)>> 0x00;
charbuf[1] = (my32bitint & 0x0000ff00)>> 0x08;
charbuf[2] = (my32bitint & 0x00ff0000)>> 0x10;
charbuf[3] = (my32bitint & 0xff000000)>> 0x18;
which looks like it would put it in least to most significant digit order -little endian as wintel (windows + intel) is natively, birthplace of the .bmp file format- in the character buffer whatever the endianness of the platform, and converting to char* variable by variable would avoid 64 bit struct padding/alignment.

I didn't do that. I'll put it on my to-do list.
-Doug