Kuro5hin.org: technology and culture, from the trenches
create account | help/FAQ | contact | links | search | IRC | site news
[ Everything | Diaries | Technology | Science | Culture | Politics | Media | News | Internet | Op-Ed | Fiction | Meta | MLP ]
We need your support: buy an ad | premium membership

why linux didn't break into the game market

By turmeric in Technology
Thu Jan 24, 2002 at 04:44:02 PM EST
Tags: Culture (all tags)

So I downloaded this great game called 'racer' for linux. Its screenshots were snappy and cute as heck with nifty graphics and etc. But installing it, well, it just goes to show you why linux has a long way to go to enter the 'gaming market'.

Here is what I had to do to install it:

  • 1. download a binary file (the data)
  • 2. download another binary file depending on which video card you have (the program)
  • 3. create a new directory
  • 4. extract those files into the new directory
  • 5. read some install instructions FAQ for the game
  • 6. get some obscure library for the sound. (this library is not in debian)
  • 7. unpack and read the README for this obscure library.
  • 8. find the '.so' file within the directory tree of the unpacked library.
  • 9. copy the .so file from step 8 into /usr/local/lib
  • 10. have flashbacks to screaming unix bigots yelling at you not to put it in /usr/local/lib, or whatever, and beating you up, and stealing your lunch money, and having your thesis trashed and having you kicked out of university. curl into fetal position and cry a while.
  • 11. ldd the 'racer' binary to see if it found the .so file from step 9.
  • 12. no it didnt, so run 'ldconfig'.
  • 13. realize i need to be root to run ldconfig, so run 'su'.
  • 14. try again, this time ldd works.
  • 15. notice that racer startup screen runs about 0.02 frames per second.
  • 16. remember the FAQ you read says you need DRI to be at a decent speed.
  • 17. remember DRI has something to do with Xwindows.
  • 18. flashbacks to unix bigots, screaming ""dont say xwindows"". more crying.
  • 19. poke around in /var/log/XFree86* for anything relating to DRI using grep.
  • 20. notice a message in the logfile that says ""DRI doesnt work for tdfx with 32 bpp, restart X with 16bpp for this to work""
  • 21. ponder the best way to do the restart of X in 16bpp mode.
  • 22. look at kdm to see if you can make kdm do it
  • 23. give up and kludge something in yourself to play the @#$@#$ game.

Ok, here is the 'standard procedure' that i suppose most people might have tried so far. But step 22 requires a bit of 'creative thinking' so here goes. Note that I have no formatted this section at all, I merely wanted to give a feel for the sheer amount of grinding and churning and typing my mind went through in trying to figure out how to get this game to run. Actually rewriting it for readable purposes would take perhaps 5 hours. I would have to reform all the half-intuitions into pseudo-logical explanations of why I did what I did. But this is a kludge, and its spirit is by nature impenetrable and illogical. Thus:

i had no desire to ruin my wonderful kde setup and put it some retarded 16 bpp mode, so i resolved to just login on console, try to remember how to run 'startx' with -bpp -- --bp - 16 - - -- whatever so that it would be in 16bpp mode, hoping that it hasnt futzed with my kde. anyways it doesnt work. it gives me '/dev/dsp: device is busy'. i assume kde has screwed with the sound so i will try again. same error. in fact it is 'esd_open_sound: cannot open /dev/dsp: device or resource busy'. with that extremely helpful bit of advice i go off and try to start x without kde popping up. how? by making a new user. login as root. adduser. shit wrong password. ok adduser again. ok now add the 'racer' user to the 'audio' group. logout. login as racer. ok now see if i can remember how to startup X. edit ~/.xsession. put in 'flwm & ; sleep 1000000' into ~/.xsession. exit, then run 'startx -- -bpp 16'. ok. seems to work. ok then remember that i unpacked 'racer.tgz' under the user 'don' so user 'racer' wont have access to it. su to root, move the files over to /home/racer, try again. ok seems to load, but seems to lock up too. flashbacks to unix people telling me 'its not locked up just get on another computer and telnet in and kill X and restart it.' curl into a ball and cry some more. thankfully linux started responding again after about 10 seconds and let me kill X. try again. wonder if its slow because the computer is slow or because its not loading dri. look at /var/log/Xfree86 files to see what they are saying now about DRI. cant figure out logfile. erase logfiles and restart. ok it says its still not in 16 bpp mode, it thinks it is in 32bpp mode so DRI wont work. so i guess startx -- -bpp 16 is not really putting it in 16 bpp mode? what next to try.... well,lets see what startx has to say by doing startx -- -bpp 16 &> logfile. oh there is a message that flashed so fast on the screen i couldnt read it! i thougt there had been something there. it says -bpp is no longer supported. so try -depth now. ok so i am assuming it was slow becauswe it was not in DRI and was in 32bpp. notice that the program doesnt 'detect DRI and/or 32bpp' it just runs ass slow. ok. startx -- -depth 16. ok that works. ok racer seems to start but the startup menu is just a white blur with a bunch of purply junky looking menu buttons on it. well, i guess the first one must be somethin gimporatnt so i click on it. oh and now what happens? it is ass slow, even tho i have the 'min system requirements'. i assume it means for lower resolution so futz around with /etc/X11/XF86Config-4 and see what resolution is in there and see if i can make it do 640x480 now. ok erase '800x600' out of the 16bpp mode. restart x. ok now it seems to work. game is alpha level, shows lots of promise, seems to have good following on internet, etc.

So there was the way I installed it. This probably took an hour. Notice there are something like 60 individual steps to perform, many of them requiring familiarity with alot of linux command line mumbo jumbo and text based configuration files, including grep, /etc/X11/XF86Config-4, ldconfig, /usr/local/lib, ~/.xsession, and on and on and on.

Here is the way it should have worked:

apt-get install racer

Anyways, that's the end of the report. The possible solutions for these problems are many, but let me point out that at no point is the solution the following: 'the user is an idiot and should have to learn a bunch of tedious bullshit to make him/her smarter'. Tedious bullshit has nothing to do with intelligence, or how much you know about computers, or how big your unix-weiner is. It is just tedious unnecessary bullshit that could have been prevented in the planning stages of the various products that are involved (x11, xfree86, linux kernel, ld.so, etc etc etc). Note that in many linux circles, such as the irc channels, newsgroups, slashdot, and message boards, I would receive exactly this 'the users need to learn every detail of unix' attitude. No, they dont. They shouldnt. And even an expert in Unix would be tearing her/his hair out at all the impossibly mind numbingly boring tedium that you have to go through to get a graphics and sound program to work properly on linux.

It is true that linux users do not buy game products very much. Gamers buy game products. But really, people who use their systems for gaming would have no problem buying a linux version and booting it in linux if linux actually had a snowballs chance in hell of working properly. It would even be totally possible for the game manufacturers to include a sort of 'miniature linux' within their game, so that when you ran windows it would reboot into MSDOS mode and load linux and the game would start up. Or they could bundle vmware, much the same way they used to have to bundle Dos-4gw protected mode extender with DOS games in the late 1980s/early 1990s. Lord knows gamers do not appreciate having to be beholden to microsoft, having to upgrade drivers all the time, or deal with windows foibles. But they do appreciate things like install shield wizard and directX.

The game companies cant really program for linux. Without the fundamentally basic things, namely a stable and correct sound and graphics subsystem, you cannot do anything with games. By stable I mean the API is stable over time, and backwards compatible as much as possible. I also mean that the API has consistent and easy to use functions, like 'set the screen into resolution xyz with abc many colors'. Such a basic thing as that is still a herculean task for a linux graphics programmer, because he/she doesnt know if she is in X, framebuffer, or what. And even with wrapper libs like SDL, you still cant get enough information back from them to tell if the 'mode setting' operation succeeded or if it left your user with a postage stamp size window in the middle of their X display. I also mean that the system does not hangup, become unresponsive for minutes at a time, or require you to 'log in from a different computer over telnet, kill X, and restart X.'. These things are the absolute fundamental basics of a gaming platform without which you really have nothing worth looking at. This is what microsoft has been attempting to do with DirectX for the past several years, all backwards compatible with each other to a large degree. It is what Nintendo and Sega and Sony have been doing since forever with their game consoles. The PS-One is still selling for 100 bucks a pop, and it only has 2MB RAM. Talk about technical inferiority beating the pants off the 'technically superior' platforms. Meanwhile linux has about 5 different graphics libraries and 3 or 4 different sets of sound drivers, let alone sound libraries, and none of them even come close to working as well as DirectX for the purposes of having a stable API that actually has dependable output. Not that DirectX is all that great, I mean it crashes alot and so does Windows, but at least a programmer has a fighting chance that their program will be able to be installed in a few steps, start up in a certain video mode and play some sounds.


Voxel dot net
o Managed Hosting
o VoxCAST Content Delivery
o Raw Infrastructure


my favorite linux zealot excuse for why linux has no games
o linux people are serious, games are for untermensch 3%
o linus torvalds was on crack when he said he was proud doom ran on linux 3%
o games should all be text based, graphics are 'frivolous' 20%
o it is all the video card makers fault because they dont open source anything 10%
o it is all alan cox's fault because OSS sucks. 1%
o It is all users fault, because they are lazy and do not understand the true beauty of typing 150 commands in to get a game to run. 20%
o Linux without games is like a fish without a bicycle (or other stupid mutilated jingoistic catchphrase) 1%
o if you dont like it, go back to windows. 39%

Votes: 84
Results | Other Polls

Related Links
o Slashdot
o Also by turmeric

Display: Sort:
why linux didn't break into the game market | 71 comments (55 topical, 16 editorial, 0 hidden)
Dont forget... (2.25 / 4) (#1)
by Talez on Thu Jan 24, 2002 at 02:54:36 AM EST

* Ultra god damn slow video performance under linux

I don't know what causes this... but trying to play anything under linux resulted it running like it was on my old 386

Si in Googlis non est, ergo non est
Configuration problem (3.00 / 2) (#2)
by sigwinch on Thu Jan 24, 2002 at 03:03:07 AM EST

For whatever reason you weren't using hardware acceleration, which makes it slooooooow. With a fast, well-supported video card and proper configuration it's fast.

I don't want the world, I just want your half.
[ Parent ]

Maybe but... (2.00 / 2) (#3)
by Talez on Thu Jan 24, 2002 at 03:26:35 AM EST

One of the first games I tried out was my fave game at the time, Quake. I dont know whether it was the quality of the port or the library used but the performance was god damn chunky... And this is a game which would run silky smooth in a DOS box...

I tried out a few emulators... SNES9x was the first one and that was like watching paint dry... Waiting for the next FRAME to render started getting on my nerves...

I suppose this only goes to highlight the point that linux still isnt ready for gaming...

Si in Googlis non est, ergo non est
[ Parent ]
Like sigwinch said... (4.00 / 1) (#45)
by danceswithcrows on Thu Jan 24, 2002 at 05:36:17 PM EST

Your X configuration is broken in some way, or your video card is not supported by any accelerated X server (the Kyro II is a semi-popular card that has no accelerated X server as of right now.) If you want your problem with poor video performance solved, post to comp.os.linux.hardware giving your distro name, make+model of video card, and kernel version, and I'll see what I can do to help. Or use http://groups.google.com/advanced_group_search to search on comp.os.linux.* for the make+model of your video card.

snes9x ran fine for me on a K6-2 400 with a POS ATi Mach64 onboard video card. (Well, turning on "doublesize TV mode" made it run too slowly, but...)

To get back on topic, Linux was not initially designed as a gaming platform as some other posters have mentioned. The problem with switching color depth and virtual screen size in X is there needs to be a way to tell X clients, "Hey, the color depth is now 16bpp, update your colormap or else." This would be a new thing, and though newly written applications could use it, old X applications (of which there are N+1) would break in nasty and interesting ways when the color depth changed on the fly.

Similar problems exist with virtual screen size. Sure, the X server could reposition all the client windows so that they all fit on the new virtual screen size, but that smacks of interface fascism, and there are 3 or 4 people around who really like the "virtual screen is always the same size" feature. (I'm assuming this exists because of inertia and reluctance to change rather than an attempt to avoid breaking X clients.)

Oh well. I don't care too much about the latest k3wl 3D games. frotz, xmame, snes9x, and samegnome waste enough of my time.

Matt G (aka Dances With Crows) There is no Darkness in Eternity/But only Light too dim for us to see
[ Parent ]

It IS (somewhat) ready (none / 0) (#56)
by cxvx on Thu Jan 24, 2002 at 11:10:14 PM EST

Funny, so slow for you yet I can play Unreal Tournament, Tactical Ops (an UT mod) and RTCW at a decent speed on a celeron 375 with a Geforce 2 MX.

I also play alot of SNES games on my laptop (PIII 600), wich is slower than the Celeron, due to the fact that I dont have an accelerated card in there.

If your system isn't configured well or you use slow hardware, then it isn't really linux fault is it?

I agree that config isn't always that easy but don't generalise just because you had problems with it.

[ Parent ]
I get /better/ 3D under Linux... (3.00 / 1) (#4)
by pwhysall on Thu Jan 24, 2002 at 03:28:59 AM EST

...at least I do with Quake 3 Arena.

I'm running an aging P3 800 with 256MB and a positively paleolithic 32MB TNT2 Ultra.

I get a nifty 70-80 fps at 800x600x16 in Linux, cf. 60-70fps at the same res and depth on W2K (on the same machine). I'm using the latest NVIDIA drivers on each OS.

Anecdotal, I know, but at least it can be done.
K5 Editors
I'm going to wager that the story keeps getting dumped because it is a steaming pile of badly formatted fool-meme.
[ Parent ]

Solution my ass (3.53 / 13) (#5)
by sigwinch on Thu Jan 24, 2002 at 03:33:09 AM EST

The possible solutions for these problems are many, but let me point out that at no point is the solution the following: 'the user is an idiot and should have to learn a bunch of tedious bullshit to make him/her smarter'. Tedious bullshit has nothing to do with intelligence, or how much you know about computers, or how big your unix-weiner is. It is just tedious unnecessary bullshit that could have been prevented in the planning stages of the various products that are involved (x11, xfree86, linux kernel, ld.so, etc etc etc).
Every one of the packages you are criticizing, as well as the integration between them, was created because a couple of people simply decided to make them happen. The was no 'planning stage' -- it all just sort of evolved to its present state over time.

If the packages do something useful for you, great! If they don't, you're quite welcome to help improve things. Think there should be a standard base of video, sound, and real-time libraries for gaming? Help make one. Want an "instant gamer" package that can be installed by apt-get? The source code is at your fingertips. Don't have the technical skill but you do know how to organize projects and shake money loose from patrons? Help operate and fund an existing project.

Just don't spend too much time whining. A little righteous fury is a good thing in moderation, but at some point you have to either fish or cut bait. I remember the days before GNU and Linux, and the progress since they started is truly breathtaking. Over the past few years progress has even accelerated. It just seems slow -- huge multi-year projects always seem excruitiatingly slow when you're struggling with the intermediate results.

I don't want the world, I just want your half.

Great post! (3.85 / 7) (#17)
by Phil the Canuck on Thu Jan 24, 2002 at 08:47:03 AM EST

It does a beautiful job of summing up the biggest reason why Linux will never slither out of it's niche status. Someone complains that routine tasks (like program installations) are more difficult under Linux, and the helpful solution provided is for them to develop their own packages. Great. With that attitude, you won't even overtake MacOS.


I don't think being an idiot comes with a pension plan though. Unless you're management of course. - hulver
[ Parent ]

In moderation (4.50 / 2) (#21)
by Nerant on Thu Jan 24, 2002 at 11:08:20 AM EST

I believe his view is that one should take pro-active steps to change the situation. The situation at hand, is the whole mess of interdependencies we have on Linux distributions : hopefully, something like the LSB will change this.
From a meta point of view? (no, not kuro5hin meta meta) Bringing this up is considered pro-active.
Maybe if you're not a coder, you could offer your time for writing documentation, or being a tester for any project / code that's helping to change this?
Just an opinion. =)

Be part of the solution
[ Parent ]
I wasn't really speaking for myself (none / 0) (#28)
by Phil the Canuck on Thu Jan 24, 2002 at 12:54:22 PM EST

Depending on the day of the week, I could be dealing with any of four different Linux distros. I'm part of the niche market that "gets" it, that is I like to poke around to make things work. I've also picked up a couple of programming languages along the way, although I hate programming. I suppose I could apply myself and develop my own solutions if that's what I wanted to do.

I'm just getting tired of watching the Linux community pay lip service to broadening its appeal. I like to call it the Slashdot mentality. In one thread someone will be discussing the importance of taking market share from Microsoft. In the next, that same person may be taking the attitude of the originator of this thread.

If Linux is ever to do anything other than hover around the 4% mark on the desktop, then the people responsible for making Linux will have to make it grandma-friendly. I'd love to see Linux take a larger market share, but quite frankly, it doesn't deserve it yet. As long as the community in general subscribes to the "code it yourself" horseshit, it never will.


I don't think being an idiot comes with a pension plan though. Unless you're management of course. - hulver
[ Parent ]

Grandma Friendly (none / 0) (#67)
by S_hane on Fri Jan 25, 2002 at 04:16:46 PM EST

Linux _is_ Grandma friendly, once somebody who knows what they are doing installs and configures it.

In many ways, Linux is more Grandma friendly that windows is, in that it is
(a) free (pensions, anyone?),
(b) a lot easier to lock down (do Grandma's _really_ need to know about ifconfig, less, route, etc. as long as their required programs are sitting there on the desktop ready to run?), and
(c) less likely to crash.

So what if Grandmas can't install it? That's what their l33t h4x0r grandchildren are for.

   -Shane Stephens

[ Parent ]
It's a trade-off (none / 0) (#36)
by sigwinch on Thu Jan 24, 2002 at 02:34:45 PM EST

Microsoft spends the equivalent of about a hundred tonnes of gold per year developing new software. Most free software is written by small groups of people working alone, frequently for no pay. This dichotomy produces fundamental differences in how things work.

If you want to pay through the nose for a big spaghetti mess of interlocked, poorly-conceived software, which looks pretty and mostly works, and you want it right now, Microsoft is your solution. Just be prepared to pay through the nose again next year, and suffer major disruptions of your systems, because their code is such a disaster that they have to basically throw most of it away to add next year's improvements. (That is, when they're not throwing it away to create gratuitous incompatibilities to lock out competitors.)

If you want inexpensive programs that can be separated from each other and rearranged, free software is the answer. If you want prepackaged solutions, you will wait a couple of development cycles longer than for Microsoft, although the final product will tend to be better. The underlying software will tend to be more stable over time, which means the systems you build using it will break less, and interfaces rarely change except for genuine improvements.

Someone complains that routine tasks (like program installations) are more difficult under Linux, and the helpful solution provided is for them to develop their own packages.

Or wait for someone else to do it. I was merely pointing out that if you want it done faster, the only solution is to help.

I don't want the world, I just want your half.
[ Parent ]

you need alot more than 'skills' (none / 0) (#29)
by turmeric on Thu Jan 24, 2002 at 12:54:53 PM EST

its pretty damn hard to write code for X unless you can download several megabytes of CVS code, get it compiled, and running along side your 'real' X. you need a fast connection and a fast machine and alot of time to set it up. but most of all, you need the people running the projects to agree with you about the problems. but i can easily imagine someone putting 100 hours into some X feature to simplify, say, switching bpp modes on the fly, then having the maintainers say 'this doesnt matter, we are more interested in display PDF and transparent qt windows'. the article is an attempt to state a basic fact about why linux didnt break into the game market, so i dont have to see a bunch of people on slashdot or wherver saying 'gee i wonder why linux didnt break into the game market'. its pretty goddamn obvious to me, it lacks the basic technical features needed for gaming. if that is 'whining' then tough shit. as for 'planning', well, actually alot of those projects have 'planning'. you can see by reading the X documentation that there were quite alot of committees and 'smart people' and phds and all that trying to think of what X might be used for and how to accomodate that. same for any other project that has to do with graphics and sound on linux. even linux has planning, whether or not its 'conscious'. ie the virtual file system layer, for example, is well planned and works quite nicely. it did not just 'congeal' one day out of random bits of source code, someone thought about it carefully before implementing it.

[ Parent ]
Features (none / 0) (#53)
by sigwinch on Thu Jan 24, 2002 at 08:38:42 PM EST

the article is an attempt to state a basic fact about why linux didnt break into the game market, so i dont have to see a bunch of people on slashdot or wherver saying 'gee i wonder why linux didnt break into the game market'.

All free software features go through an "it exists and does sort of the right thing but is obviously too crappy be mainstream" phase. That has been true for every important package. Berkeley Unix was once derided as "Berzerkley Unix". Gcc was once a crippled and limited academic project. Linux in 1993 was pretty pathetic. Apache was once a general malaise and dissatisfaction with NCSA httpd; Netscape Navigator, with NCSA Mosaic.

Fast forward a couple of development cycles and the basic programs are starting to get pretty solid, but you still have to download stuff from a million different ftp sites and lose several nights of sleep gluing them all together. It's doable but not pleasant. I propose that Linux gaming support has approximately reached this phase.

Fast forward one more development cycle and the major distributions are shipping the feature in a half-assed state. It sort of works out of the box, but you might want to download and install the latest and greatest yourself.

Fast forward one or two more development cycles and the feature is quite solid and well-supported in all the major distributions. Linux gaming ought to reach this state sometime between late 2003 and early 2005.

its pretty goddamn obvious to me, it lacks the basic technical features needed for gaming.
The technical features are pretty much there: you can play good games under Linux, watch DVDs, make music, etc. What it lacks are 1) integration of the various pieces, and 2) autoconfiguration. I.e., you have to download pieces from lots of different places, and it takes a lot of manual configuration to make them play together nicely.

It does not require exotic skills to help with this. It simply takes a lot of annoying work, esp. on regression testing.

as for 'planning', well, actually alot of those projects have 'planning'. you can see by reading the X documentation that there were quite alot of committees and 'smart people' and phds and all that trying to think of what X might be used for and how to accomodate that.

It has been a while since I studied the history of X, but I seem to remember that it was conceived and initially implemented by a small number of people, and that its success lies more with the portability and extensibility of the protocol, than with master plans and committees.

ie the [Linux] virtual file system layer, for example, is well planned and works quite nicely. it did not just 'congeal' one day out of random bits of source code, someone thought about it carefully before implementing it.

To hear Linus talk, it did "just congeal". The VFS has been ripped out and rewritten several times, and did not reach its current quality because the VFS Committee sat down and developed a master plan for how it should work, and assigned action items to project personnel. Certainly there was thought, but most of its present elegance comes from lessons that were learned the hard way on production systems, and a massive amount of rewriting over many years.

The Linux virtual memory is an even better example of code "congealing". Linus ripped it out and replaced it in the middle of a stable release series because it was having problems. To hear the authors of the ex-VM talk, it's bugginess was due in part to Linus not applying the proper set of patches.

Or take the dynamic module loading of the XFree86 4.x series, written because some vendor decided of their own accord that platform-independent dynamic modules were da bomb. Nobody told them to create it, and there was no Strategic Roadmap with 'dynamic modules' pencilled in for Q2 2000.

In closing I'll reiterate what I said above: you can either wait on the sidelines for your desired feature to reach mainstream quality, or wait a somewhat shorter period of time as an active contributor. Either way, it would be a good idea to learn the dynamics of free software, so that you can predict when something will go mainstream, and not despair needlessly in the meantime.

P.S. I didn't mean to imply you were whiny. It was just the dirty GNU communist inside me noting that there was no patch set attached to your problem report. ;-)

I don't want the world, I just want your half.
[ Parent ]

Write-in candidate on poll (3.00 / 3) (#6)
by sigwinch on Thu Jan 24, 2002 at 03:50:06 AM EST

"Linux without games is like a statue without pigeons."


I don't want the world, I just want your half.

Don't forget the real motive of Linux (1.50 / 4) (#8)
by Masa on Thu Jan 24, 2002 at 04:07:53 AM EST

I agree, that to break its way to desktop market, Linux has to evolve and try to become more user-friendly. Especially with installation and library issues.

But whining about Linux as a bad gaming platform is redundant because Linux wasn't meant to be a gaming platform in the first place! people tend to forget this. Linux is a *nix-like system, not some kind of Windows or gaming console killer. Linux is Linux and originally it was meant to be a light-weight *nix-like workstation OS. I don't remember any *nix-like system which could be used for gaming. And I don't see any reasons why Linux should be any different.

So, for now, the platform for gamers is Windows or some sort of gaming console. Not Linux. Period.

unix was invented to play 'space travel' on a pdp- (3.66 / 3) (#25)
by turmeric on Thu Jan 24, 2002 at 12:39:28 PM EST

Thus, the point of linux IS TO PLAY GAMES. DUH.


" One of the main motivations for Thompson embarking on this project was that he needed a decent operating system to run his game called Space Travel on, so instead of optimizing Space Travel he decided to write a new operating system. He jumped right on it. "

[ Parent ]
Another experience... (4.33 / 9) (#9)
by krogoth on Thu Jan 24, 2002 at 04:12:19 AM EST

I play the Return to Castle Wolfenstein multiplayer test a lot. Installing it was 2 steps (and the first is only included because so many people whine about it):

1) Install the nVidia drivers. I didn't choose the easiest way, so I downloaded 2 SRPMS, rebuilt them, and installed them, then rebooted (I now just restart X when I do this after a kernel upgrade).
2) Install the game. This involved the complex task of running 'sh wolfdemowhateveritscalled.run', selecting two directories (install dir and bin dir) and clicking on a button.

I know it could be better, but if you don't count the driver installation (and really, following instructions is the same whether it's a Linux command line or a Windows Control Panel), this was no harder than Windows, although I did have to remember to make both directories in my home since I wasn't running the installer as root.

Coincidentally, the Linux Wolfenstein demos are packaged with the Loki installer. This is the kind of thing that can be done right now and has been going on for a while. Of course, with Open Source software you don't always get binaries, but a lot do have RPMs at least, and those are very close to what you ask for. Some software is packaged badly, but others show that there is a potential to do this well.

As for configuration of all the requisite hardware, I give the standard answer: Mandrake. It configures a lot of hardware as well as Windows or better (When I completed this computer, my Mandrake 8.0 install had the network card driver built into the default kernel, but I had to go to another computer to download the Windows driver).

I think the real reason Linux Gaming isn't doing as well as it should is the Linux community; a few badly packaged games don't mean there is no hope.
"If you've never removed your pants and climbed into a tree to swear drunkenly at stuck-up rich kids, I highly recommend it."
This is exactly the problem. (4.00 / 8) (#11)
by Inoshiro on Thu Jan 24, 2002 at 04:33:04 AM EST

If XFree86 was able to be more dynamic (different colour depths/resolutions via API or via desktop control applet, PnP USB input devices, etc), we'd reduce the steps there by half. Having a slightly more consistent game API (SDL + OpenGL is nice, but needs to be in the base of ALL distributions -- plus the OpenGL backend needs to be plugable, so the same `front end` works with any backend card [nVidia][wait, isn't that DRI/DRM?]). The autoconfiguration logic is very, very slowly getting there.

The best thing I can think of to do is donate some money with a request for these features to XF86 and other related projects (street performer protocol?). Loki Games come close to this ideal if you install them (Heroes3 had a static binary if your system didn't have the proper base libs), but we need to make it easier for hobbyist programmers to be professional -- we need better installers (think autoconf that's GUI and GPLed/BSD) and a better base (XF86/etc extensions).

[ イノシロ ]
Hardware limitation of the Voodoo 2/3 cards (none / 0) (#18)
by maynard on Thu Jan 24, 2002 at 08:57:55 AM EST

I'm sure you already know this, but running in 16 bbp for rendering 3D is a hardware limitation of the Voodoo series 2 and 3 cards. The author doesn't state what card he's using, but since we know the driver is tdfx.o we can assume it's at least one of the Voodoo cards. Only in the unlikely event he owns a Voodoo 5 would this be untrue. If he owned one of the newer Geforce or Radeon cards he wouldn't have run into this issue.

XFree does suffer from the limitation of being unable to dynamically switch bit depth and virtual resolutions on the fly. This would be nice to fix. But in the grand scheme of things I don't think it's that important compared to getting X Render or Display Ghostscript in widespread use. JMO.


Read The Proxies, a short crime thriller.
[ Parent ]

its important, for games! (none / 0) (#27)
by turmeric on Thu Jan 24, 2002 at 12:46:07 PM EST

if you cant set the video mode and number of colors, you cant play the game. display postscript and render x and whatever else are lovely, but they have been vaporware for what, 10 years?

[ Parent ]
you can (none / 0) (#41)
by damiam on Thu Jan 24, 2002 at 04:03:08 PM EST

You can change the number of colors by restarting X, you just can't do it on the fly. Besides, I just leave my Voodoo3 in 16bpp mode all the time and I never notice a problem. Very few people can tell the difference between 16bpp and 24/32bpp on a normal dekstop system.

[ Parent ]
I know. (none / 0) (#44)
by Inoshiro on Thu Jan 24, 2002 at 04:59:58 PM EST

I had a V2 SLI rig for some time. I still have them somewhere in my room, with my Awe64 Gold and other hardware that was great for the time, but isn't required anymore.

While things like X Render or Display Ghostscript might be nice, they're also crap. Crap in that the base system can't do something Windows can. If we can't do a base thing Windows can, why are we adding other features? I want dynamic res change and Xrenderer (for the fonts, etc). Once those are in and I can play my games whereever whenever, I'll think about Display Ghostscript. Win95 can do this, for crying out load!

[ イノシロ ]
[ Parent ]
I think you're being too hard on the XFree team (none / 0) (#51)
by maynard on Thu Jan 24, 2002 at 08:29:19 PM EST

I agree that this is something Windows does better than XFree. It would be nice to be able to switch virtual resolutions and color depth on the fly, but obviously X Render and DGS have attracted developers and this is why they're moving forward. (duh) I don't know what to say... given that Loki has just gone tits up it doesn't seem as though Linux gaming has taken off. I'm not following it closely (bought a PS2), but I don't know of any other porting companies.... since Linux PC gamers are going to have to dual boot anyway why is this such an issue?

I dunno. Frankly, I'd rather have DGS. I used to have a NeXT slab on my desk some years ago and going back to those butt ugly bitmapped fonts in X was a real disappointment. I may just have to go buy a Mac I guess... :)


Read The Proxies, a short crime thriller.
[ Parent ]

Not me. (none / 0) (#59)
by Inoshiro on Fri Jan 25, 2002 at 02:40:17 AM EST

I play Linux games. I don't dual boot -- I own a Dreamcast. The next best thing :-D

[ イノシロ ]
[ Parent ]
The solution to your problems is quite simple. (4.00 / 7) (#13)
by Tezcatlipoca on Thu Jan 24, 2002 at 05:27:02 AM EST

Don't use Linux, it is not adequate for your needs.

I think a better title for your article could be in the lines of "why linux has not yet succeeded in the game market". 10 years ago nobody, except Linus Torvalds knew Linux. 5 years ago Linux was a nice toy for geeks that some people found useful as a server. 2 years ago Linux gained mainstream acceptance as an enterprise level solution for many problems in many industries (notice I am not saying all problems). Now Linux is in the brink of being a respectable desktop choice. I think we can expect that in a few years (2,3,4? who knows) Linux will become a serious gaming platform.

Somthing else you should keep in mind is that "Linux" is not looking to become a gaming platform. People like you, that perhaps have the time and skill to do so, are tryiong to make of Linux a viable platform. The best thing is that once it is done it will be for everybody to enjoy, I think the results far outweight the relative pain we have to endure now.

It hurts me far more to fill the pockets of corrupt corps (talking OS here) than to wait for a stable Linux gaming solution or to dribble with 60 steps to install a game.
Those who sleep can't sin.
Those who sin, sleep well.

Problem is (3.25 / 4) (#14)
by Betcour on Thu Jan 24, 2002 at 06:32:03 AM EST

Gaming on a platform is only viable once several requirements are met :
  • The system is easy to setup and use for daily tasks (spreadsheet and word processing, graphic creation, etc.). Installing a Windows or MacOS app is as easy as putting the CD in the drive ; default paths, libraries and desinstallation is automatically handled by the program.
  • There's a standard, fast, full featured and robust game API available. The usual X Windows + OpenGL + SDL is not very standard (too many variations depending of the underlying hardware, API version and drivers), it is not very fast (at least not compared to DirectX+Windows) and it is severely lagging behind DirectX as far as features are concerned (since MS and hardware vendors work hand in hand)

Open Source DirectX thing (2.00 / 2) (#15)
by binarygod on Thu Jan 24, 2002 at 07:19:11 AM EST

We desperately need an equivilent of direct X for linux. Once we have this the gaming world is our oyster!

[ Parent ]
direct x for linux? (1.00 / 1) (#16)
by Delphis on Thu Jan 24, 2002 at 08:43:35 AM EST

What do you think DRI for X is?

[ Parent ]
Direct Rendering Infrastructure (none / 0) (#58)
by lovelace on Fri Jan 25, 2002 at 01:33:16 AM EST

Well, you obviously don't know. DRI is the Direct Rendering Infrastructure, a method of allowing graphics programs to directly access video cards. It is nothing like DirectX. Probably the thing most like DirectX would be SDL, but it still doesn't have everything (i.e. retained mode...).

[ Parent ]
System Instability (3.00 / 4) (#19)
by Cloaked User on Thu Jan 24, 2002 at 09:09:28 AM EST

I also mean that the system does not hangup, become unresponsive for minutes at a time

Now, are you talking about Linux or Windows there? :-)

Seriously though, I have never yet seen an OS that I have not seen crash. That includes Windows3, 3.1, 95 (in a variety of flavours), 98SE, NT 3.5, NT 4, and 2000Pro, a variety of Linuxes from Slackware 3 through to Mandrake 8.1, and a couple of versions of MacOS. In my experience, I've had far more stability problems with Windows than with Linux. Hopefully, Windows 2000 will see this balance restored somewhat (but then, it couldn't be much worse than Win98...)


"What the fuck do you mean 'Are you inspired to come to work'? Of course I'm not 'inspired'. It's a job for God's sake! The money's enough and the work's not so crap that I leave."
Windows XP is rock solid (At least for me) (none / 0) (#43)
by Echo5ive on Thu Jan 24, 2002 at 04:25:47 PM EST

I've only been running XP for about a month, but so far I haven't had even the slightest problem with any game. Windows 2000 used to hang after 5 to 15 minutes when I ran any game using Direct3D, forcing me to dual boot between 2k (work stuff) and 98 (for games) - but no more. No problems at all with XP.

Overall, I'm quite impressed by XP. The only hang so far was due to sucky WLAN drivers from KarlNet (when will they release a driver that doesn't hang the computer when you install them?).

Frozen Skies: mental masturbation.

[ Parent ]
A suggestion... (3.00 / 6) (#20)
by japhar81 on Thu Jan 24, 2002 at 10:09:27 AM EST

And yes, this is something I'll take on myself if there's enough interest. Email kdentdev@hotmail.com to express interest, or better yet, a desire to help.

I've been thinking about this very issue for a while now. I love linux, but I don't use it much for one simple reason, no games. I mean, what am I supposed to do at work?

The beauty of linux is it's not windows, you can access hardware. So here's my idea. I think a gaming toolkit of sorts should be written. Essentially, this would involve several components:
  1. A 'passthrough' graphics driver subsystem

    This means a driver that sits between the hardware and the standard linux drivers, and only does something other than pass messages between the hardware and standard linux drivers when its activated. This means if you activate the passthrough driver, in X or not, you kick in to the mode you want, and do what you want. The subsystem should be stateful, and once the driver is de-activated, everything goes back to where it was.
  2. A 'passthrough' sound driver subsystem

    Same as the graphics subsystem.
  3. A convenient, and maybe even DirectX compatible game development library

    Yeah, DirectX has issues, but guess what, every gaming house on the planet that makes any money now days uses DirectX. And they use C++. Yeah, the source for DirectX is closed, but the APIs arent. Why not just implement the same classes/methods using the above?
  4. A nice, simple to develop and use InstallShield-like app

    Not apt-get, not rpm, not even red carpet does it right. All the dependencies, everything in one big file on a CD. And an app that will run on 99.9% of systems. What does that mean? Testing. That thing we always forget as developers.
  5. Backwards compatibility

    'Nuff said. And its automagic if we emulate DirectX at the API level.
Yes, this is alot of work, but I guarantee you that it would be well worth it. A port of any game to Linux would be a compile away (well, almost). I've worked for a number of gaming houses, and most current games are actually written in very portable C++ with DirectX being the only proprietary library. That's taken care of above. Every game house I've been to has indicated that if the list above is met, they'd seriously consider Linux ports. These people aren't dumb. Give them the tools, they'll give you the games.

As I said, I'll take this beast of a project on, I've been looking for something to do. If you're interested, or want to help, email me.

<H6>Rome is always burning, and the younger generation never respects its elders. The time of your second coming, japhar81, is no exception. -- Aphasia</H6&gt
ahem (5.00 / 1) (#46)
by ish on Thu Jan 24, 2002 at 06:12:03 PM EST

sdl anyone

[ Parent ]

No, no, no... (3.00 / 1) (#55)
by Sunir on Thu Jan 24, 2002 at 09:39:46 PM EST

This is open source. This is free software. You are dampening his freedom to code what he wants, even if it's completely redundant, of low quality, and will soon join the legions of ghost projects on SourceForge. Go back to Hell, you fascist Microsoft bastard.

You may take my sanity, but you can never take my freedom!

"Look! You're free! Go, and be free!" and everyone hated it for that. --r
[ Parent ]

...but still a waste of time (none / 0) (#61)
by mrsbrisby on Fri Jan 25, 2002 at 09:23:04 AM EST

Oh if it were only this straightforward. Firstly, the only way to truly achieve points 1 and 2 is to move that code into the kernel. SDL and ESD(or alsa or whatever) will *seem* to do it, but load your favorate SDL app, push it to full screen and from your serial console (you DO have a serial console, don't you? :D) kill-9 the app. note it doesn't come out of full screen, and if you were really unlucky, it may have grabbed the mouse and keyboard. short run: you're fucked.

point 3 really isn't worth talking about, ESPECIALLY because you aren't a developer, but I'll try: you see, DirectX is an extension of a Win32 API. It shares the same constants, and the same notations, and certainly enough, there are functions that simply cannot be performed in DirectX alone (configuration data, threading, file I/O, mouse and keyboard "grabs" [yes: there is a dxgrab feature, but it doesn't work on most systems; so most dx developers tend to also use the win32 varieties]) -- and once you start adding these features: you have reproduced the WINE project, which after all these years is still incomplete, it would only be in EVERYONE's best interests to stop everything and REDO EVERYTHING that the WINE group has already done.

point 4 is however, fairly close to the money. Until package management improves to the point of a single unified cross-distribution package management system, I don't think it's a good idea. This is the trap that windows fell in (and so many other developers) - that you have to trust other developers to do the RIGHT THING [tm]. and provide a "good way" to uninstall the package without screwing anything else up. Microsoft already sees the error in this and thus has started moving to their "self healing" MSI format (which is neither self, nor healing).

Macintosh folks used to have it much easier - simply drag said APP onto where-ye-wantit, and run. It's I/O api allowed programs to find their resources and data without having to know where "everything" is. Some of the better ones would even copy data into the System Folder when they started.

Personally, I think this is a better way to move. And while I'll have a hard time convincing traditionalists, it COULD happen. But either way we go, eventually we need to specify and solidify (and most importantly USE) a unified package system.

And no, I don't want to turn into a RH/APT/DEB/RPM/MDK/etc flame; if you feel like retorting on these points go away, because you lack the intellegence to understand my points.

finally, "point 5" you label as backwards compatability. this SHOULD be a non-issue -- nobody goes out of their way to make a new version incompatable with an old version simply for the sake of pissing people off. They do it because there's a PROBLEM with the old version. Sometimes (smarter) developers will include a transitional phase to help old-version'd users up. But that's about the end of the stick. You don't want backwards-compatability to the point of 0. take the gets() function call (ok, i don't suppose you can; but pretend! find somebody who writes code semi-regularly and ask them to tell you what that means) ;; gets() is archaic and bugprone. it's the model of what's wrong with early C-library development. But we still have functions that follow it's model (and they're used simply because exploiting them is slightly more difficult) -- this here, THIS HERE is what backwards compatability is about. I would just as soon remove gets() altogether (infact: GCC does somewhat well- it'll give warnings and sometimes errors if you use it! go GCC!)

so to recap: to EVER make backwards compatability a goal is a bad idea, and asking for trouble. If you started with something sane, it should be more work to BREAK backwards compatability -- if you didn't, then you probably SHOULD break it.

[ Parent ]
Hahaha! (1.15 / 13) (#30)
by core10k on Thu Jan 24, 2002 at 12:57:40 PM EST

It's your own damned fault for not reading the instructions. It would only take you 5 minutes to install, excluding putting in all the new sound drivers, making sure you're using the right linked libraries, logging in as root, and compiling your kernel for the l33t new 3d drivers!

Silly Windows loser! You're not smart enough for Linux. Go back to your 'user friendly' operating system, and wait for your blue screen of death. We don't want you.

1.33/6? (none / 0) (#62)
by core10k on Fri Jan 25, 2002 at 09:30:17 AM EST

Guess that means that noone understood the (subtle? maybe...) joke. Which means it worked.


[ Parent ]
j00 n3ed m00re 1337sp3ek ph00!!!> (none / 0) (#66)
by angry android on Fri Jan 25, 2002 at 03:07:53 PM EST

w3 hax0RS Ar3 n3veR subT!e ab0Ut Owr l33tnEs5!!!!!!!!!!!!!!!!

PrAis# Teh lo0rd f00004r LUniX

[ Parent ]
The simplest reason (3.33 / 3) (#33)
by Ken Arromdee on Thu Jan 24, 2002 at 01:56:52 PM EST

And I'm really surprised that nobody has mentioned it yet.

If we're talking about the game market, we mean *commercial* games, not free downloads like racer.

The reason why commercial Linux games haven't taken off is simple: People who run Linux typically can at least dual-boot to Windows. By the time the Linux version of the game is out, the Windows version has been out for months, and is probably on sale too. There's little reason not to just get the Windows version instead.

Mac games can get away with it because you can't dual-boot a Mac into Windows--if you put the game out several months later and at a higher price, Mac owners have to actually wait and pay.

The only way commercial Linux games will ever become successful is if many people have Linux *without* Windows. That's a long way off, if ever.

Good points, one problem. (4.25 / 4) (#38)
by ubernostrum on Thu Jan 24, 2002 at 03:22:28 PM EST

You described this horrendous-sounding, monstrous list of steps to install a game. I can see where that would happen, but I also know that (forgive me, I use RPM-based distros) in my experience, I've rarely had to do more than `rpm -Uvh game.rpm', or, in really nasty cases, the familiar `./configure, make, make install'. Of course, I also take the time to find things that I want in a convenient form, and usually I can find where someone's slapped together an RPM for whatever I'm looking for.

So I guess I see your example of all those steps as being a bit misleading. It's as if I'd written an article about my experience installing Windows 98 and started with

  1. Obtained hard drive and magnetic read/write head.
  2. Manually created FAT32 filesystem using read/write head.
  3. Obtained printouts of binary DOS code.
  4. Installed DOS by etching on drive with read/write head, manually.
  5. Booted to DOS.
  6. Went to another computer and downloaded first set of DLLs.
  7. Copied DLLs to floppy, transferred to DOS system and began creating eventual Windows system.
And so on. You could probably set up Windows that way, but why do that when you can get it on CD? And the same is true with a lot of Linux games, if not Linux software in general. Once you understand your distro's package manager and/or how to compile from source, you're pretty much set. And some stuff is even nicer - you just unpack a tarball and run an install.sh script or something similar.

Of course, that's not true all the time, but there are still probably bits of software on other platforms (even Windows) that are bitchy to install, too.

With that said, I think you have some good points, and I think people who develop for linux/port things to linux have a lot of work to do, but you're definitely using an over-exaggerated example with the installation.

You cooin' with my bird?

you are lucky i didnt have to recompile the kernel (2.00 / 1) (#54)
by turmeric on Thu Jan 24, 2002 at 08:47:44 PM EST

this post woudl have been about 10 pages longer.

[ Parent ]
Yeah, that's hard (none / 0) (#70)
by fader on Thu Jan 31, 2002 at 04:01:00 PM EST

you are lucky i didnt have to recompile the kernel... this post woudl have been about 10 pages longer.

I'll buy that... if you're using 144-point fonts.

You said you're using Debian. I'm using RedHat with apt from freshrpms.net, so you and I should have the same extremely long and complex series of commands to enter:

apt-get install kernel

Whew! That was tough. But lets assume you're so uber-1337 that whining about freeware isn't enough for you... you want to *gasp* compile your own!

  1. cd /usr/src/linux
  2. make bzImage
  3. make modules
  4. make modules_install
  5. arch/i386/boot/install.sh
Admittedly, this isn't something Joe Sixpack will do, but he doesn't need to. I haven't compiled my own kernel in years. Of course, it is written step-by-step in the README file...

If you're gonna FUD about Linux being hard to use, at least choose something accurate to FUD about. Like manually configuring X, or building MPlayer, or convincing your cable modem provider that yes, Linux really is able to 'browse the Internet' or something.

[ Parent ]
In the immortal words of Jimmy Dugan (2.00 / 1) (#42)
by davidduncanscott on Thu Jan 24, 2002 at 04:08:29 PM EST

There's no crying in baseball!

16 bpp is not a retarted mode! (4.50 / 2) (#47)
by mandria on Thu Jan 24, 2002 at 06:30:34 PM EST

>>i had no desire to ruin my wonderful kde setup and put it some retarded 16 bpp mode

16 bpp is not a retarted mode. Actually after 16 bpp the human eye can not really see the difference.
I run my desktop at 16 bpp and I have also tried other modes (24 bpp and 32 bpp ) and I really could not see the difference. So why waste resources of the machine, if the final quality of the picture is not going to look any better?

16 bpp myths (4.50 / 2) (#49)
by mewse on Thu Jan 24, 2002 at 07:05:32 PM EST

The human eye can indeed see the difference between 16 bit and higher bit graphics, and this can be proven easily in your own home. Here's how to do it:

  • 1. Set your desktop to 16-bit colour.
  • 2. Create a tall, thin, 32-bit document in your favourite 2D graphics program (Photoshop, The Gimp, whatever). 20x600 would be a good size.
  • 3. In this document, create a vertical gradient, with blue at the top and black at the bottom.
  • 4. Look at the image.
  • 5. Switch your desktop to 32-bit colour.
  • 6. Look at the image again.

Looks nicer, doesn't it? That's because 16 bit colour is made up of a matrix of colours formed by taking 32 shades of each primary colour[1] and taking every possible combination of those shades. It works great, for most things.. but if you want varying intensities of a primary colour, you've only got 32 of them (including black), which means you'll get lots of banding or dithering in what ought to be smooth gradients.

That said, I run at 16 bit. I prefer the improved performance of only having to transfer half the data to the video card.


[1] Some implementations give 64 shades of green in 16-bit colour, for reasons I won't get into here. :)

[ Parent ]
Greens (none / 0) (#57)
by democritus on Thu Jan 24, 2002 at 11:55:42 PM EST

[1] Some implementations give 64 shades of green in 16-bit colour, for reasons I won't get into here. :)

In case anyone was wondering, it's because the human eye is tuned to see more shades of green then other colors. Something to do with forests and monkeys.

[ Parent ]
Green Monkeys (none / 0) (#69)
by MVpll on Tue Jan 29, 2002 at 07:41:38 AM EST

I'm pretty sure that the visible light from the sun is most intense in the green spectrum, too lazy to go look it up though.

[ Parent ]
Sigh (4.00 / 4) (#48)
by mewse on Thu Jan 24, 2002 at 06:52:27 PM EST

So. Um. Let me check that I have this straight. You download a single game for Linux. A free game which doesn't use any of the various (FREE) installation utilities available for Linux (including GNU's autoconf system for source-based distribution, the ever-present rpms, Debian's debs, Loki's graphical installer, and undoubtedly several more that I'm not aware of). And because this one installation was difficult, you conclude not only that all installations are difficult, but that it's because Linux is incapable of supporting easy installs?

Please download and install a game by Loki Software or from your own Linux distribution, and then post your impressions of the install process. Here's mine (I also use Debian):

  • 1. sudo apt-get install maelstrom

All done! I've now got an arcade game with sound, and I didn't even have to change directories or anything! It even autodetected which libraries I needed upgraded and fetched and installed them automatically! Hey, maybe -- just maybe -- racer has a poor installation procedure. Maybe it's not indicative of a fundamental problem in the design of the Linux, kernel, xfree86, ldd, etc., but just of a poorly designed installation procedure for racer! What a concept!



Funny, Loki just went under (none / 0) (#50)
by Fuzzwah on Thu Jan 24, 2002 at 07:13:06 PM EST

Loki Games is dead. As the original poster stated, linux and games don't mix. There is no market for it.

The best a human can do is to pick a delusion that helps him get through the day. - God's Debris
[ Parent ]

Even more funny. (4.50 / 2) (#63)
by Znork on Fri Jan 25, 2002 at 10:19:55 AM EST

Most consumer application vendors for Windows have gone under. There is no market for applications under windows. (well, actually there is a market, but it's only for one vendor).

Loki survived for a long time, and failed by, from what it sounds like, a rather small margin.

That does not equate with no market. That only means that it's a tough market (and judging by the number of games companies going under there would, by your reasoning, be no games market at all anywhere). The followers will have it easier, because they know there is actually a market, a lot of free tools have been developed from Loki's buisness, and the distributions are getting better, but they'll have to drive even tougher deals for the porting rights.

[ Parent ]
My experience (4.57 / 7) (#52)
by Bob Abooey on Thu Jan 24, 2002 at 08:29:50 PM EST

  • First, your story heading is misleading. This is a story about your problems trying to get some free download game to run on your system.

  • I've bought three games for Linux, Civilization Call to Power, Descent3, MythII Soulblighters. All three of them installed the same way, I ran a script called setup.sh from the CD. Pretty much exactly like you would run a setup.exe from a CD in windows. All three games had nice proffesional graphical installations which let me point and click with my mouse. All three were then simply started up from a command line with simple commands like "descent3". All three games have have run very well and are equal in quality to any Windows game I've ever played.

  • The game companies cant really program for linux.

    I believe this to be patently false.

  • I believe the market for games on Linux is very small and thereofore it would be very difficult for a Linux game company to stay in business, Loki for example, but that is not because they cannot make execellent high quility games, because my experience shows that they can.

    America... just a nation of two hundred million used car salesmen with all the money we need to buy guns and no qualms about ki
  • Blame X (3.00 / 2) (#64)
    by hardburn on Fri Jan 25, 2002 at 10:33:54 AM EST

    I think the most wonderful thing that could ever happen to GNU/Linux is getting rid of X. I was recently created a new signature file for my e-mail (I created a fortune database and called it from my MUA), and I realized later that half the quotes I put in there are flaming X, but only about a quarter of them are flaming Microsoft. I really don't like X.

    So the XFree guys have done as good a job as can be expected in creating an X-based windowing system, but they are working with damaged goods. X shouldn't be hacked into something that sucks less, it should be replaced with something that sucks less.

    A huge chunk of your problems could have been avoided if the game worked under, say DirectFB, among many other alternatives.


    This is what microsoft has been attempting to do with DirectX for the past several years, all backwards compatible with each other to a large degree.

    Have you ever tried using older DirectX games under new DirectX releases? Sometimes it is so buggy to be unplayable. If you're lucky, you'll only have some minor rendering bugs (like artifacts showing up when you first move the mouse on a new menu screen or something). If you're not so lucky, it will be totally unplayable. One example is the first two X-Com games, which were ported from the orginal DOS codebase into DirectX (yeah, that was really dumb, but somebody was stupid enough to do it) and then repackaged into a "collector's edition". Except they were written on an older DirectX API, and I had a newer one. The screen was completly garbled and was totally unplayable. I checked the company's web site and (not surprisingly) there were no bug fixes available for the game. I got the blasted thing running under WINE better than native Windows (WINE didn't do a great job, either, but it was almost playable).

    while($story = K5::Story->new()) { $story->vote(-1) if($story->section() == $POLITICS); }

    Whiney bitch (1.50 / 8) (#65)
    by Canthros on Fri Jan 25, 2002 at 12:35:37 PM EST

    Well, really. Because their game isn't part of your distro, because you had to install a couple of extra things (Oh, no!) you're upset. Gee, what a shame. Honestly, I've no sympathy: Linux is not a gaming platform. It's got games, some of them very good. That doesn't make it a gaming platform: the hardware support is so-so, configuration is still a pain in the butt, etc, etc. And you're not even complaining about a commercial game! You're bitching about some freeware! Freeware, for God's sakes! Get a grip.

    It's now obvious you are either A) Gay or B) Female, or possibly both.
    Reality to earth! (3.00 / 2) (#68)
    by strlen on Sun Jan 27, 2002 at 08:45:00 PM EST

    In reality, if the library is designed to run 16 bbp mode, it is _DESIGNED_ to run in 16 bpp mode. And I for sure wouldn't want apt changing my default bit mode. Yeah it'd be nice if the Debian people made a package racer for you, but they have _OTHER_ things to do. They didn't write the game, they may not even know about it. But they didn't, they can't make a pacakge of every single piece of software there is.

    Oh, and here's what you do:
    # killall -9 kdm
    Press Ctrl-Alt-Backspace
    # startx -- -bpp 16

    You should know how X works, and how to kill gdm and how to change the bitmode before you have the need to change the resolution. Linux isn't designed for your average house wife, Linux is mostly a workstation OS, there's no need for point and click interface for every possible option. Linux is designed to also do many different roles, games aren't the primary goal. Why not just have a windows partition and dual boot if you want to play games?

    In addition, you can also change your XF86Config to run in 16 bpp mode by default (RTFM if you want to know how to do it), then quit kdm/xdm with ctrl-alt-backspace, which will respawn it.

    [T]he strongest man in the world is he who stands most alone. - Henrik Ibsen.
    why linux didn't break into the game market | 71 comments (55 topical, 16 editorial, 0 hidden)
    Display: Sort:


    All trademarks and copyrights on this page are owned by their respective companies. The Rest 2000 - Present Kuro5hin.org Inc.
    See our legalese page for copyright policies. Please also read our Privacy Policy.
    Kuro5hin.org is powered by Free Software, including Apache, Perl, and Linux, The Scoop Engine that runs this site is freely available, under the terms of the GPL.
    Need some help? Email help@kuro5hin.org.
    My heart's the long stairs.

    Powered by Scoop create account | help/FAQ | mission | links | search | IRC | YOU choose the stories!