ssokolow: ScummVM isn't "emulated". It's a from-scratch rewrite of various game engines (originally just LucasArts SCUMM) for modern platforms.
[...]
Porkepix: My mistake. I thought it was some ugly trick with an emulator layer as CIDER is for example to run Windows-only games on OS X.
Fair enough. Given how unique ScummVM is, being a collection of
34 different game engines (with many more in development) sharing a common UI and OS interface layer, supporting
nearly 200 games, I can easily see how you'd mistake it for an emulator or binary translation layer.
The only other place I can think of where something similar happened is
Gargoyle whic combines 11 different interactive fiction (text adventure) runtimes into one program and it's nowhere
near as well-known as ScummVM, even relative to the community it serves.
shaddim: Following your argumentation that reimplementing a API/ABI is not emulation and the not unusual experience that WINE games run often fine where "native" ports struggle, WINE should be maybe
[url=http://www.codeweavers.com/about/blogs/jwhite/2012/06/05/whining-about-wine]accepted as stable, working and unified gaming solution for the problematic linux ecosystem. As it was also proposed by
John Carmack.
I
have seen that article and, while I initially had an emotional reaction to it (which means it'll be a hard sell for people less used to stopping to rationally consider things) I have given the idea some thought.
I already accept things like DOSBox as isolation layers and, in some ways, I actually prefer Wine for its ability to control what games are allowed to do. (eg. Disabling desktop integration so games don't clutter up my Documents folder with save files, forcing a virtual desktop so I can work around a game's broken idea of what fullscreening should imply on a multi-monitor desktop, getting working audio in something that was tested against PulseAudio but not bare ALSA+dmix, getting sane resolutions out of a game that, natively, only lets me select windowed resolutions that match what's allowed for fullscreen resolution changing, etc.)
Given GOG's comment that games modernized using DOSBox or ScummVM result in the fewest support requests on Windows, I'd say that the concept of using an emulator or API/ABI shim as an isolation layer between the game that never changes and the platform which changes rapidly can definitely work.
The problem is really one of getting Wine to the degree of stability DOSBox and ScummVM show, given that they're trying to implement a much
much larger ABI and one that, unlike DOS and SCUMM, continues to grow and change.
My #1 rule for acceptable isolation layers is that I have to be able to run all of my games on the same build, which also has to be the newest (or, if they react promptly to regression reports, the second-newest), so I can feel safe in the knowledge that they actually
are serving their role as an isolation layer. (With Wine, most of my games are on 1.6.x as provided by the official stable-release PPA but some have to run in 1.2.x because of regressions I just noticed or in 1.7.x because they depend on freshly-implemented Direct3D functionality... or require non-redistributable Microsoft libraries like XNA 4.0 or quartz.dll or XAudio2 to be installed to make the game work.)
I don't want to end up stuck doing my own patching and compiling to keep some ancient pre-regression Wine versions working on my system while I wait for the developers to mature "the proper implementation" to the point where my game accepts it as much as "the old, cheap hack".
Wine just isn't mature enough yet for me to accept it as an official solution rather than a DIY-only one and that's a bit of a chicken-and-egg problem in the near future since, without more acceptance, it'll be harder to up the rate at which it matures.
Also, I know it's unfair, but one of the reasons I like Humble Bundles is that, if I have both the native Linux port and a Windows version running in Wine, I have twice as many chances to make the game playable by fiddling around with things. If it's just running in a QA'ed build of Wine and that breaks, there's less chance I'll be able to get the bare Windows installer to work in another copy of Wine. (One of the reasons I'm hoping that, 10 years from now,
darling will still be around and will have grown complete enough to run OSX ports on Linux. That would give me
three chances to get a game working acceptably.)
I take that view mainly because of compromises I make elsewhere. Basically, aside from a few tiny exceptions (nVidia Binary Drivers, Flash, and Skype) which I hope to be able to replace in the near future (Nouveau, Shumway, WebRTC), games are the only closed-source software I allow on my system.
I don't intend to hold games to the same open-sourceness policy I use elsewhere because I understand that I'm dealing with a tortoise-and-hare situation. Open-source is great for stuff where slow-and-steady improvement over a decade or more wins the race (kernels, office suites, browsers, game engines for genres where technology has matured and stabilized and innovation has moved into storytelling, etc.) but proprietary development wins when you're competing by being on the cutting edge as it continues to flee from you. That market makes games more of a "throwaway software" model where there's no time to slow-and-steady your way to a workable game engine.
However, since closed-source software isn't open to myself and the rest of the world to debug and patch in perpetuity the way I've grown used to with open-source code, I consider it effectively unmaintained, unsupported, and frozen. As such, I hold my games to a higher standard elsewhere to compensate... hence desiring both a Windows version and a native Linux port so I have twice as many chances to get the thing working 5/10/15/etc. years down the road without having to dig out an old PC and find an old OS install CD because the VirtualBox 3D guest drivers no longer support kernels that old.
