Sign in with
Sign up | Sign in
Your question

32 bit gaming in x64 OS

Last response: in Windows 7
Share
a b 4 Gaming
a b $ Windows 7
February 9, 2010 2:30:53 AM

Hello,
Do 32 bit games run slower in a 64 bit environment? At present, I am playing FO3. I am trying it in both XP x86 and Win7 x64 (dual booting), and I notice a definite stuttering in Win7 that isn't present in XP.

More about : bit gaming x64

February 9, 2010 2:56:11 AM

It all comes down to the coding. If FO3 is Fallout 3, I'm also running it on Win7 x64, but I haven't noticed any problems. Have you tried updating this game? Also, make sure you have all up-to-date drivers, and good hardware.
m
0
l
February 9, 2010 3:58:01 AM

do you have all 64-bit drivers installed? especially for your graphics card?
m
0
l
Related resources
a b $ Windows 7
February 9, 2010 4:10:51 AM

sound card can be a big one too.
make sure thats updated...
m
0
l
a b $ Windows 7
February 9, 2010 2:22:53 PM

When you run a 32-bit program under 64-bit windows, there will be some degradation because it is emulating a 32-bit environment for you. Normally, it shouldn't be that big of a deal though. Definitely like people stated, check all your drivers.
m
0
l
a b $ Windows 7
February 9, 2010 2:34:39 PM

isamuelson said:
When you run a 32-bit program under 64-bit windows, there will be some degradation because it is emulating a 32-bit environment for you. Normally, it shouldn't be that big of a deal though. Definitely like people stated, check all your drivers.


actually no, it is not emulation, a 64 bit cpu in long mode can switch between long and legacy (32 bit) while running
m
0
l
a b $ Windows 7
February 9, 2010 3:13:31 PM

mindless728 said:
actually no, it is not emulation, a 64 bit cpu in long mode can switch between long and legacy (32 bit) while running


Well, yeah. I thought about that and it's not true emulation, but it still has to decode the 32-bit instructions via "software" in the CPU, so it's still not as fast as TRUE 32-bit, but it's minimal. It shouldn't be causing the original poster any problems like what he's seeing.
m
0
l
a b 4 Gaming
a b $ Windows 7
February 9, 2010 3:25:57 PM

Hey, thanks everyone for the good advice. Yes, all my drivers are the latest 64 bit ones available. And, yes, the latest FO3 update from Bethesda has been installed (V1.7)

My hardware is fairly sufficient. What started out a Velocity Micro desktop has been upgraded to 8G RAM, EVGA 285GTX, Soundblaster Extreme Gamer sound card, Q9550 quad CPU w/Freezer 7 cooler, and 850w PS, Win7 Home Prem.

So far, FO3 is the only game I have that I've found that runs better in XP than Win7. The stuttering isn't too bad to play comfortably, it's just left me wondering...
m
0
l
a b $ Windows 7
February 9, 2010 3:44:34 PM

clutchc said:
Hey, thanks everyone for the good advice. Yes, all my drivers are the latest 64 bit ones available. And, yes, the latest FO3 update from Bethesda has been installed (V1.7)

My hardware is fairly sufficient. What started out a Velocity Micro desktop has been upgraded to 8G RAM, EVGA 285GTX, Soundblaster Extreme Gamer sound card, Q9550 quad CPU w/Freezer 7 cooler, and 850w PS, Win7 Home Prem.

So far, FO3 is the only game I have that I've found that runs better in XP than Win7. The stuttering isn't too bad to play comfortably, it's just left me wondering...


I guess it depends on how bad the "studdering" is. Have you also turned off things such as services, virus scanners, etc? I with ATI, they have a tool that you can run before you run a game that shuts down all kinds of unnecessary services. It's called AMD Fusion. I haven't tried it myself but you can get it at http://game.amd.com/us-en/drivers_fusion.aspx?p=1.

You just run this before you're ready to run a game. Once you're done, then you close down Fusion and it puts your machine services back online.
m
0
l
a b 4 Gaming
a b $ Windows 7
February 9, 2010 4:05:10 PM

isamuelson said:
I guess it depends on how bad the "studdering" is. Have you also turned off things such as services, virus scanners, etc? I with ATI, they have a tool that you can run before you run a game that shuts down all kinds of unnecessary services. It's called AMD Fusion. I haven't tried it myself but you can get it at http://game.amd.com/us-en/drivers_fusion.aspx?p=1.

You just run this before you're ready to run a game. Once you're done, then you close down Fusion and it puts your machine services back online.


Yes, antivirus is running. But it runs while playing in XP too. I have very little running in Config/Startup; only about 3-4 necessary items. I haven't tried turning off any MS services, etc. because I don't know what I'm doing there. That AMD Fusion looks promising. Unfortunately, they say it requires an AMD proccessr. Maybe 'stuttering' was a poor description. What I'm noticing in game is a pause when turning rapidly in first-person; just a blink-of-the-eye pause. Btw, thanks for the info on the emulation (or lack thereof).

One other caveat I should have mentioned; I could not even get the game to run in Win 7 x64 until I found a pgm that disables "Games for Windows Live". The game would load and play for less than a minute before crashing to the desktop. Once GFWL was out of the picture, the game ran flawlessly. Seems strange that a Games for Windows product running on a MS OS would need to have a MS prg disabled before it would work properly...
m
0
l
a b $ Windows 7
February 9, 2010 4:22:17 PM

isamuelson said:
Well, yeah. I thought about that and it's not true emulation, but it still has to decode the 32-bit instructions via "software" in the CPU, so it's still not as fast as TRUE 32-bit, but it's minimal. It shouldn't be causing the original poster any problems like what he's seeing.



Incorrect - The binaries run natively.


On the processor side:

The CPU reads the actual binary code, which is presented in the form of instructions. These instructions are the "x86" and "x64" that you read/hear about. Now, most people understand that an x86 Processor (pre~2003, 2004) can't run x64 code. That's because the newer standard has commands, syntax, instructions, and data sets that do not exist in the older one. BUT: Understand that the newer x64 instruction set includes everything in the x86 - So any x64 processor can and will fully handle anything that's x86. Indeed, if your processor is a Sempron, P4, or newer, it *is* an x64 processor.

Therefore, as long as the (game) was compiled to the x86 (32bit) standard, the CPU can fully understand and run it because they are still 'speaking' the same language. And the reverse isn't true: Imaging speaking to a grade school child with words and phrases an MBA can use. The kid (older standard) won't understand it. The MBA can fully understand the child, though.



On the side of the OS: There is a similar mechanic, though here it's called an "API" (Application Programming Interface). In very broad terms, it works like the instructions sent to a CPU: These are the commands and formats programmers use to talk to the Operating System, which they use to access system resources like memory and information on the hard drive. You can think of it like the teller window at the bank: It's your way to pass an instruction inside in order to get the result you want. When you go to the teller (API), you have to give her a message (instruction) in the format that that she understands, right? The OS wants to see some Function (Withdrawl), the location required (Account #), and some data set (how much). If you give the teller (OS) that, then you'll get your twenty bucks.

As long as the program (game, whatever) follows the proper API's then it will run on the Operating System.

Therefore: As long as a given (32 bit) game is written to the proper Windows (Vista) API's, and compiled to run on an x86 processor, then it *will* run on 64 bit (Vista).


Generally speaking, when you hear about incompatibilities it's because the programmers who wrote a given application either did not adhere to the proper API spec when they wrote their code, or because they took short cuts (which may no longer work), or because the (new) Operating System's API set is different from the old one.
m
0
l
a b 4 Gaming
a b $ Windows 7
February 9, 2010 4:32:52 PM

Scotteq said:
Incorrect - The binaries run natively.


On the processor side:

The CPU reads the actual binary code, which is presented in the form of instructions. These instructions are the "x86" and "x64" that you read/hear about. Now, most people understand that an x86 Processor (pre~2003, 2004) can't run x64 code. That's because the newer standard has commands, syntax, instructions, and data sets that do not exist in the older one. BUT: Understand that the newer x64 instruction set includes everything in the x86 - So any x64 processor can and will fully handle anything that's x86. Indeed, if your processor is a Sempron, P4, or newer, it *is* an x64 processor.

Therefore, as long as the (game) was compiled to the x86 (32bit) standard, the CPU can fully understand and run it because they are still 'speaking' the same language. And the reverse isn't true: Imaging speaking to a grade school child with words and phrases an MBA can use. The kid (older standard) won't understand it. The MBA can fully understand the child, though.



On the side of the OS: There is a similar mechanic, though here it's called an "API" (Application Programming Interface). In very broad terms, it works like the instructions sent to a CPU: These are the commands and formats programmers use to talk to the Operating System, which they use to access system resources like memory and information on the hard drive. You can think of it like the teller window at the bank: It's your way to pass an instruction inside in order to get the result you want. When you go to the teller (API), you have to give her a message (instruction) in the format that that she understands, right? The OS wants to see some Function (Withdrawl), the location required (Account #), and some data set (how much). If you give the teller (OS) that, then you'll get your twenty bucks.


As long as the program (game, whatever) follows the proper API's then it will run on the Operating System.

Therefore: As long as a given (32 bit) game is written to the proper Windows (Vista) API's, and compiled to run on an x86 processor, then it *will* run on 64 bit (Vista).


Generally speaking, when you hear about incompatibilities it's because the programmers who wrote a given application either did not adhere to the proper API spec when they wrote their code, or because they took short cuts (which may no longer work), or because the (new) Operating System's API set is different from the old one.


I realize that explanation was directed at isamuelson, but I have to say; that was the clearest explanation of the subject I've ever come across. Heck, even I understand it now... :) 
m
0
l
a b $ Windows 7
February 9, 2010 4:44:22 PM

I never said incompatibility. Maybe I should explain it further. I see how my synopsis was flawed (my fault).

What I meant to say that typically, 32-bit applications perform better on 32-bit HARDWARE and 64-bit hardware is compatible with 32-bit applications.

Windows 64 (which supports both 64-bit and 32-bit applicatiojns) uses the Windows on Windows 64 (WOW64) x86 emulation layer. The WOW64 subsystem isolates 32-bit apps from 64-bit apps. This prevents file system and registry problems. The OS provides interoperability across the 32-bit/64-bit boundary for COM and for basic operations which includes things like cutting and pasting with the clipboard. However, 32-bit processes cannot load 64-bit DLLS and 64-bit processes cannot load 32-bit DLLs, hence the need for 64-bit drivers for your hardware.

However, my main point was how the WOW64 layer does provide the means to run 32-bit software, but it won't necessarily run as well as it would in native 32-bit Windows on 32-bit hardware. That's where my explanation was flawed and I can see why. Sorry about that. It was lunch time and I was trying to explain something in simple terms with the least amount of typing and it failed. Argh!
m
0
l
a b 4 Gaming
a b $ Windows 7
February 9, 2010 11:04:50 PM

OK. I've learned a lot and been enlightened. Thanks to all. But cutting to the chase here... all else being equal, do games properly written in 32 bit code suffer from slower (albeit, slightly) execution when running in a 64 bit OS environment than they would within a 32 bit OS's environment? (Assuming a 64 bit processor and adequate hardware)
m
0
l
a b $ Windows 7
February 10, 2010 12:11:58 AM

clutchc said:
OK. I've learned a lot and been enlightened. Thanks to all. But cutting to the chase here... all else being equal, do games properly written in 32 bit code suffer from slower (albeit, slightly) execution when running in a 64 bit OS environment than they would within a 32 bit OS's environment? (Assuming a 64 bit processor and adequate hardware)


Yes, they will run slower but usually, it's not something you would usually notice unless you measured the performance.

I've seen people though complain when they've gotten something like 100 fps on a game under 32-bit Windows and then they go to 64-bit Windows and it drops to 90 to 80 fps and they freak! :o 

But usually, you shouldn't see a drop off that makes the game unplayable unless the game was optimized poorly (such as GTA IV).
m
0
l
!