Moving to Intel!
Last Monday at WWDC, Steve Jobs dropped the bomb that the Mac platform was going to move to Intel-based chips. This represents a significant shift in direction, and a bit of a psychological one as well. It's been a whole week now, and I've had plenty of time to digest the implications. What follows is my somewhat lengthy analysis. There are many facets to the move, and I'll attempt to compartmentalize these where I can.
On Metrowerks CodeWarrior
Let's start off with the unspoken truth here - Metrowerks' CodeWarrior is effectively dead on the Mac platform. They sold off their entire x86 toolset to Nokia a few months back, and they'd now need this back to have any future on the Mac platform. This also comes on the heels of their spin-off from Motorola to Freescale a year or so ago which appears to have left them in a bit of a transitional period for a while. Not coincidentally, for the first time in as long as I can remember, they did not have a new major CodeWarrior release last year.
Before last week, I would have taken Metrowerks' sell-off of the x86 toolchain as relatively good news - they never competed effectively on Windows, and had spread themselves a bit thin, IMHO, which was reflected in the lack of major updates to their Mac tools. However, they still generated the best code on the Mac platform, and their compiler - though only able to take advantage of 1 CPU - was nearly twice as fast as Xcode/gcc in many cases. As well, CodeWarrior had many options that Xcode/gcc did not that made for an easier time porting Windows software to the Mac: 1-byte bools, 2-byte shorts, support for old-style for-loop scoping, the ability to have easily-maintained build targets, and support some VC 6.0 syntax oddities that, while non-standard, were often used.
But things have changed quickly, and there's a new sheriff in town. :-) Xcode 2.0 and 2.1 have made huge strides to close ranks with CodeWarrior. We presented Apple with a list of things that we needed badly from Xcode and gcc sometime early last year, I believe. As it stands now, it sure looks like Apple has taken that feedback to heart as Xcode 2.1 addresses pretty much all of those issues. Part of this work involved moving our libraries and a few games over to Xcode (KOTOR, for example, builds in both Xcode and CodeWarrior), and at this point it looks like eliminating CodeWarrior will not be any big deal for future projects. From a sentimental standpoint, I'll miss CodeWarrior - Metrowerks always treated me right and gave great support.
On the Porting Process
The transition to x86 will, long-term, make the porting process easier. The move to x86 will make ports go faster mainly because we won't have to deal with byte-swapping issues. This represents a non-trivial amount of work in making a Mac version of a game - binary data lives everywhere. Even games based on portable engines like the Quake 3 engine require byte-swapping changes with each game. Take Jedi Academy for example: scholars of the release notes for that game will remember that it shipped with a bug where acid rain on the Vjun level fell indoors as well. This was a subtle byte-swapping issue for a specific chunk of binary data that was again specific to just one level of Jedi Academy. That was (and still is) the fastest port I've ever done at 7 weeks, and it would have gone much quicker had I not had to deal with endian issues.
However, in the short-term the move to x86 will add some additional work. For starters, the PowerPC Macs currently make up 100% of the Macs for which software is sold. (Someone prove me wrong and show me software that is still sold to 68k Mac users.) In looking back, the transition from 68k-based Macs to PowerPC-based Macs took roughly 4 years start to finish. PowerMacs were introduced (and started shipping) in March 1994. By 1998, most software vendors had finally discontinued 68k versions of their software. In 1998, Mac OS 8.5 was the first MacOS to require a PowerMac. If it takes 4 years from shipping for most current Mac users to get off the PowerPC platform and Apple is one year away from shipping it's first x86-based Mac, then we're looking at roughly 5 years before Mac developers kill PowerPC versions for good. Likely it'll happen sooner, particularly for demanding software like games, but the transition will still be measured in years.
One thing I'll miss about dealing with byte-swapping issues are the interesting side-effects. For example, in Jedi Knight and Jedi Academy, if I forgot to swap a certain piece of data, your lightsaber would not attach itself to your hand but would instead be positioned in the center of the model. As it happened, this was on your crotch, facing forward. Mark Krenek had another interesting bug where, while working on Spider-Man, Spidey's hand protruded from his butt. Glenda had another byte-swapping issue in Madden 2000 where players' heads would rotate continuously. Good times.
In a twist of irony, pretty much all next-generation consoles will be running on big-endian processors like the PowerPC. If it ever happens that we end up predominantly porting games from consoles to the x86 Mac (instead of from Windows to the Mac), we'll have to deal with byte-swapping again in force. Could we be so lucky?
On the Implications for the Mac Platform
The move to x86-based Macs has several implications for the Mac, and it's too early to tell how it's all going to play out. Phil Schiller, an Apple VP, has publicly stated that Apple will not prevent users from running Windows on these new x86 Macs, but Apple will prevent OSX from being used on any old x86-based PC. This is a gamble, and I believe it greatly increases the odds for two extreme (and wildly different) scenarios to play out.
The first scenario is that these new Macs are seen by the general populace as an all-in-one solution and Mac market-share increases wildly. They run OSX, they run Windows, they run Linux. Why buy any other PC when you can get all 3 on a Mac? Well, aside from price that is. ;-) If OSX only runs on Apple hardware and this notion of a one-stop solution gains significant traction with the computer-using populace as a whole, Apple is in a good spot. I suspect some hacker will come up with a way to run OSX on non-Apple hardware after a time, but I'd expect Apple to actively pursue these transgressions. It's entirely possible that once more people use OSX and see the relative elegance and security of the OS compared to Windows, they'll leave Windows behind, making these new Macs a "gateway drug" to OSX.
The second scenario is that the Mac enters a death spiral due to Windows running on the Mac hardware. It's possible that developers who now cross-develop for the Mac and Windows decide to cut costs and let their Mac users dual-boot into Windows and run the Windows versions of their software. I suspect this temptation will be greatest for the smaller developers first. If Mac users start showing a real willingness to do this, the trend could become irreversible.
This is a particularly unpleasant scenario for Mac games, since Mac ports usually arrive 3-12 months after they appear for Windows, and usually at the original full price-point - at a time when the Windows version has already seen discounts. These are unfortunately unavoidable aspects to doing most Mac game ports. Ryan Gordon made some points, drawing upon his experience with Linux gamers, that tend to show that this is already a real problem with the Linux user base. Unfortunately his comments were in an old .plan entry, and I can't find a working link to them now. The bottom line is that the health of the Mac platform will always depend on the availability of Mac software.
Will people who buy Macs because they can run both Mac software and Windows software slowly migrate to OSX and leave Windows behind? Will Mac users notice "Hey, Windows isn't all that bad after all!" and start to leave the Mac behind? Too early to say, that's for sure.
On What the x86 Will And Won't Give Us
I believe the move to x86 is inspired mainly by Apple's frustration in getting low-power G5s for PowerBooks as well as significant quantities of faster G5s for the towers. I heard lots of "informed speculation" at WWDC about Apple's plans from folks I consider to have good knowledge of the situation. The general consensus seems to be that laptops will be the first to move to x86. Intel really has some fantastic laptop CPUs - low power and high performance, so it makes sense that the PowerBooks and Mac mini will be the first and will benefit most from the switch.
I'm less sure about what this means for peripherals. For example, Mac video cards currently contain Mac-specific firmware just to run on the Mac. It wouldn't surprise me either way if these new x86 Macs could use PC video cards right off the shelf or if they still needed Mac-specific firmware. One thing I have seen speculated is that the move to x86 will magically improve OpenGL support since the Mac drivers will be able to leverage work done on OpenGL for Windows. I don't know if this logic holds true - Apple's OpenGL implementation is radically different from what exists on Windows. On the PC, each vendor (ATI, nVidia, etc) implements their own OpenGL stack. On the Mac, Apple maintains OpenGL with hooks for each card to talk to OpenGL. As I understand it, most optimizations for OpenGL on the PC are algorithmic rather than, say, hand-tuned x86 assembly in the drivers.
It has been leaked on the net that the "Developer Transition Macs" as they are called have integrated Intel 3D video on the motherboard. I don't know at all if these will ever make it into a shipping Mac. My hope would be that they do not - we have enough fun as it is managing two different 3D chipsets, and the Intel graphics chipset isn't really geared towards high-performance gaming. The chipset is, as I understand it, very CPU-dependent for many things. You can read more about it here.
That ended up being more than I was planning to write, and yet I can think of several more things to add. However, I've clearly got a ton of work to do in the next year to get past, current and future games ready for x86 Macs, so I'm going to shut up for now and get to work. :-)