For years, AMD has been talking about the positive impact that 64-bit will have on games. Honestly, we never bought it; games are still a couple of years away from breaking the 2GB process limitation under present day 32-bit Windows. Despite our lack of belief, AMD still did their best to convey the message that gamers would be given a better experience in a 64-bit environment.

AMD has been demoing 64-bit versions of the Unreal engine as well as Far Cry for quite some time now, but neither were ever made public. Originally, we heard talk of 20% increases in performance due to decreased register pressure when running in 64-bit mode. We desperately wanted to see a game recompiled with 64-bit support, but alas, we needed a 64-bit OS. Last month's release of Windows XP x64 Edition fulfilled the latter requirement, but we still lacked any games to test the hype.

The Chronicles of Riddick: Escape from Butcher Bay actually shipped with a 64-bit binary out of the box. Unfortunately, we saw absolutely no performance improvement from using the 64-bit binary vs. the 32-bit binary in our extensive evaluation of the x64 edition OS. If performance under Riddick was any indication, 64-bit wasn't going to be much of a performance sell for gamers.

Today, however, AMD and Ubisoft are announcing public availability of the first 64-bit patch and content update to Far Cry. As we just implied, the 64-bit add-ons to Far Cry come in two separate packages. First, there's the actual 64-bit patch that installs and enables a native 64-bit binary to run under x64 edition. The second package is the AMD64 Exclusive Content Update that improves the actual content in the game.

AMD listed the changes to the 64-bit version of Far Cry as follows:
All Levels
  • Improved terrain textures
  • Increased view distance
  • Offset bump mapping added for rock and stone objects
  • More insects and birds
On the Pier Level
  • New beach road with additional vehicle
  • Barrel storage camp
  • Opened more space to explore
Pier and Boat
  • New terrain textures with shader
Two New 64-bit only Multiplayer levels
  • Stronghold
  • Gorge
As you can probably already tell, none of the additions or enhancements have anything to do with 64-bit memory addressability. In fact, a fast GPU is all you really need to take advantage of most of these features - not a 64-bit CPU. The patched version of Far Cry doesn't even eat up more than 512MB of memory during normal gameplay, and supporting more insects and birds doesn't really depend on more architecture registers provided by AMD64 either. It's no surprise that none of the enhancements offered by the 64-bit patch have anything to do with a 64-bit CPU at all, but you have to add value somehow and this is how Ubisoft and AMD decided to do it.

Far Cry doesn't use more than 512MB of memory, even with the 64-bit patches.

Both patches are scheduled to be available to gamers starting today, free of charge, but of course, you must already have a copy of Far Cry to utilize them. The patch and the exclusive content update will only install under Windows XP Professional x64 Edition, so 32-bit XP Professional users will not be able to even install the additional content patch. Despite being very tightly associated with AMD, the new Far Cry patches will work on Intel EM64T enabled systems as well.

Despite the wording of the error message, the patches will work on Intel EM64T enabled systems - just not on 32-bit processors.

The patches themselves are huge, totaling over 1.5GB in size, so be prepared for a hefty download. Even after applying the patches, you can still run the 32-bit Far Cry executable, but doing so will not give you access to the additional features or new multiplayer levels.

The Far Cry patch also acts as a no-CD crack, it appears, as we no longer had to have our play disc in the drive to play the game after applying the 64-bit patch.

64-bit Far Cry Performance


View All Comments

  • Jynx980 - Thursday, May 12, 2005 - link

    More insects and birds? I better hop on the 64 bit wagon!

    Im surprised to see so many uneeded processes running. qttask, ati2evxx, ipodservice, ituneshelper; these things eat up the ram little by little.
  • KF - Wednesday, May 11, 2005 - link

    There is no way to say for sure that the basic design of Far Cry is sufficiently ambitious to show off AMD64 well, because designers need to design to what is available in mass if they plan to sell games in large quantity. Intel only recently capitulated to doing EMT64, so designers could not design with 64 bit in mind.

    It may be that AMD's intent was to show that more abitious game designs are more practical for a 64 bit machine. If AMD wants to demo advantages of AMD64, there needs to be a 32 bit version of the game with the extra content to compare, or else they need to show why the added content is not possible with 32 bits.

    Why do more registers speed things up? Keeping things in registers is the fastest way to do things. x86 has 8 general purpose registers, 6 of which are ordinarily available. To do a very simple loop, you are liable to need 2 or 3 registers to hold adresses and at least 2 to hold operands. Since you need to hold onto intermediate results in the process, you are already nearly maxed out. That was fine in the original 386 days. But current CPUs can readily execute 3 ops simulanaeously, so if you attempt to use the CPU to maximum capablity, and do multiple things concurrently, you run out of registers. Therefore the capabilities of present CPUs are vastly underutilized. Adding 8 more general registers, like AMD64 does, helps a lot. Intel says that by actual measuremnent in real programs, currrent CPUs average 1 op per cycle, when they can do a possible 3. Not impressive. I hope that explains the potential of more registers.

    OTOH, programs like games obviously use massive amounts of data which is only briefly in registers, so slinging that in and out of memory is going to take up a lot of time. That will limit the average ops per cycle considerably. It is only while you are processing a given chunk of data that you could get the number of ops per cycle up. The more you process a given chunk of data, the more potential speed up possible. If the design was not ambitious enough, there is not going to be much speed up. Older CPUs would be good enough.

  • thelanx - Wednesday, May 11, 2005 - link

    Has anyone compared the enhanced visual quality screenshots with hdr screenshots? I know that enabling hdr makes the colors of the land and the water more vibrant, which seems to occur in the enhanced version as well, most noticably the better water and more vibrant trees. Perhaps crytek used what they learned doing the hdr and implemented similar effects without using hdr? Reply
  • Sheeno - Wednesday, May 11, 2005 - link

    I don't get the problem, Anand showed that the difference between the 64bit patch and a normal 32bit farcry was negligible. In fact, the only difference is the graphical enhancements you get from adding the second 'graphics' patch. We can all assume that the quality of your graphics card will run the latter, so why the 64bit? It seems this was nothing more then a marketing stunt, and those of us with 32bit processors, AMD or not, are left without a neat update. Thanks AMD, I'm glad you decided to forsake your 32bit processors. Reply
  • ir0nw0lf - Tuesday, May 10, 2005 - link

    As much as I love AT, I feel that the [H]ard|OCP article was much more informative and "meaty." Their article didn't seem to have a rushed feel to it vs. the AT article, which as mentioned above feels a bit rushed and possible incomplete. Reply
  • msva124 - Tuesday, May 10, 2005 - link

    Thank you, that makes sense. Reply
  • stephenbrooks - Tuesday, May 10, 2005 - link

    ^ Compiler doesn't get in knots swapping stuff in and out of main RAM or cache so often. Registers have a 0 cycle access delay :p Reply
  • msva124 - Tuesday, May 10, 2005 - link

    >That's like asking why would more cache, or more RAM increase performance..

    Then it should be very easy for you to explain why more registers will increase performance.
  • Concillian - Tuesday, May 10, 2005 - link

    I will go along with many of the opinions I'm seeing here and say that I think there is a lot of assumption in the article, and not enough proof.

    - The reader is assumed to know that 1024x768 high quality is CPU bound

    - The article assumed that the performance of 64 bit patch + additional content would show worse performance, but has no demonstration of that in either a CPU bound or GPU bound scenario. (speaking of the comments: "In fact, a fast GPU is all you really need to take advantage of most of these features - not a 64-bit CPU" and "but the fact of the matter is that none of the visual improvements enabled by the Far Cry patches had anything to do with AMD64 or EM64T"

    Perhaps those comments assume more knowledge of how all this stuff works than the average reader has, and it's more obvious to someone like Anand with a more extensive knowledge of CPU architecture and how software interacts with specific registers, etc... Maybe the conclusion is more obvious to someone with that kind of knowledge, but I just see conclusions being drawn about one thing (64 bit patch + ehanced content) from a test of a completely different thing (64 bit patch only)

    Anand, you talk about apples to apples comparison. To take that analogy and run with it... Why do you do an apples to apples comparison and then make a conclusion about potatoes?

    I think it would have been a reasonable comparison to see the performance with and without the additional content to demonstrate which hardware was actually being taxed (video or CPU). Especially with the strong opinion expressed in the article about what hardware the etra content taxes. I don't question the conclusion necessarily, I just think that if you maake such a strong statement you should have real data to back it up.

    I only criticize because we have high expectations of AT articles. I hope these comments are seen as constructive, because that's the intent.
  • xtknight - Tuesday, May 10, 2005 - link

    I agree that some additional benchmarks with the 64-bit content pack would have been a good idea, even if it's not apples to apples. I'm not downloading this patch for the 5 FPS increase, I want the extra eye candy. Is the content pack supposed to include only stuff a 64-bit CPU could do efficiently? Then it would be nice to compare it to a 32-bit CPU. Otherwise, I understand your reasoning that this pack really has nothing to do with 64-bit in the first place. Reply

Log in

Don't have an account? Sign up now