Final Words

As we wrap things up, we'll reserve a few words for game & application developers who are working on projects that will hit the barrier. Supreme Commander is extremely disappointing in how it handles running out of addressing space. Ideally we'd like for it not to crash, but realistically we'd settle for just an error message pointing out that it hit the 2GB barrier so that we could quickly reach a solution. Otherwise seemingly-random crashes tend to be one of the hardest problems to resolve as a user. Developers need to take care here to offer some kind of warning when the 2GB barrier is the problem; not everyone is or will be well read on the subject or have the time to diagnose it, when it's actually an easily solvable problem.

Getting back to the point at hand however, we feel that this is only going to be the tip of the iceberg. As games and applications continue to come out that push the boundaries of computer hardware and run afoul of the 2GB barrier, these problems will only pick up in pace. For many power users this experience will be a common occurrence, and for most it will be a frustrating experience.

We're at the front end of a messy transition, one that may not end for several years. Today, 32bit games will hit the 2GB barrier, and tomorrow games with support for large addressing will hit the 3GB/4GB barrier. Not until 64bit versions of games are ubiquitous will we be completely through this transition, and that will still be a few years away.

Until that point, stories such as these will continue to be told as users unknowingly hit the 2GB barrier. Developers need to be doing a better job at handling the issue via better crash reports, but our inner cynic says that they can't be solely in charge of the matter. So it will be up to users to diagnose their own problems and take the appropriate action, be it switching operating systems and/or modifying executables. A little knowledge in this regard can go a long way.

Other Problems, Other Solutions
Comments Locked

69 Comments

View All Comments

  • miahallen - Saturday, July 14, 2007 - link

    What I found extremely interesting is that you had problems modifying your boot.ini file for a lsrger than 2.6GB app space. I have an almost identical configuration, and have modded almost all my games headers, and my boot.ini is set to 3GB app space. When I modded the boot.ini, I was unaware of the possible problems, but since it didn't cause any, I've been perfectly happy with it.

    A8N-SLI Delux
    Opty 165 @ 2.5GHz
    2GB DDR400
    8800GTX (768MB VRAM)
    Vista x86

    I've modded the headers for:
    STALKER
    C&C3
    CoH
    Dark Messiah M&M
    DiRT
    FSX
    Silent Hunter 4
    TDU

    Thanks Ryan, for the great article!
  • MadBoris - Sunday, July 15, 2007 - link

    quote:

    I've modded the headers for:
    STALKER
    C&C3
    CoH
    Dark Messiah M&M
    DiRT
    FSX
    Silent Hunter 4
    TDU


    This should be made clear to people.
    If an application is not Large Address Aware there is usually very good reason the developers did not include it that way. There maybe things you break in the game or cause stability problems by adding it.

    So people should not be just adding this to all their games, especially considering many games don't come close to the 2GB ceiling in the first place, so their is no benefit only potential negatives.
  • ChristopherO - Monday, July 16, 2007 - link

    This is true... One shouldn't go setting the binary flag because they *can*.

    I will however confirm that C&C3 and FSX run into the 2GB barrier. FSX is fine once it is patched.

    However, C&C3 is so poorly written that it can easily pass 2GB and run into the revised 3GB barrier on any multiplayer map with the maximum number of AI and/or opponents. Detail settings as low as the "medium" preset do nothing to alleviate this problem.

    Unfortunately C&C apparently has absolutely no code to purge and re-use memory as I've been in huge games, on the downward slope in terms of remaning opponents/units, and the app still hits a revised 3GB memory space and crashes.

    As a developer myself, memory management is *not* that complicated. It takes some forethought, but the EA people apparently never bothered. This is a huge letdown since I've been a C&C fan since the first game came out my first year of college.
  • miahallen - Saturday, July 14, 2007 - link

    I have to add one more thing about my system, may be important.....most of my games I play at 2048x1536, as opposed to you test rig at 1600x1200. That and you were using Vista Ultimate, I'm using Home Premium. Do you think this is what is effecting the results? If so, Home Premium (or even Home Basic) is the x86 OS of choice for gamers, not Ultimate!
  • miahallen - Sunday, July 15, 2007 - link

    I was hoping you would comment on this Ryan, do you think the difference in our boot.ini mod was due to the version of Vista we run? Any thoughts?
  • sheh - Thursday, July 12, 2007 - link

    ...and disturbingly it doesn't set off any sort of multiplayer cheat detection in the game in spite of the fact that we have modified the executable in a very visible way.

    The game probably checks the code (and maybe data) section(s) in memory, and not the actual EXE file (makes sense considering you can use memory patchers). The header might not be important for cheat prevention.
  • MadBoris - Thursday, July 12, 2007 - link

    quote:

    ...and disturbingly it doesn't set off any sort of multiplayer cheat detection in the game in spite of the fact that we have modified the executable in a very visible way.

    Yeah, I remember thinking that the first day I did it, actually in those days it was Securom protected which I was actually more suprised about bypassing. But seriously the exe header should not be something that cheat protection should look for. I can only say glad it didn't or crashing would be a constant problem. ;)
  • atlr - Thursday, July 12, 2007 - link

    I thoroughly enjoyed this article. Good job.
  • atlr - Thursday, July 12, 2007 - link

    A lot of good comments have helped edit and tune this article too. (meh, not this one though) Yayyy, community.
  • JetBlack69 - Thursday, July 12, 2007 - link

    From a programming perspective, what is a programmer to do? I assume this can happen in a program when "new" returns NULL because the program is out of memory, but what can a program do gracefully?

    I assume it could just display an error message, but if it were during a game, how could it handle it gracefully and not crash or give an error message? Would it lower the texture detail or remove unneeded objects on the screen?

Log in

Don't have an account? Sign up now