Forums | MacLife

After the initial surprise- only surprising, I suppose, because UT2003 is being ported- it really shouldn't be so surprising. I had the noodling notion that it was nearly a given, so was probably in the works. This doesn't say it won't happen, or that negotiations aren't going on or in the works; it just says that the PC is the only platform at present. Even '03 wasn't announced until the PC version, or at least demo, was nearly or actually out, and that was with the demonstrated sales and support for UT in the Mac community. At this point, Unreal II is an unknown quantity as regards sales on PC, let alone Mac; and Loki couldn't make a go of the Linux market... FPSs with great graphics aren't exactly a novelty these days, and even the Mac has a goodly number.

UT2003 is Epic's first product with the current Unreal code base, and they're still getting the bugs squashed in '03. It uses a lot of advanced graphical effects, not all of which are trivial in OpenGL, tho they will be in time, with experience and OGL 2.0. Currently Epic's OGL renderer omits an effect or two, and Apple's OpenGL still lag's the PC's; if I remember Mark Rein's recent post aright, he says nice things about Apple's support on the issue re: new extensions, and mentioned there were still a few more needed...

Off the top of my head, those three issues alone- new code base, uncertain sales, OGL support not quite there yet- it really isn't too surprising there isn't a Mac U2 yet. They committed to porting '03 in-house, and come to think, by the time UT2003 for Mac ships, Epic/ Infogrames wil have a good idea of U2's sales and potential Mac sales. For them, with substantial money riding on it, that's probably soon enough for doing, or finalizing, say, a deal with Destineer (or whoever) to publish and Westlake to port,* and the other issues will have largely sorted themselves out... hopefully.

This doesn't look like an effort to freeze out the Mac market, but justifiable caution. Disappointing, but understandable.

*Assuming they don't decide to port U2 in-house.

(That raises a good question or 2 for the next installment of IMG's ongoing multipart interview with Westlake's Glenda  :idea: ...any thoughts on porting the current Unreal engine code unseen, and how much challenge will it be to match Gearbox's DX9 enhancements to Halo?  Are you out there, Greg?)

Edit: Speak o' the devil... must've posted just after I started composing. 

Actually, Greg, it went Gold a few Days ago. Infogrames says it should be in U.S. stores 2/4. My local Wal-Mart has had a slot for it for a week, and you know how stingy they are with shelf space. (Just did a product refresh and pulled a number of $10 JC editions I had eyes for- Sub Command, Homeworld GOTY Ed. [sniff]...)

And why bother with a Linux port? Dunno, but UT 2003 has one like UT before it and Doom III to come, separate patches and all. Dedicated server version's always a good way to go...

(And mostly off-topic, but Mac RtCW had patch v1.41 beta released yesterday. Brings it up to speed with the Win32 and, um, Linux versions...)

Well, the relevant point here would seem to be that there are no announced plans for any other platform- Linux & console included. So half the porting work has not been done for this game, tho the '03 work with the engine should give a good head start.

U2 has more than extra polys, tho- that flamethrower is 100% particle-based for starters. For graphics, Mark Rein recently posted


"Apple has been very helpful by providing some necessary OpenGL extensions in the latest updates to Mac OS 10.2 (Jaguar) and there are some more to come before our game ships. To run the game you're going to need Jaguar (OS X 10.2) and we recommended the latest OS updates to make sure you're getting the best performance and visual quality. Jaguar has a very easy method for updating the OS so every user with an internet connection should have no problem getting these."


..and that was about '03.

http://www.ina-community.com/forums/sho … id=3273472

An informative, if unpolished FAQ is on the official boards at

http://www.ina-community.com/forums/sho … did=233720

This game is long on story, for a change, and has garnered a lot of praise from those who recently got hands-on with it, barring only the ending- but the weapons are also very cool (yes, the Spider Gun is a nod to Half-Life- and coincidentally, there is a player model/ character in '03 who's a dead ringer for Gordon Freeman. I styled my avatar "Gordo," and plan on using him again, incl. online when I finally get my replacement CD#1).

There are a lot of misconceptions in what you wrote that need clearing up.

OSX is unix-based, but when it comes to game porting, that doesn't really mean too much. The OS-specific code in any port basically amounts to the GUI, the event system, the sound system and the graphics system. Unless you're going to make your OSX port run in an X-window system like X11, you won't be able to leverage much, if any, of the unix code here aside from the file handling.

A Macintosh can run OS X, or Linux natively... without X11...

http://www.yellowdoglinux.com/

The Core, and the filing system of Unix, and OS X are nearly identical, as well as the commands themselves. (only a few are left out)

Even then, you've got the major task of byte-swapping on the Mac to get the data into the correct format. Virtually no games aside from the Quake 3 engine have provisions for this, and even then, some Q3-based games ignore this since they're made for x86 hardware first. This is typically the largest source of bugs in a Mac port, as tracking these things down can be very time-intensive. There is no magic bullet to make this easier, aside from writing the game properly in the first place.

With the programing languages that are out there now, you could create a Mac and PC version almost identically if you got rid of DivX.

Use OpenGL, instead of DivX and OpenGL for the Mac version...that is almost 60% of the rewrite that occurs when it comes to programing for both systems....the way the system handles the graphics.

Unix can run on a PC or Mac, I'm still a little confused here, why would the program be so difficult to port over...and Unix deals with Bite-swapping in a better manner than Windows can...

Cyberpawz

Uh... Cyberpawz? You do know that Brad Oliver is a developer with successful ports under his belt (Jedi Knight II springs to mind), and knows whereof he speaks, don't you?

Sorry...my bad, unthankfully, the name didn't ring a bell...

I apologize...but what I speak of is mainly from what other programers have told me in the past, guess it's true what they say about 2nd hand info hmm?

As for Unix/Linux and OS X, consider allocating memory (as an example). In Unix and Linux, you'd probably use the malloc function in C, or new in C++. On a Mac, you can keep these, or replace malloc with NewPtr. Or go with handles, and use NewHandle. There are good reasons to use Apple's functions, especially if you're writing with a view to gamers playing in Classic.

There are literally thousands of functions in Unix, Windows and on the Mac that perform similar tasks, but they're not directly replacable. QuickDraw doesn't have a direct Unix counterpart (as far as I know), and it's quite different to the Windows drawing environment.

You would think that the Quick Draw functions in a Windows OS and a Mac OS would be similar, so that programers would not have to worry about platform coding, at least in my mind that would make the most amount of sense don't you?

Also, running a seperate OS (like Linux) on top of the existing Mac OS would mean that an event would have to filter through two operating systems before you could grab it. That's a lot of extra complexity, and could easily lead to a lot of extra bugs.

Actually Yellow Dog Linux, is a separate entity all together... you can run it on a new iMac instead of OS X (or OS 9 if you are a masochist) if you wanted.

And then there are occasions when an API call has desired side effects (like resetting pen state, or flushing the OpenGL buffer, or resetting the sound queue) that may may require several API calls in the ported code. There are a lot of traps to be aware of.

I sort of hoped that OpenGL extensions could help with byte swapping, but that's only for textures and colours. Vertex data, AI data, and all the many other custom data formats that exist in those monolithic data files need to be converted on the fly to maintain some compatibility with the PC data files.

There seems to be a lot of work in porting, to my 'hobbyist' eye, and I think that the operating system APIs wouldn't help that much.

Personally, I don't know why, but how come there isn't a programing language out of the box that can work on Mac/PC/Linux with very little porting effort...

It seems to be asinine that Mac programing, PC programing, and Linux programing are so vastly diffrent...we have come a long way from the key programing languages, you would think that there would be a language (except Java 2) that would be 90% portable with little to no effort on the programers.

Even though under new programs, there has to be a "core" program that handles all the functions etc of the different system functions of every OS that it runs on...

Now I know games are coming out that are "new, and more advanced AIs" etc... but no matter what it is, don't you think that even though these advancements are around that the core of each feature has already been ported over to the Mac or PC already for cross platform abilities??

I don't know why it hasn't been though of, or attempted, for this type of mindset, or programing would be the "holy grail" of cross platform gaming...

Possibly Open Source these "functions" who knows, advancements of each capability would be for the company itself, but the core cross platform programing would be O.S.

Cyberpawz

A Macintosh can run OS X, or Linux natively... without X11...

Unfortunately, this has very little bearing on game ports from x86 Linux.

With the programing languages that are out there now, you could create a Mac and PC version almost identically if you got rid of DivX.

For starters, yes, you could do this. But no one on the PC side does. Second, what does divx have to do with anything? I haven't worked on a game port that uses it. I've heard Warcraft 3 uses it, but regardless, that has no bearing since War3 is available for the Mac. What's more, Divx is essentially mpeg4 with a funky wrapper, so it's not terribly difficult with the advent of QuickTime 6.

Use OpenGL, instead of DivX and OpenGL for the Mac version...that is almost 60% of the rewrite that occurs when it comes to programing for both systems....the way the system handles the graphics.

Uh, no. As I said before, DivX is not a major player in games. Most games that start out life on another platform use DirectX instead of OpenGL. But even if they do use GL, they need to be tuned for the Mac's implementation as the fast paths on the Mac are different, and there are some Apple-specific extensions to speed OpenGL up. These things are almost necessary to make up for performance deficiencies in other areas on the Mac.

Unix can run on a PC or Mac, I'm still a little confused here, why would the program be so difficult to port over...and Unix deals with Bite-swapping in a better manner than Windows can...

The host processor (Intel or PowerPC) is what determines the need for byte-swapping. Unix (or for that matter, Windows) is a non-factor; byte-swapping is not handled at the OS level. I'm not sure where you got this information, but it's way off.

Sorry I meant Direct X, not DivX....

Cyberpawz

I looked at CyberPawz reply about OS X and Linux only to find Brad beat me to the gun. Although Pawz, if it weren't Brad, would have continued to argue relentlessly? Anyways, moot point I suppose.

Truthfully probably not, I just want to know why out of any pit of imagination that there is not a core that can allow porting over PC games to Mac easier than having to recode the entire engine...

Being somewhat logical, I would think that there is parts of a game engine that no matter how "advanced" it gets, there are parts that are transferable, for cross-platform transfer.