Slashdot Mirror
GOG.com To Add Linux Support
jones_supa writes "More great news for Linux gamers: following the footsteps of Steam, GOG.com is preparing delivery of Linux games. They expect to start doing so this autumn. The officially supported distributions will be Ubuntu and Mint. Right now, they are performing testing on various configurations, training up their teams on Linux-speak, and generally preparing for the rollout of at least 100 titles — DRM-free, as usual. This will update some of the catalog's existing games with a Linux port and bring new ones to the collection. Further information on specific games is yet not known, but GOG invites fans and customers to their community wishlist for discussion."
The linked announcement was a bit vague on details. Not very hard technologically for them if its only the old dos games which they already distribute with dosbox to run properly even on windows. It would be interesting to see what they can do with the DX based stuff.
This is great news. Gog installers are very easy to use. I've been wanting this for some time.
Cloudiot: A person who does not see offsite storage as a way to lose control over access to his or her own data.
About time too. All their games catalog which runs on DOSBox and ScummVM should be easy enough to port. Other games have portable engines too like GemRB.
GOG is a vendor that sells DRM free games so more power to them.
This should rope in literally a handful of crotchety old nerds. I almost decided not to buy stuff from GOG because they didn't already package for Linux, and I imagined that it would sometimes be a pain in the ass to make the games work even though it should be easy because I've written dosbox configs before, etc. And lo, I was right. The dosbox configs for example have no consistency in the style department, so you actually have to understand them in order to write the new one. That's just a waste of space in my brain that I could be using for something useful, like Firefly trivia. So I wound up only buying the games I really felt I needed, or games which were a buck, because I would then run them in a XP VM. So huzzah, GOG. I am likely to spend more money with you in the future.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
I wonder how hard it will be to play these games on a Steam Machine. The quantity of Linux games available will make a big difference in the success or failure of that project.
PlayOnLinux can already access your GOG account and install many Windows games automatically and run them using WINE.
Here's a good tip for older games that use DOS4GW.EXE: download the GPL'ed binary from http://dos32a.narechk.net/inde... and re-name it DOS4GW.EXE, then substutite it for the original. You'll find a noticable improvement in game performance, even using WINE o DOSBOX.
If your game uses CWSDPMI.EXE , download the latest version of it from http://web.archive.org/web/201...
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
The dosbox configs for example have no consistency in the style department, so you actually have to understand them in order to write the new one.
Rather than just complain, you could contrinute better DOSBOX configs back to the GOG community and encourage GOG to write to a higher standard by example.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
Damn, already spent some mod points here...
...and all these "linuxes" (not the kernel, but all the software around it) are free, and can run beside each other (sometime at the same time using a chroot) if you end up with a combination of things that can't start the games. I did that for steam, when debian didn't have a recent enough version of libc.
Anyway, it's not a shame that they support a specific distro, as there is no such thing as a "generic linux". Different libc versions, different set of patch for the same version of some libraries, different config locations, different way to handle very simple stuff... Although there is some "standardization", mainly for the visible stuff (standard way to add menu in every desktop environment...).
And officially supporting one distribution doesn't mean it won't work almost anywhere. Back when steam started by supporting only Ubuntu, it was relatively painless to launch it on almost anything (as long as it was x86). It just mean that they focus on *support* in a relatively well-known environment.
'How hard can that be?"
Really, really hard. Linux is a mess of mutually incompatible pieces with mutually incompatible dependencies. There have been attempts to create a "common base" that can be used, but very few people seem to use it. Pretty much the only truly safe way I've found to distribute Linux binaries (as opposed to source code, for which there's autoconf and friends) is to statically link all your dependencies and build for as many architectures as you feel like supporting (x86 obviously - probably i586 at best, though and maybe i386 - and likely x64; maybe ARM but probably not). This produces huge binaries with a lot of redundant code compiled in, but it means it works regardless of which libc you use, what version of openssl (or gnutls) you have, and so on.
Distro-specific builds let you use package files which pull in the requisite dependencies. They have smaller install footprints and smaller downloads, and you don't have to push a whole new version every time a dependent package fixes a security bug; you can expect the user's package manager to handle that. You can also massively reduce support costs by assuming that users have a common base of software installed (a full set of standard utilities instead of busybox, a version of python that can execute a given script, etc.)
However, distro-specific builds have their own costs. If you say you support distros X and Y, you have to test on all the common configurations of those distros. The more you add, the more the costs go up. There are over a thousand tracked distros on distrowatch. You have to draw the line somewhere. Ubuntu and Mint are close enough that it's really easy to handle both of them, but it's awkward for those who don't use Debian-derived distros.
For what it's worth, some game companies do take the "support generic Linux" approach. Heroes of Newerth, for example (a DotA clone that predates, and is in some ways better than, DotA 2) has a Linux client that often works... but sometimes it doesn't (I've had real issues with some older Fedora machines), and troubleshooting why can be a real pain.
There's no place I could be, since I've found Serenity...
PEBKAC. DosBox is easy to configure on all platforms.
You say that, but a lot of video output options don't work properly with a lot of games, and which are appropriate for which isn't immediately apparent. I could dick around with it, but the whole point is just to play a game and the "make shit work so I can do shit" game isn't as fun to me as it used to be. If that's your idea of a good time, by all means go forth and write some dosbox configs and give them away, posterity will thank you. Wait, I mean, forget you.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
Partially because it's now supported as in they'll give you help if something goes awry and will test the releases before claiming they work on Linux.
The bigger deal though is that it gives more visibility to Linux users. Buying a Windows version of a game and running it on Linux does very, very little for Linux,but buying and running a Linux version is something that developers notice. Even more so if people refuse to buy the Windows version and opt for the Linux version instead.
Funny. It would seem IBM has no problem with their DB/2 UDB releases, which run on every version of Linux I've thrown them at over the past 5-6 years. Sure you have to install some optional modules on some platforms, but how much more complex do you get than a database server?
Shame on the other database vendors for not being able to do the same. Currently DB/2 UDB 10.2 is the only commercial database I was able to install on Debian. Clearly it can be done, but the other vendors seem to take the "RHEL or the highway" lazy approach to "Linux" support.
I do not fail; I succeed at finding out what does not work.
how much more complex do you get than a database server?
How about an application that not only does client/server network processing, but also does realtime hardware-accelerated 3D rendering, multi-channel 3D sound processing, and processes user input from a wide variety of completely different devices. Oh, and it's probably got an internal database that it uses to track its state so that it can serialize and deserialize it to a file at any time. And don't forget that the video, audio, network, and input all have to appear to be synchronized to the user.
But the problem here isn't actually how complex things are, but how self-contained they are. How many external dependencies does DB/2 have compared to your average modern game?
Karma: Terrifying (mostly affected by atrocities you've committed)