Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Games Entertainment

Unreal Engine Linux Ports Not Dead? 90

Posted by Hemos from the i'm-not-dead-yet dept.
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. "
This discussion has been archived. No new comments can be posted.

Unreal Engine Linux Ports Not Dead? More

Unreal Engine Linux Ports Not Dead?

Comments Filter:
  • 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 [devolution.com] is trying to do. It was successfully employed in the linux port of "Civilization: Call To Power."
  • Three words: Time to market. 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. 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. And I don't really believe that a multiplier of 3 is too much, but I'm not a games programmer. 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. 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.
  • I agree...

    The '?' Dosn't matter the words "No more Linux port" still mean "No more Linux port" yes it's a question not a statment and thats the context the Linux community took it.

    I don't care if UT is ported to Linux or not. It is nice to have more software titles than less but if someone isn't going to support us what can you do?

    What I do care about is someone jerking the community around and then blamming the community for jumpping to the conclusions we get handed on a silver platter...
  • The Mac is definitely not being abandoned in business; check out MacCentral's recent series on dual-platform corporations and schools (the series starts here [maccentral.com]. Companies who use both platforms report better overall productivity. As always, the right tool for the job. Even if certain companies like mine don't quite get it...sigh....

    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.

  • If you would read the .plan, you would find that he stated Blue reported accurately and drew appropriate conclusions. Blue is only responsible for getting the facts out--other people are responsible for jumping to conclusions.
  • There are things that just aren't supported by OGL though, like hardware T&L. The currently accepted release is OpenGL 1.2. How long has it been since there's been a new version of OpenGL with new features? Meanwhile, DirectX is continually updated. Yes, this means headaches for programmers and for users. "What, you mean you don't have directx 7.01? 7.0 just won't work, and there's this bug, and this feature is missing..." All in all, though, I'd rather see the updates come fast and furious than see a lack of innovation.

  • 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.

  • Aw, hasoo got da snifoos cause da big nasty Swashdotter is pwoving you wong?

    Honestly, you needn't be so defensive or hostile.

    You see, every goddamned PC in the world also has OpenGL in some form or another. Well, not every goddamned PC in the world, but as many as support D3D (not every goddamned PC is the words is brainless enough to "upgrade" every day; well over a third of the goddamned Wintel PC's out there still use Win3.1). And OpenGL has the backing of a lot more companies than Microsoft alone.

    As for fucknuts who think Linux is a real OS and insist on using it, I assure you that there are more than two or three of us, and at least our OS has never been called -and subsequently proven to be- a threat to national security (check the latest article at www.infowarrior.org to see what I'm talking about). Surely an OS of such low quality as to be called a threat to national security could not possibly be called a real OS. Besides which, there are a lot of us fucknuts out there who don't use Linux or Windows.

    By the way, you call me "you stupid fuck" and "you goddamned fuck." Please make up your mind; which kind of fuck am I? It's a lot easier to understand where you're coming from if I can figure out precisely which what sort of fuck you are accusing me of being.
  • I was going to construct a useful reply to this, but when I go to The Microsoft DirectX Press Page [microsoft.com] and click on news articles right now, I get the equivalent of a 404. Go microsoft!

  • This is just another opportunity for Loki (Score:3)

    by SurfsUp ( 11523 ) on Monday May 15, 2000 @05:57AM (#1072851)
    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.
    --

  • Keep an eye on the hardware for the next year or so; I think you'll be surprised at how many of the new DX8 features aren't supported at all, or aren't supported in a consistent way across vendors.

    With respect to texture management, there's always been a great deal of misunderstanding about the differences between OpenGL's memory usage and D3D's. The fundamental problem is that kernels in the Win9X line can destroy the contents of texture memory without warning the driver first, so there's no way for the driver to save the textures to main memory. D3D deals with this by simply notifying applications that the data has been lost; OpenGL drivers on Windows deal with it by keeping a main-memory copy so that the data can be reloaded transparently. (Note that this is a characteristic of the OS, though, not the APIs; OpenGL on Linux doesn't have to keep a separate copy of textures, because the kernel doesn't misbehave.)

    The problem with the D3D approach is that the app doesn't necessarily have a copy of the texture to reload, particularly if the texture was created dynamically (like a Perlin noise texture or an environment map created by rendering in the framebuffer). So it's a burden for the app developer to deal with the situation.

    Obviously the best solution is to fix the bogus behavior in Windows, but Microsoft has no interest in doing that. The fallback is probably to add a Windows-specific extension to OpenGL to allow textures to evaporate when necessary. Tim suggested this at one time, but as far as I know never managed to convince any IHV to support it. It would be interesting to know why.

    In the meantime, we can at least be amused that Microsoft now supports OpenGL-style driver-managed textures in D3D, and recommends that people use them. Like so many other features in D3D that started out different from OpenGL, and then eventually were changed to be like OpenGL. (Anyone noticed that DX8 vertex shaders require a vertex data representation that looks like OpenGL vertex arrays rather than the vertex structures in DX7?) :-)

  • Actually, it's faster and less clunky than OpenGL. However, it's missing some dramatically important things like the ability to plot 2d pixels and such.

    You know how you do 2d graphics in d3d? You have to create a polygon and then map a texture onto it. If you want to do real 2d graphics in direct3d you are required to go down to the windows graphics driver level, and do direct screen writes; this is slow, and inefficient. You cannot mix directdraw and direct3d.

  • These same things were said a few years ago about porting games to OS/2. A few were done (Links, Doom)but eventually the market went 100% Windows. There's just too much market saturation. It's not like the 80's where you could get games on several platforms, because any one by itself wasn't big enough to make money on. Gaming is all Windows 98 is good for, so let it have the market and Linux can take the rest. This of course means that Linux will never have the desktop market, but against Microsoft (trial or no) and the will of the great unwashed, no one can win, even IBM.
  • 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

  • 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 [opengl.org]. The number of OpenGL extensions that are being cranked out per quarter has gone up, not down, in the past year.

  • Re:I prefer D3D now (Score:5)

    by Bert Peers ( 120166 ) on Monday May 15, 2000 @03:49AM (#1072857) Homepage
    Well, this is only partially true. The thing is that progress in D3D often means nothing more than defining a number of new features in the docs. That's only an illusion of progress : sure, in theory you could say that D3D is more advanced than OpenGL because for instance D3D exposes 8 stage texture combiners since D3D6, while OpenGL still struggled to get multitexturing past the ARB, but on the other hand, as long as the hardware out there doesn't set the capability bits that actually make all the theoretical D3D feature *real*, all that M$ progress is just APIware. And it's just as easy for, say, NVidia, to expose a GL_EXT_thisandthat as to set a capability bit. Basically, I disagree with you saying that D3D > OpenGL, because OpenGL is open to start : any vendor can define extensions for his hardware; with D3D, everything has to come from M$.

    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...

  • The story didn't say anything not allready admitted...
    I think Hemos knows more about what went into the story than someone who just reads the headlines :)
  • It would probably be pretty stupid for Epic to start ignoring Linux, now that the market is booming, and them having an edge with their cross platform engine of today. What it'll probably mean (if you read the part about "support for modular code" etc) is that there may be a Linux port, but it'll be seriously inferior to the D3D version. Given that the past problems where mostly with texture swapping, and GM's emphasis on D3D's "better API", I would guess that'll mean less textures, lower resolutions, less procedural effects in geometry and textures, less advanced shaders, and a few more, in the Linux version..
  • I'm not in good forum today sorry...
    "No more Linux port" Was from Slashdot :)
    I keep thinking how Slashdot gets game news from peoples fingers with quicky one-liners like...
    "No more Linux port?" and nothing else...

    "No more Quake for ID?"

    Still it was a valid jump given the details...
    This is the reason Linux and Mac ports havn't been made in the past....
    There is absolutly no reason to assume history isn't repeating itself....

    In the lack of facts we assume busness as usual and in this case busness as usual means No Linux port...

    The words "No Linux port?" No matter who the author is pritty dang clear.... it means one thing....
    It's valid speculation from us....
    If the engen gods start asking it... then we do have something to worry about
  • Say it ain't so... [/sarcasm off]

    --

  • OK... Windows is where most of the gaming action is at the moment. I don't think anyone can argue with that. If you are building a box for gaming, you put Windows98 on it and woop dee doo. It crashes a lot but it doesn't really matter because you're only playing a game and you can reload from your previous save game. Annoying but not too bad. Microsofts slogan for windows should be - "Windows98 - crashes loads but runs games really well. HONEST.".

    Pinning the development of their game engine to DirectX is really dumb though. Look. Microsoft have just been found guilty of loads of shit. Nobody trusts them. They are the most self-serving company ever to walk the earths surface. The really anoying thing is they take advantage of people who don't know much about PC's and claim everything they do is for the good of the PC industry. Does this Unreal guy really believe that Microsoft has created windows out of the goodness of Bill's heart? This is bollocks. He did it to make money. This whole Kerbos thing is a disgrace as well. I really can't believe that they have so blatantly ripped off something and fixed it to their advantage. Will they ever learn?

    By pinning themselves to DirectX the writers of Unreal are in danger of finding themselves going down with a sinking ship. Microsoft may be big but their market share is shrinking. That .plan was quite strong in Microsofts favour wasn't it? Maybe Mr Gates is interested in bundling Unreal with the XBox (or whatever name it has this week). Money talks and the amount of money Microsoft has to offer talks very LOUD.

    I would be very interested in hearing from 3D games developers about which is really better/nicer D3D or OpenGL. As a user I love OpenGL. Somehow it seems to offer smoother graphics. Does this make any sense? Also, OpenGL has never fucked my system with a VERY big stick. New versions of DirectX used to do this on a regular basis.

    Long live OpenGL (come on guys... new version please!)

    Bit of a rant. Sorry.

  • Market forces (Score:4)

    by slim ( 1652 ) <john@@@hartnup...net> on Monday May 15, 2000 @04:08AM (#1072863) Homepage
    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?
  • 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.
  • 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.
  • Allow me to anwser this - they could make a product people actually want.

    And this cannot be done in OpenGL or QD3D? Please, explain why. Because from a programmer's perspective, I don't see it.
  • So I guess I should be overjoyed at being a second class gamer? Its very frustrating seeing news like this, while game support for GNU/Linux seems to be rapidly maturing. I regularly play Quake3 and Unreal Tournament in GNU/Linux. In fact, I've dropped windows entirely now that my current favorite games are available and quite playable.

    I'm not sure what's better. Having a second rate port done more as a nice gesture, or just dual booting and playing the game in its full featured mode.

    Perhaps everyone would be pleased if Epic would consider outsourcing the port. Let Loki do it. They did an excellent job on Heretic 2. And as far as I know, have ported Direct 3D games.

    Who knows. There may well be a nice little market for companys who perfect the art of porting games across platforms.

    Of course, this will only work if people loose their allergy to spending money on software. If you don't like spending money on commercial software, thats all well and good. Just dont clamor for a port of game XYZ then balk at spending actuall money on an actual commercial product. Hypocracy doesn't do the community justice.
  • See you dis him for pointing out MS controlling the API, but then applaud ID for doing the same thing, just through a different means. So essentially you have rendered most of your argument nihl.
  • And don't forget Mac OS X (aka OpenSTEP 6) One of John Carmack's favorite OS's. I believe Quake 3 came to OS X Server first before MacOS, Linux, and Windows. With the release of OS X, Microsoft will have the only non UNIX-based OS on the market, and ME is another DOS-HACK still... so they still don't GET IT. With the advent of OSX, Mac hardware will begin to outshine Intel by leaps and bounds instead of by baby steps. Andrew
  • I don't work for Epic, but maybe I can answer your question.

    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 .plan in fact.

    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.
  • Windows 98 is. Microsoft could probably improve their reputation with this crowd by a couple notches if they cancelled 98 tomorrow and just went with NT.

    However, the gamers would freak, because Windows 2000 means they would lose about 5% of their frames. Boo Hoo, and irrelevant with 6 months worth of new hardware. There's also still a few business users with DOS/Win31 apps, but whatever.

    This is one of the most insideous aspects of MS's monopoly -- they push a sh*tty OS (9x) on everyone through preload agreements, and then charge a big premium for a nothing more than working version (NT) of they same thing.

  • What is this about the writing on the wall for consoles, just because some PC games companies develop using D3D? How does that affect the console market? I am guessing that lbrlove is a PC gaming, non-console-owner.

    Go take a look at the PC and then the console sections of your local games shop. How much cross-over do you see? Quake 2, and the Tomb Raider series, anything else? Final Fantasy games have been ported in the opposite direction. Not much cross-over at all.

    The console games market is very healthy indeed, and is in no way dependant upon the PC games industry for its success. When a title makes it really big in one sector, it usually gets to cross-over, just to milk the license as far as possible.

    But N64 vs PlayStation vs Dreamcast makes a lot more sense than PlayStation vs PC. I have the mis-fortune of owning a PC rather than a decent computer such as an Alpha or UltraSPARC. I don't use it for games at all, because I don't find the PC games genre appealing. RTS and FPS don't get me going at all. PC RPGs tend to be very much in the TSR style, which I don't like. And I would much rather sit on the sofa with my nice big TV and a very well designed controller, and play something really accessible and original than sit at my desk looking at my piddly little 17inch monitor, torturing my wrists with a mouse, and trying to contort my other hand in such a way as to reach all of the most important control keys, in useful combinations.

    I'll be buying PS2 and Dolphin, but its pretty unlikely that I will buy any games that do get ported from the PC to them. I'm just not interested.

    There is one cross-over from PC to console that does appear to be coming whether people want it or not. On-line gaming. I personally find this disturbing. I have played several PC games over LANs, but only once each. Each time I approach it with an open mind, and each time I come away with the impression that it is just a tedious void. But now Final Fantasy X and Phantasy Star On-line are apparently only going to open up the majority of their content to people who play on-line. I want an accessible videogaming experience with polish, that I can play when it suits me. I don't want to only be able to play if and when three other people that I trust happen to have the same gaming tastes as me, and are available at the same moment in time to play. And be at the mercy of one or more of them deciding half way through the game that they can't be bothered to finish it. And I don't want to meet complete strangers on the Internet, just because some games company marketing department thinks I might. And there is a reason that their script writers earn top dollar, rather than being someone who walked in off the street. They provide top quality content. I don't want my game to have the quality of some amateur, sub-fan-art creation. And how about getting into role? How is that going to work when the people you play with talk about the game mechanically and call you by your real name because they find it easier? Or they ask about something in the real world. Aeris wasn't about to break the spell in that way.

    PC gaming, please stay away from my consoles!

  • I believe that you are missing the point. The features that you speak of most likely CAN be developed using OpenGL. The problem is that the time that they would need to invest in making this possible means that they spend way more money on development when a perfectly viable (from there perspective) option already exists. Would that be sound business sense?
    I beleve that the levereging that M$ did with the the whole directx package is both terrible and brilliant at the same time. The made development of softwares for their platform easier and cost effective while making porting of those games to competative platforms difficult and expensive. It was a very effective strategy. The only effective cures for this are a> release of the directx APIs for all to use or b> development of an Open Source alternative. Even if such a thing was not adopted by Win32 developers it could make the port much simpler if it had equivalent functions that could be substituted for the DirectX ones.
    my 2 cents
  • You make excellent points, my amino acid friend. I suppose I considered it much more from the development stage; the games are programmed on PCs and "ported" (same hardware with keyboard and a compiler I admit).

    While definitely giving you your due, I still think the console game manufacturing companies have more ability to port anywhere as they predominantly make games, and reformatting a given product (whether it be from the PC world or not) to their platform may prove important. Cross-over the other way (console to PC) sort of furthers that point, that they are more efficient at it. At least they will port better than the open source community who are not unified even in desire to see games, let alone port them.

    As to your rant, all I can do is nod with a stupid sculpted smile. It all sounds pretty reasonable given your stated preferences. I have owned game consoles, but not in a while - the industry has really changed since then. Although I have played PC games as well, I do not get into these as much as I used to. Sorry, but I like FPS over anything else (the PC versions are much better IMHO), nothing to any great extreme. I am not a gaming snob or anti-game elitist, just somewhat apathetic.

    Cheers, and again good points all.

    -L
  • 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.
  • Slashdot has been DDoS'd repeatedly over the past few days. Everything has been screwed up, that is (most likely) where all of your problems are comming from.

    There have been at least three seperate occassions where slashdot hadn't responded to me at all although I haven't had any trouble logging in.

  • Good points. I analyze it exactly the opposite though for the long run.

    All console gaming systems can do is improve the experience they have already delivered for a long time. Other than building the ability to tie them together, it is a raising of the ante for "more of the same".

    But PCs are boasting the following:
    (1) faster CPUs;
    (2) faster graphics and sound subsystems;
    (3) unified graphics and sound APIs (e.g. D3D, OpenGL);
    (4) greater household penetration;
    (5) TV output and access to unique controllers (via USB, etc).

    This tells me that developing for the PC will become like developing for an appliance - you can guarantee everyone will have one and that it will be fast enough to handle the gaming load. With the unified APIs, PCs will finally have the ease to program that game consoles do. They will essentially have abstracted the hardware to one set of commands, the advantage the game machines have always had.

    As my last replier rightly pointed out, there are very few ports from console to PC right now. But there are more than there have ever been, and I expect the trend to continue and deepen as people realize the power of the ubiquitous and capable PC.

    Speaking of the here and now, game consoles are still dominant due to their price-performance, but I expect that to change over the long haul.

    The one wildcard seems to be people like yourself who like the console gaming experience (after seeing the newest generation of consoles, I cannot fault you at all). I expect this is an issue of visual technologies which can also see some adjustment over time, but it remains to be seen.

    -L
  • The DX8 vertex shaders use the flexible vertex format. Which is actually better then the OpenGL method of doing things. Extending the vertex structure to handle new features is a big deal in GL. In order to do things like multi-texture it requires multiple uv coordinate lists. The DX8 method is equal to the interleaved vertex format in GL but it is much more flexible. You can put any combination of the data you need in a single vertex entry. True DX copied the idea of interleaved vertex format but they have vastly improved it over the current GL method. -Jeff
  • This is offtopic, but I am wondering why slashdot has not posted a story about it. I have been having tons of problems with slashdot, sometimes I cannot connect to the server, sometimes I do and I get tons of CGI errors, last night, I got errors that my account no longer existed and I should create a new account. I am glad my account is back, but it has been frustrating for the past couple of days that I no longer feel like coming here to read news. Worst of all I am afraid that if I click the submit button, I will get one of those errors. Why can't slashdot post a story and tell us what is going on? This is a service, and they owe us an explanation. If the new server is not holding up, please downgrade. Yes, this is offtopic, and I do not care about submitting a new story, because I am very sure they will not let it through.

  • 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!
  • The Linux community??

    Good God /. has balls to post this quote after running a headline like "No More Unreal Ports For Linux?".
    --
    Have Exchange users? Want to run Linux? Can't afford OpenMail?
  • 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!

  • uh huh? (Score:2)

    by Anonymous Coward
    "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?
  • with that "Maybe he should read beyond the headlines" comment. I would guess that he knows more about the engine and its future than you do Hemos.

    Once again, Slashdot "editors" prove to be reactionary just to pump up a story. When the next version of UT for Linux comes out are you going to apologize for whipping people up for no reason.
  • I invite you to notice the question mark at the end of the title ...
  • > If you are not careful, you will find yourself back in a niche market until DirectX can overtake you there too.

    Yeah right. OpenGL runs on every other major "desktop" ranging from low-end PC's Windows/Linux/Be, etc to high-end SGI's. How is that a niche market ?

  • Blame BluesNews for the paranoia (Score:3)

    by Electric Eye ( 5518 ) on Monday May 15, 2000 @03:03AM (#1072891)
    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?
  • I think you're right... If we're not careful, OpenGL will the the technology of yesterday. Unfortunately, as we're all realizing, Open-Source "free" software has a relatively slow development path, as Linus' motto is "we'll release it when it's ready".

    Although this is a motto that has created a beautiful and stable OS, it's also our Achille's heel. M$ can inject millions of dollars into new technologies. If the technologies fail, oh well, better luck next time.

    They did it with Windows, they did it with Explorer, and here they are again, doin' it with DirectX. The Open Source community could rapidly develop OpenGL into something oodles better than DirectX, but when people don't get paid for it, what's the rush??
  • I am appalled at the level of flamebait moderation there is going on in this post. Flamebait is saying "Slashdot sucks, you are all a bunch of losers" it is not saying that an arrogant comment was made, or that people on slashdot made a lot of incorrect assumptions. Please, all of you moderators right now, quick marking flamebait because someone said something that "wasn't nice". Wow, it wasn't nice to slashdot in general, live with it, it's not intended to spark a fight, just to express a relevant opinion.

  • I think you get the point.
    --
    Have Exchange users? Want to run Linux? Can't afford OpenMail?
  • > But how can they exclude the Mac?

    I've been meaning to ask whether the Mac is dying, in terms of software support. I don't have enough Mac contacts to know what's going on, but lately I've visited various download sites that seem to be more and more Windows-only, IE-only.

    So, are companies ditching the Mac and going Windows-only these days? Even outside computer software, it seems that companies are more and more going toward "any size so long as it's 'medium', any color so long as it's 'black'".

    --

  • I prefer D3D now (Score:3)

    by JamesSharman ( 91225 ) on Monday May 15, 2000 @03:15AM (#1072897)
    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

    OpenGL does not
    .oO0Oo.
  • it is his job to find every rumor on every website. Please find a better excuse than that.

  • pick this up in a positive way (Score:3)

    by jilles ( 20976 ) on Monday May 15, 2000 @04:29AM (#1072900) Homepage
    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.

    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 .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).

    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.

  • An honest question for Epic... (Score:3)

    by Millennium ( 2451 ) on Monday May 15, 2000 @04:39AM (#1072901)
    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).
  • There are things that just aren't supported by OGL though, like hardware T&L

    Um, wrong. OpenGL is an API, the way it works behind the scenes is hidden, and it could be a software rasteriser rendering your frames, it could be a hybrid setup that does the rastering in hardware, but everything else in software, or it could be a 100% hardware setup (such as an expensive SGI rig). I'm afraid you need to read up a bit :) The moment you plug in a T&L board and update the OpenGL driver, most well-written apps will get a speed increment (and that's not just theory, my crappy PII-200 got a new life with a GeF recently).

  • 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.
  • LOL. I don't have a sister, there's no third and main in my country, I don't know who you gave the $5 to, I do have a brother though...

  • 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.

    Well, this is true, but as you point out, the features that D3D is gaining over OpenGL are in the high-level domain; D3D is getting built-in support for reasonably exotic stuff like shaders, vertex morphing, continuous LOD etc. So you're right that Epic would in theory be reinventing the wheel if they wanted to support OpenGL, because they'd have to reimplement all that D3D stuff on top of OpenGL.

    However, it's important to keep in mind that the higher the complexity goes, the tougher it becomes to write an API, and implement it, in such a way that everybody is happy feature & performance wise. As an example, there are numerous scene-graph libs for OpenGL that actually rock the house -- if you use them for what they were meant for. Like you say, they suck if you don't. Now I admit D3D features like shaders or LOD are still somehow on the borderline, there is probably only a very limited number of ways to implement this, so chances are that if you'd write it yourself you would indeed arrive at what D3D does, so don't bother. But as this trend continues it'll still be worthwile to implement highlevel stuff yourself. I mean, yes, content creation is a substantial burden these days, but that doesn't change the fact that a race game, a FPS and a flightsim still have massively different requirements from the highlevel parts of the 3D engine.

    If you think about it, the argument of Epic that D3D is nice because they have a large input in it's development is pretty interesting. It almost seems to suggest that if hard decisions have to be made to trade off features vs performance as D3D gets more highlevel, the balance might swing towards "whatever benefits FPShooters", thanks to Epic.. ;) ;)

  • 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.

    Your comments are interesting, but GreenMarine commented that it took Epic 6 months to port UT to the PS2. Assuming they had a fairly large team of coders working on it, it seems like 6 months is an awful long time to spend rewriting a 'mere' 2% of the total codebase.

    I don't know anything about graphics coding, so maybe I'm wrong. What's the real verdict?

  • As a game developer and someone who has written extensively in Game Developer magazine on openGL issues, I think my credentials on GL support cannot be questioned. However, let me explain why OpenGL is having problems and why more and more companies will be shifting to DX.

    The facts are that there is no one really to evangelize GL. Someone needs to lead graphics development. Someone needs a vision and a roadmap for where hardware should be going and how developers should be using it. In the old days, the defense industry and SGI served that role to some extent but cannot anymore. Microsoft has stepped up and like or not are the only ones able to do this now.

    Microsoft goes out to the developers and asks them what they want to see (you may not believe this but it is true that this happens). They then talk to the hardware manufacturers and ask them what they think is possible in various timeframes. They then establish a roadmap for features and lay that out for both developers and IHVs. Hardware vendors decide what to tackle for their cards and developers decide what to use. Sometimes it works well and sometimes it doesn't.

    For example, DX7 had matrix blending but it was limited. It was all the IHVs would agree to but it wasn't really good enough for any developers to actually use. So it was not widely adopted. Everyone acknowledged this and the next gen it will improve.

    Now the problem. OpenGL has no one able or willing to serve this role. It is a tough one. Someone who can work with developers and IHVs, keep trade secrets, and make people listen. So OpenGL is the orphan stepchild. Ends up with proprietary extensions that follow DX and wait around for the ARB to decide what to do. Look how long it took the ARB to decide on multi-texture.

    You do get people like Carmack who via a plan file (as well as discussions with hardware vendors) lets out his vision. There are others as well. But face it, DX is more agile. It can adapt to ideas quickly and has a roadmap for a yearly update.

    As far as the API. Most developers don't really care. They want access to hardware functions and a method for making things work on a variety of cards. I use GL because I like it and am used to it but if a client wants D3D, I have a wrapper that takes about an hour to hook up. Unfortunately, if GL doesn't get its act together, I will be forced to prototype in DX. I am looking for solutions but this is the reality and it is looking tough for GL.

    -Jeff
  • Sorry, your right, its not an engine. Its an API. But the idea is still the same. From reading some of the previous posts though, DirectX is at a much higher level than OpenGL or any other free renderer out there and the gaps are just getting bigger and bigger as more features become available. So it still costs more to write the code to make the same program just to add a little more market share. Look, I'm a fairly young consultant with only a few years of professional coding under my belt. I admit I know very little about the actual implementation of DirectX I looked at it a little bit back when it was the Games SDK. Regardless of that fact, I think the same principles I stated earlier apply even if I missed the wording slightly.
  • First, it wasn't six months. More like six weeks, before it was first shown at GDC.

    Second, there are some things that OpenGL provides that can be nasty to port to simpler APIs. Texture management is one. OpenGL and Direct3D do this transparently, but on the PS2 you have to do it yourself. Clipping is another. If you use OpenGL, then your clipping is built in. Move to something else and you have to do the clipping yourself. This doesn't change the fact that any decent modern game shouldn't be based around 3D API calls.
  • Yes, I work for Microsoft. I work in the deep dark laboratory where they plot World Domination(TM) over the weak conspiracy-minded folks like you. In fact, I produced the product Active Soul Stealer(TM), and may use it against you.

    How dare you act as if the console game industry is not about money. Microsoft brings big bucks to whatever it does whether you like it or not. Consolidating/abstracting hardware to a single API is a good idea whether Microsoft does it, or some open source regime that you sycophantically butt-sniff. If game companies of any sort adopt a porting philosophy, then that is the potential for revenue.

    Now, AC loser, why don't you go back to your commune and bemoan the world of big capitalism in a country that does not give you the right to make a buck. I am so sick of pure socialists who live in a free country yet have nothing to do but bitch (and troll).

    -L
  • I play UT all the time on Linux.
  • Yeah, I'm aware of the multitexturing support, which worked dandily. Also, OpenGL extensions only do so much good if they're not rolled into the official spec; People are loath to use them if they're not 'officially' supported. Who wants to handle a bunch of special cases in their rendering engine? You want to know that the features you need will be available everywhere.
  • it's name is Quesa [designcommunity.com]
  • 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
  • In a capitalist society, it all comes down to money. If Epic starts seeing a lot of money coming from the Linux sector, it's not going to be as open to making ports to it because they cost time and money.

    All we can do is send our support and monies to Linux games to support those ends. Hopefully, the gaming companies will wake up and start porting to Linux and other platforms.
  • 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. "

    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.

  • What is up with "Maybe he should read beyond the headlines"???

    Maybe the linux community should be glad that there are still entertainment software houses supporting this arrogant community
  • Anyone who would flame you over supporting a M$oft gaming API is just not being realistic. Windows has far-and-away outrun alternate PC-based platforms for being game friendly, and I for one agree whole-heartedly.

    -L
  • Whatever happened to Farenheit, the SGI and M$ hybrid OpenGL/DirectX replacement?
  • That was an honest opinion, it is what I felt when I read the initial story, that one of the best games out will not be released on other platforms but Windows. Why would a company that is making such successful strides in 3d gaming would not want to carry these strides to other platforms, show that the company is willing to stretch 3d gaming between other platforms.

  • I paid for a linux version of Quake 3-- at first they were taking a while to release patchlevels between different platforms. With 1.17 they all came out at the same time-- I think that trend will continue.

    However, UT seems to have pawned off their stuff onto SourceForge and it seems to have floundered.

    Seems to me, most people don't use D3D because of the higher overhead of programming with it. It's slower and clunkier than GL. Many of the commands are the same, but the invocation is not as clean with D3D.

    I'll bet some $$ that Epic is motivated by the X Box, and not by technical considerations.

  • Both Thursday and Friday. Check out this story [wired.com] at Wired.
  • "So I guess I should be overjoyed at being a second class gamer? "

    Well, that's the result of using Linux. No one to blame but yourself.

    --

  • I agree that that statement was pretty damn arrogant. However those are not Hemos' words they are from the person who submitted the story to slashdot.
  • Um...Half-life is not made by id software...It was written by Valve Software and published by Sierra. But ironically all Half-life would need to do is hand the source over to Loki, since it does support OpenGL already, and it could be ported readily.
    Links to prove it:
    http://www.valvesoftware.com/projects.htm [valvesoftware.com]
    http://www.sierrastudios.com/games/half- life [sierrastudios.com]

    I really have very little respect for Tim Sweeney any longer. He has shown he can code C++ extremely well, and write games that are very nice...but he has no business attempting to dictate technology. He has made claims about OpenGL which are simply not true (for example his claim regarding texture swapping and memory usage being better on Direct3D.) I have also not seen ONE feature that he or any other engine maker has published in a game that BOTH API's couldn't handle equally or near enough. Maybe he has a vested interest in Microsoft (stock?) or something...
  • Truthfully it is for this very reason that Microsoft has spent so much time creating the DirectX API. You will notice that despite everything else, Microsoft loves developers. Of course they do. Why do you think windows has an 85% Market Share. They have poured all these man hours into creating a really top notch API and give it away for free for what reason? Market Share. How many people honestly continue to have a windows PC at home for the express purpose of running games. I know I do. If I had everquest on Linux, I wouldn't need windows, thats for sure. Honestly, if you want to see these games continue to come out for linux and mac, do something about it. Lets see a better API, please.
  • BeOS use OpenGL as 3D API, Quake1, 2, 3 are running, and maybe a UT in closed beta. There's also QNX/NTO that claims they will release UT for their free platform Neutrino.
    --
    BeDevId 15453 - Download BeOS R5 Lite [be.com] free!
  • to understand HOW the 'community' reacted. The other main story about the 'drop' of opengl support (and thus mac/linux) here on /. is a total cry for -1, troll. Most people simply think a gameengine IS the api (huh?) but most of the code is simply not api-oriented. If they don't port it, some linux-game oriented company can pick up the small part of d3d specific code and port it to opengl. Big deal.

    And besides that... how many people BUY games when they're available for linux? BUYING software isn't in the linux user's mind (because everything is free and open).


    --
  • 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.
  • The sad truth is that Linux is not running on their main consumer target group's machines. But how can they exclude the Mac? Mac has decent 3D hardware, and the speed is quite up to snuff. It's a great gaming platfom, although some things need to be worked on. Like stability for instance, I own an iMac, and I still have the odd lockup from MacQuake for instance.

    I agree that going totally D3D would be stupid for EPIC, since that would blow the portability away, but the OpenGL group should hurry up in improving their standard. I know OpenGL is a better API to work with, also because it's simpler and less complex, and you need less code to get something done, but where M$ is winning is the amount of features (read: bloat) that they have in /their/ API. If a graphics card supports e.g. Bump-mapped reflection or something, M$ is the first to cram support for it in their API. Now why can't we (the OSS community) do that? Utah GLX for instance is going great, and is producing pretty decent drivers, and they have some big names putting in time for them.

    I once heard that nobody can out-feature Open Source.

    Cheers,

Slashdot Top Deals

It is now pitch dark. If you proceed, you will likely fall into a pit.

Close