Announcement

Collapse
No announcement yet.

Updates To Linux As A Gaming Platform

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

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


            • #21
              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.
              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.
              Both of you would look to this 'revolutionary' distro where each program gets its own specific folder

              http://en.wikipedia.org/wiki/GoboLinux

              Apparently it has failed to get interest from the linux community.

              Comment


              • #22
                Originally posted by juanrga View Post
                Both of you would look to this 'revolutionary' distro where each program gets its own specific folder

                http://en.wikipedia.org/wiki/GoboLinux

                Apparently it has failed to get interest from the linux community.
                I started using Linux full time as my main desktop after it got depreciated (I was way too big on my pc gaming in college...), and I don't think the filesystem layout is a critical consideration for me as a user. It is an annoyance as a developer, though. I value pacman / rolling release / the AUR more than I do a more logical fileystem layout (albeit, Gobo has a really good one I think). The /Depot doesn't make much sense to me, though - have VFS top level subdirectories depending on context would be great, like in plan9, but I'm not sure Linux has generic virtual directories that can support that behavior, so I'd rather see all a users "stuff" in the users filesystem under their username. I'd also rather see a replication of user owned files of the same types as those under /System under the users home directory. Better yet, I'd rather see traditional /bin /lib etc for the system under /Users/root/Lib, /Users/root/bin, etc, since system files and root-owned files blur here.

                Another way to think about it is / is the root home folder, and Users/<name> is the users "root". Maybe not even have a /root or Users/root at all? Same way Ubuntu doesn't come with a literal root user account, just sudo permissions and the root group.
                Last edited by zanny; 07-15-2013, 07:54 PM.

                Comment


                • #23
                  Originally posted by plonoma View Post
                  The %appdata% has a subfolder structure with the application name in it.
                  Duh... just like .config and .local/share

                  Comment


                  • #24
                    Originally posted by Cyber Killer View Post
                    Duh... just like .config and .local/share
                    And /opt, and /usr/local, and /usr/share, and ~/.<appname>.

                    Also, I like how the name for the "application state" is local/share. Because share used to mean network shared resources, and local meant system local files per box, and both names lost all meaning and mutated, and then we threw a dotfile in the home directory to just make even less sense. Wtb ~/Data and ~/Config (without being hidden).

                    Comment

                    Working...
                    X