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.'"
YAYAYAYAYAY!!!!!
That's all
Goodbye Slashdot. You've changed.
I did, I was not surprised that he specifically called for a move to linux because it's not written by Jews.
Not everybody uses Ubuntu or Mint.
It's a shame they decided to support a specific "distro" instead of just generic Linux. How hard can that be?
What's wrong with specifying minimum version numbers for libraries, using /usr/local/games and providing standards-compliant *.desktop files? How difficult is that?
Or better yet, ship the required libraries with the binaries (providing the source code via ftp) and using a wrapper script to load the correct libraries and run the game for a "works-every-time" experience.
To GOG's credit, their support forums contain a wealth of information about running some of these games using Linux. As well, PlayOnLinux can install supported *.exe games directly from your account at GOG, so they have been supportive of Linux for a very long time.
"I believe in Karma. That means I can do bad things to people all day long and I assume they deserve it." : Dogbert
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
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.
Well, like I said, I wrote one or two crappy ones and then gave up wasting my time on it when 100% of the games I tried would run fine in vmware. Well, as fine as they did anywhere else. I finally dusted off an XP box and a lot of games were crashy there too.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
PEBKAC. DosBox is easy to configure on all platforms.
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.'"
I have purchased a significant number of games from GOG already, and play pretty well all of them on my Linux laptop in WINE.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
Ah, I see you use the US QWERTY keyboard layout. Good for you. However, that doesn't make your statement true for anyone else with a different key layout... No, dosbox uses scancodes instead of the virtual keycodes of the OS, and it really is a pain in the ass to configure a new key layout for it, even though it is possible, and it even has a keypress display feature.
I hear that it supports all the latest Matrox Graphics cards - yay!
I haven't come across a single DOS game that hasn't just worked with default settings. So yeah, the problem is probably you.
Thank you so much GoG!!!
No DRM, clean installers, good responsive forums, reasonably priced. And now Linux support incoming. Virtually unheard of in today's game publishing/distributing business.
This is great news. I own over 200 games on GOG and would be delighted to play on my linux machines, especially for some casual gaming on my linux laptop.
This should rope in literally a handful of crotchety old nerds.
If Slashdot is any indication, this news will increase the GoG customer base by at least 4 people. 8 might be pushing it though. I think the group of 'Linux users who want to play games available on GoG, know about GoG, but aren't technologically savvy enough to improvise around the current release formats' is really in that 4-8 range.
I think the group of 'Linux users who want to play games available on GoG, know about GoG, but aren't technologically savvy enough to improvise around the current release formats' is really in that 4-8 range.
Again, there's that typical arrogance that makes non-savvy people hate us. I paid GOG to think about that shit for me because I have other projects to work on, and I just want a game to play when I clicky.
On the other hand, I think we both agree that this does target a fairly small market. But perhaps it will help to grow desktop linux numbers again, and it could really be a boon for netbook owners since these are the sort of games which will actually run on computers like theirs. XP is about to asplode and it'd be nice to have games to run on all those XP netbooks when they don't run XP any more.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
This produces huge binaries with a lot of redundant code compiled in, but it means it works regardless of which libc you use
You didn't statically link glibc did you? It's LGPL which requires that the end-user be able to swap out the glibc you used with any other version they'd like to use. I suppose it's possible to do in some way, maybe by distributing object code which can then be linked against the user's custom glibc, but the requirement is ridiculous enough that, for a project that a friend and I are working on, we tell the Linux users to just run the Windows version in Wine even though the Windows version is just a port of the Linux version, as MinGW's libc isn't covered by the LGPL. When you're working on a free game in your spare time, you don't have any desire to waste resources complying with such BS licensing requirements.
I suspect that were it not for glibc's license making static builds illegal, we'd see a lot more commercial software available for Linux. It's kind of ridiculous that people even have to worry about licensing requirements just because they type "#include " but they do. I mean, I understand when searching out other libraries, for example, I wanted to use cracklib to suggest to users when they should choose a better password, but as it's LGPL, I simply passed on it and instead offer no suggestion at all as to the strength of a password. However, if you can't code anything that accesses the system at all (basic file I/O is covered by glibc) then you've got a major problem with the licensing requirements of releasing closed-source software for your OS. The result is that, rather than offer a fully statically-linked executable (which isn't nearly as bloated as most people assume -- 99.9% of your hard disk is full of data, not code) to guarantee a program will be functional (as the Linux ABI is quite stable in the portions covered by POSIX, which is all that the vast majority of software needs to access), you instead have people first requiring that you choose which distribution you're using, then which version, and if that fails, they at least ask which glibc your system has since, while they can probably find public domain or BSD-licensed code for most things they need to do, Linux's API is glibc and it's LGPL, so they can't statically link it, and instead have to provide a version of their program dynamically linked against every version of glibc that someone may have.
For more ridiculousness, just try to statically link a program that uses the getaddrinfo() function. You'll get a warning that the function will only work when run on a system with an identical version of glibc (which defeats the purpose of statically linking) and the glibc people see this as a non-issue since, due to the LGPL licensing, they don't believe you should be statically linking anything that uses glibc anyway. Indeed, this warning message was how I found out that I was violating the LGPL by releasing static builds of my free Linux game which I had been careful to use only public domain and BSD-licensed libraries. The fix for this, as mentioned above, was that I simply stopped releasing Linux versions of the game. With no money involved, I can't set up a server farm with every version of every Linux distribution in order to compile all of the different downloads, nor do I want to start and stop as many virtual machines as that would turn a 60-second compile into an hour long affair. If I had that kind of time to waste, I'd spend it improving the game, not dealing with BS licensing requirements. I imagine any commercial developers thinking about supporting Linux encounter the same situation and see that what just barely made any financial sense when they first thought of it suddenly makes much less sense when they realize what a complete PITA the licensing requirements of the standard library are.