# Why are there so few games compiled for 64-bit processors?

I noticed that I could not find any game that has a native 64-bit version on the x86 platform (there are some for platforms, obviously for example the Nintendo 64). In fact when I asked if the Allegro library supported 64-bit, the developers had no idea. When I tried to compile something for 64-bit my compiler failed (it was MingW, it wrote that 64-bit is not implemented).

This this make me wonder: why?

At least if the issue was 32-bit-only machines, you could make two .exes and run the more appropriate one or something. But I haven't even seen that, so why does nobody make 64-bit games?

• You must have an old version of MinGW; GCC (which is what MinGW essentially is) most certainly does support compilation for 64-bit targets these days. – user1430 Jan 31 '14 at 1:45
• "Tools that emulate the Nintendo 64 benefit from the scarcity of 64-bit operations in the game's executable-code, especially when running with a 32-bit machine architecture as a host. These emulators perform most calculations at 32-bit precision and trap the few subroutines that actually made use of 64-bit instructions." en.wikipedia.org/wiki/Nintendo_64_technical_specifications – AturSams Jan 31 '14 at 2:43
• Josh Petrie I actually found out yesterday that the official MinGW does not support 64-bit, and they have no intention of ever supporting it, it seems. There is a fork of MinGW called MinGW-W64 that does support 64-bit, it is not part of the official MinGW project. – speeder Jan 31 '14 at 12:06
• You're right about the last paragraph. It's perfectly possible to build both a 32-bits and a 64-bits version and have the game run the appropriate one. It's not very common, but many games already do exactly that. – Marcks Thomas Jan 31 '14 at 22:30

Not enough of the gamer market is running a 64-bit OS. If your game was 64-bit only, it may not run on a number of customers' machines, giving both lost sales and increased support/return costs. This is likely the #1 reason, though that's conjecture on my part. Once the Steam hardware survey indicates that >90% of users are running a 64-bit OS, more games are likely to start being 64-bit only.

If your game has 32-bit support, you probably have no benefit to also QAing and delivering a 64-bit copy. There are some moddable games like Bethesda's that could definitely use a 64-bit version for people who like to add more content, but those are a rarity.

There's also the argument of speed. 64-bit AMD64 has a lot of speed benefits over 32-bit IA32, but it has a disadvantage in pointer sizes. For some apps, 64-bit builds are actually slower or use too much additional memory. A game engine may or may not have these problems, depending on design, and so a 64-bit version may not be a good idea for that engine.

A lot of engines out there simply don't support compiling in 64-bit and it's not seen as a worthwhile use of time/money to fix. One big engine I've worked with recently for instance has all kinds of 64-bit-unclean issues; since the game barely tops 1GB of memory usage, there's really just no incentive to spend the time it would take to fix up just yet.

The new console generation and the increasing pressure on visual fidelity will likely push games to 64-bit before too much longer. We're just not there quite yet.

• I disagree with this as a reason: "Not enough of the gamer market is running a 64-bit OS", I don't think that is the consideration. For instance, most gamers don't have the latest GPU but I doubt that stops anyone making an AAA game from making sure that high-end GPUs are properly supported. I am sure most gamers who bought a pc within the last two years were coerced into getting Windows 8 64bit with their laptop. w3schools.com/browsers/browsers_os.asp I think it's the fact that it will not benefit performance. +1 for that – AturSams Jan 31 '14 at 2:34
• @ArthurWulfWhite: supporting optional features for newer GPU gives the player a benefit in improved visuals. supporting 64-bit compilation has very little impact on the game experience. there hence is value is committing time/money to various levels of GPU support while there is little value to committing time/money to 64-bit. be careful with your assumptions about OS availability; new Windows installs might all be on 64-bit but you hardly want to limit your customer base to only people with new hardware/software. consider the global market and not just the USA, too. – Sean Middleditch Jan 31 '14 at 3:17
• @SeanMiddleditch - Yeah, that is what I said basically" I think it's the fact that it will not benefit performance." :), I was just pointing out that even if 50% of the market had 64bit systems, I doubt it would be cause for concern. Sort of invalidating the first part of the answer and stating that I completely agree with the rest. – AturSams Jan 31 '14 at 10:26
• Another stumbling stone for dependencies is that Windows doesn't have the same sizes for the unsized integer types as the LP64 platforms, often leading to open-source libraries having tons of assumptions about things like sizeof(long) vs. sizeof(T*). It only takes one library doing it wrong to make your build so much less feasible. – Lars Viklund Jan 31 '14 at 12:57
• All desktop CPUs have 64bit support since Intel Core2, released in 2006. Most serious gamers should have 64bit systems by now. And even when you still don't want to lose that tiny market segment which hasn't, you could just ship two executables, one with 32bit and one with 64bit. – Philipp Jan 31 '14 at 16:34

Not just about market, but about need, where is the need ? 64 bits is good when you need more than 3GB (for windows), or 4GB (for mac) in main RAM. Many games are texture and render targets heavy so its about space in the graphics card rather than the RAM, and the graphic cards addressing is handled by driver, it may be whatever, 32 bits, 48 bits who knows, anyway you've got to limit yourself to something reasonably in the range of the target hardware space. 1 GB ~ for desktops, ~100MB for mobiles...

• The extra registers in x64 mode are really nice and are often worth taking the performance hit that 64-Bit introduces. – Michael Stum Jan 31 '14 at 4:16
• @MichaelStum when making a game performance hits are in general not worth it – ratchet freak Jan 31 '14 at 10:09
• @ratchetfreak Indeed, but with x64 it's a tradeoff - you gain a lot of performance because you have more registers (and OpCodes) but you also lose a lot of performance because all your pointers are twice as large and you thus lose cache space and have to deal with increased memory traffic - that usually results in a net performance benefit. – Michael Stum Feb 1 '14 at 3:45

AAA games these days do come out with 64bit executables. For example Fallout 4 is 64bit.

The most important question one should be asking is this: Does the game needs to be 64bit ?

The important difference of a 64bit game is that it can use more RAM than a 32 bit game. There is also the additional benefit that 64 bit variables (for example decimal type) are processed faster because they are not cut in half, but this kind of variable rarely is used in video games, it's mostly used for money calculation in bank software etc.

So if a game doesn't really need a 64bit executable, why should it have one ? Remember that 64bit software can't run on 32bit operating system. So there is no need to make a game available for less people if the game doesn't really need the more RAM.

As for the "bit wars" of consoles of the past, it was all a marketing trick, and the number of bits was referring to different things in different consoles.

For the NES, SNES, and Sega Genesis the 'bits' (8, 16, 16) were referring to the color depth capability of the GPU. Playstation 1's 32 bits were referring to the actual processor, and N64's 64 bits were referring to the bus bandwidth of the GPU.

The processors and the games of consoles have been running on 32bits from the console generation of PS1 and N64 up to the generation of XBOX360 and PS3. Only in the latest generation of XBOX1 and PS4 the CPUs and games of consoles made the jump to 64bit computing.