Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

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

  • Originally posted by Remco View Post
    This is already possible. Just launch the app with pasuspender <app>. Then you lose all PA sounds during the game. I'd be fine with that as the solution for games that use legacy audio libraries. Note that the new versions of these libraries do work with PA. So this whole thread is pretty much a non-issue.
    This isn't a proper solution as the sound daemon should not have to be bypassed for applications to work. And like what has been said before, even some newer libraries do work with the PA approach in all cases.

    Anywho, I'm leaving this thread as I have said all that I want to say. After 481 posts and 49 pages probably all that can be said by both sides has been said. It seems like the thread is just becoming trolling (from both sides).

    Good day.

    Comment


    • Gah stupid edit limit:

      This isn't a proper solution as the sound daemon should not have to be suspended (or really even bypassed) for applications to work. And like what has been said before, even some newer libraries do work with the PA approach in all cases.

      Anywho, I'm leaving this thread as I have said all that I want to say. After 482 posts and 49 pages probably all that can be said by both sides has been said. It seems like the thread is just becoming trolling (from both sides).

      Good day.

      Comment


      • LOL I made a repost and didn't even fix the issue:

        This isn't a proper solution as the sound daemon should not have to be suspended (or really even bypassed) for applications to work. And like what has been said before, even some newer libraries do *not* work with the PA approach in all cases.

        Anywho, I'm leaving this thread as I have said all that I want to say. After 483 posts and 49 pages probably all that can be said by both sides has been said. It seems like the thread is just becoming trolling (from both sides).

        Good day.

        Comment


        • Originally posted by Remco View Post
          This is already possible. Just launch the app with pasuspender <app>. Then you lose all PA sounds during the game. I'd be fine with that as the solution for games that use legacy audio libraries. Note that the new versions of these libraries do work with PA. So this whole thread is pretty much a non-issue.
          1. "pasuspend" is not out of the box. PA disabling should be done automatically.

          2. When working with PA, these libraries eat 30% of my core 2 duo, which is too high. It also eats the system bus because of interrupt latency (PA requires twice as much interrupts because of its design). IMHO, PA design is flawed for games, which don't need its features.

          Comment


          • Originally posted by chaperon View Post
            1. "pasuspend" is not out of the box. PA disabling should be done automatically.
            Games don't develop themselves either. The game publisher is responsible for disabling PA.

            Comment


            • Originally posted by Remco View Post
              Games don't develop themselves either. The game publisher is responsible for disabling PA.
              The game publisher uses OpenAL, not PA : disabling PA if needed would be the role of the distro, or OpenAL, or even PA, not the game. That's pretty much my point in most of my posts : game studios don't care about details, they just flag the platform as "unsuitable" if it does not work right. SEGA Saturn died because it was hard to program (among other reasons), Windows 95 rocketed with DirectX 3 because it was easy to package and deploy. All platforms since then somewhat mimic the mid-90's PC, which is seen as ideal because of its flexibility and deployment ease. Gaming industry wants to make money by delivering good games, not by solving technical issues.

              Linux is not considered as a gaming platform because it simply does not work well enough for that task and because of all negative reasons expressed in this thread.

              Comment


              • Games studios do develop games for Linux. The majority of the most successful indie games of this year and the last were launched on Linux. Corporations like EA and Activision do not develop games for Linux because Linux runs contra to their DRM sales oriented plans. The complexity of simplicity of Linux has no baring for them. The openness of the platform does.

                VALVe will indeed support Linux because they are smart enough to know that the more way they can sell their own and other products via Steam the more money is to be made and the stronger the Steam brand gets. I wouldn't be surprised if Steam made it to Android etc eventually too.

                Comment


                • Originally posted by chaperon View Post
                  The game publisher uses OpenAL, not PA : disabling PA if needed would be the role of the distro, or OpenAL, or even PA, not the game. That's pretty much my point in most of my posts : game studios don't care about details, they just flag the platform as "unsuitable" if it does not work right. SEGA Saturn died because it was hard to program (among other reasons), Windows 95 rocketed with DirectX 3 because it was easy to package and deploy. All platforms since then somewhat mimic the mid-90's PC, which is seen as ideal because of its flexibility and deployment ease. Gaming industry wants to make money by delivering good games, not by solving technical issues.

                  Linux is not considered as a gaming platform because it simply does not work well enough for that task and because of all negative reasons expressed in this thread.
                  If game studios die because they have to configure one thing in deployment of their app, then they should not be able to make any money at all. Disabling PA for legacy library versions is not the end of the world at all. Modern OpenAL works fine with PA.

                  Comment


                  • Did anybody removeing the precompiled libopenal.so* and using the shipped version instead in case of problems? In some cases a symlink might be needed.

                    Comment


                    • Shipping such libs with a game is anyways big time bull-crap.

                      Comment


                      • Originally posted by Dragonlord View Post
                        Shipping such libs with a game is anyways big time bull-crap.
                        You try shipping something linked against libpng12 sometime and you might just change that tune just a smidge- Arch Linux users will be complaining at you over it, just for starters. I'd gotten bitten by that one in recent times along with a few other gems like it.

                        Not all libs play nicely the way you'd expect them to, Dragonlord. To normalize things, you DO have to, unfortunately provide select .so's to assure things are there in the versions you expect them to be. You can more safely link against things like libc and similar- but unless you're part of the distribution directly, it can be very problematic to expect everything except the game's binary itself will be provided by the distribution. Missing libs, incompatible libs... It's a quagmire if you don't ship a few select .so's. I'm suspecting OpenAL-Soft gets bundled with the title because it can NOT be presumed it's on a given distribution install unless there's already been a game that needed it having been installed. Trying to get the users to resolve their dependencies is...entertaining... So you, much to most's dismay, do that "bull-crap" thing to ensure availability and compatibility of key libs you can't be assured will be there for you.

                        Comment


                        • Let's rephrase it and say it "should" not be like this. Granted I've seen a bunch of libraries which are coded in an un-godly way. I don't think though that OpenAL for example would be one of them. It's a pure C library interface if I'm not mistaken. Stuff like libpng you can though compile directly into the binary. Less problems than having a bunch of libs trailing behind you no matter where they are located.

                          Comment


                          • This is a closed-sourced problem TBH.

                            Newer libraries may be binary incompatible with the games, so closed source developers are forced to bundle their libraries with their programs.

                            This is problem on WIndows as well, where nearly all major applications statically link their libraries to avoid DLL hell. To mediate this, Microsoft also includes multiple versions of the libraries in the WinSxS folder.

                            The need to run multiple versions of each library to maintain compatibility with applications is the main reason why WIndows and Mac OS X take up so much RAM compared to an install of Linux, where single versions of dynamic libraries installed and updated by package managers are more common place.

                            Comment


                            • Originally posted by Dragonlord View Post
                              Let's rephrase it and say it "should" not be like this. Granted I've seen a bunch of libraries which are coded in an un-godly way. I don't think though that OpenAL for example would be one of them. It's a pure C library interface if I'm not mistaken. Stuff like libpng you can though compile directly into the binary. Less problems than having a bunch of libs trailing behind you no matter where they are located.
                              Let's just say you're going to find that it doesn't always work out the way you envision... OpenAL might be something you'd expect to work right- but...yeah, it's a C lib, with consistent ABI edges, but...

                              If you look at the range of what was shipped until very recently, you'd find that OpenAL SI was shipping until about 1-2 years ago in most distributions. OpenAL SI had developed serious bitrot and was unreliable for game use. So, what do you do? Do you do what you propose here or do you do a ./libs dir that can allow you to have the users remove a selected .so that's been vetted for broad use? If you did what you proposed, you'd have issues down the line as it doesn't play nice.

                              For libpng12, if you linked against the binary, you'd have issues if your code used a wrapper like SDL_image. Linking against it would be a potential liability as it might use differing edges of the libraries it uses.

                              You need to be cautious and think things through there. What you talk to is the ideal- but it'll never quite happen all the time. And it's no different in every environment other than the consoles; where there's this largely constrained world with exacting control on firmware revs, etc.

                              Comment


                              • Originally posted by darkphoenix22 View Post
                                This is a closed-sourced problem TBH.
                                The source model has nothing to do with this; library hell exists with Open Source applications as well. Remember when we changed over from kernel 2.4 to 2.6, and almost simultaneously changed GCC versions as well?

                                Originally posted by darkphoenix22 View Post
                                Newer libraries may be binary incompatible with the games, so closed source developers are forced to bundle their libraries with their programs.
                                Also not specific to games either... any application can become victim of a library upgrade gone wrong. Generally this is why we have minor and major version changes.

                                Library hell exists on Linux really as much as any other system, but distribution maintainers know that throwing every version of a library onto a box to maintain compatibility is really bad practice. Pointing the finger at the closed source apps is wrong and solves nothing.

                                Comment

                                Working...
                                X