Page 1 of 2 12 LastLast
Results 1 to 10 of 24

Thread: Updates To Linux As A Gaming Platform

Hybrid View

  1. #1
    Join Date
    Jan 2007
    Posts
    14,375

    Default 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. #2
    Join Date
    Mar 2012
    Posts
    16

    Default

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

  3. #3
    Join Date
    Nov 2007
    Posts
    1,024

    Default

    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.

  4. #4
    Join Date
    Jun 2013
    Location
    Gliwice, Poland
    Posts
    15

    Default

    Quote 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.

  5. #5
    Join Date
    Sep 2010
    Posts
    453

    Default

    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.

  6. #6
    Join Date
    Jun 2012
    Location
    Koszalin, Poland
    Posts
    126

    Default

    Quote 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

  7. #7
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,861

    Default

    Quote 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.

  8. #8
    Join Date
    Dec 2012
    Posts
    507

    Default

    Quote 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.

  9. #9
    Join Date
    Mar 2013
    Location
    California
    Posts
    110

    Default

    yes, please bring all of your games to linux.

  10. #10
    Join Date
    Aug 2012
    Location
    Pennsylvania, United States
    Posts
    1,861

    Default

    Quote 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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •