November 7th, 2007, 02:39 PM
32bit vs 64bit Destroying Game Playability/Compatibility
Okay, so as many gamers are already aware, there are issues with having a game that was built for a 32 bit system that plays blazing fast in a 64 bit system. I have seen it, heard it, and fought with it. It is a major struggle to find any solutions for it, and it definitely makes for some serious disappointment when you buy a new game hat you can't play on a new system.
The question that arises as I'm contemplating on where to start with regard to 3d engines is: What if this happens to my project? Now a quick and easy answer is to find/purchase an engine that runs on both, and develop to that end. Has anyone had any experiences with this as a problem, and if so, what is your story?
Ride that train of thought out all the way. See where it takes you. Then, think about if that's where you want to be.
November 11th, 2007, 03:28 PM
The only reasons that I can think of why a game would run "blazing fast" on a x64 system is simply because the game uses RDTSC instructions or the game's movements from the input devices are not timed. This shouldn't be a big issue at all.
The only games I can think of would be games that were developed before x64 became a standard platform such as Unreal Tournament or Quake 1-3).
December 15th, 2007, 06:07 PM
a 32-bit engine running faster on a 64-bit system...huh? when a 32-bit program runs on a 64-bit system it runs in compatibility mode where it's the same as it running on 32-bit only system (64-bit cpu's only real advantage is registers are 64-bits wide instead of 32 and the data bus is wider).The only advantage i can think is that the 64-bit OS would run slightly faster but it's hardly "blazing" in comparison.
As for porting your applications to 64-bit. Just re-compile them with a 64-bit compiler...easy...done. You may have to use some different libs and stuff but it's not a very big job. Windows have cleaned up their 64-bit OS's a bit as well in the 64-bit versions which may effect the speed, when functions are called from the api they now use the fastcall method instead of standard call (parameters in registers instead of stack)...stupid little things like that.
And doesn't RDTSC exist in most 32-bit cpu's too? my assembly "cheat-sheet" says athlon upwards....i'll have to check that out (or is it that they can now assume the feature is present as all 64-bit cpu's have it?).
Last edited by calpol2004; December 15th, 2007 at 06:14 PM.
December 16th, 2007, 03:20 PM
RDTSC is available on most CPU's, yes. On 32 bits systems they will work fine yet on 64 bits CPUs they might not work as expected since the two cores might not be in sync and their RDTSC timestamps might not be equal resulting in faulty timing in games that depend on RDTSC instructions. As you might recall, RDTSC measures the cpu cycles since startup, a fractional startup delay in a core will throw the timestamps off.
December 16th, 2007, 04:05 PM
I haven't heard of this either, and it doesn't make sense to me that it would happen. It was my understanding that most games are designed so that critical timings are delayed using the real-time clock when needed, precisely to avoid dependencies on the upper-bounds speed of the CPU and GPU. While it was common for older games from the 1980s (and some Flash games from the 1990s) to have timing problems of this sort, the rapid rise of processor speeds in the 1990s made it nearly impossible to write salable programs which would be affected by clock speed - otherwise, a program written today would be already unplayable on new machines by the time it reached the market. I can't think of any reasons why this would be changed in going from 32 bits to 64 bits, especially if it is actually running as 32-bit code in emulation - if anything, you would expect it to run slower on the 64 bit machines, and it certainly wouldn't get any of the bus width advantages which native 64 bit programs would enjoy.
Last edited by Schol-R-LEA; December 16th, 2007 at 04:07 PM.