Slashdot Mirror
Unreal Engine Linux Ports Not Dead?
CookieMnstr|PuF writes: "Brandon Reinhart, programmer at Epic, has updated his .plan file in response to the fear that no more Unreal Engine-based games will be ported to Linux. He faults the Linux community for jumping to the conclusion that Unreal Engine games will not be a reality for the Mac and Linux. Maybe he should read beyond the headlines. "
How to pick this up in a positive way? Develop a highlevel, crossplatform gaming API that does not force game developers to reinvent the wheel. Apparently such a library is lacking on both the mac and linux.
I believe this is what SDL is trying to do. It was successfully employed in the linux port of "Civilization: Call To Power."
As for Unreal and UT, I have faith in Westlake, they've done a great job so far on the ports for the Mac they've handled. Between them and companies that already grok the Mac and the value of cross-platform development (i.e. Bungie and Id), gaming on the Mac is finally becoming viable again.
If I were a serious game developer, why woould I want to use any technology that limited my product to a single platform? What happens when it's no longer the dominant one? With OpenGL, it may be a little slower or harder to code, but it lets me capture that extra 10% market share, plus it brings free good will. Pretty simple choice.
I use Macs for work, Linux for education, and Windows for cardplaying.
Microsofts slogan for windows should be - "Windows98 - crashes loads but runs games really well. HONEST.".
So what you're saying is that Microsoft Windows is in essence a Wintendo.
Will I retire or break 10K?
Fresh from their great success with Heavy Gear, the first port of a D3D game to Linux/OpenGL, I seriously doubt that Loki would consider this project a major challenge. It means there will be a lag of a few months before the Loki version comes out (I think it has to be a no-brainer that Loki will bid on this) and personally I'm happy to wait for it. Knowing Loki, the Linux/OpenGL port will be totally solid.
As far as I'm considered, if a game doesn't exist on Linux, it doesn't exist.
--
Life's a bitch but somebody's gotta do it.
Um, any OpenGL app that uses the OGL T&L pipeline automagically uses hardware T&L the moment you plug in a 3D card that has that capability (oh, and as long as the drivers are smart enough to go "oh look, we can do this in hardware, lets not bother with software", which is useually the case once you've plumped for a nice hardware accellerated board). Why do you think Q3 gets such a benefit on the GeForce boards? Its because it uses the OGL transform pipeline (although not lighting, unless you opt for vertex lighting in the options which actually produces a speed decrease on geforce boards, because of the extra load on the chip IIRC. And it looks worse because you dont get all the extra effects that the Q3 engine does with the lightmaps or something).
As for development of the API in general, well, any card vendor can implement an extension in thier drivers. If there is an obvious need for that extension in general then a majority of card vendors will implement similar extension and eventually someone will come up with a version of that extension that is acceptable to the ARB and it will get accepted as an 'official' OGL extension and included as a feature of the next release of OGL. I personally think thats a much more democratic way of developing the API then Microsoft's approach where they basically dictate what goes into the API, although to be fair that situation has improved a lot recently. I do think its a good thing that Sweeny has DirectInput to DirectX (sorry for the awful pun =P), after all, good developer communications makes for a better API for everyone.
Nick
Nick
Uh, OpenGL has supported hardware T&L since 1992. You'd have to check with Intense3D to be sure, but I believe Intergraph was shipping hardware T&L OpenGL systems running Windows NT by 1994. D3D is years behind on this one.
One of the reasons it's taken so long to get hardware T&L in the consumer market is that D3D didn't support it until very recently, and Microsoft shut off OpenGL support in the Win9X line as quickly and completely as it could afford. You can say similar things about stencilling, full-scene antialiasing, curve/surface support, and probably a dozen other cases in which it's taken a while for D3D to catch up to OpenGL. Even multitexturing shipped as an OpenGL extension (from 3Dfx) before it shipped in D3D.
Also, check the OpenGL Architecture Review Board meeting minutes. The number of OpenGL extensions that are being cranked out per quarter has gone up, not down, in the past year.
I do agree though that D3D is currently the better environment for development when you want to build 3D engines for vast continuous levels; Windows' tendency to trash the videomemory upon a task switch forces OpenGL to waste huge amounts of memory on keeping copies of every texture. Sweeney complained about that quite a while ago, so it was evident back then that he'd either have to find a solution for it (hoping for a GL_EXT_nosystemcopy perhaps ?), or drop OpenGL for being too memory intensive.
About OpenGL being geared towards id. That's true, but it's probably a good thing. The 3D APIs of today are so complex that it's probably daydreaming to think a driver writer can optimise *everything*. The combined internal state is so huge that you cannot build an optimal path for each and every combination. One influential game that uses a limited set of the API gives driver writers an opportunity to max out performance on that path, which in turn allows other developers to write their code with that path in mind -- instead of just reading the docs and picking one of the 35 possibilities to specify their geometry, hoping it'll come out right and speedy. You're right that this situation is not without danger of getting stuck, though...
Stop gnashing and wailing, and just vote with your pockets. Don't buy the Windows version of UT2, wait until a version for the platform you want comes out.
If you just can't wait, and buying the Windows version is acceptable to you -- well it looks like Epic made a sound commercial decision, doesn't it.
We have no right to "demand" that Epic do (or do not do) anything: we can only appeal to their pockets.
--
I think you understand the problem perfictly as stated.
My only gripe is the how far along Microsofts API is compared to OpenGL.
The OpenGL solution to switch to software is there becouse OpenGL was designed to support hardware that dose not in any way exist on the PC.
This dose mean software can not probe for optimal config.
The small venders COULD give many config options but I doupt many end users know what features they have.
It would still be nice.. Say the game runs fine on a P 200 but I'm on a Athon 1k... Let's tweek in some of those software solutions hmm?
I don't actually exist.
Maybe there needs to be an outfit that makes Linux-only games. Mac has/had Mac-centric game developers like Bungie and Ambrosia. Maybe a Linux-centric group could put out some kick-ass shit so they can have their big-breasted representative sign autographs at conferences.
Such is the infinite Grace of Popeye.
ID software don't have a problem, whenever they are about to release a big-name title all the card vendors run around making sure there drivers are optimally configured for the feature set ID is using. If you're a smaller developer, things work differently, the vendors are not as concerned with you and basically you have to limit yourself to using the features that the big-boys have already used.
This is a very good point, one that no one has brought up before. I think it's more of a "chicken and egg" problem than you realize. Although many vendors' OpenGL drivers are highly optimized for Quake (compiled vertex arrays), id also goes to great lengths to code in a way that will be fast on all current hardware--something that a lot of smaller and/or inexperienced game programmers don't do (or don't know how to do).
Things like using the more generic GL_RGBA texel format, instead of the more obscure GL_LUMINANCE6_ALPHA2 and then complaining that it isn't supported as fast as GL_RGBA. Or, loading all the textures a level needs once at the beginning, rather than constantly loading and unloading them. Learn how to best use the API, and the small-time developer can take advantage of the fast parts of implementations that Quake's popularity has produced.
I don't work for Epic, but maybe I can answer your question.
.plan in fact.
How about pixel and vertex shaders? Under DirectX 8 there's a standard microcode language for designing these and all the upcoming video cards will support this. Write your shaders once and they'll work on whatever next-generation video card your Windows gamer owns. Under OpenGL support will be vendor-specific (via extensions).
Shaders will be tremendously important for next-generation games. They allow lots of advanced surface effects (furriness/hairiness, all the various uses of bump mapping like beads of sweat on a person's skin or water dripping down walls to name but two) you just can't get with conventional multitexture or multipass because you'd need so many passes even 8 bits per channel is not enough to avoid enormous quantisation error. John Carmack was talking about this just recently in his
DirectX also has texture memory management more suited to games, especially games which algorithmically generate textures (like the lava, fire and water in Unreal). OpenGL takes a very high level approach to this which makes texture management nicer to program for but less efficient both in RAM and CPU terms (converting textures from one format to another and storing multiple versions in memory). Remember, performance also ties to features. If something only runs 15fps on a P3-800 with 256megs of RAM, it's not going to go in the game because it will make the game play badly on most people's systems.
Graham
The game developer quoth:
We aren't announcing ANYTHING about Mac or Linux support. Its going to continue along the lines it has.
If I'm not mistaken Linux support consists of buying the windows version and applying a patch to make only the server portion of UT run under Linux. They do not have a Linux client. Correct me if I'm wrong.
Sure, you can write your own proprietary engine to do exactly what you want it to do. And it will only take you three times as long to bring that to market.
Why? Direct3D is not a gaming engine. It's only a renderer. If you're going to talk about engines, the Unreal engine is proprietary. So is the Quake engine. So are all other 3D gaming engines out there, with the possible exception of Crystal Space.
And D3D is proprietary all the same. OpenGL is porderline; you can get non-proprietary implementations but the standard itself is proprietary. Ditto for QD3D.
Thats three times the salary, three times the rent, three times all expenses for the same profit only to have the chance to get that other 15% of the market. The math says no.
Your logic says no, not the math. This doesn't even work, since you assumed D3D was a gaming engine, which it is not. So your math is completely invalid anyway, because the premise was incorrect.
Your math is incorrect anyway. Increasing the marker 15% increases revenue, so the chances of the profit being the same are nil. Your multiplier of 3 is also laughably huge.
Let me give you an example using the Quake3 codebase. Now, as we all know, Quake3 consists of several million lines of code. I don't know the exact number, but let's take a conservative estimate of two million. How much of that is platform specific? According to Id, less than ten thousand lines. That's not even one percent of the codebase.
So let's look at the real numbers. Design your app right, increase your costs and such by less than one percent, and consequently open up an extra 15% of a market which is showing signs of shifting away from the 85% you would have had otherwise? This seems like a very wise maneuver to me.
But whenever I'm given the choice of say writing an object oriented wrapper for a database or just using something that already exists, I'm going to to just use that which already exists. Sure we could write our own database, but the cost associated with writing a proprietary database is phenomenal when I can pay someone else who has already developed, tested, and put into actual use their own database.
Dammit, get it through your head: D3D is not a gaming engine. The Unreal engine is proprietary, and will remain so regardless of whether or not it is tied to one renderer (unless of course you know something I don't about possible Epic plans to Open-Source the Unreal engine; last I heard there were none whatsoever).
Now instead of having 30 developers and 2 years to get this application done, we only need 5 developers and 2 months. Thats serious numbers.
Laughable, though, since you have no idea what you're talking about anyway. D3D is a renderer, not an engine. It is quite possible to uncouple an engine from its renderer, and do so in such a way that you can implement every single feature present with one renderer in another. The advantages cannot be denied. Portability, Support for a broader range of devices, adaptability to a changing marketplace (what happens if for some reason D3D suddenly falls out of favor? If you went with D3D you're screwed). The ability to take better advantage of each possible device (one card does GL better than D3D? You're out of luck on a renderer-dependent engine).
Honestly, it surprises me how many people here are actually coders and still don't get it. This math is not difficult; all it takes is a willingness to design a program correctly. Sure, you can't take shortcuts that way, but in the end the payoffs are greater.
Moot point. console games far outsell PC games. Eventually I'll predict that *almost* everyone will switch to console game stations of some type. I don't care what API's my playstation uses. I just play the game.
Now.. with computers, that's different. I *do* care what OS my computer runs since I have to live with it and interact with it every day.
If windows and D3D end up being the absolute best gaming console platform and become the clear leader (I'm not holding my breath, tho), then I'll buy $LEADING_GAME_CONSOLE and play $BEST_CONSOLE_GAMES and I really won't give a darn whether it uses OpenGL or not.
Ultimately, the money is in the gameplay and mass markets.
Well, I for one am glad to hear that they _acknowledged_ our fear and responded to it. Too many companies are committing entirely to M$. This is not healthy. Competition means advancement for the consumer. If there were no more Unreal for Linux, there would be no more Unreal on my machine.
Linux is really taking off as far as commercial software goes. Ok, maybe the GUIs ain't as pertty as some, but my Linux Workstation is fully functional and Windows-free. Not that I hate Windows, I just _choose_ not to use it. And UT is part of that choice. I bought the game, because it's fantastic and because it runs on _my_ platform!
As long-time readers, I feel we have a right to know why we can't access the services. Well, maybe not a right, but as geeks, SysAdmins, Techs, etc. we could probably all learn from Slashdot's behind-the-scenes problems. Sharing those would shut us up, render us happy and probably make us appreciate Slashdot a whole lot more!
That was my attempt to get subject into concise form. Yeah, Epic games will probably continue to be ported, since they're pretty much guaranteed A-level titles, with enough guaranteed sales on the "lesser" OS's to be worth the effort of finding a porting house. Note also that Epic is big enough to have built the necessary relationships with porting shops. But will their engine be ported?
The HUGE and CRUSHING disaster of Epic's decision is in the effective death of many, many other ports. Take a look at the list of games being made on the UT and Q3A engines for the PC. A majority of those games are being ported to Mac (and Linux? I don't follow Linux ports, just Mac ports). Why? Because the engines are cross-platform.
This is GREAT for pretty much all users, but Mac & Linux users especially.
The games based on the earlier iD and Epic engines that weren't cross-platform weren't ported nearly as often.
That's the real reason for despair and gnashing of teeth. Epic is both a game maker AND an engine producer. They feel responsible enough to ensure that their games get ported, but do they care to ensure that the engine will be?
If Epic makes a Direct3D based engine, but hires a company like Westlake to make a Mac version of the engine, and not simply the Epic game based on the engine, (and likewise for Linux), then we'll have reason to calm down. Otherwise, it's time to be revolting!
--
Make mine methylphenidate.
"I've talked to Blue and he confirms that I did indeed say that the ports were in danger at our meeting at E3. Blue is a damn honest reporter and I believe him. I did not, however, say that we would be dropping those ports. Blue and Loony didn't say that either...it was the conclusion of the Linux community. That conclusion is not correct." If you didn't mean you were dropping support for Mac and Linux what was it, a threat? I'm sure Office 2K could be 'ported' to Linux, doesn't make it supported though, does it?
I invite you to notice the question mark at the end of the title ...
These guys were the one that pretty much started this "panic" by stating the "no more port" part, but completely failing to actually ASK developers who do the ports whether or not this is a problem. Mark Adams, head of Westlake Interactive, who ported UT for Mac, among others, said this really isn't an issue with them. They've ported a bunch of D3D games like TR3 and the Sims.
It would be nice if the guys who break the news do their homework. It would have saved a lot of the doom and gloom talk.
The new .plan makes it clear that they are not going to say that they are dropping mac and linux, but instead that they will be open to the games/engines being ported. This is a considerable collapse in their position and we are right to question them on it. I want games developers to start aiming for writing cross-platform code so they can have mac, win, *nix, psx, dc all out together, but if they can just manage to put out each subsequent port within a month of the last (jan=*nix, feb=mac, mar=psx, apr=dc, may=win) I will be content.
It is not a good sign for us that one of the few companies who had been trying to do the right thing looks like quiting......what hopes for linux as a gaming platform now?
Never underestimate the dark side of the Source
I must say I find it difficult do disagree with him on this. In the early days of D3D there was heavy contention between OpenGL and D3D, I myself was very vocal on the side of OpenGL. OpenGL has barely moved forward in the intervening years whereas D3D has developed at an alarming rate. OpenGL support for the full range of features available on different graphics cards is limited at best whereas D3D has done a pretty good job of keeping up (although there are some nasty sides to the yearly release of the API).
Now I know I'm going to get flamed for saying anything pro a Microsoft api, and the first comment is going to be 'But Id software don't have a problem'. The largest benefit with openGL is that the specification defines exactly how every thing gets done, if the hardware can't do something it gets done in software, this unfortunately is also it's down falling. ID software don't have a problem, whenever they are about to release a big-name title all the card vendors run around making sure there drivers are optimally configured for the feature set ID is using. If you're a smaller developer, things work differently, the vendors are not as concerned with you and basically you have to limit yourself to using the features that the big-boys have already used. With D3D the situation is different, you are no longer shielded from the differences between cards but this can be used to your advantage, using once set of optimal features to achieve an affect on one card and another set on another (or a simpler effect).
The ironic situation here is that (Microsoft proprietary) D3D API is providing the smaller developer with a far more free development platform than the open OpenGL.
DX includes input and sound
.oO0Oo.
OpenGL does not
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
Epic's main reason to focus on direct 3D is, as they put it, that opengl and direct 3D are diverting too much. Basically direct 3D is still gaining features while opengl is a low level 3d standard that does not change much anymore. Therefore keeping direct 3D apps and opengl apps on a par becomes increasingly difficult.
.plan files I gather that there's some good software engineering practiced at Epic. This is visible from how the app is structure (nice usefull GUI, clever mod installation procedure, etc). This nice architecture is increasingly endangered by the apparent differences between opengl and direct 3D. So drop opengl (and in due time replace it with something higher level).
Given this epic can do the following:
- Write their own highlevel library on top of opengl
- Adopt a good existing highlevel library on top of opengl
- Don't reinvent the wheel and use direct 3D.
Onviously Epic is not in the business of reinventing the wheel (that kills option 1), there are no good highlevel libraries ontop of opengl (bye bye option 2). That leaves us with option 3.
How to pick this up in a positive way? Develop a highlevel, crossplatform gaming API that does not force game developers to reinvent the wheel. Apparently such a library is lacking on both the mac and linux. You can't expect epic to do that work for you since it is going to take a while before it becomes profitable (in terms of revenue) to do so. In any case, true unreal fans will probably buy the windows version anyway.
So quit whining and start coding if you want games on linux (I think there are some projects). It's the same as with GUI applications: you need highlevel libraries, being able to put things on a screen is not enough.
I like unreal, and from the techpages and tim
If you are secretly thinking quake 3 is better consider that UT is nothing more than incremental improvement of Unreal which used to compete with quake II. In the time ID spent on developing quake III, epic just kept improving the unreal engine. The fact that it can compete with the quake III engine proves that it must have been well designed since it is scalable and maintainable. Apart from that, quake III's UI sucks (you basically need to get a third party wrapper for it) and the way quake III deals with user mods is very primitive.
Developing 3d games is increasingly less about building a good 3d engine (I think I can quote John Carmack on that). It's about creating good content (nice levels and such). Unreal heavily depends on directX for implementing loads of features. Porting these features to other platforms is expensive and not very productive.
Jilles
You claim that by using D3D, you can develop features on Windows that would not be possible on Linux or Mac.
I don't believe that. No matter the API, 3D is 3D. So let's hear it. Exactly what features can you do in D3D that you can't do in OpenGL or even QuickDraw3D?
Honest question, folks. I don't see any advantage to D3D, other than that a bunch of paying but technically-clueless Windows gamers might see this as some great "feature." Or perhaps grants from Microsoft for making your engine platform-dependent (not a prudent move when that company's future is, at the moment, quite uncertain).
The "Rah-rah OpenGL rocks!" attitude needs to get toned down. We're talking about a 3D API here. In an average game, maybe 2% of the total code has any involvement at all with 3D API calls. Most of the graphics-related code is encapsulated inside of "draw_character" and "draw_mesh" and "draw_bitmap" type of routines. It's not like using OpenGL or Direct3D or whatever has any real bearing on the game itself. If you want to switch from, say, OpenGL to Direct3D, then you go get one of those "Programmiong Direct3D" books, slog through it over the weekend, write code for a few days, and you're good to go. It's not like switching between C++ and Smalltalk or somesuch.
The other thing to keep in mind is that consoles like the PS2 use the hardware as the graphics API. Some people think this is crazy, but it's not a big deal. You take the 2% of your code that deals with actually drawing things and rewrite it to use PS2-specific features. That's about on par with switching between different software-oriented APIs. And Epic has stated that they'll be focusing on consoles first and PCs later for future projects. Other PC developers have said the same thing.
The bottom line is that 3D APIs aren't the cornerstones that people think they are.
it's name is Quesa
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
Hmm, what is Brandon saying?
Basically, Epic is only going to create for Direct3D, a Windows-resident API. If someone wants to port, they can, but Epic is not going to do it for them. Epic for their part will use the API to the extent possible so that someone can plug in a Linux, Mac or game console API later to fill the void.
This tells me that the ports just will not get done, at least not in a timely manner. If Epic sees no value in designing for the Linux APIs that do exist, then why will someone else? Maybe an open source effort, but that will not be timely enough to make these game ports current on other platforms (open source's stength is freedom, not breakneck speed of release).
And as for the PlayStation 2 port, I am not impressed. The companies that make game consoles have certainly long seen the writing on the wall. They must have replacement APIs for Direct3D (or complete implementations of it) for their systems already, or they cannot enjoy ports of the best and brightest PC games promoting their systems. Games are their bread and butter, not a sideline.
People get real work done in Linux, and the effort toward the gaming market is simply not there to make these ports a "six-month" affair. And as we know from watching the PC game market, gamers are a fickle bunch, and have tunnel vision toward the new and exotic.
Just my take on the issue.
-L
But maybe the headlines should be a little more specific. Many slashdot readers never make it past the headline and more never bother to read links in posts. I'm quite sure that many slashdot readers just glanced at the summery and started emailing about how outraged they were.
"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."
Looks pretty inflamatory to me. Many of the readers here have strong feelings about linux and companies that say they are going to support software development for the OS. It doesn't take much to get them up in arms.
Oh well it was an honest mistake on everyones part, at least I hope it was, and we have good news to show for it.
Environmentalists are their own worst enemy. ~tricklenews.com
No I don't. Slashdot has posted much worse stories. In this case, it wasn't GREAT journalism, to any extent, but I have to admit that I would have jumped to the same conclusion, given the input from the Blue people.