As modern machines are moving more and more towards 64 bit, we are receiving a growing number of requests for 64 bit binaries of our games. This semi-technical article will illustrate how we do plan to create 64 bit binaries in the end, and to give you an overview as to why we haven’t done so before.
The first stumbling block to 64 bit, is the build environment. The build environment is absolutely essential, and it is what allows us to create a game that works on all Linux distros. Over many years, we have tuned our 32 bit system to find a set of libraries and build tools that are cross-distro compatible with pretty much any Linux distro out there. The discussion of this in detail will be for another day, but finding a comparable cross-distro environment for 64 bit is the work of many months of solid research, costing tens of thousands of pounds.
The second problem is the code itself. Only in the last 12 months or so have a few games started to come out for Windows with 64 and 32 bit versions. Most games, even today, are 32 bit only. This means that assumptions have been made about the sizes of pointers, and sizes of various data types, that do not hold true for 64 bit. The biggest issue there is the size of pointers. Various aspects of the game rely on a pointer being 4 bytes in size, and suddenly throwing an 8 byte pointer into the mix is guaranteed to cause problems. This is something that, depending on the way the program is written, is incredibly hard to work around.
Data types such as long int, are easier to work around. Simply replacing all long int variables to be an int32_t will solve that issue with no problem – unless of course the game uses pointer arithmetic. I have never seen a game that does not use pointer arithmetic. This means we cannot make blanket substitutions, every variable in the whole program, sometimes millions of lines, tens of thousands of variables, needs to be examined in depth.
Once we have all of these factors addressed, we will be in a position to produce a 64 bit version of a game. An estimated 3-6 months advance work making a build environment template, probably 25% extra development time increase for the project, and we end up with a speed increase that is not large enough to warrant the extra development time. Our research shows that 64 bit versions of games would run around 5% faster than 32 bit, and you would get more of a performance increase by closing down your web browser when playing, than by running 64 bit.
With the impatience our customers have for new games, we have for now made the call to bring the game to release earlier, than to have a 64 bit version. As and when we license a game that is available as source for 64 and 32 bit, we will certainly spend the time doing the work to build an appropriate build environment, so that we can take advantage of the source, but the costs and risks of doing this to an entire source base that is not designed for it are too high to justify.
Tags: 32 bit, 64 bit, build environment
Fascinating article. 64-bit computing still doesn’t feel to me like its “caught on” on the consumer level yet. As an example, I have a 64-bit processor in my machine but am running 32-bit Linux anyway because of the troubles 64-bit libraries cause me.
The only place I think 64-bit computing has made large-scale changes are with Apple’s Macintosh computers. Switching all their processors to 64-bit and creating a coding environment in which programs can run on both old/new machines was something I hope can push the adoption of this “new” tech. I could be wrong, since everything I’m typing is unsubstantiated opinion, but 64-bit seems slightly like a novelty right now.
Running a fully 64bit system is no problem at all, and in distros that provide 32bit library packages for 64bit systems, running 32bit applications is no problem either (95% of the time, and this is with x86_64, I have no experience with Intel 64bit systems).
I don’t think it’s really LGP’s responsibility to provide 64bit binaries if the game didn’t originally have 64bit binaries. As long as the 32bit binaries work on my 64bit system, I’m happy.
I’ve been running 64-bit Vista for almost two years, and 64-bit Linux (Ubuntu server LTS) for almost a year now. I have had much fewer problems than I expected! The biggest annoyance is really having to type longer pointer values into debugger windows, which I figure is a habit to get into to future-proof myself anyway.
I can whole-heartedly recommend it.
I just stumbled across this fairly old article, but I’d like to add my perspective.
It’s increasingly common these days to have more than 4GB of RAM. Especially in the circles of tech geeks and hardcore players. On such systems, you can only use all that memory with either 64b system, or a specially tweaked kernel (and that has some downsides).
Of course you can run 32b apps withing 64b system, but that also means additional 32b libraries (not straightforward for a newbie) and sometimes there are even more problems. It may be just my environment, but some of your demos for example are just crashing for me.
Anyway, keep up the good work. I’ve already bought one of your games and I plan more in the future.