The Direct3D 10/11 State Tracker Is Still Around

[Sha43Gal]

What are the legal issues surrounding the distribution

[RussianNeuroMancer]

Isn't Open Build Service solve "create package" problem for developers and pubslihers? (It may be installed to their own server to build packages with proprietary software).

[Eduard Munteanu]

Eh, that's fine for a single-user machine, but I think installing in a dedicated "users"-group read/write-able directory would be better...but then you have the problem of a (basically) world writable directory which contains executables which are likely to be executed. The safe solution to that might be to limit read/write/execute access for all code executed from that directory to it's own directory and a shared data (game-saves, scores, etc.) directory. Then the only possible security hole would be shared libraries existing outside of this "sandbox"....

I understand you want to avoid having different installations of the same app, though that may or may not be a problem. The issue with the approach you described is letting unprivileged users install stuff globally. You don't need or want that. You also don't need shared state, as saves and scores naturally belong to ~/.<app_name>.

Instead you can have the sysadmin install the application globally, but you also want that process to involve no 3rd party executable code. I'm thinking the distro could provide a general installation script that simply takes a compressed archive, unpacks it (perhaps registering it with the package manager, or in a self-contained directory), mangles permissions and sets up the paths properly for normal users. This part is distro-specific anyway.

That sort of stuff might or might not exist already, I'm not sure, but one problem I see is convincing the vendors to stop supplying installers and asking you to run them with root privileges (and hoping they don't do anything stupid or downright evil). A simple compressed archive might be enough in many cases, although I imagine the installation script could sandbox an actual installer and move the resulting files where they belong (similar to what Gentoo does).

[Nobu]

I don't really see the issue here. If you're going to distribute a 3rd party closed-source app you might as well make a statically-linked build (to the extent that's possible) that installs somewhere in ~/, and maybe a shortcut or two.

Eh, that's fine for a single-user machine, but I think installing in a dedicated "users"-group read/write-able directory would be better...but then you have the problem of a (basically) world writable directory which contains executables which are likely to be executed. The safe solution to that might be to limit read/write/execute access for all code executed from that directory to it's own directory and a shared data (game-saves, scores, etc.) directory. Then the only possible security hole would be shared libraries existing outside of this "sandbox"....

...but I fall off topic.

[ChrisXY]

They work okay. They're fragile (try installing one of those games three years from now, let's see what happens). They have a much lower chance of working if you move off the main distros.

Like the original doom3 installer or even the return to castle wolfenstein installer? Still work on my 64 bit archlinux.

In the humble bundle installers there was sometimes indeed the problem that there were not all 32 bit libraries there needed for the installer to run, but that's a packaging problem that should be easily avoidable...

** Admittedly, doing things the Linux way and asking the OS to install them would be better, but last I checked MojoSetup/Loki_setup could not do that, and for good reason since not every distro is guaranteed to have every library the game might need, so Linux games take a step backward from even Windows' DLL hell and statically link or "locally bundle" libraries that otherwise have stable ABIs and belong on the system.

On the other hand KISS is not that bad. How often do you install a windows game and then there's still d3dx9_32.dll missing because the oh so sophisticated installer failed to install it?
www.google.com/search?q=%2Bgame+%2B"dll+not+found"+-"wine"
About 2,910,000 results

I get so upset about the Linux installer topic in particular because it's (almost trivially) FIXABLE. It's just the distro engineers having their damn heads lodged so far up their asses that they can lick the lining of their own stomaches. Bunch of political shenanigans, intense NIH syndrome, and fear-induced bullcrap. I'm not even talking about just hitting parity with Windows, but it could be done so much _better_ than Windows if only the distros weren't in the way.

Almost trivially? How?
Take Archlinux. They don't feel like packaging ancient libraries. There's only one version of libjpeg: The recent one. Only one version of libpng, etc.
How would you fix it there?

And why have it installed at all? Simply unpacking and putting a .desktop file somewhere ought to be enaugh...

You're right. That sounds so much easier than clicking an Install icon and having it Just Work all by itself. Why didn't I think of that?

Why should an installer do more?
Doubleclick it,
ask whether the install should be for everybody and say that in this case the root password is needed or just for the user,
pop up a filechooser with /opt/gamename/ or $HOME/games/<gamename> preset, copy that stuff there,
place a .desktop file in /usr/share/applications or somewhere accordingly in the homedirectory and ready.

But I don't see an easy fix for libraries. Is there a system where this is not a mess? You end up either maintaining ancient libraries and everything they depend on forever or at some point you break backwards compatibility...

work around bad UIs

fix obvious bugs

Well, I think I found the problem.

Obligatory XKCD comic:

That in fact is extremely annoying.
Then you do "xset s off" and "xset -dpms" and it doesn't even remember those setting over suspend to ram. *grrr*
But to be fair: All players I have used have successfully disabled that behaviour. Except for flash. But that is obviously not intended to work correctly anyway...

https://bugbase.adobe.com/index.cfm?event=bug&id=3002806

https://bugbase.adobe.com/index.cfm?event=bug&id=2908816

[Eduard Munteanu]

I don't really see the issue here. If you're going to distribute a 3rd party closed-source app you might as well make a statically-linked build (to the extent that's possible) that installs somewhere in ~/, and maybe a shortcut or two. I certainly don't want 3rd party stuff asking for superuser privileges and spreading their stuff all over the filesystem like they do on Windows. Uninstalling should be quite trivial then.

In fact, I regularly go about building and installing FOSS software in a prefix under my home dir, stuff like latest Git versions.

[Drago]

I am 200% with elanthis here. I think users allready have to do this Disctro-natural-selection, and Linux distributions ( at least desktop ones), should reduce to 3-4, with interoperatable package system. I like Ubuntu, but it as I am pedantic, I don't use it. I just don't get why there are so many unnescessary services running (like cups without a printer attached, bluez stack without blue-tooth device, even python is running. For that reason I use Arch, but eventually for the cause I can switch to Ubuntu

PS: I Ubuntu you can download a package file (.deb), and istall it with the installer. It will resolve all needed dependancies.

[elanthis]

There is very little linux specific in its engine, so I really don't understand why other games don't have ports, even unsupported ones.

Well, there's a couple reasons. First, "unsupported" does not mean "free to the publisher." There's still a ton of costs involved in a port, even if it's just things like double checking licensing and liability for posting binaries of a game using third-party paid-for libraries. A lot of engines require a licensing fee per platform the game is released on. Most games still also don't have (maintained) OpenGL renderers, and it takes time to write those. Lastly, few game developers really care; the Linux nerds I run into in the industry are much more of the "omg I just installed Ubuntu its neat talk to me about Linux" and they barely even understand the (rather vast) differences in basic dev tools on Linux compared to Windows.

On a related side note, I know a ton of hardcore bad-ass developer Linux nerds at Microsoft. Opposites attract or something, I guess.

Really? The Loki installer that most of the games of the Humble Indie Bundles use seems to work pretty good.

They work okay. They're fragile (try installing one of those games three years from now, let's see what happens). They have a much lower chance of working if you move off the main distros.

Windows installers can register the app with the system so it's available for uninstallation via the OS's software manager. Windows installers can use Windows snapshotting so failed installs can be rolled back. Windows installers are guaranteed that the base GUI library and other mandatory support libraries for the OS are always available with a standard ABI. Windows installers don't need users to set executable bits to run them. Windows installers can bundle optional system libraries so they get installed if they're not available**. Even little things matter, like how a Windows installer .exe can have an icon embedded in it that the desktop file-manager or browser can show, while the .sh/.bin packed installers on Linux cannot.

** Admittedly, doing things the Linux way and asking the OS to install them would be better, but last I checked MojoSetup/Loki_setup could not do that, and for good reason since not every distro is guaranteed to have every library the game might need, so Linux games take a step backward from even Windows' DLL hell and statically link or "locally bundle" libraries that otherwise have stable ABIs and belong on the system.

The Linux software installation scene is still just totally whacked. My particular favorite is when somebody follows a link to some clearly Linux-friendly FOSS software like the Gimp and then they go to download it for Linux and LOL! they just get a source .tar.gz and what the hell are they supposed to do with that? Nobody in Linux land seems to have realized yet that users find software by links in blog articles or Google or email and visiting the completely OS/distribution-agnostic homepage for said software. Not by opening "Applications -> System Tools -> Software Package Repository Viewer 2.14.3" and then browsing categories like "Application/Desktop/Graphics/Raster" and then wading through options like "gimp-docs", "gimp-libs", "gimp-common", "gimp-tools", "gimp-pulp-fiction", "gimp-desktop", "gimp-scripts", etc.

In the App Store scene, likewise users still aren't browsing around looking for specific apps. Angry Birds is not popular because users are hearing about it and then looking it up on their phone's app store. Angry Birds is popular because bored users open the app store games to see if anything there looks interesting, seeing Angry Birds at the top of the list with 5 stars after 450,000 reviews, and then installing it because it looks fun. Likewise on Steam, relatively few people hear about a game and then go look for it there. Most of the sales come from users opening Steam, seeing the giant banners in the main store page with the "75% off!" pricing and impulse buy. These companies _also_ sell in other channels so that TV advertising works (most TV advertising accounts for sales in brick-and-mortar stores) and Web advertising works (usually by linking directly to a product in an online store like Amazon or some such). Point is that the approach where Fedora is trying to build their own little distro-specific app store silo is not going to do any good at all for companies making games and trying to sell them because they aren't hitting any of the target demographics for app stores and also aren't hitting any of the target demographics for web stores or brick-and-mortar stores. The FOSS software that can ever end up in their silo are not things that people "impulse install." They're not solving the problems of finding and installing desktop software. The Ubuntu Store might work out since it allows proprietary software, and devs might start releasing into that, but then we're stuck in a world where the only distro that can play commercial games is Ubuntu because the other distros didn't want to play ball and build a larger, open, neutral platform to compete.

This is again one of the reasons why classically Flash and now HTML5 and NaCl are so appealing to developers: the app/game literally is a web page so there's no need to ever install anything or find an OS-specific icon to click or anything else. Follow link, app loads, done. On Windows, it's almost that easy for native apps, and is likely just going to get easier come Windows 8 and the new app store. Which I'd expect them to focus on, because the last thing the dominate OS vendor wants is for traditionally native-only apps to move to an OS-neutral platform like the Web.

I get so upset about the Linux installer topic in particular because it's (almost trivially) FIXABLE. It's just the distro engineers having their damn heads lodged so far up their asses that they can lick the lining of their own stomaches. Bunch of political shenanigans, intense NIH syndrome, and fear-induced bullcrap. I'm not even talking about just hitting parity with Windows, but it could be done so much _better_ than Windows if only the distros weren't in the way.

And why have it installed at all? Simply unpacking and putting a .desktop file somewhere ought to be enaugh...

You're right. That sounds so much easier than clicking an Install icon and having it Just Work all by itself. Why didn't I think of that?

I've spent the years using Linux-Fu to install apps and work around bad UIs and fix obvious bugs and make a server OS feel like a cheap desktop OS and generally get things working, and felt proud of myself on how skillful and awesome I was. After 10 years of that crap, eventually you realize you just don't care anymore and just want it to work when you click the icon, because given the choice between screwing around with installers or doing something actually fun, guess which one wins out once the novelty of Linux wears off?

Obligatory XKCD comic:

[curaga]

I suppose the question is, is the DX11 Heaven any faster directly than via Wine or the native binary?

[ChrisXY]

Skyrim:
doesn't even want to use d3d11, maybe it doesn't actually support it ... works with mesa/OpenGL though (looks ok but is really slow)

I wasn't aware Skyrim used DirectX 9, but sure enough, it does, says HardOCP, adding that there's no DX10 or DX11 renderer, which probably sounds as strange to you, in 2011, as it does to me. Long story short, as wonderful as Skyrim's mountains can look crowned with wisps of fog or tufts of clouds, the underlying visual architecture's pretty dated, especially in terms of the way the Creation engine handles shadows. HardOCP also notes the textures tend to be more diffuse or low-res than they might have been had Bethesda designed the game with the PC in mind and not the space-limited Xbox 360 (the entire game fits, remarkably, on just one DVD).

Also, somebody name some Open Source directx games to help this project please!