9 réponses à ce sujet

[rjshae]

Does anybody know if the NWN2 mdb file format is always little-endian, even on the Mac?

[kevL]

i'm no expert, but have never heard of endianness changing to suit the OS.

 

if it did it wouldn't be the same file format ...?

[rjshae]

i'm no expert, but have never heard of endianness changing to suit the OS.

 

if it did it wouldn't be the same file format ...?

 

True, the file format would be the same, but values might be read incorrectly. A person using a Mac ran into an issue with a Python Unpack command, so my first hunch is an endianness issue such as reading in an array counter. I was thinking it might work to force little endian packs/unpacks, but I wasn't sure if the Mac MDB files had been reworked to support big endian behavior.

[kevL]

you mean, it's not so much an issue of file format, as whether files are being 'unpacked' differently on different OS

 

I imagine a low-level programmer could write a small app that tests that, compiled and run on the two OS's, hooked onto the output from Python - is it worth it, is there a workaround? Maybe it's an issue w/ Python itself + mac

 

... if it is an endian-thing at all. My first hunch would be that the Python script is a bit borky,

[Eguintir Eligard]

You guys are so racist

[rjshae]

You guys are so racist

 

I assume this is some reference to endianness.

[Tchos]

Big-endian vs Little-endian was an ideological conflict for how to eat boiled eggs, not race-based, in Gulliver's Travels.

[Dann-J]

You guys are so racist

 

One little, two little, three little endians...

[kevL]

i couldn't believe my eyes when I saw this:

#if SDL_BYTEORDER == SDL_BIG_ENDIAN
inline void FlcPlayer::readU16(Uint16& dst, const Uint8* const src)
{
    dst = (src[0] << 8) | src[1];
}
inline void FlcPlayer::readU32(Uint32& dst, const Uint8* const src)
{
    dst = (src[0] << 24) | (src[1] << 16) | (src[2] << 8) | src[3];
}
inline void FlcPlayer::readS16(Sint16& dst, const Sint8* const src)
{
    dst = (src[0] << 8) | src[1];
}
inline void FlcPlayer::readS32(Sint32& dst, const Sint8* const src)
{
    dst = (src[0] << 24) | (src[1] << 16) | (src[2] << 8) | src[3];
}
#else
inline void FlcPlayer::readU16(Uint16& dst, const Uint8* const src)
{
    dst = (src[1] << 8) | src[0];
}
inline void FlcPlayer::readU32(Uint32& dst, const Uint8* const src)
{
    dst = (src[3] << 24) | (src[2] << 16) | (src[1] << 8) | src[0];
}
inline void FlcPlayer::readS16(Sint16& dst, const Sint8* const src)
{
    dst = (src[1] << 8) | src[0];
}
inline void FlcPlayer::readS32(Sint32& dst, const Sint8* const src)
{
    dst = (src[3] << 24) | (src[2] << 16) | (src[1] << 8) | src[0];
}
#endif

now *I* don't understand it, but the underlying meaning seems clear (!)


/end

[rjshae]

I've seen something like that before in Java code; it is just reversing the order of the bytes for a multi-byte field.