I've played games on Wine for a long time, I think since Baldur's Gate was new. You could see the same hate back then, every posting about wine on gaming sites had comments about how wine is killing Linux gaming.

I hope you asked them "What Linux gaming?". ;-p

OSS is dead. At least as far as Linux is concerned. Plus its API is supported by others via wrappers.

ALSA is a Linux kernel component, just use it. It'll work with PulseAudio just as well. You can use PulseAudio directly if you don't mind some screaming in the background.

Aureal – what?

raw – err?

XWindows – do you mean X.org API? Nobody sane is using it directly, especially for games. It's going to be dead after Wayland arrives anyway.

Curses is a library for terminal text interfaces, you don't need that in games unless you decided to make another text-only rogue-like *cough*

Console output is… it just works, I'm not sure what's the problem here. Why should you even care about it in a game again?

SDL – yep, you might want it.

http://wiki.winehq.org/WineOnWindows

There was a handful of games those days with native ports. The selection wasn't great, but it existed and people were concerned - and rightly so - that it would die out instead of take off. I still have a few big boxes.. Heroes of Might and Magic III, Heavy Gear II, Descent 3 .. even a tin box edition of Quake 3. Not sure if any boxed editions still came out after Loki went under, but there were some that you would buy the windows version for and then download a Linux installer from the publishers web site. It would contain the Linux binaries and pull the rest of the resources from the CD's. On my shelf at least Neverwinter Nights and Unreal Tournament are like this.

I think the objections against wine were also partially fueled by a mistaken impression of what it was and wasn't, as well as a general perception that native ports would necessarily be simply better in all respects than something that is merely fitted in with suitable glue, no matter how nicely it stuck on.

This is not always the case. Getting the native HoMM 3 running today might not be a trivial undertaking. It could involve hunting down or compiling some really old libraries first, along with their dependencies, and this would be old code that might not like new compilers. In addition the kernel sound interface of yesteryear is not widely provided by todays systems anymore, and could pose an additional problem. After clearing these hurdles one would still have to concede that the games videos are re-encoded to crappy MPEG-2, there is no network play with windows clients, and there are no expansions at all. At least in this particular case it's better to just run the Windows version on wine instead. No hassles and no problems, basically.

Another point of view that was as close to my heart then as it is now; even if native games on Linux really take off, what about all the Good Old Games that will never be ported? Surely they must not remain forever unplayable on other systems. I always liked Wine.

Well I knew there was effort to make Wine for Windows years ago but it was apparently abandoned. As the article you linked states, many Wine DLLs can be cross-compiled with MinGW already, but Wine itself doesn't work yet. And have any actual work been done to bring Wine to Windows like past half decate? Is there new up to date repository I can check progress on?

What GOG does with wine wrapped games is stupendous. Planescape is a fine example: it runs perfectly, no hassle at all. I've never played the original on windows back then and I could progress a lot on the linux version with zero issues.
Just wanna see my linux backlog grow! Yep, yep, native ports are better, but doing what gog did for the original Baldur's Gate series, Planescape and Flatout 1 & 2 for those "ah, the memories" games would be great :P

There are lots of mac wine games that could, I suppose, be on linux too.

OSS isn't dead.
The current OSSv4 is a different beast than the old one but it's still OSS.
www.opensound.com

Sound quality wise it's excellent.

I know. But for all intents and purposes in Linux it might as well be dead.

What you say above is both true... and not quite so true... :) On the surface if a developer directly codes to the lowest level API, then yes there are a lot of them and it can be a real massive headache to support them all across a multitude of distributions and architectures (32/64 etc.) However, *many* developers may actually be looking at Linux "the hard way" and not capitalizing on the great cross platform wrapper interfaces that are available. Valve has given presentations and whitepapers on how to do this in Linux to make cross platform gaming much much simpler than coding directly to OS specific APIs on any given OS (including Windows). The very very short version is that game developers should be using SDL or similar, OpenGL, OpenAL, and/or other cross platform solutions wherever possible, then they end up with their game working on just about every platform that exists with very very little OS specific or arch specific coding needing to be done. If a developer has instead hard coded their game already to use Windows-only APIs then yes, they'll have some porting work to make it work on Linux or Mac or any other OS, but if they port it to SDL/OpenGL/OpenAL or use something like Unity or one of the other game frameworks out there, then non-Windows platforms are not nearly as difficult as some developers might make them out to be.

The problem only really arises when game developers develop their software from the beginning with lack of foresight about cross platform development. In today's massively heterogeneous computing world this is a rather amateur mistake to be making by any development team big or small, much like web developers who create brand new websites without making them responsive design by default.

There are other issues on Linux but things are getting a lot better due to all of the support that is actually happening out there.

Hopefully more game developers will start using cross platform frameworks from the start so this becomes a non-issue going forward though.
Not so much a matter of coding for a particular distribution, but more a matter of building on a platform deemed the "official" one that builds are done on and only providing official technical support for the chosen distributions. Companies generally need to choose a small number of distributions to consider officially supported or otherwise they would end up with dozens of distributions to have to test on and fix obscure corner case issues that pop up. Of course that doesn't mean games etc. wont run on other distros that aren't officially supported, but just lets people set their expectations before putting out money and then being let down if something doesn't work on distribution #4829.

That's somewhat of an oversimplification I've given, but I think most reasonable folk would realize that companies can't test every possible distro/hardware combo out there and put some limits on "official" support, while still making a best effort to fix things that arise on any particular distro if enough details are present to diagnose and resolve an issue without major effort.