Quote:Original post by asp_

Quote:
struct MyStruct
{
char name[32];
int a;
short b;
float c;
};
.
.
MyStruct data;
.
.
fwrite(&data, sizeof(a), 1, myFile);

Never simply dump a structure to file like this. Write each field separately because the structure will contain padding between fields in order to align data effectively. This means you'll end up writing crap to the file and the padding may be different between platforms.

Never say never. If you're doing it for a file that will only ever be loaded by a particular platform (and you should be using platform-specific data files for best performance), then the padding will always be the same, and this kind of direct memory read/write is precisely what you should be doing if you want good load/save times.

Quote:Original post by asp_

Quote:
struct MyStruct
{
char name[32];
int a;
short b;
float c;
};
.
.
MyStruct data;
.
.
fwrite(&data, sizeof(a), 1, myFile);

Never simply dump a structure to file like this. Write each field separately because the structure will contain padding between fields in order to align data effectively. This means you'll end up writing crap to the file and the padding may be different between platforms.

Using compiler packing hints can go along way to ensureing that this works correctly if you need to do this in a cross platform way.

Cheers
Chris

Quote:Original post by asp_
If I would venture a guess I doubt your bottleneck would ever be that code, no matter if you split it to one call per field. I doubt there's any sane reason to do it except for lazyness.

On certain platforms - mainly consoles like the PS2 - it's much more efficient to schedule a single large read than lots of small ones. These are systems with very little in the way of filesystem cache; they are designed to stream data in from discs as quickly as possible, without any stopping/starting or faffing about.

If you really can't cope with it, you could read the data into a buffer and then 'read' that buffer out member by member, but there's really no need.

It's not lazyness, it's Sony/MS/Ninty telling you that if your game takes longer than X seconds to load a level, they won't let you release it.

Quote:It's also not just platform specific but compiler specific and affected by a lot of factors such as build settings and so on.

Yes, it's compiler specific (and in fact, as a result it's not platform specific, if you run the same binary on two different platforms the padding will not change), but it's still deterministic. If you know what the padding is like, you can account for it. Repacking and converting assets into the most efficient layout/format for a given platform is a common practice for cross-platform titles (e.g. DDS on Xbox vs. TM2 on PS2), and writing out datastructures with the correct amount of padding is frequently rolled into that.

Quote:Original post by Zahlman

Quote:Original post by chollida1

Quote:Original post by asp_

Quote:
struct MyStruct
{
char name[32];
int a;
short b;
float c;
};
.
.
MyStruct data;
.
.
fwrite(&data, sizeof(a), 1, myFile);

Never simply dump a structure to file like this. Write each field separately because the structure will contain padding between fields in order to align data effectively. This means you'll end up writing crap to the file and the padding may be different between platforms.

Using compiler packing hints can go along way to ensureing that this works correctly if you need to do this in a cross platform way.

Cheers
Chris

Uh, compiler packing hints are highly compiler-specific, and not all compilers are available on all platforms. That's quite opposed to "cross-platform". The "cross-platform", and proper, way is to read and write members individually. Zomg!

Very much agreed that compiler hints are OS specific:) Perhaps I wasn't clear in my point. By using compiler pragma's you can ensure that the structure's packing is in a format you know.

Now that you know the packing you can read back in the file with one read on any OS:)

Actually SuperPig summed up my point very well in his post above.

Quote:
Yes, it's compiler specific (and in fact, as a result it's not platform specific, if you run the same binary on two different platforms the padding will not change), but it's still deterministic. If you know what the padding is like, you can account for it. Repacking and converting assets into the most efficient layout/format for a given platform is a common practice for cross-platform titles (e.g. DDS on Xbox vs. TM2 on PS2), and writing out datastructures with the correct amount of padding is frequently rolled into that.

Cheers
Chris