|
Pages: [1]
|
 |
|
Author
|
Topic: Intel Macs (Read 2982 times)
|
Han
Guest
|
hi all, now that the Intel Macs are out (I have a MacBook Pro), are there any moves to make the OSX version of UQM a universal binary?
Secondly, if so, then that would largely solve the problem of endianness between save games, right?
|
|
|
|
|
Logged
|
|
|
|
Han
Guest
|
Oh, I might just add that I'm currently running UQM on Rosetta on my MBP (at least I hope it is... Get Info says that UQM is a PPC app), while I'm also running UQM on my PC (I need windows on my desktop but the MBP is still my one true love).
That being the case, I would like to play a single game of UQM but be able to transfer between PC and Mac. Unfortunately the difference in endianness is an issue, but I was hoping that since the MBP is running on Intel chips, perhaps a universal binary would allow me to transfer save games in this way.
|
|
|
|
|
Logged
|
|
|
|
Novus
Enlightened
 Offline
Gender: 
Posts: 1938
Fot or not?
|
hi all, now that the Intel Macs are out (I have a MacBook Pro), are there any moves to make the OSX version of UQM a universal binary?
Secondly, if so, then that would largely solve the problem of endianness between save games, right?
Well, it wouldn't solve the problem; you'd end up with two incompatible Mac versions instead. The Intel Mac version would probably be compatible with the other Intel versions, though (Windows, Linux, et.c.).
Fixing the save game format is one of things that are supposed to be done before version 1.0, IIRC.
|
|
|
|
|
Logged
|
|
|
|
|
|
Death 999
Global Moderator
Enlightened
Offline
Gender:
Posts: 3874
We did. You did. Yes we can. No.
|
hi all, now that the Intel Macs are out (I have a MacBook Pro), are there any moves to make the OSX version of UQM a universal binary?
Secondly, if so, then that would largely solve the problem of endianness between save games, right?
Well, it wouldn't solve the problem; you'd end up with two incompatible Mac versions instead. The Intel Mac version would probably be compatible with the other Intel versions, though (Windows, Linux, et.c.). Fixing the save game format is one of things that are supposed to be done before version 1.0, IIRC.
Novus, the question was about a 'universal' app, which is what Apple is calling an application that works on both kinds. So, NO, it WOULDN'T be incompatible.
|
|
|
|
|
Logged
|
|
|
|
|
|
Michael Martin
Core Team
*Smell* controller
Offline
Posts: 387
|
With the exception of savegames, though, the content is all basically endian-safe.
The fact that the same source compiles both for x86 and PowerPC as it is implies that gluing two such binaries together shouldn't be a huge deal. Any endian-specific code would already have been dealt with.
Yes, this is said with the breezy confidence of someone who's never tried to do it. We'd really need to have people with x86 Macs available for testing purposes to be confident that the "easy attempt" worked.
|
|
|
|
|
Logged
|
|
|
|
Death 999
Global Moderator
Enlightened
Offline
Gender:
Posts: 3874
We did. You did. Yes we can. No.
|
Novus, the question was about a 'universal' app, which is what Apple is calling an application that works on both kinds. So, NO, it WOULDN'T be incompatible.
Unless I've completed misunderstood Apple's documentation, an OS X "universal" binary is just two binaries glued together so that it looks like a single executable. This means that endianess issues are still a problem as the same file contains two different programs that are supposed to do the same thing on different systems.
I don't see anything in your link saying that that is the strategy they used (though I only spent a few minutes on it).
Certainly, they do speak of endianness issues, but it seems to me moer like they're trying to educate those who only work on big-endian machines about the difference, rather than saying that they have to be handled in one way or another.
If our code already works on both, and we aren't basing it off _i386_ and _ppc_ but rather _BIG_ENDIAN_ and _LITTLE_ENDIAN_ then we're in good shape.
But let's see, where do we care about endianness? Anywhere other than file I/O?
|
|
|
|
|
Logged
|
|
|
|
Novus
Enlightened
Offline
Gender:
Posts: 1938
Fot or not?
|
I don't see anything in your link saying that that is the strategy they used (though I only spent a few minutes on it).
Certainly, they do speak of endianness issues, but it seems to me moer like they're trying to educate those who only work on big-endian machines about the difference, rather than saying that they have to be handled in one way or another.
Right in the introduction, they state that universal binaries run natively on both PowerPC and i386. Therefore, the universal binary contains native code for both architectures, as their instruction sets are incompatible. What I said isn't explicitly stated, though.
If our code already works on both, and we aren't basing it off _i386_ and _ppc_ but rather _BIG_ENDIAN_ and _LITTLE_ENDIAN_ then we're in good shape.
But let's see, where do we care about endianness? Anywhere other than file I/O?
File I/O is hard to do efficiently and completely endianness-neutrally. However, the content loading routines are all OK. The save game routines are the real problem, as they just dump internal data structures to disk with no attempt at consistency (as meep-eep said, it's a miracle UQM save games can be moved between even different operating systems on the same CPU).
|
|
|
|
|
Logged
|
|
|
|
|
Pages: [1]
|
|
|
|
|
