While these games are absolutly amazing, for those of us who have upgraded to 64 bit systems, the memory problems plaguing gameplay makes these games tough to play sometimes.


I grow so tired of seeing this in my crash logs.

General Exception Information:
Operating System: Windows 7 Professional (6.1.7601)
Report Time: 1/29/2012 2:43:05 PM
Process Filename: C:\program files (x86)\steam\steamapps\common\fallout new vegas\falloutNV.exe
Process ID: 2896
Thread ID: 4580
Process Description: FalloutNV
Process Version: 1.4.0.525
Process Company: Bethesda Softworks
Product Name: Fallout: New Vegas
Product Version: 1.4.0.525
Crash Address: 00A6DF48
Crash Address (Relative): falloutNV.exe+0x66df48
Exception Code: C0000005
Exception Description: Access Violation - Failed to access 6E707790 memory address (Read Access)
Exception Parameter (1): 00000000
Exception Parameter (2): 6E707790
Crash Code Bytes:
D9 06 57 D8 46 10 8B F9 89 7C 24 08 D8 46 20 D9
5C 24 1C D9 EE D9 44 24 1C D8 D1 DF E0 DD D9 F6
C4 41 75 68 DC 05 70 20 01 01 D9 5C 24 1C D9 44
24 1C E8 C1 80 45 00 D9 5C 24 1C D9 44 24 1C D9


When is Bethesda going to realize that most gamers aren't buying 32 bit machines any more. There is simply not enough addressable memory, and when a RAM hungry game like FO3NV attempts to gobble up more than it can address...BAM we get these.

A 64 bit client would fix all of these memory problem related crashes, and while I realize that this is probably not in the cards for NV, it having received it's last update and all, I would ask the community to demand that Bethesda realize that most of us are not using rigs which were built 8 years ago, and to build it's next generation of FO games with full 64 bit support.

Are you using the LAA patch? With 4gb, you shouldn't be having any problems with memory ceilings.

FO3: NEW VEGAS??!!!!!

LOOK WHAT HAPPENS WHEN MY THREAD ABOUT CALLING IT FO3: NV GETS IGNORED??!!!!!


FO: NV, NOT FO3: NV!!!!

Give him a break. He's new.

Now, if he comes back in three weeks and says that, by all means chew him out for it.

@Cronos Sorry to say, but Bethesda's critics and such like yourself are in the minority. Regardless if 64-bit support is implemented, people will buy the next TES and Fallout games simply because Bethesda is really market-savvy and knows how to properly lie/bend the truth to people. Hopefully, they'll implement 64-bit clients but otherwise I just learn to deal with it through extensive modding to ease the technical headaches.

If he's new that's okay I guess, I just HATE it when people say FO3: New Vegas.

I have a 64bit Win7 system and been playing NV for a couple of months now. I don't remember the last time I crashed/locked up if ever.

I suggest you try to find whatever fault you have in your system. Maybe start by testing your memory.

There's a reason games rarely, if ever, have 64-bit builds and instead are 32-bit with at best the LAA flag enabled: we have a couple solid decades of heavy-duty 32-bit compiler optimization, and like 5 years of mediocre 64-bit compiler optimization. Tack onto that a programming workforce with lots of experience with 32-bit programming, and not so much with 64-bit, and the side benefit of keeping production costs down if you aren't pressing your artists to design ludicrously high resolution textures (about all that that extra memory would be used for) and you wind up with reasonable resistance to shift to 64-bit builds of complex non-productive software (aka games).

Queue

No, the error you're getting is thrown when the process attempts to access an invalid address (i.e acessing uninitialized or deallocated memory). It has nothing to do with running up against per process address space limits.


Compilers for x86-64 and x86 should be almost identical when it comes to code generation. It's not a question of maturity, it's a question of installed base. A 32 bit binary ensures that your game will run on the large legacy population of 32 bit Windows XP systems out there.

FO3:New vegas

Maybe I just haven't been paying attention, but this thread is the first time I've seen someone do that.

Yes, they ''should'' be, but optimizations to 32-bit code do not automatically translate to optimizations to 64-bit code (different number of registers, the same instruction taking differing numbers of cycles, differing performance of the instruction cache due to longer code length for 64-bit addresses, different function call structure, and those are just the most obvious differences). 32-bit compilers produce highly optimized code; they HAD to during the 1990s, and CPU architecture evolved around common code optimizations to make things even faster. 64-bit compilers produce poorly optimized code; there's cycles to spare these days so heavy duty optimization is less important, and CPU optimization around code optimizations in the 64-bit realm are still in their infancy. It's just the current reality.

Queue

ABI and calling convention changes are a one time change and so have nothing to do with "maturity". Minor changes to register allocation heuristics are not difficult (if anything writing a register allocator for 8 registers is harder than writing one for 16 since the latter isn't register starved). Cache effects due to larger pointers aren't something that affect compiler complexity either.


This is just wrong. Go look at the SpecCPU submissions (http://www.spec.org/cpu2006/results/). Every x86 submission uses 64 bit mode almost exclusively(the exception being a couple of subtests that lose performance with larger pointers). There's no way vendors would do this if compilers were generating such poor 64 bit code.