Why Intel Macs only?

blightstrider · **Joined:** Fri Sep 22, 2006 9:00 pm **Posts:** 4

Just read the announcement of the Beta test for mac, but it seems only Intel Macs are supported, so I'm wondering if this is considering that the majority of Mac users haven't yet made the jump to Intel, this doesn't make sense to me why they would shut out a large segment of their market. I have a 3 year old powerbook 1.4 ghz which works fine for most games, and I don't have the money to spend on a new Macbook since I'm a student. No-one I know with a Mac has yet bought a new Intel Mac, so I really have no way to play URU if PowerPC macs aren't supported. Any thing to clarify the issue is much appreciated.

chucker · **Posted:** Tue Jan 23, 2007 1:23 am

The porting technique they use doesn't allow for building on different architectures than the original code.

Islander · **Posted:** Tue Jan 23, 2007 1:40 am

Please, don't take this the wrong way:

Mac users have been pleading for years to have URU compatible with Macs. Now Cyan have finally done it, to their best of their ability.

It is, I grant you, unfortunate that only Intel Macs are supported, but this is still a huge step forward.

My opinion: Something's better than nothing, and this is a whole lot more than 'something'.

Firesign · **Posted:** Tue Jan 23, 2007 2:29 am

it also makes economic sense. the cost to port uru to non-intel macs would be vey costly for what is, essentially, a dead platform. not that i dislike non-intel macs (heck, im typing this on a g3 ibook), but theyre done. the intel macs are extremely similar hardwarewise to a pc which, while certainly not making the job trivial, makes it more economically feasible.

Zib_Redlektab · **Posted:** Tue Jan 23, 2007 4:09 am

woot, i be rockin' da macbook pro with intel core duo...

any word on a date we can expect this beta to commence?

Tiran · **Posted:** Tue Jan 23, 2007 8:30 am

Cyan is using TransGaming's Cider to run MOUL on Macs. Cider works mostly as a compatibility layer that translates Windows DirectX and Win32 api calls to Mac OS X calls. The technology is similar to WINE for Linux. Because Cider is not a virtual machine or emulator it works only for Intel compatible CPUs.

HeadCheese · **Posted:** Tue Jan 23, 2007 12:50 pm

I have both, but since that wasn't an option in the poll I voted for the one more pertinent to this discussion - Intel-based Macs.

Were it not for the existence of the Intel-based architecture, I doubt we'd even be having this discussion about a Mac port for URU in the first place.

Firesign · **Posted:** Tue Jan 23, 2007 2:42 pm

HeadCheese wrote:

I have both, but since that wasn't an option in the poll I voted for the one more pertinent to this discussion - Intel-based Macs.

Were it not for the existence of the Intel-based architecture, I doubt we'd even be having this discussion about a Mac port for URU in the first place.

actually cyan had always planned for a mac version of uru. if i remember right, it didnt happen before because the promised mac version of the havok engine either never materialized or came too late.

chucker · **Posted:** Tue Jan 23, 2007 2:59 pm

Firesign wrote:

actually cyan had always planned for a mac version of uru. if i remember right, it didnt happen before because the promised mac version of the havok engine either never materialized or came too late.

That's true, but that particular Mac version would
1) not have required Intel Macs (the architecture move hadn't even been announced then),
2) not have used a virtualization layer.

It would have been more of a "real" Mac app, which possibly means more optimization, but also a lot more work (possibly prohibitively so).

Firesign · **Posted:** Tue Jan 23, 2007 3:06 pm

chucker wrote:

Firesign wrote:

actually cyan had always planned for a mac version of uru. if i remember right, it didnt happen before because the promised mac version of the havok engine either never materialized or came too late.

That's true, but that particular Mac version would
1) not have required Intel Macs (the architecture move hadn't even been announced then),
2) not have used a virtualization layer.

It would have been more of a "real" Mac app, which possibly means more optimization, but also a lot more work (possibly prohibitively so).

which was the point of my post and my original post. i guess i shouldve been more clear about that.

Zib_Redlektab · **Posted:** Tue Jan 23, 2007 7:33 pm

chucker wrote:

That's true, but that particular Mac version would
1) not have required Intel Macs (the architecture move hadn't even been announced then),
2) not have used a virtualization layer.

3. take a lot longer and more money to make

isomorphic · **Joined:** Tue Feb 13, 2007 4:36 pm **Posts:** 92

There is nothing inherent in the design of WINE that would prevent Cyan from making a universal binary. WINE actually consists of two things: the binary compatibility layer and WineLib, a source-level compatibility layer. In theory, compiling for PowerPC and linking with a PPC WineLib should produce a Unix native binary. This is what the Darwine project has mostly focused on.

It is hard to tell if Cider is simply Wine compiled for OS X on Intel, or if it is actually a WineLib based solution. If the latter, then it is probably third-party libraries that are keeping URU off PowerMacs now. If the former, there is no reason for Cider to be a publisher-only solution.

For what it is worth, I'm using an iMac Core2Duo.

chucker · **Posted:** Fri Feb 16, 2007 4:14 am

isomorphic, you're assuming that:
1) Cyan can compile Uru Live for two architectures. Not so easy: Visual C++, the toolchain they use, has no support for PowerPC compilation, so they'd have to add a toolchain just to compile for PowerPC, with, say, gcc.
2) Cyan can get the developers of third party libraries they use to compile the libraries for two architectures, or to give Cyan the source code so they can do it themselves. In particular, OpenAL and PhysX. With OpenAL, perhaps. With PhysX? Not very likely at all.

Unless, of course, you're suggesting wrapping OpenAL and PhysX calls into QEMU and adding a PowerPC toolchain for Uru Live. Which is even more absurd: at that point, it would be easier to simply replace OpenAL with the Mac OS X-shipped version of OpenAL, which is already a Universal Binary, and to replace PhysX with some Mac OS X-available physics library (oh boy). And then you might as well make a Mac OS X-native Uru Live client application…

Sorry, it just isn't going to happen.

Tiran · **Posted:** Fri Feb 16, 2007 1:07 pm

chucker wrote:

2) Cyan can get the developers of third party libraries they use to compile the libraries for two architectures, or to give Cyan the source code so they can do it themselves. In particular, OpenAL and PhysX. With OpenAL, perhaps. With PhysX? Not very likely at all.

OpenAL is open source and supports Linux, Mac and Windows http://openal.org/downloads.html

PhysX supports only Win32 on i586 compatible computers: http://www.ageia.com/drivers/drivers.html

chucker · **Posted:** Fri Feb 16, 2007 2:55 pm

Tiran wrote:

chucker wrote:

2) Cyan can get the developers of third party libraries they use to compile the libraries for two architectures, or to give Cyan the source code so they can do it themselves. In particular, OpenAL and PhysX. With OpenAL, perhaps. With PhysX? Not very likely at all.

OpenAL is open source and supports Linux, Mac and Windows http://openal.org/downloads.html

Yes, I know; I should have been clearer on that part. Mac OS X 10.4 actually ships with OpenAL, though its version may not be the newest.

Quote:

PhysX supports only Win32 on i586 compatible computers: http://www.ageia.com/drivers/drivers.html

Right.

Why Intel Macs only?

Who is online