linux, the very weak system for gaming

[brosis]

Gaming sucks on linux because WHO THE HELL CARES?
Games don't pay the mortgage!

Games are a pointless waste of time. GET A GIRLFRIEND OR GO OUTSIDE.

<sarcasm>

Wanted to game on linux...
Hacked, hacked, hacked...
Became older, wiser, didn't really notice change...
"Fuck that, Linux is a RPG in itself. I am lvl 80 hacker now!"

</sarcasm>

Yeah, thats probably why Linux is not good for gaming. All those games look pale compared to Linux itself xD

[elapsed]

fucktard.

Well done on necroing a 2 year old thread.

[mmstick]

Well done on necroing a 2 year old thread.

Notice that he is the one who started the thread, and he took two years to respond.

[DanLamb]

Gaming sucks on linux because WHO THE HELL CARES?

Most technology enthusiasts like to play and explore technology and aren't always guided by serious, explicit work goals.

Linux will always be limited in general if it can't fix the gaming situation. I think it will. There is no fundamental reason that normal 3D games written in C++ with OpenGL shouldn't run well on desktop Linux.

I am cheering for higher level toolkits: Java and JavaScript both host some games and run perfectly on Linux.

[torsionbar28]

Linux will always be limited in general if it can't fix the gaming situation. I think it will. There is no fundamental reason that normal 3D games written in C++ with OpenGL shouldn't run well on desktop Linux.

Actually, yes there is one very good reason why games don't run well on Linux, and why game developers don't want to spend the time developing for Linux. Two reasons actually, although they're related.

1. Distro lifecycle. Unless you're talking about RHEL, SuSE Enterprise, or Ubuntu LTS, most desktop Linux distros have a lifespan measured in months. Typically ~1 year, sometimes not even that much. And RHEL and SuSE Enterprise are mainly targeted at the server & professional workstation market, so they have almost zero consumer market share.

Writing a commercial app that links against shared libraries which have a ~1 year lifespan is insanity. The game developers end up having to package a complete runtime environment to go along with the game, or they have to re-build and re-distribute the game for every distro version bump. Both are a lot of extra work, coding, logistics, and tech-support, that isn't required on Windows or OSX.

2. Software version differences, and packaging differences. Ubuntu uses kernel x.x.x and libc x.x.x but Fedora uses y.y.y and y.y.y and SuSE uses z.z.z. Either you target a single distro and lose market share, or you spend a large amount of time building and testing against many different constantly changing OS versions. Plus the packaging differences, .deb, .rpm, tarball, etc. These are all headaches that one doesn't have to deal with on Windows or OSX.

[DanLamb]

Actually, yes there is one very good reason why games don't run well on Linux, and why game developers don't want to spend the time developing for Linux. Two reasons actually, although they're related.

1. Distro lifecycle. Unless you're talking about RHEL, SuSE Enterprise, or Ubuntu LTS, most desktop Linux distros have a lifespan measured in months. Typically ~1 year, sometimes not even that much. And RHEL and SuSE Enterprise are mainly targeted at the server & professional workstation market, so they have almost zero consumer market share.

Writing a commercial app that links against shared libraries which have a ~1 year lifespan is insanity. The game developers end up having to package a complete runtime environment to go along with the game, or they have to re-build and re-distribute the game for every distro version bump. Both are a lot of extra work, coding, logistics, and tech-support, that isn't required on Windows or OSX.

2. Software version differences, and packaging differences. Ubuntu uses kernel x.x.x and libc x.x.x but Fedora uses y.y.y and y.y.y and SuSE uses z.z.z. Either you target a single distro and lose market share, or you spend a large amount of time building and testing against many different constantly changing OS versions. Plus the packaging differences, .deb, .rpm, tarball, etc. These are all headaches that one doesn't have to deal with on Windows or OSX.

Wow, I didn't realize how complex that was. Higher level games written to Unity or Java don't have to deal with any of that. For example, I can play Wakfu or Minecraft and they seem to work extremely well. I've only tried on Ubuntu, but I presume they run fine on Fedora or SUSE.

[ChrisXY]

Writing a commercial app that links against shared libraries which have a ~1 year lifespan is insanity. The game developers end up having to package a complete runtime environment to go along with the game, or they have to re-build and re-distribute the game for every distro version bump. Both are a lot of extra work, coding, logistics, and tech-support, that isn't required on Windows or OSX.

I think I should be able to write a script that recursively searches for library dependencies with ldd and copies them in the game directory in about 15-20 minutes. Also, -static. Use it.

2. Software version differences, and packaging differences. Ubuntu uses kernel x.x.x and libc x.x.x but Fedora uses y.y.y and y.y.y and SuSE uses z.z.z. Either you target a single distro and lose market share, or you spend a large amount of time building and testing against many different constantly changing OS versions.

Are you telling me your game depends on a specific kernel version? How would you even do that?
What exactly are you doing in your game that won't work on a newer glibc? Seriously, that's not a rhetorical question.

I have a few old game ports here like doom3 or prey. I just started prey again. Last modified date is december 2008. I don't know if the actual port is older. Apparently I deleted the directory in which my key was saved but it started without any problems. Because why wouldn't it?

I'm not really an expert but basically the only times I run into issues are:
* The game packages an ancient libc that doesn't work with mesa drivers. The remedy is usually deleting/renaming the packaged libc because the system's libc will work without issues.
* The game has been created for technology that does not exist in this form anymore, e.g. for the OSS sound system. That is unfortunate but I don't think it should happen for anything created in the last 10 years.
* Not all libraries are shipped. That's the same than on windows, but strangely there nobody complains that it is "too hard" to package required dlls with your program.

Plus the packaging differences, .deb, .rpm, tarball, etc. These are all headaches that one doesn't have to deal with on Windows or OSX.

This "headache" is replaced by the "headache" of using an installer like on Windows. Why making an installer "too hard" for linux, but not for windows and why do most commercial games and independent ports from return to castle wolfenstein to most of the humble bundle games do it if it is such a "headache"?

[torsionbar28]

I think I should be able to write a script that recursively searches for library dependencies with ldd and copies them in the game directory in about 15-20 minutes. Also, -static. Use it.

You're preaching to the choir. None of the major Linux game developers do either of these things. Valve Steam certainly doesn't.

What exactly are you doing in your game that won't work on a newer glibc? Seriously, that's not a rhetorical question.

Nothing. The issue isn't building against an older glibc and running against a newer one. Its the other way round. I'll point at Valve Steam again. Steam requires glibc 2.15, which means it won't work on any currently shipping version of RHEL. RHEL uses glibc 2.12. So my very latest and greatest fully patched up to date RHEL workstation can't run Steam.

If Valve looked across all currently supported distros and built against the lowest common denominator, that would work fine. But they didn't. If they provided a runtime package that included the needed libraries, that would also be fine. But they didn't. If they built Steam staticly, so you don't have to worry about shared libraries, that would be acceptable too. But they didn't.

Maybe this is an education issue? Windows developers being unfamiliar with how the Linux ecosystem works? I don't know. But it's a problem for sure.

This "headache" is replaced by the "headache" of using an installer like on Windows. Why making an installer "too hard" for linux, but not for windows and why do most commercial games and independent ports from return to castle wolfenstein to most of the humble bundle games do it if it is such a "headache"?

Nope. Windows doesn't have a software package manager. Developers are forced to provide their own installer and uninstaller. Some don't even bother with an uninstaller, so there's no clean way to remove the software. It's messy. This is one of the major contributors to the phenomenon known as "windows rot".

Linux and UNIX have these wonderful things called package managers. Use them. Don't re-invent the wheel by creating a Windows-esque "installer". It isn't needed or wanted on Linux. Package manager tracks the file locations, required dependencies, etc. so that end users don't have to.

[Vim_User]

YNope. Windows doesn't have a software package manager. Developers are forced to provide their own installer and uninstaller. Some don't even bother with an uninstaller, so there's no clean way to remove the software. It's messy. This is one of the major contributors to the phenomenon known as "windows rot".

Linux and UNIX have these wonderful things called package managers. Use them. Don't re-invent the wheel by creating a Windows-esque "installer". It isn't needed or wanted on Linux. Package manager tracks the file locations, required dependencies, etc. so that end users don't have to.

http://en.wikipedia.org/wiki/Windows_Installer

[sarmad]

Well done on necroing a 2 year old thread.

Maybe he did that so we can finally tell him to: go get an nVidia card, install Steam, and STFU.