Files and endianness
Hello,
First I'd like to say thanks to the guys at MS for being so open about the development of the XNA Framework and associated tools. The recent blog posts have been really excellent.
At the moment for opening files I use File.OpenRead(). To read the data from the Stream it returns, I use Stream.ReadInt32() and so on. Obviously on my little endian PC platform, reading little endian data, there is no problem.
But on the Xbox, does System.IO.Stream exist? And if so, does Stream.Read*() do endian conversion on the fly?
Thanks again,
Peter
Yes, System.IO exists on Xbox.
By Stream.ReadInt32 I assume you really mean BinaryReader.ReadInt32?
In that case you're in luck, because BinaryReader and BinaryWriter
always load and save data in a little endian disk format, regardless of the platform they are running on.
The times when you might run into endianess issues are mainly:
- If you use System.BitConverter
- If you use unsafe code to read and write whole structures as byte arrays
- When reading GPU resources like textures and vertex buffers
But you don't need to worry about that last one if you use our Content Pipeline to handle those resources.
Hi Shawn, thank you very much for your detailed reply.
 Shawn Hargreaves wrote: |
| By Stream.ReadInt32 I assume you really mean BinaryReader.ReadInt32? |
|
Sorry, I forgot that it was in BinaryReader instead of Stream. I should check my code next time!
Very good news about endian issues! It means I can continue without wrapping my IO routines with an endian-handling version.
Yes, the 360 uses a PowerPC CPU, in big endian mode!
Also, I'm not an experienced C# programmer, but I think its "long" data type is indeed 64-bit!
*swoon*
In .NET, the long type is always 64 bit. The standard C# types are:
- byte = 8 bit unsigned
- sbyte = 8 bit signed
- short = 16 bit signed
- ushort = 16 bit unsigned
- int = 32 bit signed
- uint = 32 bit unsigned
- long = 64 bit signed
- ulong = 64 bit unsigned
- single = 32 bit floating point
- double = 64 bit floating point
This is true for all platforms that .NET runs on, regardless of whether the underlying CPU is 32 bit or 64 bit.
The main thing that changes when you go from a 32 bit to a 64 bit CPU is the size of pointers. But that rarely affects your code because .NET code doesn't tend to manipulate pointers directly in any case.
Well, I was thinking of the C/C++ long, admittably it's not actually relevent here.
When you said that reading GPU resources might be problem, does that mean the GPU uses little-endian resources, or just that the source files for the resources might be in a little-endian format?
The Xbox GPU uses big endian resources, just like the CPU. This tends to show up as a problem more often than CPU resources, though, because textures and vertex data are often saved and loaded as byte arrays, which prevents the BinaryReader from automatically handling the endianess swap. So your resource loader (assuming you are writing your own rather than using ours) will need some code to handle this difference.
