If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

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.

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.

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.

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.

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.

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.

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.