1
\$\begingroup\$

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?

\$\endgroup\$
4
  • \$\begingroup\$ +1 Most likely not. Also very related: gamedev.stackexchange.com/questions/37712/… \$\endgroup\$
    – House
    Commented Jan 12, 2013 at 0:53
  • \$\begingroup\$ "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? \$\endgroup\$
    – jmegaffin
    Commented Jan 12, 2013 at 0:57
  • \$\begingroup\$ 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. \$\endgroup\$
    – House
    Commented Jan 12, 2013 at 1:00
  • \$\begingroup\$ Okay, thanks. I wasn't certain if I should even bother with worrying about endian-ness, and I guess I don't have to. :) \$\endgroup\$
    – jmegaffin
    Commented Jan 12, 2013 at 1:05

1 Answer 1

6
\$\begingroup\$

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.

\$\endgroup\$
1
  • \$\begingroup\$ I was only confused about desktop platforms, but I'll accept it because it's informative and is a true answer. \$\endgroup\$
    – jmegaffin
    Commented Jan 12, 2013 at 15:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .