The problem I have is ATI video drivers for Linux. So far they have been a huge dissapointment. My brother has an Dell notebook with an old nVidia graphics card that works much better than my Radeon 9800.

For productivity, I'm using OpenOffice, FireFox and Thunderbird amongst other open source applications. For games, I play Savage (http://www.s2games.com) which has a native Linux binary. I also play some other games like BattleField 1942 and Vietnam that run under Linux through an emulator.

Still, with porting to OpenGL, you get the benefit of not having to use a runtime Direct3D-to-OpenGL translator (which is essentially what Wine/WineX/Cedega uses), and you're also a step closer to the OpenGL-only Mac.

Hmm... Enemy Territory runs quite well on my Linux system, and that's despite having a crappy low end ATI Radeon. Not quite as fast as under Windows but that's probably due to the video driver.
Enable glx, dri, and do some AGP tweaks...

Loki closed almost four years ago. The market today is significantly different then it was then. Linux is used significantly more, on the server and the desktop. Id say with ALSA, and Winelib, the effort required to do source code porting today would be significantly less then it was back when Loki was alive. Also with broadband connections being far more popular as well, a modern Loki could sell direct to users.

So a modern Loki would have more customers. The porting would be easier - cheaper. And they would have higher margins if doing direct-download sales. The economics are compleatly different.

For those of us unfortunate enought to have a 9500 or greater, using DRI is not an option, we have to use ATI's pitful excuse for a driver. My 9600 Pro gets slaughtered by a GF4MX in glxgears , yes I know glxgears is not much of a bench but still..

We're also still waiting for official Xorg support. This was promised by mid-December but that's now been put back until mid-January.

well, ut2k4 has a native linux version. Believe me, my crack is Diablo 2, and it runs great under cedega (wineX, from transgaming.com). HL2 is well supported (they even released an intermediate version for the sole purpose of working around some steam breakage). It looks like GR is not supported by Transgaming, but works well (the wiki node is a little out of date, though. I don't have it to report directly, thought).

Additionally, transgaming supports popular games pretty well, releasing versions to support them fairly quickly after (or even synchronously with) their release.

how hard would it be to make a compiler that takes win32 code and outputs it into something linux can use...

Very hard. Since most games rely heavily on libraries of code the compiler would have to be able to recognise the functions and either translate Windows DLL calls to Linux.so calls or synthesise new code for routines which are not supported on Linux.

This is in the realm of possible but not the realm of even moderately difficult. Otherwise, as you say, it would already have been done.

Cedega [transgaming.com]/WineX (based off Wine) is more or less what you just described. It's not exactly free ($5 a month) but it plays most high-profile games with decent sucess. There's also a free CVS version, but from what I've heard it's not as up to date or complete. However, if you're looking to play a game that has never been that popular, good luck. It may work, but chances are some API feature isn't implemented yet.

One problem is that OpenGL (pre 2.0, haven't looked at that yet) is horrible to work with if you actually want to get stuff done. I'm using it in a game right now, and let me tell you, using a library with a stateful API is no fun. Direct3D does a great job of abstracting things like geometry submission (Vertex Buffers) away, and things like shaders are backwards compatible. For example, on Direct3D, a Radeon 9800 can use GeForce3-class 1.1 pixel shaders; in OpenGL they are a NVIDIA-specific extension. If you want your game to be successful you have to cater for ALL hardware out there, and D3D just makes this so much easier.

Having said that, I still use OpenGL, as I run Linux, and don't like the closedness of Direct3D.

Yes, ALL we need is a really well programmed display driver and gfx API for Linux. Many people haven't realised it yet, but NOW we do have the sound driver problem solved as ALSA (Advanced Linux Sound Architecture) was incorporated into Kernel 2.6 series. Now we have a common sound architecture and that's a really good start.

Cedega.
http://www.transgaming.org/ [transgaming.org]
http://www.transgaming.com/ [transgaming.com]
Works great for me and no need for Windows at home... I played Everquest with Cedega up until November of 2004 and then moved on to World Of Warcraft. These games play flawlessly. It's not free for the packaged version but the CVS installs are. I pay $5 a month to support the project and well worth every dollar.

It looks like it's been/.'ed so here's the full article text (sans images).---------------Does Linux Have Game

Introduction

[IMAGE]Live out your Unreal 2004 midnight adventures on Linux.

Earlier this year, our Linux Comes to the Desktop article caused a stir, when we stated that gaming on a Linux platform remained a limited proposition. Now it is time to detail why this is the case. We will explore what is the best you can hope for when you opt for the penguin to play Unreal and Doom III. We will also look at why Linux lovers must be contented with the state of things -- for the time being, that is, because things are looking up for the Linux gaming crowd.

So why is wide-scale gaming support for Linux not 100% there? A better question may be: why would game developers spend the money to add Linux functionality to games for a limited number of users? The answer is not that simple, especially since Linux desktop use continues to grow.

There are many reasons why you might want to shift from Windows to a Linux OS. We won't cover what those reasons might be in detail here, but will note that users routinely complain of Windows instability, high prices and many layers of software that impede performance. For others, there are ethical considerations for avoiding Windows, such as decisions by courts of law in the U.S. and Europe holding that Microsoft has illegally wielded its monopolistic influence in the marketplace. On the other hand, there are magazines out there, backed by now-a-word-from-our-sponsor Microsoft ads, that claim Windows XP deserves your money.

According to a report issued this month by analyst firm IDC, Linux "is no longer a niche phenomenon." The overall Linux marketplace revenues for server and PC hardware and packaged software are expected to reach $35.7 billion by 2008, IDC says. Packaged software revenue is the fastest growing market segment within the Linux marketplace, growing 44% annually to over $14 billion in 2008.

On the desktop, IDC says Linux PC shipments are expected to almost triple from six million units this year to 17 million units in 2008. Percentages of PCs shipped with Linux increase from about 3.8% in 2004 to about 7% in 2008. However, these numbers do not take into account the PC units shipped with Windows, to which Linux is subsequently added.

As you can see, the evidence suggests that Linux on the desktop is growing, and that means more PC gamers who will want to be able to frag at will in Linux. In the game console sector, hackers already know that Microsoft's Xbox and Sony's Playstation II also support Linux.

Until Linux does become as pervasive as IDC and other analysts claim it will, what is a gamer who wants to play Halo on a Linux platform do? And why is it such an issue to begin with? Without detailing differences based on benchmarks, we offer a look at the connection between graphics card drivers and the APIs that developers use for their games, and how the interface between the two works and doesn't work with Linux.

Direct3D Vs. OpenGL

[IMAGE]Doom III shows OpenGL can rock

Whether game developers use Direct3D or OpenGL as their API is the main determinant of whether a game will run on Linux or not. Both APIs are used to create games' 3D imagery, including lines and other shapes, smoke, shadows and all the other good imagery games offer. It has been said that Direct3D is superior to OpenGL, but this is not really the case. While Direct3D is indeed the predominant game API, superior graphics have more to do with the creative skills of the game developers than the choice of API.

Direct3D falls under the brought-to-you-by-Microsoft umbrella, and is geared for the Windows-only world. Because Windows is the main OS in the PC world, graphics card makers have only one OS with which to contend when configuring their drivers for Direct3D games.

OpenGL, meanwhile, is everywhere - it is compatible with Linux, Windows, Unix and Mac OS. But

Why can't someone port the Direct3D API to Linux? This would save a lot of hassle of porting the games to OpenGL.

It's not so much that no one can...just that it's way too much trouble for the benefits you'd get. Specifically, D3D relies heavily on a lot of the rest of the Win32 API. If you want D3D, you'll need either a Win32 API, or to rewrite all those calls. This makes sense in the context of wine, which is why cedega/winex have basically done all this. Not perfectly, mind you...but this is their goal.

Of course, you can add to this the fact that Linux already has perfectly good API's for this sort of thing in the form of OpenGL and SDL. And the fact that Microsoft has kept D3D a moving target.

And finally, there's the fact that porting D3D wouldn't necessarily solve all the problems; presumably, games that use D3D also make a bunch of other Win32 system calls. So, you're back to needing both D3D and Win32.

In other words, you might as well have said, "why doesn't somebody just port Windows to Linux so we can forget about all this bullshit?"

With the success that is DirectX, Microsoft has also been pushing companies to use it for audio and video in their games. Effectively, in addition to DX, they're locking games in with Windows Media Player now, as well.

Even if you're able to get a DirectX game working under WINE or Cedega, for instance, you may be stuck if you're unable to get the in-game movies working. I'm not certain if modern versions of WMP can be installed via WINE, but it just tacks on to the burden of the Linux gamer -- or should I say another nail in the Linux-as-a-Gaming-Platform's coffin; that is, until it becomes popular enough for developers to take notice and change.

As a little example, I found myself in this situation a few months ago. A certain game I wanted to play had installed fine, but once launched it ran a little in-game movie that required WMP. I can't recall now if I was able to install a copy of it or not, but I remember having to do some mouse clicking voodoo every time I started it as to keep the movie from playing, in order to play.

When it comes right down to it, Microsoft has itself another little monopoly. It's yet another reason the XboX is doing so well. Perhaps Apple will come along and save us, with an iBox or something, someday. That, or Linux might actually catch on as a desktop pla-- oh, never mind.

I just long for the day VMware gets a working DX API. Now that will be the day.

This isn't a very good comparison. In the one case you're talking about an OpenGL game that runs native on both platforms, and in the other you're talking about a D3D game that can only run in Linux through emulation.

That said, the reviews I've read about Doom3 on Linux say its performance is not as good as on Windows.

ALSA is only half the puzzle if you're going to compare it against DirectSound. Where's the positional audio in ALSA? It doesn't exist. To get "3D" audio you need OpenAL..and there isn't any OpenAL->ALSA API yet, and that means there isn't any positional audio in any ALSA drivers yet either, except for a handful of experimental drivers for E.g. Audigy and Aureal based cards.

I got both of these from the respective download sites. The only difference being the Linux version is the demo release, which should cause minimal concern since they are going by how well the engine itself runs on the platform.

My system is an AMD XP2100+ 512MB & ATI9700Pro @ 4x AGP. The Windows version runs great, the Linux version runs so-so. It is playable, but not much fun. I think this has more to do with needing to upgrade to something in the FX53 range than being any blame of ethier operating system.

Let's face it, performance isn't nearly as much of an issue as developer support at this point.

Well, I hate to say it but one of the biggest titles coming to Linux was pre-empted from Linux, OS X, and even Windows in favor of the X-box. Yes, eventually it shipped for Windows and OS X, but Linux was left out in the cold when Microsoft purchased Bungie. Bungie had plans for simultaneous release of Halo on Windows and OS X to be followed soon by a Linux release.

The Halo ports weren't big releases anywhere except for the Xbox. (Except in terms of hype.) It sucks that the Linux port was nixed, but Halo was no great shakes as far as PC games go. Gamespy stats [gamespy.com] says there are ~700 people playing Halo currently, which is respectable but also pretty much indicates that the game failed to captivate online gamers - eg, there are ~100,000 Half-Life players playing online currently. Call of Duty, a game that was released exactly one month after Halo PC, has ~20,000 players online now...

Just saying, it wasn't the be-all end-all game; to Xbox gamers, a multiplayer FPS was revolutionary, to PC gamers it was just more of the same. I bought it strictly out of Marathon: Infinity nostalgia, not because it was a groundbreaking effort. Linux gamers didn't miss much.

That all changed when Bungie was bought out. Honestly given the consolidation within the game industry, I don't see much hope for games on Linux for a few years yet

I think the best hope for Linux gaming is in the hands of Indie game developers, and Emulator (or fooglebarg layer, or whatever you want to call it today) devs as well. As far as I can tell right now, those are very good hands.

FPS games tend to get ported because developers/publishers see the value of having user-run Linux servers, and it's easier (although by no means guaranteed) to get a client port from a dev team that's already porting the server code.

Just something I'd like to note: Most FPSes these days aren't being ported to linux/mac by their dev team. this guy [icculus.org] does it for them.

> Get an NVidia. While you will be completely dependent upon nvidia to provide drivers for the lifetime of your card, you get seriously butt-kicking graphics now, not several years down the road when ATI would have finally told developers the specifications.

While their drivers contain a substantial binary only component, your statement is not entirely true.

The layer of their drivers that interfaces with the kernel has sources available, and with some efford it can be adapted to newer kernels when it breaks (which it doesn't do that often)

They also provide drivers for FreeBSD and seem to be taking this idea of supporting such open source platforms very serious, despite their non-free drivers.

From what I've read, porting MFC-based utilities (such as game editors) is more of a pain than switching 3D APIs.

It's really not all that difficult if you use something like wxWidgets [wxwidgets.org] (formerly wxWindows). Slashdot has covered [slashdot.org] the MFC and wxWidgets comparison before. If your interested, IBM has written an article on Porting MFC applications to Linux [ibm.com]. Just let it be known, it is something being done. I've personally converted applications directly from MFC to wxWidgets with very little difficulty and really very little code change. However, none of the apps had non-standard interfaces.

Change 'the' to 'an' and you may have a point. The PS2 doesn't use linux as the operating system in the same respect as microsoft uses a windows based kernel as the operating system on the xbox. Linux on the PS2 is confined to the linux kit, its not like when you are playing a game on the PS2 it's running on top of linux. It's not.

Gee whiz folks, we've got UT2004 with a NATIVE PORT, we've got Doom 3 with a NATIVE PORT (excellent port thank you ID), HL2 plays under Cedega (you need a brute of a CPU tho.) Lots of games with nice installers: Check out http://liflg.org/ [liflg.org] for installers for the best games.

People cry that it's too hard to get your video to work; I'm really sorry you were too cheap to get the GeForce Go 5200 and got the Intel "Extreme" integrated graphics and now your pixel shader games look crappy. Nevertheless, UT2004 and the UT2004 DEMO play under linux with the DRI drivers.

Stop complaining, Loki is gone, but http://icculus.org/ [icculus.org] is still around, and several of those guys WORKED for loki. If you want it EASY, you want GAMES then either USE WINDOWS or buy an X-Box. If you prefer Linux and are willing to expend the time and energy (and reap the rewards of what you learn) then USE LINUX and play the games that work well, there are a bloody AWFUL lot of games that work, work well and aren't that difficult to set up.

In D3D you need to check caps bits for feature, OpenGL you need to check if the extension is supported, seems about the same to me.

I don't understand your comment about OpenGL being Stateful, D3D also stores its own internal state and it maybe more than one copy, one for the DX runtime and another in the driver proper.

About the extensions, nothing stops a Radeon (or anyone else) implementing the NVidia extension (which I think they do). OpenGL allows you just to call the new features (if supported). In D3D access the new feature means you will need to move all your calls to the new interface.

Vertex Arrays do the same sort of job as Vertex Buffers in D3D, plus you have display lists so you can combine geometry and state change into a single call.

In the end to support cards with different features sets you are still going to have different codepaths.

the article basically says:
- OpenGL games can look as good as Direct3D games
- Linux games use OpenGL
- NVidia is the better choice for Linux gamers
- Transgaming's Cedega is useful
Since these are mostly well-known facts, the article is not worth bothering with (sorry TomsHardware), it contains nothing new.

I am using SDL for windowing, threading, timers, events, etc. However, SDL itself only provides 2D graphics capabilities, for 3D you have to use OpenGL. Yeah, you don't have to worry about contexts and so on, which is nice, but it still means you have to use OpenGL.

So your right. I doubt many games use just Direct3D. If you are going to use D3D, why not use DirectSound and DirectInput too? They are much better than just programming Win32 for that stuff (I would imagine). Even Quake2/3 used DirectX for everything but graphics (I think).

As the parrent said, there is more to the problem than just Direct3D, there is all of DirectX (which WineX/Cedega/whatever is working on alongside D3D). If more games were written with OpenGL+SDL (or any other cross platform combination that may exist) things would be easier to port.

I run CS 1.6 (the non-Source version) and it runs beautifully, I'm on Ubuntu.

Everything works as it should, the install can be a bit messy, and lots of people (including myself) have some weird problems, but after a restart that all cleared up, now I have Steam and CS icons on my desktop ready to launch.

Steam runs about 10x faster than on Windows (seriously) but that may in part be to do with the fact that Windows trashes itself after a couple months of abuse.

CS 1.6 is definately playable, only thing is it feels "delicate" when you're using it, you don't want to click HERE and THERE while THIS is loading etc, but I'm sure I'll get rougher as it as time goes on (had it installed about 2 weeks).

Oh, also I only get around 50fps, whereas I got 101 (max) on XP, this is more to do with the nvidia drivers than Cedega itself, though, and I'm sure if I actually bother to tweak the settings around I can maximize its performance.

it's been a bit quiet recently, development-wise, but it works nicely with ut2004, and supports everything but earphones at the moment. According to my friends it's also given them a noticable FPS boost, although i haven't benchmarked it myself (mostly because i've got the ut2004 demo only, which it also works with but is a pain to benchmark)

you can even configure it to a non-standard speaker orientation if you're able to understand the math, but it has many pre-rolled configurations that suit common setups.

Features: It is similar, but still means you have to call completely different functions to do stuff. This makes any sort of data-driven model quite hard to do.

Statefulness: For example, functions that operate on a texture of a certain stage in the multitexturing pipeline operate on the *current* one, whichever that may be. So you have to set the current texture stage of the API, do all your state changes, move to the next stage, etc. The changing of the current stage only affects the state of the API, it doesn't actually affect rendering in any way.

In D3D the SetTexture() and SetTextureStageState() functions take a texture stage number argument, so the same call, called at any point, will always do the same thing. This isn't the case for OpenGL!

Extensions: Nothing stops them from implementing them, no, but it just so happens that they don't, for the most part. In particular, anything shader-related is not implemented by the competitor. (NV_register_combiner, for example)

Vertex buffers: Vertex arrays do the same thing as DrawPrimitiveUP() (or so). Vertex buffers store the vertex data in the most convenient location for the hardware. In OpenGL, this might be ARB_vertex_buffer_objects, NV_vertex_array_range (older drivers), ATI_vertex_array_object (again, older drivers, plus some other extensions that build on this as well), compiled vertex arrays, and so on. They're all ever so slightly different, the drivers have their unpublished implementation quirks in different versions, etc. I hear OpenGL 2.0 improves this, which sounds good.

Another example are render-to-texture operations. In Direct3D you simply set the render target to something. In OpenGL, it depends whether you're in Windows/WGL, X11/GLX, or MacOS/AGL, plus there are extensions (WGL_ARB_render_texture, GLX_ATI_render_texture) in addition to the basic P-buffer extensions, which accelerate render target switches on certain hardware. So I have different renderpaths for different OSes, for different hardware. Lovely. Yeah, you can conditionally compile the OS-specific stuff, but it shouldn't be necessary.

Codepaths: yes, but in Direct3D those different codepaths share quite a bit of code, whereas the codepaths in my current OpenGL code are completely separate, because vertex submission, shading, etc. have to be handled differently for everything.

OpenGL might be lovely for Hollywood CGI type stuff where you have ONE set of hardware and need the finest-grained control possible, but for games which are supposed to suppord a vast array of hardware, Direct3D is just nicer.

If you want it EASY, you want GAMES then either USE WINDOWS or buy an X-Box. If you prefer Linux and are willing to expend the time and energy (and reap the rewards of what you learn) then USE LINUX

You mean keep doing what the mass majority of gamers have been doing for years? Its that kind of attitude why Linux is so heavily shunned by casual gamers. Most people are not willing to expend the time and energy and reap the rewards of what you learn just to get UT2004 running in Linux when they can use the auto-installing and play it on Windows. People want EASY. People don't like having to change their video settings everytime they want to play a certain game.

The masses don't like to get told, 'you should learn our complex and difficult methods to achieve the same results using your simplicitic and traditional ways.' Its like telling the American people that the electorial college is inferior (and in a way it is) but even if its true, people aren't going to go along with it for the sake of ease. (Do you REALLY want to spend the time and effort necessary to constantly remain updated and educated on what goes on in the government while having a job/family/school/social life/playing video games/reading Slashdot/etc.?)

Vertex buffers: Reading this it sound like display lists would be a better fit for this.

The trouble with them is, because they store state information and such, they tend to be very bad for multi-pass operations, as you pretty much have to keep multiple copies of the same geometry around. I've already got more geometry than I'd like to have, so storing distinct copies of it for cel shading and shadowing/lighting is just not an option.

I am complaining specifically about the effort involved. To install HL2 on this machine it was a case of: Pay Valve, start steam, play game, done.

I don't want to dick around with a machine that I use basically as a gaming console - and you cannot tell me that my framerate will be as good under Linux - because it will not be.

I want to play my game and NOT take the extra "20" min involved - for each game I play that is 20 min too long. Not worth my time. I prefer to use the right tool for the right job. Linux is not the right tool for gaming. Sorry to burst your bubble.

One problem is that OpenGL (pre 2.0, haven't looked at that yet) is horrible to work with if you actually want to get stuff done. I'm using it in a game right now, and let me tell you, using a library with a stateful API is no fun.

OpenGL is stateful because 3D hardware is, and OpenGL always tried to be a thin layer on top of the hardware. Unfortunately, as you've noticed, state leakage becomes a real problem as soon as you start trying to build anything beyond a single static scene. It's just too much bother to keep track of all the state variables you have to save and restore as you traverse render nodes, particularly when the traversal order isn't predetermined. That is why SGI developed Inventor, which takes care of managing the details of state variables so you don't have to. You specify which state you want to carry over between render nodes and Inventor takes care of making sure that's the only state that carries over. Inventor isn't open source, but Coin [coin3d.org] is, sort of (the license seems to imply the GPLed version can't be sold, which would be an "additional restriction", incompatible with GPL).

the Mac has switched up its whole system software in incompatible ways a whole lot of times

Do you have any examples or do you really not know what you're talking about? We're talking about APIs here. Mac OS has had stable APIs for games since System 8 at least and probably before. OpenGL has been there and so has Quicktime, QuickDraw, and DrawSprockets (and the other sprockets libraries). There have obviously been other APIs to come forth like OpenAL and Quartz, but these certainly don't count as 'switching up the whole system software to be incompatible.' It just adds new ways to get stuff done. The old ways are still there.

I wouldn't rule out Walmart.com machines. WalMart *does* sell Linux games, and at least the one at the corner of US-30 Bypass and US-30 in Wood Village, Oregon is even happy to point out the Linux games for you.