Announcement

Collapse
No announcement yet.

Linux is not ready for Steam

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

  • Originally posted by shakaran View Post
    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.
    Well I think the video side is more than ready. It's the audio side that needs work.

    Comment


    • Originally posted by chaperon View Post
      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.
      Nothing wrong with that, because you *are* alien. /opt/ is the accepted directory for unmanaged software. You should never mess with /usr/ if you don't use a package manager. /usr/local/ might also be OK, but /opt/ is the canonical answer.

      Comment


      • Originally posted by Remco View Post
        Nothing wrong with that, because you *are* alien. /opt/ is the accepted directory for unmanaged software. You should never mess with /usr/ if you don't use a package manager. /usr/local/ might also be OK, but /opt/ is the canonical answer.

        There are standards developed in Linux for this sort of thing.


        STANDARD PACKAGE FORMAT
        ========================

        Standard package management == RPM. This is from LSB. Everybody supports LSB. Even Debian (and Ubuntu since it's based on Debian) supports the use and installation of RPMs.

        If your using Ubuntu try a 'apt-cache search rpm' sometime.

        But users won't typically like that. Just create a deb file.

        Look at what companies like Opera do.

        They generate rpms and deb file that, on a their website, a user can choose specifically what deb or rpm for their OS they want to use.

        Does Opera provide a new build for each Linux system?

        FUCK NO they don't.

        They provide the same exact binaries for Ubuntu, Fedora, Redhat, Debian, etc etc. I've hashed them. They are the same binary. Only very old versions they provide different binaries and that is because a breakage in the C++ ABI that GCC and other folks introduced a long time ago. (yes C++ sucks balls).


        STANDARDS FOR 3RD PARTY INSTALLS
        ===================================

        /usr/local/ is a mess. Don't use that.
        Don't install into /usr/. That's just stupid because distros consider that their playground and it will piss off your users one way or another and ruin compatibility.

        For installation of software using tools like RPM, but it's outside the package management system you'll want to use '/opt'. That is what it's for... packaged 'alien' software.

        You want to install your software to /opt/$app-name/ and you can use your normal Unix-style directory launcher.

        Soo... say a intellegent approach for Steam would be like this:

        /opt/steam-1.2-56231/

        Put a symbolic link to /opt/steam/

        then you'd have
        /opt/steam/lib/
        /opt/steam/common/
        /opt/steam/bin/
        /opt/steam/sbin/
        /opt/steam/doc/

        Etc. etc.

        That way when people upgrade to a newer version of the application all you have to do is change the symbolic link. Makes it safer as users will never face a situation were upgrading steam breaks everything. They can always go back to a older version with a simple shell command.

        Helps out a lot for support....


        WHAT TO DO ABOUT YOUR EXECUTABLES
        ====================================

        Then to launch your application you will not want to have a binary directly executed. You will need to use a script that will setup the environmental variables so your libraries and other do-dads will get correctly launched.

        See 'man ld'


        WHAT TO DO ABOUT PATH AND MENUS
        ==================================


        Instead of doing something stupid like trying to stick a command in the users $PATH you will need to create various *.desktop files.

        The .desktop files is a standard for letting the system know about your application and how to launch it.

        To a 'locate gedit.desktop' or something like that when your using Ubuntu. The format of the file is very self-explanatory.

        So you can add a few of these .desktop files in a fairly safe way directly to the user's /usr/ directory in the correct location.

        The OS will pick up the presence of the files and then use that to generate new entries in a user's application launcher menus.

        Say for steam you have:

        steam.desktop
        steam-help.desktop
        steam-quicklauncher.desktop

        Here are a few examples on how they get used.

        PROBLEM: Need launcher on user's desktop
        -----------------------------------------

        Copy your 'steam.desktop' to their Desktop directory. It will behave similar to how shortcuts works in Windows.

        USUALLY the desktop directory is going to be ~/Desktop, but it's configurable. Especially for internationalization support it's going to be popular to have that directory be named different things for different languages.

        What you want to do is use this command:

        xdg-user-dir DESKTOP

        That will deal with a user's desktop.

        If xdg-user-dir does not exist then your dealing with a shitastic Linux distro and it's not really worth your time fucking around with because it's broken or a user does not care about compatibility.

        For people like that just use ~/Desktop if it exists and otherwise just stick it in ~/

        They will probably bitch and moan about random problems with *.desktop stuff or they won't understand what your trying to do, but you can safely ignore them.

        xdg-user-dirs are:
        DESKTOP
        DOWNLOAD
        TEMPLATES
        PUBLICSHARE
        DOCUMENTS
        MUSIC
        PICTURES
        VIDEOS


        PROBLEM: Need to provide QuickLaunch-style icon in the systray
        ----------------------------------------------------------------

        So that requires having a program getting launched that starts a systray instance (to do that in KDE and Gnome is a bit different, but it's in the process of being standardized right now)


        To launch applications automatically when the user logs in stick your *.desktop file in $HOME/.config/autostart

        You may have to make that directory.

        So that would mean something like taking a symbolic link from were steam-quicklaunch.desktop is stored and putting it into:

        ~/.config/autostart/steam-quicklaunch.desktop


        All decent desktop session managers will launch that automatically from now on. XFCE, LXDE, Gnome, KDE, for example should all handle that the same.



        PROBLEM: Want to launch browser for HTML readme and links to online FAQs and links to support forums, etc
        --------------------------------------------------------------------


        Do NOT try to run a command like 'firefox'. It will probably work, but it's still a stupid thing to default to.

        What you want to do is use 'xdg-open'

        That will detect the mime-type of the file or decipher the URL and launch the appropriate application for you according to user's preferenecs.

        So something like:

        xdg-open http://www.google.com/

        Will launch the user's preferred web browser.

        xdg-open music.mp3

        will launch their preferred music player

        etc etc.


        If the system does not support the xdg stuff then it's shit. You don't have to care because it's going to be impossible for you to do the right thing. Just launch firefox in that situation.



        HOW TO DEAL WITH USER CONFIGURATION FILES
        ===========================================


        This one is easy.

        So you don't end up with a shitload of different ~/.??* files the standard for configuration files is now:

        ~/.config/$app-name

        Blows your mind, right?

        So you will probably want to use something like

        ~/.config/steam

        That's it. It's your directory; you can do what you want.


        Now if you want to store user specific files....

        Say you want a place for your application to store downloaded content.

        You will want to use
        ~/.local/share/$app-name

        ===============================


        And there is a bunch of other crap like this to.

        It's all very simple and makes a lot of sense, but it's not common knowledge yet, unfortunately.

        Comment


        • Originally posted by drag View Post
          They provide the same exact binaries for Ubuntu, Fedora, Redhat, Debian, etc etc. I've hashed them. They are the same binary. Only very old versions they provide different binaries and that is because a breakage in the C++ ABI that GCC and other folks introduced a long time ago. (yes C++ sucks balls).
          This must be why I couldn't install UT99 some time ago. It claimed that the installer wasn't an executable.

          Instead of doing something stupid like trying to stick a command in the users $PATH you will need to create various *.desktop files.
          I wouldn't say putting the startup script somewhere in your path is a bad idea. *.desktop files don't work in the terminal. A usable terminal is a major advantage of a Linux system.

          Comment


          • I don't see how audio is an issue. Practically all newer and not so newer games resort to software mixing anyway.

            The only capabilities a game needs to have access to is the ability to set an output mode (frequency, bit depth, channels), get the playback position and just stream the audio. Any functionality beyond that is unnecessary. If there's a Source engine for Linux, it would do fine with most distros by using small wrapper libraries that handle either native Alsa or Pulseaudio. I think both implement the needed caps in uncomplicated ways.

            Comment


            • Originally posted by shakaran View Post
              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.
              Except that the norm is now DirectX 10 and companies are looking toward DirectX 11. To be more precise, all AAA titles are tailored for XBox360 hardware, which is between DX10 and DX11. You need at least OpenGL 3.0 to compete with that (Please, do not feed the troll).

              Comment


              • Originally posted by Tomservo View Post
                I don't see how audio is an issue. Practically all newer and not so newer games resort to software mixing anyway.

                The only capabilities a game needs to have access to is the ability to set an output mode (frequency, bit depth, channels), get the playback position and just stream the audio. Any functionality beyond that is unnecessary. If there's a Source engine for Linux, it would do fine with most distros by using small wrapper libraries that handle either native Alsa or Pulseaudio. I think both implement the needed caps in uncomplicated ways.
                It depends on how the application implements sound. If it uses sound for timing, it's toast with PulseAudio due to the higher latency introduced by the wrapper/buffer. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.

                Comment


                • Originally posted by chaperon View Post
                  Except that the norm is now DirectX 10 and companies are looking toward DirectX 11. To be more precise, all AAA titles are tailored for XBox360 hardware, which is between DX10 and DX11. You need at least OpenGL 3.0 to compete with that (Please, do not feed the troll).
                  Luckily, NVIDIA and AMD provide OpenGL 1, 2, 3 and 4 drivers. Games will always support multiple renderers, and the OpenGL 2 renderer won't go away for quite some time. So, for the small percentage of people who don't run the proprietary drivers, the games will still work.

                  Comment


                  • Originally posted by darkphoenix22 View Post
                    It depends on how the application implements sound. If it uses sound for timing, it's toast with PulseAudio due to the higher latency introduced by the wrapper/buffer. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.
                    For games that need direct control over latency: http://www.pulseaudio.org/wiki/LatencyControl

                    Comment


                    • Originally posted by darkphoenix22 View Post
                      It depends on how the application implements sound. If it uses sound for timing, it's toast with PulseAudio due to the higher latency introduced by the wrapper/buffer. Unfortunately, this is the way many games are written. This barrier makes it much harder to port games over to Linux. Almost all the ports I tried in my testing do not work under PulseAudio or, at the very least, required a bit of configuration. These same games/programs work out of the box on Windows.
                      From my experience, the problem lies entirely in PulseAudio's ALSA compatibility layer. It just doesn't tend to play nice with lower latency ALSA applications, even those that stick to the "safe ALSA subset". The same application with a PulseAudio backend, with the same latency settings, will not have issues. For example, the audio problems many users were experiencing in HoN disappeared when the PulseAudio backend was added.

                      Comment


                      • Originally posted by Remco View Post
                        This must be why I couldn't install UT99 some time ago. It claimed that the installer wasn't an executable.
                        There are lots of things that could cause that. For example: It's a shell script or other interpreted language and the person that wrote it hardcoded it to a interpreter that can be moved, instead of using the 'env' command to locate it for them.


                        I wouldn't say putting the startup script somewhere in your path is a bad idea. *.desktop files don't work in the terminal. A usable terminal is a major advantage of a Linux system.
                        You can still use a terminal. The user can just find the executable in /opt/$app-name/bin/ and if they would like they can add it to their path accordingly. A guy used to using a terminal for stuff should not have a problem figuring that out.

                        The thing that sucks about $PATH is that it can be anything. I would avoid trying to write to /bin/ or /usr/bin/ and things like /usr/games/bin is very distro-specific. Symbolic link to /usr/local/bin/ is probably the best place, but even then it's not 100%.

                        Comment


                        • Originally posted by Remco View Post
                          For games that need direct control over latency: http://www.pulseaudio.org/wiki/LatencyControl
                          So I get to control the buffer size...

                          Ya, this isn't a solution. Like Svartalf, as soon as you add a a layer of abstraction via a wrapper, you automatically latency. Especially when using programs and APIs that weren't intended to tolerate a wrapper. You are never going to be able to convince developers to recode their code to tolerate something that wasn't supposed to be there in the first place.

                          The status quo can not be fixed due to architectural problems.

                          The only real solution at this point is to put all or most of the functionality of PulseAudio directly into the ALSA API or simply replacing it with another API like OSSv4. I'm in favour of whatever will be economically cheaper.

                          Comment


                          • Originally posted by Remco View Post
                            Luckily, NVIDIA and AMD provide OpenGL 1, 2, 3 and 4 drivers. Games will always support multiple renderers, and the OpenGL 2 renderer won't go away for quite some time. So, for the small percentage of people who don't run the proprietary drivers, the games will still work.
                            Yeah. No.

                            You have it backwards. The minority of people run proprietary drivers on Linux.

                            In, general, if you combined the amount of people using ATI and Nvidia into one big pool you will not come close to the number of people using integrated Intel graphics.

                            If all the game developers cared about was targeting Linux users on Phoronix running the latest and greatest of everything then they probably would not have to care about MESA-based drivers.

                            But if they actually want to have some sort of market and have the possibility of ever making money or garnering a lot of users... then only caring about proprietary drivers are a no-go.

                            Comment


                            • PROBLEM: Need launcher on user's desktop
                              -----------------------------------------
                              ...
                              PROBLEM: Need to provide QuickLaunch-style icon in the systray
                              ----------------------------------------------------------------
                              Ewww. You're free to have your .config/.local/.$NAME dir, but never ever try to mess with my ~ beyond that. Don't try to put anything to my desktop, my autostart, and especially not to my tray.

                              These unwanted, unasked additions would just irritate people. It's practically malware.

                              Comment


                              • Originally posted by darkphoenix22 View Post
                                So I get to control the buffer size...

                                Ya, this isn't a solution. Like Svartalf, as soon as you add a a layer of abstraction via a wrapper, you automatically latency. Especially when using programs and APIs that weren't intended to tolerate a wrapper.
                                Stop and think about what your talking about.


                                -----------------------------

                                IF all your application library or application targets is OSS then _yes_ you have to deal with a wrapper. There is no real way around this.

                                OSS support in Linux sucks. It is unreliable, undependable, user unfriendly, etc etc.

                                It will NEVER not suck. I don't give a crap if you plan to offer OSSv4 in your hobby Linux version or not. It's not going to make any difference and the chances of OSS ever NOT being crap is about 0.

                                Even with CUSE + PA solution, which I mentioned before, were Linux distributions can implement 100% compatibility with OSS (yes even old Quake4-based games with it's DOS-era mmap sound support) nobody gives a crap enough to implement support in their distributions.

                                I wish they did, but as far as I can tell they don't.

                                Actually trying to use OSS drivers in Linux does nothing but makes the whole system worse.

                                ---------------------------------

                                As far as PA goes...

                                You NEED to implement software mixing in the audio stack.

                                This is NOT optional. If you want a modern OS with any decent hardware support and performance then you are ABSOLUTELY going to have to implement a software mixer.

                                You do NOT have a choice in the matter. It's a bold faced requirement to have a minimally functional audio stack.

                                And it's going to add latency.

                                It does not matter if you do it in the kernel or in dmix or if you do it in PA. The effect is the same. There is no magic latency-reduction that you get by implementing mixing service as a kernel module or as a userspace daemon.

                                Comment

                                Working...
                                X