Announcement

Collapse
No announcement yet.

Updates To Linux As A Gaming Platform

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

  • Updates To Linux As A Gaming Platform

    Phoronix: Updates To Linux As A Gaming Platform

    Last month we shared slides from a presentation about Linux as a gaming platform. After that generated much interest, the developer of this presentation has revised his slides...

    http://www.phoronix.com/vr.php?view=MTQxMDY

  • #2
    yes i agree games should be portable and able to use from second or external HDD

    Comment


    • #3
      Hmm, he missed the existence of shared contexts and then says they can be used for threaded rendering (they can only be sanely used for threaded resource management). Not sure what he meant by writing his renderer to be multi-threaded; with shared contexts, you can't actually generate rendering commands and submit them in a proper manner. The closest thing GL has to D3D11's deferred command lists are display lists, but those are both deprecated and not at all what you'd want to use in practice (display lists don't have the correct semantics, they copy vertex data into the list which you'd want to keep in separate buffers). The best you can do is build up buffers in multiple threads then do all the command submission (and validation) on the main thread.

      Comment


      • #4
        Originally posted by tuuker View Post
        yes i agree games should be portable and able to use from second or external HDD
        This isn't a gripe against Linux, its a gripe against Windows too... I really wish all programs assets-- especially games-- just got dumped into their specific folder instead of being spread around /usr/bin /usr/share/games and ~/.local/share

        Like I want to just be able to copy the game's folder and run with it.

        Comment


        • #5
          Originally posted by Ericg View Post
          This isn't a gripe against Linux, its a gripe against Windows too... I really wish all programs assets-- especially games-- just got dumped into their specific folder instead of being spread around /usr/bin /usr/share/games and ~/.local/share

          Like I want to just be able to copy the game's folder and run with it.
          I've always liked the idea of when installing a binary, drop it in its own folder (in Linux-space, it would be $GAMES/$GAMENAME and symlink all the relevant stuff where it needs to go (ie, link /usr/bin/$GAMENAME to $GAMES/$GAMENAME/$GAMENAME.elf, etc.

          One of the biggest hassles with source ports on Linux is that they always throw their files in random places, like .zandronum or /usr/local/games/doom.

          Comment


          • #6
            yes, please bring all of your games to linux.

            Comment


            • #7
              Originally posted by zanny View Post
              I've always liked the idea of when installing a binary, drop it in its own folder (in Linux-space, it would be $GAMES/$GAMENAME and symlink all the relevant stuff where it needs to go (ie, link /usr/bin/$GAMENAME to $GAMES/$GAMENAME/$GAMENAME.elf, etc.

              One of the biggest hassles with source ports on Linux is that they always throw their files in random places, like .zandronum or /usr/local/games/doom.
              I'm also including necessary shared libraries as well, like everything is self contained. For REAL applications, this isnt' as much of an issue-- i'm not expecting to just copy out Photoshop or something and stick it on a USB. But a game? You can ship static libs of any dependency that you can't safely assume will be installed on just about any machine.

              Comment


              • #8
                Originally posted by Ericg View Post
                I'm also including necessary shared libraries as well, like everything is self contained. For REAL applications, this isnt' as much of an issue-- i'm not expecting to just copy out Photoshop or something and stick it on a USB. But a game? You can ship static libs of any dependency that you can't safely assume will be installed on just about any machine.
                The future will hopefully be here soon: https://www.guadec.org/session/sandb...ons-for-gnome/

                Comment


                • #9
                  Originally posted by Ericg View Post
                  I'm also including necessary shared libraries as well, like everything is self contained. For REAL applications, this isnt' as much of an issue-- i'm not expecting to just copy out Photoshop or something and stick it on a USB. But a game? You can ship static libs of any dependency that you can't safely assume will be installed on just about any machine.
                  That's how Mac OS X handles programs. A big folder with everything inside.

                  Comment


                  • #10
                    Originally posted by zanny View Post
                    I've always liked the idea of when installing a binary, drop it in its own folder (in Linux-space, it would be $GAMES/$GAMENAME and symlink all the relevant stuff where it needs to go (ie, link /usr/bin/$GAMENAME to $GAMES/$GAMENAME/$GAMENAME.elf, etc.

                    One of the biggest hassles with source ports on Linux is that they always throw their files in random places, like .zandronum or /usr/local/games/doom.
                    The rational behind the way the LSB works is the GNU business module. By providing a service rather than selling a product, programmers were guaranteeing both their own livelihood as well the quality of their code.
                    In case you haven't noticed, even mediocre FOSS projects will tend to outlive their closed source counterparts. And, their developers tend to survive the current trend of disposing the old horse when it run it's course. This idea also came about at a time when computer systems were taking more and more life critical jobs so the question of liability for an engineer selling bad code also needed addressing.

                    Of course, all of this doesn't mean anything to big game publishers. They want to ship their games and move on. Long term livelihood for programmers? You better start saving your earnings. Liability? It's just games. Besides, for big companies that's what EULAs and lawyers are for.

                    So, long story short, the current layout is there for a very good reason. You might not approve of it. But it's purposeful and isn't a mistake.

                    Comment


                    • #11
                      Yea, I like the FHS way of handling things. It allows much finer control and security. When things are in /usr, it's automatically read-only for everyone but root, which means that you can be confident that the contents won't be changed without the administrator's consent. User-specific configuration goes into /home, which means that each program automatically has unique configuration for each user. ~/.config is the central place where each user can change the configuration by hand. ~/.local/share is where their logs and saved games are kept. And having all libraries in /usr/lib allows for more efficient use of both RAM and SSD/HDD space. It's also extremely nice once you do a fresh install, as even though the base system gets upgraded, you don't lose any configuration or progress in your game. By having each program be self-sufficient, you throw away these advantages for the sake of some situational convenience. So it makes sense to follow the FHS.

                      Why do you need games to be portable, anyway? If you purchase a game, you get to play it on all the computers you own, anyway. Installing it shouldn't be a problem. And if you wish to play it on someone else's computer, well, you're not supposed to do that to begin with. Ask the owner of that computer to install it, instead; have them purchase it if they don't already have a copy. In fact, the FHS makes it much nicer to allow others to play your games on your computer: simply create a new account (or use a guest account), and you can be sure that whoever you allow to play your games won't mess with your configuration, won't delete your saved games, and won't deal any harm to the system in general. Or you could set ~/.config to be read-only or back it up, and then restore it after use, if you wish to keep both save files in one place, but don't want any configuration changes. And that works for all games following the FHS at once.
                      Last edited by GreatEmerald; 07-14-2013, 07:03 PM.

                      Comment


                      • #12
                        Originally posted by jonnor View Post
                        The future will hopefully be here soon: https://www.guadec.org/session/sandb...ons-for-gnome/
                        You should check out this http://www.phoronix.com/scan.php?pag...item&px=OTA1MA

                        Comment


                        • #13
                          Originally posted by GreatEmerald View Post
                          Yea, I like the FHS way of handling things. It allows much finer control and security. When things are in /usr, it's automatically read-only for everyone but root, which means that you can be confident that the contents won't be changed without the administrator's consent. User-specific configuration goes into /home, which means that each program automatically has unique configuration for each user. ~/.config is the central place where each user can change the configuration by hand. ~/.local/share is where their logs and saved games are kept. And having all libraries in /usr/lib allows for more efficient use of both RAM and SSD/HDD space. It's also extremely nice once you do a fresh install, as even though the base system gets upgraded, you don't lose any configuration or progress in your game. By having each program be self-sufficient, you throw away these advantages for the sake of some situational convenience. So it makes sense to follow the FHS.

                          Why do you need games to be portable, anyway? If you purchase a game, you get to play it on all the computers you own, anyway. Installing it shouldn't be a problem. And if you wish to play it on someone else's computer, well, you're not supposed to do that to begin with. Ask the owner of that computer to install it, instead; have them purchase it if they don't already have a copy. In fact, the FHS makes it much nicer to allow others to play your games on your computer: simply create a new account (or use a guest account), and you can be sure that whoever you allow to play your games won't mess with your configuration, won't delete your saved games, and won't deal any harm to the system in general. Or you could set ~/.config to be read-only or back it up, and then restore it after use, if you wish to keep both save files in one place, but don't want any configuration changes. And that works for all games following the FHS at once.
                          I'm not complaining about consistent packages that install as per your distributions package manager, but games don't do that. Even the FOSS game engines require the game data be placed in completely random areas of the file system, as per my example, and they often don't pass around nice .rpms .debs or heavens forbid PKGBUILDS, they give you that custom unix installer that (fortunately) lets you specify where to put game data, but otherwise saves and such end up all over the place.

                          When you get a game from the humble indie bundle, it usually just thorws everything in /opt. Steam has its own copy of sdl in ~.steam/something, and there is no game standard. In practice, you want portable game state, which includes saves, configurations, versoning, etc - so you can backup easily, and quickly deploy, your game state. Likewise, you want to control where game data and binaries go. But in security terms, writing over a game executable isn't that much of a problem (and you probably shouldn't make a .elf writable anyway).

                          Games consistently want to drop everything in one folder, so I'd rather the FHS support that than trying to pigeonhole the shared applications behavior on game developers.

                          It is also annoying how game saves end up in hidden folders a lot of the time, but because ~ isn't really well thought out for this use case, you end up either polluting ~ even worse. The best scenario would be to agree on ~/State or ~/Save being the user-based save directory for game state, and you write into a subfolder like ~/Save/doom or ~/Save/hl2, but nothing is really followed conventions wise across Linux gaming.

                          Comment


                          • #14
                            I would hope he has also contacted the SDL devs about updating the doco and has not just left it at updating his slides.

                            Comment


                            • #15
                              Originally posted by amehaye View Post
                              That's how Mac OS X handles programs. A big folder with everything inside.
                              I guess Ubuntu click-packages will do the same.

                              Comment

                              Working...
                              X