Announcement

Collapse
No announcement yet.

Updates To Linux As A Gaming Platform

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

  • #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; 14 July 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


            • #16
              To respond to the bit about source ports throwing data around randomly (I work on ZDoom, ECWolf, and Zandronum): From my point of view the file system standard is actually quite good. Following it correctly can reduce support headache a bit since I don't need to worry about explaing /path/to/where/you/installed/product/x and can instead just give ~/.config/product/x or something like that. But the reasons why things are as they are has already been explained.

              The problem isn't so much with supporting the games themselves (although I can see how DLC could be a minor issue), but for source ports there's no standard for how to handle third party shared data. Especially in the case where that data could potentially be shared across many ports of the same game. This is understandable since the standards were designed with commercial software in mind, which for obvious reasons won't depend on the user installing another company's data. All of the ports I work on allow specifying a custom location in the configuration file, so it's technically up to the user, but in the installation instructions we put the easiest default case (in the same directory with the configuration file).

              Other than that issue almost everything else is covered. The binary and any supporting 1st party data go into a shared directory (Ubuntu specifically requests that /opt/packagename be used), and then a symlink or bash script is installed to launch from $PATH.

              I do agree that home directory clutter necessitating hidden directories is a problem, but that's what ~/.config and ~/.local could have solved. Unfortunately someone decided they should be hidden as well. OS X is the only platform I'm aware of that got this right (although it still has no real standard for 3rd party data).

              Comment


              • #17
                Keeping savegames in the game directory doesn't solve anything. We already had that in the last century. Every game had one of the things like
                - a 'save' subdirectory where it kept savegames
                - savegame0.sav, savegame1.sav, etc along other game data
                - a 'profile' subdir for userdata
                - a randomly named file with a savegame that was hard to tell from the others, placed along other game data
                - a milion other solutions

                And I'm not even talking about the problems with file permissions!

                What we have currently is something like a transition era between the old bad and the new good solution. I guess it'll take another 10 years for all games and apps to use the .config and .local/share directories properly (and %appdata% on windows), but we'll get there.

                Comment


                • #18
                  Originally posted by zanny View Post
                  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.
                  Well, that's their problem. The topic of the article and the slides in it is porting Windows games to Linux. And for that you want to follow best practises, which means FHS. The games that currently don't do that are beside the point.

                  True, it's too bad that .config and .local are hidden. Well, .local wouldn't be that much of a problem, as you typically don't need to manually do anything in it, aside from finding the game logs for debugging, but .config is a problem. Same thing with .wine, actually. However, it could be solved in file managers by adding a fast way to get there. For example, in Dolphin:

                  You can add that manually, of course. But it would be nice if it was added automatically.

                  Comment


                  • #19
                    Originally posted by elanthis View Post
                    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.
                    I thought that's an obvious mental shortcut, but yes, I meant threaded resource management, background shader compilation etc. Thanks for being vigilant.

                    Comment


                    • #20
                      Never liked the idea of having the different folders as in the FHS.
                      Like things like Gobolinux filesystem.
                      http://www.gobolinux.org/

                      Liked the idea of having application folder with subdirectories with what is now the topdirectories.
                      Fedora and a few other distribution are already changing their file system structure somewhat away from the classical FHS structure.

                      What we have currently is something like a transition era between the old bad and the new good solution. I guess it'll take another 10 years for all games and apps to use the .config and .local/share directories properly (and %appdata% on windows), but we'll get there.
                      The %appdata% has a subfolder structure with the application name in it.


                      We need a way to structure things better than now, better than the FHS stuff.

                      Comment

                      Working...
                      X