No More Unreal Ports For Linux?

Ant was among the first to write with a link to this article on Blue's News claiming that Epic's new game engine is Direct 3D only, based on statements made at an E3 demo yesterday. Check that link to read the full article, but consider this excerpt: "A major side effect of this is that any future ports of Unreal-engine titles that use the new technology will need to have a completely rewritten rendering system, making Mac and Linux ports significantly more difficult." DoenerMord also wrote, saying "This kind of puts some perspective on recent comments from Tim Sweeney (the man behind the Unreal engine) on Microsoft's breakup ..."

Comments

DirectX has passed by OpenGL

[Anonymous Coward]

It's sad, but true. OpenGL needs a lot of
extensions now, and these extensions must be
made mandatory for the next generation of
games.

Cards are now hitting the market with environmental bump mapping, cube mapping, texture coordination perturbation, etc, and unfortunately, the only way these are currently supported is through mutually incompatible OpenGL vendor extensions.

In typical MS fashion, DX1,2,3..5 sucked. By DX6-7 were good, and now DX8 overtakes OpenGL.

You can't blame game developers from moving away from OGL if they can't write to a consistent standard API that utilizes all of the hardware acceleration features available on a card.

This christmas we will see the ATI Radeon, 3dfx Rampage, and NV20. All of these chipsets are likely to support the DX8 shading language. OpenGL won't except through proprietary extensions like NVidia's register combiners extension. That means developing a game that uses advanced photorealistic lighting on OGL will be hard.

Herein lies the difference between open-source and commercial development. MS actually runs conventions, gathers developers and manufacturers together in the same room, has people present papers, and say: What do you want in the API? The game developers and hardware manufacturers interact, and MS adds the most request features to the API.

As far as I know, there is no open-source equivalent to MS Meltdown, E3, WinHEC, etc.

What Linux needs is a hardware/kernel convention so that there is some actually two-way communication between developers and manufacturers instead of just: "Gimme your goddamn specs so I can write a driver."

Re:DirectX has passed by OpenGL

[Allen Akin]

You have valid concerns, and I don't want make light of all of them. But I did want to inject a dose of realism about a few things:

• D3D is far from consistent. Different implementations have different capabilities, and that definitely includes the new vertex and pixel shader stuff in DX8. Developers will have the same trouble getting those new features to work in D3D that they'll have dealing with OpenGL extensions, if not more.
• There are a lot of people working to keep OpenGL competitive. For example, a VP at NVIDIA recently told me "Every hardware feature will be exposed in OpenGL extensions." The first step is always to expose new functionality in extensions; it gets incorporated in the core standard only after it's shown to be useful and generally practical to implement. (This is unlike D3D, where Microsoft decides which vendors to favor and shafts others by adding D3D features that they won't necessarily be able to support.)
• Always view new stuff in D3D with a healthy dose of skepticism. Microsoft has had to reverse its design decisions in D3D many times in the past, and now that they can no longer copy features wholesale from OpenGL, they're even less likely to get things right than before. There are highly knowledgable people in the games industry who have major doubts about the new features in DX8.

Bottom line, I think you're correct that more needs to be done to support graphics and games in the open-source world. But I also believe that the game is far from over.

You can't port Direct3D to linux

[dek2]

You can't "just port Direct3D to linux", because D3D is carefully licensed and protected by Microsoft. The reason they switched to D3D-only is because OpenGL doesn't have the features Sweeney wanted, and he told Microsoft to add such features to D3D. OpenGL's ARB just can't implement new features and versions of OpenGL as quickly as Microsoft can add new features to D3D, due to organization structure and manpower.

Re:They're Doing The Direct 3D Ports...

[atw]

You are absolutely right in my opinion asserting that Microsoft paid them money (and they have all right to do so, nothing bad here). However, since EPIC always targeted DOS/Windows as their primary gaming platform, it would never have become a problem to run it on Xbox. The actual answer as I think is that if Microsoft were to compete with Sony and SEGA in the console arena (and that's what they presumably trying to do with the XBox), then Microsoft would have to have some EXCLUSIVE games to lure players to buy Xboxes in the first place. Usage of DirectX ensures that whoever crazy enough to port this game will have hell of a time.

What's really interesting is that EPIC seems to be desperate enough to bank on their relationship with Microsoft, and they do all that in a very foggy situation when Microsoft can be split up and God know what else can happen to them. EPIC is really taking a major bet here, and this probably is because they are not really doing too well in financial terms, hence comes cash infusion from Microsoft. Games development is an expensive business you know... and hey, EPIC guys deserve to drive Ferraries, too, right?

I don't understand this...

[Millennium]

Epic has already made a ton of money off of all three operating systems. And yet they would do something which would hinder that strategy? Particularly with an inferior 3D API?

I'm not worried about the Mac port; Westlake (who did the Unreal and UT ports to MacOS) has a lot of experience converting DirectX to interoperable API's (heck, most of The Sims is Windows-specific but they've already got it playable, albeit not yet at Alpha). But this could spell big trouble for the Linux port.

It's yet another of Microsoft's Broken Promises (tm). The Mac compatibility layer for DirectX was due years ago, according to Microsoft itself. And with a public API, a Linux layer would have been far easier to implement.

Now, let's look for a moment at layers:

DirectX
Pro - Easily controlled if you're in bed with MS, as Epic admits to being. Relatively easy to program.
Con - Windows-specific.

QuickDraw3D
Pro - Very easy to program. Available on many platforms via the Quesa project (already nearly complete). (and available on at MacOS and Windows in its original, closed implementation) Open-Source, again via Quesa. Implements a standard file format (3DMF, the basis for VRML97).
Con - No longer being actively developed by Apple.

OpenGL
Pro - The most powerful API out there. Already has the non-game marketshare by an overwhelming margin. Runs almost anywhere (hell, it even runs on PalmPilots!) Has Open-Source "alternatives."
Con - Few primitives, making it harder to program. Eats resources like you wouldn't believe; requires hardware acceleration for decent results. No true Open-Source "implementations," though that's more a technicality than anything else.

So which is the best? Each has its pros and cons. I'm more partial to the underappreciated QD3D (which, incidentally, Quesa implements on top of OpenGL). I will say that DirectX's platform specificity is a big problem unless you only plan to port the thing to the X-Box. But again, if you're in bed with MS, you can change the API practically at will. OpenGL really doesn't have that big a share of the gaming market (though overall it's overwhelmingly the most popular), but it's more powerful than any of the others. QD3D has ease of programming, but it never really caught on for some reason.

Why *STANDARDS* are the way to go

[DragonHawk]

The problem here is again, a different stack tere, a different browser here, a different protocol there, a different compression scheme here, a different xml engine there, a different ipsec here, and you get the point.

And this is why standards are what should be followed. Not Microsoft's "Here is our proprietary solution that locks you into our platform" APIs, but standards. Like POSIX, like HTML, like CSS, like XML. If you followed the standard you will be okay.

It is when vendors like Microsoft decide to "enhance" the standard with extensions designed to lock out competition that things break down. Microsoft is an illegal monopoly, and something needs to be done to stop their abuse of that power, or the future of the information age will be owned by a single company.

Microsoft is an illegal monopoly, and something needs to be done to stop their abuse of that power, or the future of the information age will be owned by a single company.

I don't think breaking up MSFT is the best solution possible, but it may be the best solution possible under US law. I would rather be inconvenienced then enslaved.

What would my ideal solution be?

First, behavioral restrictions: Force Microsoft to publish complete specifications for all of their interfaces and file formats, and allow unlimited third-part re-implementation of them. If they cannot provide a spec, they cannot sell the product.

This would keep Microsoft from using their products to lock people into their products. People would be free to choose Windows, Exchange, IIS, IE, or what-have-you if that was the best product available. But if MS tries anything funny, people would be free to switch vendors.

Prohibit Microsoft from entering into exclusive licensing agreements with PC OEMs. This is something that is technically already done, but MS has found loop holes. Close them.

Next, some punitive and corrective measures. MSFT has broken the law and deserves to be punished; they also have locked out their competition in many markets and can continue that lock-out legally. So:

Prohibit bundling any other MS product with Windows for the next five years. No Windows Media Player. No MS-Works or MS-Office pre-loads. Force a choice on people, as MS has forced the lack of a choice on them for so many years.

Force MS to include freely available third-party browsers in the Windows OS package along with IE, and give users the choice of which they want to use. They've used their OS monopoly to build a browser monopoly; correct that.

But again, I don't know if any of this is possible or feasible, and I would rather be inconvenienced then enslaved.

I agree... and think it's GOOD

[The Man]

Pretty much everything he says is correct. And it's a good thing. Microsoft's "standards" may be helpful for the peecee gamerz, but they're harmful to virtually everyone else who's ever touched a computer. We're all better off if Microsoft goes away completely; whatever "remedies" come out of this court case will probably be insignificant in the long run. Already the market is solving the problems itself with the rise of Linux, BSD, and the strengthening and in some cases re-invention of the traditional high-end vendors, then the subsequent Windows 2000 response from Microsoft. Sure, it still sucks, but if you ask me it's obvious that they recognized some of their shortcomings and have at least attempted to improve.

The problem for gamez writers is real. The fundamental problem with peecee gaming is that gamez, to get the performance gamerz want today, need to get very close to the hardware. Unfortunately, this is exactly the type of thing that good operating systems both prevent and facilitate: arbitrary random physical access to hardware devices is out of the question, but there exists one prescribed method of gaining the access you need, which offers protection from at least most mistakes. DirectAnything is hamstrung by two problems: 1) It fails to provide any real protection, and has been designed and implemented in the same slipshod way as the rest of windows, 2) It requires hardware support which is anything but universal.

So it's understandable that gamez manufacturers like targetting the consoles - it's a single known environment (as is pointed out in the article) which is generally rock solid internally and offers very direct hardware access, making high performance easy to get. Naturally, the lack of protection is problematic, but people have been writing hardware gamez since Pong - it's a science by now.

I would argue that, once completely implemented, the new DRI/DRM XFree implementation will be infinitely preferable to Microsoft targets for gamez developers. Why? Performance (with the right hardware), universal availability, and uniformity. In other words, you won't _need_ a FuxorGraphics model 455CA specifically; anything will work, though naturally if you want good performance you'll want something that can do hardware GL. GL is not itself without problems, but at least it's widely available. And with a fast enough CPU, software rendering is not out of the question (in fact, some SGI systems were set up specifically to do most of the rendering on the CPU. This is not altogether a bad thing; the 3D performance on those systems does not suck, to put it mildly).

Whether this ever happens, and whether it's ever adopted, remain to be seen. But even if all of his worst fears are realized, and DRI never gets completed in any sane fashion, it's not the end of the world. The worst doomsday scenario he comes up with is the death of the peecee. Would it be so bad to kiss the relic of the 70's, never designed but patched together by marketing types and marginal hackers from day one, unstable, unreliable, and nonuniform, a final goodbye? I'd like nothing better than the death of the peecee. Good riddance. Tragically, though, this fear is massively overblown: the peecee's existence relies on buyer ignorance and gullibility, of which there seem to be no shortage.

All those ports, huh?

[Starselbrg]

you got Win95, Win98, Me

That's great. You just listed 1 operating system with 3 different names.

, Win2000

Ah yes, Windows 2000. It's got an enormous market share. It's so different that Windows 95 that you would absolutely nood DirectX to be portable. Can't use OpenGL or your own engine.

, Windows CE (Personal/Palm PC's),

What? Do you honestly expect someone to run Unreal on a "Pocket PC"? Are you crazy?

DreamCast

Nobody uses DirectX on the Dreamcast. The performance is just terrible. And from your very own comment, it appears that it also costs more.

and the soon to be released X-Box.

The X-Box is a PC. Just because Microsoft is trying to convince you otherwise means nothing. If you write it for the PC, it'll run on the X-Box, with or without DirectX.

So, it seems while you tried to list 7 platforms, you really listed 3 that are so similar that you don't need DirectX to be portable.

Mac users may not be shut out after all...

[DoenerMord]

A few posts to comp.sys.mac.games.action from the premier porting house for Mac games, Westlake Interactive, clears up the situation a bit. Here's a post from president Mark Adams:

Of course porting "difficult" code is what we get paid to do. And we've dealt with many more Direct3D only games recently (TR:TLR, The Sims, etc.), so we're pretty confidant we're keeping our engine re-writing skills up.

Kenn Cobb (also from Westlake) had this to say:

Not a big problem. We port D3D titles all the time now (TR4, The Sims, currently). It really depends how they use D3D. There are various approaches to take with D3D, and some are easier to port than others.

3dfx themselves are phasing out Glide, so I can understand Epic dropping it. I'm disappointed about OpenGL, but from a PC-only viewpoint I can see the argument. Most OpenGL drivers on the PC are designed primarily for Quake. Even though fuller implementations have been coming out, they are generally not as mature (ie, optimized, bug-free) as the D3D drivers. There are far more D3D games than OpenGL on the PC, so this only makes sense. Still, it would be nice if there were two major fronts pushing OpenGL (Epic and id) instead of just one.

So, while it may not be a great situation, atleast Mac users won't be shut out entirely. Westlake knows what's up...

-doenermord

Re:One more company to NOT buy games from....

[sammy baby]

Oh, please.

First of all, don't jump to the conclusion that games written for Linux are necessarily going to be better performers, either where netplay or graphics are concerned. Most graphics cards these days have better OOTB support for Windows, hands down. All things being equal, that translates to better performing games. And where netplay is concerned, that varies highly from game to game. Compare Unreal's unpatched netplay to the latest patchlevel, or to UT's. Compare either to Q3. On the same hardware, with the same OS.

Second, don't be ridiculous about "refusing to allow Linux ports." Companies like Loki don't politely knock on the doors of game companies and go, "Hey there, mind if we port your game for you? We'll only be a minute." Loki gets paid to do it. That's fine - they provide a service to their customers and they deserve the right to charge for it. But the folks at Blizzard aren't being evil because they don't feel like paying for a Linux port of the game.

If Loki can show that they can sell enough copies of a game for Linux, Blizzard will likely change their minds. Until then, don't have a hissyfit at Blizzard for looking out for their bottom line. This may come as a shock to you, but Blizzard, Loki, and the publishers of every game you're likley to find at the local Best Buy are, in fact, in it for the money.

Emulator?

[yerricde]

The definition of "emulator" has a slippery slope: NES virtual machines emulate the NES binary interface. Java virtual machines emulate the Java binary interface. Linux emulates the UNIX® source interface (most of POSIX® and much of the Single UNIX Spec). XFree86 "emulates" the X11 source interface. GTK+ emulates the GTK+ source interface. So you're saying an emulator is any program that exposes APIs, that all libraries are emulators?

They already are (semi-OT)

[empath]

For those of us who don't follow this sort of thing, wine already does a fair chunk of DirectX, including Direct3d. If you want to play Windows games, go help wine.

Calm down

[Troed]

... reading Tim's comment, I saw this:

Microsoft fixed that with Windows 95's built-in TCP/IP.
The government's proposal would basically shackle Microsoft and prevent them from adding new features of that sort to the OS

(on that networking was bad under DOS but works fine on Win95+)

Breaking up Microsoft into one OS vendor and one Applications company won't prevent Microsoft from adding stuff like TCP/IP or DirectX to it's OS! They're OS components, I don't think anyone would claim they're applications in the normal thoughts of the user (or the DOJ, surely).

Linux and Mac will have to push OpenGL over DirectX - I'd say that's quite reasonable. At least it's not as bad as Glide ...

Re:Calm down

[Admiral Burrito]

The problem here is again, a different stack here, a different browser here, a different protocol there, a different compression scheme here, a different xml engine there, a different ipsec here, and you get the point.

[SARCASM]
I'd like to talk to you about an upstart computer company called "Compaq". It seems they're about to release a so-called "IBM-compatible" PC. This is the worst thing that can happen to the computer industry! Everyone should buy IBM. Not just because nobody ever got fired for buying IBM, but because IBM is standard. Just look at what Compaq and companies like them are going to do to the computer industry. Soon everyone will have different computers with different hard drives and different video cards and different CPUs and different amounts of RAM. Imagine the chaos that will ensue! There is no way that all of these different parts can possibly work together in a "100% IBM compatible" way. I predict that 10-15 years from now computers will be twice the size of a house and so expensive that only the five richest kings of England will be able to afford them. Put a stop to this! Buy IBM!
[/SARCASM]

But seriously. I believe it was Bill Joy who said, "The function of an operating system is fixed." That function is to control access to the computers' resources (CPU, RAM, files, network sockets, etc). Applications ask the operating system to provide access to resources through a standard API.

What we need are operating systems (multiple, not one) providing APIs that are standard and available to all manufacturers the way hardware standards like PCI are. Then we can start to see the same competition in operating systems that we see in PC hardware.

On the internet we have dozens of different TCP/IP stacks, web browsers, protocols, compression schemes, XML engines, IPSEC implementations, etc. As long as they are written to open standards more is better. It means you have a choice in what software you use as opposed to being locked into a single vendor such as Microsoft. Vendor lock-in is what happens when you have a single dominating implementation of a "standard". When such a "standard" is violated there are few people to complain about interoperability problems and no standards-compliant vendor to turn to. When there are multiple vendors with nobody dominating then people will simply stop buying from a non-compliant vendor (why buy a broken software when you can get software that works?), thus making non-compliance unprofitable.

Competition is a Good Thing(tm).

What about WINE?

[Nicolas MONNET]

Wine seems to emulate Direct3D quite OK -- AFAIK, Unreal (not Tournament) for Windows runs on it in Direct3D mode. I guess it should be quite possible to link future Unreal games to WineLib.

Tim Sweeney on Evil Avatar?!?

[Kojo]

Now, I'm not an industry expert, but Tim Sweeney lost me somwhere with his comments on Evil Avatar...

What's really holding back PC gaming...it's harder than it should be to make a game work with your 3D card, drivers, etc. That's not really Microsoft's fault; it's a natural result of having a huge ecosystem of independent PC makers, 3D card makers, and sound card makers working together.

Ok, I agree with that...lots of different people can lead to compatiblity problems. This doesn't mean that they can't be overcome, but problems can and do occur. But then...

In all, Microsoft has done a pretty good job of making PC's work. They have forced 3D hardware makers to adopt common standards with DirectX. That is good. They did the same for printer drivers, sound drivers, and PCMCIA. Their implementation isn't perfect, but it's pretty damn good.

Jigga-What?!? Ok, this is were he losses me. First, isn't MS in trouble for exactly that...forcing software makers to do things that MS wanted them to do? What about choosing standards based on technical merit...you know, robustness, interoperability, that sort of thing...instead of standards based on their ability to tie developers to a single platform?

What ever happened to Open Standards? You know, like the ones used to build the Internet and make email work? Again, I'm no expert, but they seem to work pretty well. Don't look now, but your soaking in them! I realize some of the Open Standards may not have developed as quickly or as well as some of the MS 'standards', but how much of that was due to MS marketing muscle?

I'm not trying to bash MS or Tim Sweeney, but I don't know that dominating a market can be compared to 'setting standards'. If there's something I'm overlooking, someone please fill me in.

Re:Sounds good, but...

[Ma�djeurtam]

Isn't Linux a matter of choice ?

I can't see why a Linux implementation of OpenGL/ Direct3D/Glide/Grits3D or any other 3D API I can think of would hurt anyone.

If Linux's creed was unification, it would hurt, but Linux is about choice. So if you think OpenGL is the best 3D API, it's OK. But it's OK if some folks decide to implement Direct3D too (and they do !), it's OK too.

Stéphane