PocketMatrix

Ok folks, my brain must be completely asleep today because this one is stumping me big-time...

I have a function that writes out 83 bytes of information for my game. All of the data, except for six fields, are unsigned char's (simple flags and options, a couple of coordinates that are always 0-255, etc). I have a buffer defined as...

unsigned char* outBuffer = (unsigned char*)malloc(83);

...that I put all the data into, then write it out. It works perfectly well for just about all of the data I'm working with, no problem.

However, the six fields I alluded to are DWORD variables, so of course that's the equivalent of 4 unsigned char's.

Here's my question... how do I write them out to my file (really, how do I insert them into my buffer) without losing precision? The code I'm using for the other fields is basically:

int indexer = 0;
*(outBuffer + indexer++) = (unsigned char)volumeLevel;
*(outBuffer + indexer++) = (unsigned char)currentGameLevel;
// ... and so on...

...for the most part the casts aren't necassery, but since some of the variables are actualy ints (that are always in the range of an unsigned char anyway), I do it all the time just to be safe. I of course can't just casts a DWORD to an unsigned char because I'd lose information.

So, I guess another way of asking this is how can I break a DWORD into the four bytes that make it up, write them out, and then re-constitute the four bytes into a DWORD when I read the file back in?

TIA!

You are right about the different endianess problem and the varying sizes of data types on different platforms. I really haven't had much of a problem with this for PPC-PC programs. It has come up before though, in which case I ended up using #ifdef's for certain reads for the alternate data size. And of course you have to take care of TCHAR factors since sometimes the PC can treat a TCHAR as a char or as an unsigned short.

But in general, particularly the various integer types, I haven't had any problems for portability from PPC to PC and back. Oh and I generally use _tfopen as opposed to fopen. But aside from that, I don't see any functions in what I posted that I haven't used in both evC and visual studio.

Another thing I do is avoid using 'int' explicitly as a data type since that has been documented as varying in size. At least for variables that I intend to fwrite. Thusly I often use long or short etc, or have typedefs for 8-,16-,and 32-bit integers so that I can get some form of consistency in size.

JJB

Yes, it seems to do the trick for me too. I found the _tfopen function too. I suppose this all only really becomes and issue if you want to transfer files from platform to platform. I mean, if I write an int out on a given device, and I read it back in later, I don't see how it's endedness matters, or what actually gets written, or what the size of an int is (assuming it wouldn't matter otherwise of course). As long as the value of my int after I read it back in matches the int I wrote out, the rest I don't hink matters much.

Thanks guys, that made my code a lot easier to look at!