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?
