Will Colin McRae support 64 bit on Mac?
Posted 21 October 2005 - 02:22 PM
I noticed Codemaster released a patch to allow users to run CMR 2005 on Windows 64-bit edition. http://www.codemaste...ownloadid=20835 Does anyone know if this will be in the Mac-version?
Have anyone seen/heard req for the Mac-version?
Have anyone seen/heard how far the game is from release?
Running F1, 4x4, MTX and Nascar 2003 while waiting
Posted 21 October 2005 - 02:46 PM
Hang in there.
Posted 21 October 2005 - 08:17 PM
Steephill, on October 21st 2005, 03:22 PM, said:
It won't be. The patch is just what you said: "a patch to allow users to run CMR 2005 on Windows 64-bit edition." That's all. If you're thinking it's a patch that makes the game faster or better somehow, it's not. Pretty much the only thing 64 bit is good for is accessing vast amounts of memory, and I kinda doubt CMR 2005 needs more than 4GB of RAM. Well, I hope.
Posted 22 October 2005 - 04:19 AM
Posted 22 October 2005 - 01:55 PM
Posted 24 October 2005 - 03:49 AM
On the Mac this is not an issue (they just work), so you don't need two executables, the 64 bit version just adds compatibility with Windows 64 and does not offer any performance advantages over the 32 bit version. Also OS X Tiger is not a fully 64 bit OS as all the major frameworks are still 32 bit. Only Darwin has full 64 bit support.
Posted 24 October 2005 - 02:42 PM
bismilah, on October 22nd 2005, 05:19 AM, said:
I think the more pertinent question is, does any game for Mac need to be? And the answer is no. There's nothing to be gained by 64-bit support, except additional memory addressing. And that's hardly a problem for any game on the market today, or, conceivably, for many years.
Senior Editor, Macworld.com News
Columnist, Macworld "Game Room"
Posted 24 October 2005 - 05:37 PM
Mac data being virtually nonexistent, the fallback case for practical examples is WinXP, 32 and 64 bit versions, and Linux. While the increased memory/ no performance gain argument has been standard, it's really a bit more complex.
Developers have been moving somewhat to take advantage of 64 bit OS operation, and some have put extra detail and features into 64 bit versions with no performance degradation- degradation claimed to happen under 32 bit. (Naturally much of this centers on AMD, with their 18 month+ lead time over Intel in 64 bit consumer CPUs [Intel had for years asserted that consumers would not need 64 bit operation for many years yet, concentrating their 64 bit efforts on Itanium for the server space; without Chipzilla behind it MS was rather slow on XP/64. Without AMD it's doubtful Intel would've brought along their 64 bit efforts beyond the 48-bit memory addressability they've had for some time, hence the unlikeliness of MacIntels in the near future... while suitable for notebooks, it seems unlikely Apple would've switched CPU vendors, at least to Intel, with Powermacs/ XServes in mind]). Some aspects of that have been evident for some time- U2004 demo:
(Perhaps the load time advantage is why Ryan Gordon recently released a 64-bit Win .exe for for the UT2004 dedicated server. At 9 MB it adds very little to the install, and '04 loads maps rather slowly. A 64 bit client was released also). It's probably relevant to mention Tim Sweeney, Mr. Unreal, is bullish on 64 bit, and gave a keynote speech at the Sep. '03 intro of AMD's 64 bit Opteron.
Six months later, "Shadow Ops: Red Mercury - A Look At The First 64 Bit Windows Game," performance and screens under XP/64 beta, build 3790 (10/07/04):
AMD maintains a list of games with 64 as well as 32 bit support under Linux, Solaris (currently none) and Windows- current or planned- including
Chronicles of Riddick
Shadow Ops: Red Mercury
S.T.A.L.K.E.R.: Shadow of Chernobyl
Unreal Tournament 2004
WWII Tank Commader
The Dreadnought demo is especially interesting, as it shows a new for-license game engine planned for next year (sorry, the Instinct Engine uses Havok. So what else is new).
*uncompressed normal maps allowing for higher texture quality and greater detail
*significantly higher number of particle effects (e.g. more flames, more steam, more smoke, etc.)
*persistent decals (e.g. bullet holes stay on walls and don't fade away over time as in 32-bit)
*post-processing effects (e.g. screen glows)
*more pixel shader instructions (the adrenaline vision mode is built upon and replaces the base lighting shader to produce the effect)
Processor: 2.5 Ghz or better
OS: Windows® 2000
RAM: 1 Gigabyte
Graphics: Radeon 9700 and above or Geforce FX and above
Sound: Any 32 bit Sound Card
Recommended Specifications for 64-bit Enhanced Play
Processor: AMD Athlon™ 64 FX processor
OS: Windows 64
RAM: 2 Gigabyte
Graphics: Radeon 9800 256MB card or GeForce 6800
Sound: Soundblaster Audigy and Above
Apparently AMD should update their page, as the recent Bet On Soldier also has a 64-bit .exe available.
However, and getting back to the original question[s], there's no data to suggest a real need, and no way to test, desirability of Mac 64 bit gaming, so the theoreticians can argue this one 'til the cows come home, or OSX gets fully 64-bit. And this is enough time invested on my part.
Posted 25 October 2005 - 09:15 AM
But yeah, ppc32 already has loads of registers and the only ones ppc64 adds are used for memory management, so there's no reason for games to go 64-bit on PowerPC Macs unless they start using a whole lot of RAM real soon now.
Posted 25 October 2005 - 02:04 PM
edddeduck, on October 24th 2005, 02:49 AM, said:
Uhhh... what? Unless you know of any specific incompatibilities, that is absolute BS. I think Photoshop's swap manager/pointer mangler is one that they had to patch, cuz it's just that ugly. Drivers are another since they run in kernel space and need to be 64-bit clean. Other than that, Win64 has been worked on for far longer and supports far more than OSX's 64b extensions, and Wow64 is pretty much complete.
Posted 25 October 2005 - 02:06 PM
Batcat, on October 24th 2005, 04:37 PM, said:
Do your games use more than 4 GB of RAM? Since they couldn't use Carbon, Cocoa, or OpenGL if they did, that obviously means they don't and it's not worth it.
Posted 25 October 2005 - 08:21 PM
Posted 26 October 2005 - 12:45 PM
dj phat 2000, on October 26th 2005, 12:21 PM, said:
-- Charles Babbage
Posted 27 October 2005 - 10:27 AM
bobbob, on October 25th 2005, 01:04 PM, said:
Granted the changes needed are not always major but you still need to clean and check you code for anything that touches the kernel or any 32 bit library. Yes as you say most things work but when you start to spend time accessing hardware and or the kernel space you can hit trouble. For example here is a snippet from Microsoft on the subject of 64 bit compatibility.
" ....applications won't work in XP x64 because they access the system's kernel, which is 32-bit code in XP 32-bit but 64-bits in x64...."
You would be amazed now many games run on code that is 16 bit or 32 bit. For example the issue with Colin McRae it installs, but does not launch, this is due to the StarForce copy protection technology being incompatible with x64 as it is not 64 bit clean.
The problem is not the Microsoft libraries (as mentioned by bob-bob they are upto date) it is all the legacy libraries the 3rd party developers have been using for years (like the copy protection library) need rewriting/ making 64 bit clean. This is what can take time.
Also as a quick explanation on performance and 64 bit, I have the following interesting snippets from Windows gamers doing performance benchmarks and tests.
Game Performance Evaluation Comparison:
Chronicles of Riddick-Escape from Butcher's Bay THE RESULTS 32bit 1024x768 Average: 18.66, Min: 7.39, Max: 97.66 1280x1024 Average: 12.00, Min: 4.68, Max: 96.42 64 bit 1024x768 Average: 16.56, Min: 8.23, Max: 28.22 1280x1024 Average: 11.23, Min: 6.42, Max: 20.54
So the conclusion even on the PC is we have yet to see any game that takes advantage of the additional accuracy and power of the 64 bit processor over it's 32 bit ancestors. In fact for some games that have not been well optimised for 64 bit they can run slower.
When G4 chips came out they were not faster than the G3 chips unless you used the new part of the chip, the "Altivec" unit. When you wrote code that could use this extra feature you could get big gains in speed over the G3. For example when encoding an MP3. This is a similar situation to 32 v.s 64 bit. You need to use the new features to get the most out of the new processor.
A bit is short for “binary digit.” It is basically how a computer stores and makes references to data, memory, etc. A bit can have a value of 1 or 0, that’s it. So binary code is streams of 1’s and 0’s, such as this random sequence 100100100111. These bits are also how your processor does calculations. By using 32 bits your processor can represent numbers from 0 to 4,294,967,295 while a 64-bit machine can represent numbers from 0 to 18,446,744,073,709,551,615.
Obviously this means your computer can do math with larger numbers, and be more efficient with smaller numbers. So for example in a game you can have more accuracy with no performance hit as the increased accuracy takes no more time than before. The largest benefit will go to academic institutions and private companies, where large calculations are being performed, huge databases are being accessed, and complex problems are being solved.
For example here are quotes from the Far Cry and UT developers.
Epic was just as forthcoming about their 64-bit port of Unreal Tournament. In our interview with Tim Sweeney on the topic, Tim stated “Our goal in porting UT2003 to 64-bit was to show that it can be done without much work, that the platform is stable, and that it's ready for gaming. We're not doing anything that really takes advantage of over 4 gigs of RAM or the large virtual address space.
Anyway I hope these snips help explain the differences between 64 bit 32 bit and what issues you can come across when writing for both platforms. As you can see to get the advantages from 64 bit you have to design a game that uses the advantages of 64 bit if you don't it will not magically run faster just because the chip has 64 bit precision.
There might be a few holes in the benchmarks and quotes as technology advances and some of the issues might have already been solved. Any mistakes made in this post are my own.
Posted 27 October 2005 - 03:52 PM
Posted 27 October 2005 - 06:04 PM
Eric5h5, on October 27th 2005, 02:52 PM, said:
Addresses, not instructions, change size, yes. 32b applications get a benefit, though, since they still have 32b addresses but less space is taken by the kernel. Windows has a huge win, here, since Win32 reserves at least 1GB for kernel stuff. Even with 64b addresses, X86-64 is a net gain with more registers, according to AMD's tests with common apps. 64b PPC does lose, though, but Brad Oliver always brings up the fact that addresses aren't used very often in common PPC code, so if 64b addresses are actually needed then there'll still be a performance gain.
Don't confuse 64b CPUs with data or register sizes, though. Some people talk about math with larger numbers which doesn't make much sense. Your current CPU can do all the same math as a 64b CPU. Floating point numbers are the same in both, and 64b integers can be (are!) emulated on 32b processors. While 64b integers will be faster on X86-64, they're hardly used - especially not by games- and they aren't even the default size.
So, what does this mean? 64b gives you bupkiss unless you use >4GB of RAM or recompile for X86-64. You could have read any number of previous posts about this instead of asking it.
Posted 27 October 2005 - 06:07 PM
[Darn, bobbob beat me to the punch. :P]
Posted 27 October 2005 - 06:10 PM
edddeduck, on October 27th 2005, 09:27 AM, said:
You DO NOT have to recompile them to be 64b. Any 32b app can continue to load 32b libraries. You brought up one example of a 32b driver (some copy protection shim) that won't work, which isn't related.