Linux is not ready for Steam

[chaperon]

Being in the video game industry for years as a developer, I just see a problem in your PA/OSS/ALSA/OpenAL/... flame war (no offense meant, it is rather constructive).

The video game industry has a few de-facto standard libraries which cannot be easily replaced because many 3rd party or confidential game engines use them. OpenAL is fortunately one of them, but the most widely used is fmod. So the only goal is to make these libraries work out-of-the-box, which is not the case for me (PA takes 30% CPU and has latency and device switching problems which may be ubuntu-specific problems, OpenAL still gives me mono sound for bg music on my Audigy, and i have no game that uses fmod to test).

For OpenGL, drivers are not 100% correct, but I doubt the situation is much better under Windows. Per-card and sometimes per-serial-number quirks must be introduced in games to workaround buggy drivers and cards.
Of course, the "best" way to go (from a game company point of view) would be DirectX 11, to have a common code base for all "next-gen" platforms (Yes, the PS3 can somewhat do DirectX, which explains some of the poor XBOX=>PS3 ports). I have high hopes in Gallium3D, but it is going to take so long to be fully operational ...

Multithreading is always redeveloped from scratch for each platform, and pthreads pretty much matches the Win32 API in that respect.

SDL input and window management is good enough for most games but is lacking proper relative mouse mode and gamepad hotplug. Again, this is not much code in an engine and could be ported easily.

Steam could solve the highest priority problem, which is development environment and binary packaging/compatibility. Again, the standard is Visual Studio 2008 and its ugly build system, but it's what everybody use out there (with a load of hacks to circumvent its limitations and bugs). Also, external library dependencies is a nightmare for unpackaged linux binaries.

[darkphoenix22]

But your solution is to first remove support for bluetooth and then at some stage in the future re-instate it with patches to ALSA.

What's wrong with patching Pulse or middleware such as SDL, OpenAL, etc and leaving support for bluetooth there for those who need it?

I'm not sure if Pulse can be patched given the fact tthat only half the games/progams I tested worked with it (especially the ports). A heavy wrapper on top of a heavy, complicated base sound API is not a solution.

[darkphoenix22]

Steam could solve the highest priority problem, which is development environment and binary packaging/compatibility. Again, the standard is Visual Studio 2008 and its ugly build system, but it's what everybody use out there (with a load of hacks to circumvent its limitations and bugs). Also, external library dependencies is a nightmare for unpackaged linux binaries.

Package management is definitely your friend for this. Especially on Ubuntu/Debian.

[chaperon]

Package management is definitely your friend for this. Especially on Ubuntu/Debian.

Of course ! And it works so well. But it is not a viable solution for games, which cannot be rebuilt for every distro out there (too many of them, too difficult to test). Windows sucks in that domain, but it is a quite stable environment at the binary level, so packaging can rely on "setup.exe". Plus, making a distro package is so difficult : to package a Windows game, we just fire an InstallShield Wizard and that's all, it's a matter of minutes ; to package a Linux game, eh, well, does somebody have a wizard that always works (GUI/curses or very simple config file) and takes less than 5 steps (company/product name, default install location, data/binary/config/saves separation, ...) ?

And locating "data" directory from binary is a pain, because it can be placed anywhere (/usr/games/share/<product>, /usr/share/<product>, /usr/games/<product>, their local variants, ...). Curiously, game saves are more straightforward than Windows' (~/.<product>). I hope Steam settles the problem once and for all.

[Yfrwlf]

Of course ! And it works so well. But it is not a viable solution for games, which cannot be rebuilt for every distro out there (too many of them, too difficult to test). Windows sucks in that domain, but it is a quite stable environment at the binary level, so packaging can rely on "setup.exe". Plus, making a distro package is so difficult : to package a Windows game, we just fire an InstallShield Wizard and that's all, it's a matter of minutes ; to package a Linux game, eh, well, does somebody have a wizard that always works (GUI/curses or very simple config file) and takes less than 5 steps (company/product name, default install location, data/binary/config/saves separation, ...) ?

And locating "data" directory from binary is a pain, because it can be placed anywhere (/usr/games/share/<product>, /usr/share/<product>, /usr/games/<product>, their local variants, ...). Curiously, game saves are more straightforward than Windows' (~/.<product>). I hope Steam settles the problem once and for all.

All this still not being addressed is just mind-blowing to me. Steam, as a platform, can help these issues just because it only has to do so once, but an actual solution is still needed. To not have these addressed is utterly ridiculous.

For example, your problem with locating a data directory issue between different distros: use $OPT or some kind of relative path, then distros can put different types of programs where they want, all you need is a standard definition. Or, simply have a standard method of querying for the installation locations, in a standard config file like $HOME/.game, or if the Linux community really wants to make a centralized place for configuration files similar to the Windows registry, so be it, that could be useful for many reasons. Whatever it takes to solve such a simple communication/standards problem..

I don't know much about how this is all being addressed, but I *thought* PackageKit was going to be a universal way to query for dependencies across platforms, and thus call for libraries to be installed if they are needed. YES, U NEEDZ COMMUNICATS TO HAVE FUNCTONAL COMMUNITIS. Go figure. Linux users complain about wanting a better software ecosystem for Linux, and yet the core things required like communication to make it happen are no where on anyone's radar.

Of course, what is really needed, in order to simplify everything, is a unified packaging system/format like setup.exe that can easily interact with a standardized interface which the fragmented packaging systems can all integrate with, so you can continue using your narrow formats while also being able to install universal standardized Linux formats.

Again, why this isn't a top priority and a much more popular topic to the Linux community which is supposed to care about things like freedom, choice, and ease of use, is totally beyond me.

[chaperon]

Or, simply have a standard method of querying for the installation locations, in a standard config file like $HOME/.game, or if the Linux community really wants to make a centralized place for configuration files similar to the Windows registry, so be it, that could be useful for many reasons. Whatever it takes to solve such a simple communication/standards problem..

To avoid flaming against the Registry idea, I would say that the equivalent of "User Shell Folders" in simple text files would be cool : a /etc/directories with a simple syntax and a per-user override in ~/.directories and sensible defaults in case these files don't exist. We have fstab, passwd, even termcap ... that would make sense.

Another option I did not mention : the /opt directory, but in that case, the binary will not be in the PATH, requiring a wrapper script in /usr/local/bin (that's my current solution). But its "Program Files-like" organization just makes me feel alien.

[curaga]

I'll just add the Qt side.

As you know Phonon's getting pretty much abandoned. Two new APIs, Qt
Multimedia (desktops) and Qt Mobility (tablets, phones, etc).

Multimedia uses direct ALSA, Mobility uses PA. The grounds for these
were that ALSA works better on the desktop, and getting as high a
latency as possible on mobile (via Pulse) improves battery life.

[shakaran]

I think Steam does not matter if it fails, more development, more users. To ensure a successful market, you first have to stumble a few times. If more game makers make their attempts, albeit unsuccessful, to Nvidia and ATI are most interested in improving their drivers.

In addition to the current pace, the MESA project soon overtake ATI implementations. In just one year, development has been brutal (over 600 commits per month) and for most models of ATI, the OpenGL 1.5 is supported. When overcomes the barrier of the OpenGL 2.0 games may begin to have a decent alternative.

[pingufunkybeat]

All supported ATi cards have OpenGL 2 support with free drivers.

Still, the MESA project will not overtake the ATi proprietary implementation anytime soon. Not even close. MESA is still missing large chunks before OpenGL 3 can be supported, and it is also missing decades of app-specific optimisations which will likely never be implemented because they can turn the code into an unmaintainable mess.

The good news is that it doesn't have to. As long as it gives good 3D performance and supports everything a desktop computer needs, most users will be happy.

[darkphoenix22]

To avoid flaming against the Registry idea, I would say that the equivalent of "User Shell Folders" in simple text files would be cool : a /etc/directories with a simple syntax and a per-user override in ~/.directories and sensible defaults in case these files don't exist. We have fstab, passwd, even termcap ... that would make sense.

Another option I did not mention : the /opt directory, but in that case, the binary will not be in the PATH, requiring a wrapper script in /usr/local/bin (that's my current solution). But its "Program Files-like" organization just makes me feel alien.

Game data files could also be stored in /var with permissions to allow every user to edit them if needed.