Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When distributing my game, I am going to compile all the resources and level data into a single binary package file, which is loaded from by the game. Do I have to worry about my machine being a different endian-ness than the end-user's, or are discrepancies here obsolete?

If this is going to be a problem, what is the best way to circumvent or solve it?

share|improve this question
+1 Most likely not. Also very related:… – Byte56 Jan 12 '13 at 0:53
"In the home computer space the "Big 3" (Windows, Linux, Mac) are all exclusively, or all but excelusively, on Intel x86/x64 architectures these days, so endienness concerns are no longer relevant." Are there any other modern architectures that have different endian-ness? – jmegaffin Jan 12 '13 at 0:57
Sure there are others, they're minor though, and it's unlikely anyone is expecting your game to work with it. But once you get into supporting extremely niche markets you'll never get done. – Byte56 Jan 12 '13 at 1:00
Okay, thanks. I wasn't certain if I should even bother with worrying about endian-ness, and I guess I don't have to. :) – jmegaffin Jan 12 '13 at 1:05
up vote 5 down vote accepted

Endianness matters when it comes to game consoles. The Wii, the PS3, and the XBox 360 all run big-endian, while all major desktop computers (as of the date I'm writing this answer) run little-endian. If there's a chance you'll want to compile your code for one of those game consoles someday, or if someone releases another popular big-endian desktop machine someday -- it wasn't so many years ago that all Macintoshes were big-endian, after all -- then you need to think about endianness. And if you don't think about it now, then from personal experience I can tell you that it'll be extremely painful when you have to add big-endian support to a whole completed codebase which was written without it.

Similarly, endianness can matter when you're communicating with internet servers. If you want cross-platform server software, then all your network code should really be transmitting/receiving using the standard network byte ordering: big-endian.

A related issue which you don't mention is that of struct padding. A single struct or class can have different sizes on different platforms or even just between different compilers, and its fields can exist at different offsets within the struct. Put simply: Even if you decide not to care about endianness, you still can't simply treat a struct or class as a binary buffer and naively write it to a file or a network packet. In order to transmit a struct of data from one machine to another, you need to individually read or write each field, rather than treating the struct as a single blob of memory. And honestly, if you're doing that (because you have to in order to support cross-platform), then you might as well convert the values to/from network byte ordering at the same time.

share|improve this answer
+1 This is a good answer. – Byte56 Jan 12 '13 at 7:58
I was only confused about desktop platforms, but I'll accept it because it's informative and is a true answer. – jmegaffin Jan 12 '13 at 15:23

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.