Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Originally posted by mugginz View Post
    Rubbish. It's 2010. Linux needs to support both.
    Sure, but I'm going to support *games* first.

    Comment


    • Originally posted by darkphoenix22 View Post
      Sure, but I'm going to support *games* first.
      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?

      Comment


      • Originally posted by darkphoenix22 View Post
        I agree with this. However, I would to see an analysis of how much work either of your presented options will take.

        Right now, I think etiher of your presented opinions weel take much more works then just improving OSSv4. I also question whether either path will have the ability to maintain ABI stabily with the current implementations of ALSA. Most applications are already compatible with OSSv4 via the OSSv3 fallbacks.
        Alsa is not too bad in this way and PA already supports backwards compatibility about as well as your ever going to see it.

        Applications use alsa-lib so you can change that to do whatever you want as long as you maintain the API/ABIs.

        Plus Alsa has that nice feature were you use plugins and it's all configurable from user interface.

        Like, I am sure everybody is familar with 'Dmix' plugin. It's a little plugin that creates a simplistic (and crappy sounding) software mixer in userspace that sits between the application and the hardware.

        Well "pulse" plugin is all you need for backwards compatibility, generally.

        Technically it's possible to run alsa-lib on other systems, too... like OSS and Win32 (not that anybody gives a crap)

        Of course using the alsa pulse plugin prevents applications from taking full advantage of features that PA introduces.

        OSS, in comparison, is a much bigger headache.

        It has that really crappy design were applications can read/write directly to character devices. (The POSIX-style "read/write one character at a time" API is a really bad match for what you need for proper audio support)

        The best way to achieve compatibility with that is through the CUSE+PA approach.

        Ever use FUSE file systems like GVFS-fuse, sshfs, or ntfs3g (fuse version)? Similar in concept, but for character devices.

        That way you can get OSS compatibility without all the hacks.

        Comment


        • Originally posted by Svartalf View Post
          Careful there. Ubuntu LTS isn't the whole sum of Linux. You've just tripped yourself up if you're trying to provide a commercial game or similar. No, you're not going to be able to support every system- but your thinking you're espousing isn't the answer either.
          I just meant it as "support the most popular desktop Linux and don't worry too much about niche distros". For instance, I would never attempt to support every possible Arch or Gentoo install. That would be a nightmare. Supporting the one or two most popular desktop distros gives you most of the user base and a stable (as in, not endlessly configurable) system to support.

          Originally posted by Svartalf View Post
          More to the point I'm getting to here, the BULK of the potential userspace aren't hardcore tech geeks. They just want to have it drop in and work. Heck, I don't have the time to tinker around like you're implying or to wait for someone else to do it for me- it'd better mostly work out of box.
          From all the Linux users I know, not one of us expects things to just work out of the box. We sure wish they did, but we don't expect them to. I do see what you're saying with the lack of time, though. Even if we know there's a good chance we'll have to fiddle around, it's still not good user experience to have to investigate or wait around for somebody to fix whatever problem prevents us from playing. I'm just arguing that it's not a significantly worse user experience than what most Linux users have already. Though, I must admit, a lot of stuff does work out of the box. I am still amazed by it .

          Originally posted by Svartalf View Post
          And with PulseAudio, it DOESN'T. Raw ALSA or OSS often does better with things than PA does- now the claims of poor implementation and execution on the part of the distributions (Ubuntu, by the by, was one of the guilty parties there...) may be legit, but it implies there's some complexity we don't need.

          AND it does inject latencies in the mix that aren't there with the lowe level stuff. Seriously. You're adding a dispatch layer on TOP of everything else to support per-application level mixing of sounds and network redirection. It's going to add latency in there that isn't there with the raw, low-level stuff.
          I feel really dirty trying to defend PulseAudio. I specifically run kubuntu, because it left PA out of the default install. After 10.04 however, there was no way to have kubuntu without it and I didn't feel like changing distros. Fortunately it now works for me, doesn't introduce latency that I can hear and doesn't take 20% CPU just idling. I wish somebody would sit down and measure the audio latency with current PA. I don't notice any latency when playing Quake Live or StarCraft, though; and I'm running StarCraft in VirtualBox.

          Also, PA doesn't sit on top of everything else. It talks directly to the ALSA hardware device, meaning no buffering, no resampling, no mixing, just access to the hardware through a single API. If you don't run PA and open the ALSA default device, that gives you a plugin stack which does user-space mixing (dmix) and resampling and introduces latency. Opening the hw device yourself isn't an option, because most of them don't support mixing, so you'll be blocked out. If I remember correctly, Windows also does userspace mixing and per-app volume control and Microsoft care about games. If it was impossible to implement sanely, they wouldn't have done it. I do remember Creative being very pissed about it, but it doesn't seem anybody really cared.

          Comment


          • Here is the osspd stuff. This program works with Linux kernel's CUSE support to create /dev/dsp and other character devices needed for OSS compatibility.

            http://userweb.kernel.org/~tj/ossp/

            This should allow proper OSS compatibility in Linux and PulseAudio without all the ld_preload hacks and that sort of thing.

            You need to have CUSE support in your kernel (I think it made it in with 2.6.31) and you need to have a version of Fuse libraries that support CUSE (which I do not have, unfortunately).

            Comment


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

              Comment


              • Originally posted by mugginz View Post
                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.

                Comment


                • Originally posted by chaperon View Post
                  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.

                  Comment


                  • Originally posted by darkphoenix22 View Post
                    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.

                    Comment


                    • Originally posted by chaperon View Post
                      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.

                      Comment


                      • Originally posted by Yfrwlf View Post
                        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.

                        Comment


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

                          Comment


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

                            Comment


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

                              Comment


                              • Originally posted by chaperon View Post
                                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.

                                Comment

                                Working...
                                X