[coldtea]

>It's not like every Windows PC has the same screen resolution and hardware, yet it's the biggest gaming platform...

No, but it has excellent binary compatibility, long term game APIs, and stable 3D and audio driver APIs. Which is what matters for desktop gaming, and what Linux does not have.

As for screen resolution and hardware capabilities, those matter on mobile (e.g iOS vs Android), and mostly for applications, not games.

[un1xl0ser]

Linux has good enough binary compatibility. I have seen 32-bit applications built on RHEL 2.1 run on RHEL 5. You need the correct libraries and versions, but that's not a difficult problem to solve. See AppCafe[1] by PC-BSD. You may use it if you use plugins on FreeNAS. Lets say that you need fifteen copies of SDL installed to ensure that you can support ten years of games. This is not a problem for a Unix/Linux system with existing tooling.

Stable 3D depends on the hardware and drivers, but gaming already has hardware requirements for graphics and it's getting much better. As far as OpenGL support, recent posts on HN lead me to believe that we are doing okay.

Audio compatibility? Support ALSA and OSS.

1. http://wiki.pcbsd.org/index.php/AppCafe%C2%AE/9.2

[stock_toaster]

  >  You need the correct libraries and versions, but that's not a difficult problem to solve

Or just ship statically linked binaries. That seems like it would be a good solution for games.

[Mikeb85]

> Or just ship statically linked binaries. That seems like it would be a good solution for games.

Yup. That's what Steam does...

[srd]

Not under linux. It does supply it's own set of .so libs though.

[simcop2387]

That or shipping the versions used is usually the way it goes on windows. Take a look at a lot of the games on steam, and many of them will carry an OpenAL dll with them.

[zurn]

Someone needs to dig up pre-ELF binaries for NetHack and XPilot and we can have a backwards compatiblity race, on latest versions of Ubuntu and Windows. Linux has a better chance now that Windows has dropped 16-bit support :)

[unsignedint]

Even Windows binaries WINE on 64-bit runs 16, 32, and 64-bit applications! :-)

[stormbrew]

Kind of. Turning on 64bit by default has resulted in a lot of problems for me, though. It doesn't do the search paths right, I often have 32bit things failing because they stumble on a 64bit dll while linking (or vice-versa).

[unsignedint]

I don't know if it will solve your particular problem, but I would suggest trying PlayOnLinux. It saved me from having a lot of hassle having different Wine configurations and versions side by side.

[stormbrew]

Yeah, I do use playonlinux for reasons like this, but to me it's a bit of a bandaid to the pace of patch acceptance to the wine project. Don't get me wrong, in spite of that the wine project moves at an amazing pace, but working fixes sit on their bug tracker for months and months before being integrated into the mainline.

But the mixed 32bit/64bit thing is just a fundamentally broken part of wine that got seems to have gotten turned on by default before it was ready. It makes wine look bad.