Port DirectX Games to the Mac 53
tassii writes "MacCentral reports that Coderus' MacDX provides PC game developers with a way of moving that DirectX code to the Mac without having to rewrite it from scratch. Coderus claims that most code which uses DirectX can simply be recompiled and linked to the MacDX libraries. Maybe I can finally play the full Command and Conquer series."
This is bad (Score:5, Insightful)
Re:This is bad (Score:1, Flamebait)
sdl. (Score:4, Informative)
since i didnt see anyone else replied/posted with this mandatory link i did, whoring an' all. the recent starcon2 port uses sdl as well, and thus wa s quickly available on very many platforms instantly.
SDL SDL SDL (Score:3, Interesting)
But for existing games that were written to the DirectX APIs this should be a great boon. I'd definitely like to see Mac OS X versions of all those games that would otherwise never appear on the Mac.
Incidentally, there's an SDL version of Abuse out there. Has anyone been able to get it to compile and run on Mac OS X yet??
Re:This is bad (Score:5, Insightful)
Oh, wait. That was what the evil-me would have said. Really, I think making it easy to port games is a good thing. I don't give a crap what API folks use, just so long as I get to play the damn game on my bitchin' mac hardware.
Just as soon as OpenGL 'catches up', and game programmers start flocking to it, I won't give a shit - just as long as I get to play the damn game on my bitchin' mac hardware.
Yeah, but (Score:3, Insightful)
Re:Yeah, but (Score:4, Insightful)
And just as soon as someone writes this thing of beauty, developers will flock to it because it is better (yeah, right). Meanwhile, I just don't care. Making games easier to port is a good thing.
Some choices are easy and beneficial in the short run, but damaging in the long run. Do we really want to give Microsoft control over the API's that all game developers use?
M$ doesn't control any of the APIs that developers use (well, on the PC platform, anyway - xbox may be another story). Developers use APIs that M$ controls. There is a difference. Developers can chose not to use M$ API anytime they like. It turns out that they don't care about making their programs portable to the other 7% (or whatever), and that DirectX is the best thing for writing to windows. If there is a library that will allow them to port trivially to MacOSX, I hope they will find it worth their while. Until this magical, bitchin', non-M$ API appears, this is our best bet.
Re:Yeah, but (Score:2, Interesting)
These less restricted APIs would also be less robust and most likely suffer from performance problems. Part of the reason that Microsoft extends it's APIs and meta formats is not only to raise the cost of exit (smart move, not matter what industry)...It also allows them to add features whenever the hell they feel like it without waiting for some standards body to confer and agree on it. This is part of the reason OpenGL is currently lagging behind DX.
Re:This is bad (Score:1)
Go fly a kite if you don't care.
Re:This is bad (Score:1)
And another thing... (Score:5, Insightful)
Re:And another thing... (Score:1, Interesting)
Why don't some of you OSS fanatics start a LinuxDX project over at sf? Seems that all you'd really need to do is create OpenGL equivilants of the DirectX functions. right?
I guess it's simple, in theory, but complex in practice. oh well. too bad I'm so damned lazy or I'd do it.
Re:And another thing... (Score:2)
Re:And another thing... (Score:3, Interesting)
Re:And another thing... (Score:1)
Leading is not done by following.
Re:And another thing... (Score:5, Interesting)
Leading is not done by following.
You're right. But standing still is even worse than following (as MacOS proved for years and years). It seems clear to me that linux is not leading in many respects - gaming APIs being one, market position being another. Even if they had the best damn gaming APIs in the world, unless those APIs were ported to Windows, it would still be a losing proposition.
Providing software compatability is a great win for linux. OpenOffice is a great example of that. SAMBA is another.
Re:And another thing... (Score:1)
Damn, it's like walking on egg shells with some of these people.
Re:And another thing... (Score:1, Informative)
Re:And another thing... (Score:4, Insightful)
Sorry, but it is the truth.
The problem has less to do with DirectX vs. OpenGL than it does code reuse and other such issues at the gaming companies.
Put an other way, if you think that porting DirectX means fewer games for Linux, you are simply being naive. The reason games don't come to Linux is much more complex.
I hope this speeds up porting... (Score:5, Insightful)
Re:I hope this speeds up porting... (Score:1)
Re:I hope this speeds up porting... (Score:1)
Worthless,... (Score:4, Insightful)
The latest example: The PTW addon for Civ3. It's not yet decided if there will be a port for the mac, because the main problem is the DirectPlay based network of the windows version.
And since network gaming seems to be the place, the gaming industry is heading, imho there is a need for an free network-api, which is designed for gaming, like directplay.
There's OpenGL, OpenML, now who will create OpenNL for OpenNetwerkLibrary ?
Re:Worthless,... (Score:5, Informative)
There is one already. It is called OpenPlay [apple.com]. Here is a quote from the site:
The Myth series uses OpenPlay, as well as some other games
Re:Worthless,... (Score:2, Informative)
WinOS2, Win32S on OS/2, WINE, API shift, next... (Score:5, Insightful)
What's needed is a way to walk the knife-edge down the middle. Perhaps a *good* WINE is just what we don't want. Perhaps a WINE that can be tweaked to do just a few critical things really is living on that knife edge.
Maybe WinOS2 was just too good at running Win3.1 apps, or at least the perception was too good.
As long as WINE isn't perceived as good enough, it will be viewed as only a crutch. WinOS2 was perceived as 'good enough' to neglect a native version, even if enough market was anticipated.
It also remains to be seen how MacDX will be perceived. Hopefully only as a crutch, and a reason to then consider OpenGL and SDL as better solutions.
Re:WinOS2, Win32S on OS/2, WINE, API shift, next.. (Score:3, Interesting)
Genius! (Score:4, Interesting)
I know at least ten Mac users who have said that they keep a Winblows box around to "play games."
VirtualPC is handy, but it just plain sucks when it comes to doing high-end graphics (or, better said, just plain doesn't do high-end graphics).
Everyone is saying its endorsing a Microsoft "standard," but if you think about it it could take people off the Windows desktop, which is really our goal anyway.
So Microsoft gets to license a high-speed graphics library. So it sorta endorses the XBox. Who cares... they don't have monopolies in these areas.
I don't want it nor need it. (Score:2, Insightful)
As long as people keep making good OpenGL games - such as the recent uDevGames [idevgames.com] contest winner [mulle-kybernetik.com] - were safe.
*lbtr
Let's Not Get All Doom and Gloom (Score:4, Interesting)
i think it will work more for opengls benefit. it in effect extends mac-pc compatibility in a very striking way.
Re:Let's Not Get All Doom and Gloom (Score:2)
Dear god (Score:2, Insightful)
Re:Dear god (Score:3, Informative)
I hate to break it to you, but this technique (a wrapper that implements Direct3D/Draw/etc on top of OpenGL) is the primary graphic base for games on your Mac. Every Mac porting house already has their own set of libraries to do just this, it's just none of them have bothered to make them public like MacDX.
The real market for this is for PC developers, and it remains to be seen how many of them will actually take the bait and try and port titles over themselves (making money off developer tools is a real challenge, as you're selling to the very people who could write it themselves
There are a lot of other issues you need to consider when doing a port (endian-swapping is the biggest time sink normally, followed by code using VC-- "extensions", then platform specific issues - working around bugs in OpenGL on 9 which will never be fixed, etc), and the code which talks to DirectX is normally a pretty small part of a game's code base.
fine, I'll bite, but as AC to protect my pride (Score:1, Insightful)
1) Buy a freaking USB mouse with as many buttons and wheels as you like, it'll work fine with no extra software in OS X.
2) See point 1. Buy a tower mac and you can put in any mac graphics card you want, including ones based on all recent 3d chips available, pretty much.
3) You just gotta look in different places. Try Hotline, or better yet Carracho (www.carracho.com) and KDX (www.haxial.com). Even gnutella can be pretty good.
4) See point 3. Those are usually available along w/ the w4r3z.
Once you get the hang of it, the Mac Way(TM) is pretty fun and friendly.
Yes we do (Score:1)
All the hardware inside our machines is identical to a PC, except the quality stuff - motherboard and CPU.
You walk into a PC shop, buy a Radeon 9000, stick it in a G4 and be playing in moments.
Old News... (Score:1)
This was news back in April when it was first announced.
I have actually been emailing game companies during that time, asking them to give MacDX a try, to see if its a viable solution for them. I've emailed Epic, Sierra, EA, etc. and not a single reply. Of course I don't expect a reply, just hoping they might actually read the email and give the product a chance.
I guess making zero code changes to a game engine and only minor changes to system dialog and error codes that could probably be done in a week, is not satisfactory to an industry where good ports have historically been very hard to accomplish.
Or then again, perhaps its the fact that Coderus only lists MacDX as being fully DirectX 7 compliant, with information for 8 and 9 still forthcoming.
Then there's the speed issue (no, porting playstation games with the libraries and having them run fast is not an overall indicator of speed...lol) and whether it is relevent, as well as if MS is going to put pressure on this company, which had not updated its website since the news originally broke in April.
Re:Old News... (Score:1)
Your next conspiracy accusation is based on the belief that I had just made a matter of fact statement, rather than the facetious and sarcastic statement it was meant to be.
No, I wrote to these gaming companies and simply stated that this product claims to this and this, and you should see if this is true. I even stated that it's likely they could get the code free for testing to see if its a viable solution. Of course, I was only making suggestions to the largest gaming companies in the world, not some shmo on the corner doing a port of Super Breakout. Does that make it more ridiculous they would have any interest in a no name product? Of course...if it doesn't fit their bottom line.
MacDX is not geared towards development houses who do Mac ports specifically, but rather those companies that have Windows products and would like to have an easy, "cheap" solution. Most games are not ported because, 1. Cost, 2. Projected Sales Volume, 3. Time Constraints.
If other developments houses such as Westlake or Aspyr have these kinds of libraries, that can leverage DirectX directly with no changes to the engine, why is it that it often takes them a much longer time that you would expect if said software was in their hands? Do you think it takes them 6 months with dedicated programming talent to just figure out the differences in system errors and endian byte order? Or perhaps they always have the game completely finished, except for the networking aspects, which they just happen to dilly dally on. I would be willing to bet these companies work there proverbial asses off trying to get as much performance out of the game as possible, and using libraries that specifically reference the DirectX code may not be "low-level" or efficient enough to accomplish this.
Of course, once a development house ports an engine it becomes much easier to do subsequent ports on said engine, ie lickity split. New engines are definitely a greater hurdle.
My conspiracy theory is more based on the idea that Microsoft does not want such a product to exist due to their interest in furthering dominance of the Windows Platform and API's. If Windows itself is no longer a requirement for games, I don't think they are going to be too happy about this. Besides that MS could buyout pretty much any and everything that gets in there way (and has), so this is not ridiculous.
Then again, the libraries could be horrible to implement, slow, and just overall crap, but what's the problem with suggesting a company check it out, when their current plans might have procluded a port in the first place.
By the way...posting as an Anonymous Coward undermines any credible argument you might have had.
How do you measure "development" costs? (Score:1)
If you're already a multiplatform title, or if your title has a decent abstraction layer, putting in a decent OpenGL/OS-X kernel shouldn't take much more than a few weeks anyways. I know nothing about how sound works on OS-X, but it seems to be "in flux". A while ago I tried porting my company's code to run on my powerbook in my spare time, and I got pretty far in only a few evenings despite the fact that I know nothing about Macs (able to view shaded 3d models using the game's engine, still need texturing and sound, need some endian-conversions)--the main problem is not having the control key by the "A" for emacs--is there a good OS-X equivalent of caps2ctrl? I would bet if I tried again now, now that we've done GameCube (big-endian CPU, OpenGL-like API), it would be even easier. But then again, going from a hobby project to a shippable project is a pretty big task (compatibility testing, installers, all the usual bullshit). For example, when I upgraded from 10.1 to 10.1.5, it broke my code (aglChoosePixel Format stopped accepting AGL_FULLSCREEN as an argument for some reason). I suppose making an OS-X downloadable "experimental/as-is" executable that uses the data from the PC retail box is one middle ground.
Mac game Developers/Porters already have similar c (Score:2)
The market for this product is pretty much new developers who are not going to farm out the port.
[Apologies for the accidental AC post]