#1
  1. finding balance
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jul 2004
    Posts
    444
    Rep Power
    54

    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.
  2. #2
  3. No Profile Picture
    Contributing User
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2004
    Posts
    1,014
    Rep Power
    788
    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.

    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.
    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).
  4. #3
  5. Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Sep 2004
    Posts
    258
    Rep Power
    55
    wha?

    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.
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Beginner (1000 - 1499 posts)

    Join Date
    Jan 2004
    Posts
    1,014
    Rep Power
    788
    calpol2004,

    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.
  8. #5
  9. Commie Mutant Traitor
    Devshed Intermediate (1500 - 1999 posts)

    Join Date
    Jun 2004
    Location
    Alpharetta, GA
    Posts
    1,806
    Rep Power
    1570
    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.
    Rev First Speaker Schol-R-LEA;2 JAM LCF ELF KoR KCO BiWM TGIF
    #define KINSEY (rand() % 7) λ Scheme is the Red Pill
    Scheme in Short Understanding the C/C++ Preprocessor
    Taming Python A Highly Opinionated Review of Programming Languages for the Novice, v1.1

    FOR SALE: One ShapeSystem 2300 CMD, extensively modified for human use. Includes s/w for anthro, transgender, sex-appeal enhance, & Gillian Anderson and Jason D. Poit clone forms. Some wear. $4500 obo. tverres@et.ins.gov

IMN logo majestic logo threadwatch logo seochat tools logo