Skip to main content

Gaming In 64-Bit: Tom's Tests, Microsoft Weighs In

A Pair Of 64-Bit Gaming Case Studies

In preparing for this piece, we searched high and low, asking around to hardware and software vendors alike, for evidence of games written to run in a native 64-bit environment. Only two surfaced: Crysis and Hellgate: London (Far Cry was patched to run 64-bit natively too, once upon a time, as was Half-Life 2). Incidentally, both were made into case studies by Chuck Walbourn in his Gamefest 2008 presentation, highlighting the challenges and benefits that might be weighing on today’s game developers as they contemplate a shift to 64-bit computing.

According to Walbourn, the really big win for Crytek was Crysis’ 64-bit level editor, which made a significant difference in the quality of art rolled into the game. When the development team began work with its initial 32-bit editor, it ran into stability problems at around 1.7 GB of addressed space. They then enabled the /LARGEADDRESSAWARE flag in a 64-bit environment and got up to 2.7 GB before encountering the same issue. Thus, the 64-bit editor was born out of necessity in order to deliver the level of detail Crytek wanted to see. As a side-effect, the 32-bit single-player game pushes very close to the stability boundary I used to encounter in Command and Conquer.

We’ll be benchmarking Crysis shortly, but before we even look at the performance results, Walbourn foreshadows what we’ll likely see: the performance between Crytek’s 32- and native 64-bit .exes should be comparable because the developer didn’t devote much effort to specifically optimizing for a 64-bit environment. However, at the highest quality settings, whereas the 32-bit version is pushing a stability limit, the 64-bit executable has lots of virtual address space left. Of course, as we’ve seen at those quality settings, it’s also difficult to get playable performance at all, which means most users are likely to tune their settings down a bit, regardless of operating environment.

The other title is called Hellgate: London, an RPG that launched back in October of 2007. The game’s single-player content is still playable. However, the game’s multi-player servers, which were 64-bit themselves, shut down in January of this year. In addition the 64-bit game servers, Hellgate offered a native 64-bit client that circumvented 2 GB virtual address space limitations.

As with Crytek and Crysis, Flagship Studios ran into issues of its own developing Hellgate with ambitious hardware support plans. The game shipped with DirectX 9 and DirectX 10 .exes, single-player and multi-player .exes, and 32- and 64-bit .exes, resulting in a combination of eight executables that had to be maintained. Further, issues integrating middleware caused issues that we’d hope wouldn’t be as much of an issue today. For example, native 64-bit copy protection was a problem for both Crytek and Flagship, since 64-bit processes are only able to load 64-bit DLLs and there weren’t any available during development.

Of course, with the game’s multi-player environment already shut down, it seems pretty clear that this is no longer considered to be a significant title beyond the lessons it teaches about jumping into 64-bit development.

Walbourn’s Gamefest presentation ended with a three-point call to action:

  • Software developers were encouraged to shift development to 64-bit for the extra memory it’d enable during the content creation process.
  • At the very least, enable /LARGEADDRESSAWARE for a little extra virtual memory address space on 32-bit games running in a 64-bit environment.
  • Start using 64-bit development tools—an especially important step for working with pre-optimized content that will eventually ship right at the 2 GB boundary of 32-bit platforms.

How well were Chuck’s words heard?

  • salsoolo
    i went 64-bit from last year. i hope that game devs go 64-bit. and every programmer too.

    with Windows 7 around the corner, m$ already said that they expect the majority of windows installations will be 64.
    Reply
  • curnel_D
    "Given the very known nature of these virtual address space limitations, you’d think that game developers would be taking a more hurried approach to making the transition."

    This mainly has to do with resources. Most developers use the same engine they've built or bought for a span of many years. Take bioware, for instance, who used the Auroa engine for 9+ years, knowing that it was limited to single threads and low memory.
    To switch to 64-bit, these developers would have to take the time not just to modify their existing engines, but more likely rewrite the entire engine because of the changes involved. Something that some developers just cant afford.
    Reply
  • curnel_D
    Oh, and deffinately drop GTA. None of the GTA or games that use the GTA engine have ever been any good on PC, and have never been consistant in indicating graphics performance due to their poorly developed and optimized code. It's a waste of time.
    Reply
  • amdfangirl
    I say the benefit of having full access to 8GB of DDR2 is enough to make me switch to 64 bit. Not using a Page File and being able to use native 64 bit programs like those found in CS4, is worth it enough. The advantage of being able to execute native 64 bit instructions is absolutely heavenly powerful speed boost(CS3 vs CS4).
    Reply
  • spearhead
    indeed 64-bit is good and you can see that in games and applications which take advantage from it. it might require a bit more ram but then 64-bit can handle more applications running at the same time and execution of those applications seems to be alot faster that is what i can tell from my experience with 64-bit vista
    Reply
  • nathanlh
    One of the reasons that x64 games might run slower on 3GB of system memory than their x86 counterpart is that x64 code should be somewhat larger due to the 64 bit addressing itself. If the x86 code is already feeling the squeeze on 3GB, the x64 code will be even more so - resulting in more memory swapping to disk. Also, one of the benefits of x64 code is the use of more general purpose registers which the x64 games tested here might not have made use of.
    Reply
  • Chris - could you check the same thing on AMD platform? AFAIK there are some performance differencies between AMD and Intel @ 64bit
    Reply
  • amdfangirl
    ^ There were some on Linux with the Athlon 64 and Pentium 4. Gap has really closed tho, I'd say.
    Reply
  • apache_lives
    heh we forget the main concepts here with 64-bit:

    NO ONE uses a system with nothing bar windows a single game installed - they have a few security apps, torrent apps, messenger, keyboard/mouse apps etc - they all sap up resources, so 64 bit gives all apps all the memory they need - for example 8gb is useless to a 32-bit app, but when you got that hungry game ASWELL as a hungry background app etc they both get the full amount of memory!

    Also lessens the "thrashing" effect on HDD's and helps there lifespan etc


    As for why there arnt any benifits for 64 bit games etc - there all still native 32-bit because all those morons still think there 2gb and XP is "sufficent and up to date" - move to 64-bit so we can all benifit!
    Reply
  • amdfangirl
    ^ +1

    We should all be 64 bit.

    Those who play hardcore games should have at least a x64 proc.

    So, devs should make 64bit games simply.

    The world will transition in due time.

    We just are at the frontier.
    Reply