GalCiv II on Linux? Should I bother? » Forum Post by khelvan

ZubaZ

Join Date 11/2001

+917

Impulse needs the .net framework. Don't think that will work for you.

Successfully updated karma reason!

My experience is that, for gaming purposes, Wine is really iffy - easier to dual boot or (If your processor will support it) run a virtual machine.

Others however have had better luck than myself.

Jonnan

Successfully updated karma reason!

whismerhill

Join Date 03/2006

+19

short answer : no

you'll get hard to solve glitches and less performance ... see the linked post just above mine

Successfully updated karma reason!

Oh well. I am dual-booting with Vista, but I tried to run GCII under Vista and it was a very painful experience. I guess I will have to play on my desktop...

Thank you!

Successfully updated karma reason!

Wine is nice for some hacking to get something working under Linux. It is not a reliable tool. If you are serious, you have to install Windows.

I made one quick attempt to do it by copying Galciv2 from my Windows to my Linux partition. With Wine 0.9 I could get the game activated by running activate.exe, it ran as well, but there were severe font problems. Surprisingly, 3D was very good. I then did upgrade Wine to 1.1 in the hope it would fix something, and then I could no longer get the game activated, activate.exe complains about not being able to get the SSID from the system.

So, as much as I don't like to say this, and I am a user 100% migrated to Linux both at home and at work, you should not bother to get Galciv2 working under Linux.

Successfully updated karma reason!

In my experience, Linux is simply not a gaming platform. In fact, I don't even bother with Linux for productivity applications. It's a fun OS for tweaking - but I got tired of tweaking and decided that it was more of a toy and not really a serious or productive OS. These days I use Windows as my primary OS and run Linux on a virtual machine.

Successfully updated karma reason!

Yeah, you'll be very productive by spending 50% of your time keeping your system virus free. More seriously spoken, Windows lacks all the tools you need for productivity, like a good command line, PDF file creator, SSH client, a good scripting language. Sure, most of it is solvable, but it's a lot of working patching a Windows system to become productive and on Windows everyone wants money from you for the silliest of tools (and let's forget about EULA's for now).

Also, I have another very pragmatic reason, it allows me to fully refrain from piracy. While the price for a copy of Windows is reasonable, the price of all the software I need would be a few months of salary together. It is much more attractive to buy an OpenSuSE box and be done with it (and even that is optional) than to buy Windows, MS Office, Adobe Acrobat, Winrar, Nero burning ROM, Photoshop and so on.

Linux and games? I never had so much gaming fun with a handheld console as with my Linux based GP2X gaming console.

Successfully updated karma reason!

This issue needs to be raised at the Game Developers' conventions. There are some nice cross-compiling platforms out there. It shouldn't be too difficult to write source code once, swizzle some Makefiles around, and spit out MacOS, Linux, and Windows versions in one swoop. We've been doing that in the professional world for quite some time now. I guess the gaming companies are using such proprietary engines, that it's a bit of a task encapsulating their routines in a higher-level API that would support cross-compiling. So rather than attempting to resolve that issue, they just say, "Everyone's on Windows", and be done.

Successfully updated karma reason!

Zoomba

Join Date 11/2002

+114

App development is not the same as game development. You're taking (for the most part) orders of magnitude difference in complexity. Also, how many major, complex applications are written so they can just magically be compiled in mulitple OSes without major changes? OpenOffice is really the biggest one I can think of in this regard, and I doubt that recompiling for Windows or Mac is a simple edit and button press.

Successfully updated karma reason!

Also, I have another very pragmatic reason, it allows me to fully refrain from piracy. While the price for a copy of Windows is reasonable, the price of all the software I need would be a few months of salary together. It is much more attractive to buy an OpenSuSE box and be done with it (and even that is optional) than to buy Windows, MS Office, Adobe Acrobat, Winrar, Nero burning ROM, Photoshop and so on.

First of all, nobody's making you pirate stuff.

Second, you can get freeware variants of most of that on Windows just fine. Your OpenSuSE doesn't come with MS Office; it comes with OpenOffice.org. Which is available on Windows too. Same goes with your OpenSuSE alternates of Acrobat, WinRAR, Photoshop (GIMP) and so on.

This issue needs to be raised at the Game Developers' conventions. There are some nice cross-compiling platforms out there. It shouldn't be too difficult to write source code once, swizzle some Makefiles around, and spit out MacOS, Linux, and Windows versions in one swoop.

That assumes you're using Makefiles to begin with. Windows programmers tend to be Visual Studio users, so they're using vcproj's.

Also, how many major, complex applications are written so they can just magically be compiled in mulitple OSes without major changes?

Um, all of the ones that are cross-platform by design? You may want to investigate the various platform-independent layers and such that make all of this possible, but if you write your code to a platform-independent layer, cross-compiling is not a problem. If you write platform-independent code, it will be a priori platform independent.

The problem is that these platform-indepenent layers tend to be poorly documented and needlessly difficult to use.

Successfully updated karma reason!

I would consider cross platform application development harder than writing cross-platform games. The reason is that for applications you need to inferface with the GUI, which is Win32 on Windows, GTK or QT on Unix and Carbon on MacOS X. This is are all many different API's so you need either an abstraction layer between GUI and application logic, or implement your own user interface. The latter is the easiest but gives you an alien looking and behaving user interface on all platforms.

For games the situation is, much, much easier. because the relevant APIs, OpenGL and OpenAL are available on all relevant platforms. Besides these API's, there is little interaction with the system, perhaps you need some code to read files from disk, but that's it. Writing cross platform games is as easy as using these APIs and compiling, regardless of wether you are compiling on an x86 Windows system or PowerPC based Macintosh.

I once held a presentation about cross platform platform coding using the Free Pascal compiler. Coding cross platform with OpenGL is so darn easy that I decided to demonstrate the point. Rather than using PowerPoint or Openoffice Impress, I decided to code my presentation in OpenGL. While I developed on Linux, it has been reported to compile (and work correctly) on Win32, Win64, Linux x86, Linux x86-64, Linux-PowerPC and MacOSX-PowerPC. For something you put in no effort to make it cross-platform, that is a nice score.

Successfully updated karma reason!

I don't mean to make anybody defensive. I have no doubt that gaming applications and professional applications are different beasts.

However, it's interesting that OpenOffice was brought up. That is, in fact, a professional application. That would have been developed using Sun Studio, which is itself a cross-compiling environment. It followed the aforementioned precepts of cross-platform development. Recompiling it for different platforms no doubt would have been more than just a simple button click, but putting together the makefiles (lower-case "m"--I mean anything that constitutes a makefile, not just the file "Makefile") would have been a couple days' work.

The issue with gaming, I'm sure, is performance. But even then, at the end of the day they are all x86 and DirectX instructions. Trolltech provides a pretty good "low" level API that allows for platform-independent graphics and multithreading calls, which don't rely on every individual OS's idea of how to draw a "menu" or a "widget". The performance penalty may be a bit much for a Halo or a Grand Theft Auto (I don't know that, though...), but a turn-based game should be fine.

I am sure there are gaming-specific issues that haven't been adequately addressed in all the different cross-compilers, but like I said, that's why it should be raised as a topic in the Gaming Developers' conferences. And if the Stardocks in the world truly are anti-DRM, well--what is Windows?

Successfully updated karma reason!

Zoomba

Join Date 11/2002

+114

My point is that saying "it works on this application, it should be EASY for games" is a gross oversimplification. Anyone who says "Oh, it should be easy if you..." should put their money where their mouth is. If it was truely easy, there would be a lot more people doing it.

Successfully updated karma reason!

Yeah, you'll be very productive by spending 50% of your time keeping your system virus free. More seriously spoken, Windows lacks all the tools you need for productivity, like a good command line, PDF file creator, SSH client, a good scripting language.

Haven't had a virus in years - and I don't use much of the tools you've mentioned.

Different people have different needs and different tastes. I've been there, tried that, and it just wasn't right for my needs.

For games the situation is, much, much easier. because the relevant APIs, OpenGL and OpenAL are available on all relevant platforms.

The issue with gaming, I'm sure, is performance. But even then, at the end of the day they are all x86 and DirectX instructions.

. . . and here lies one of the many issues - a lot of games use DirectX, but if you want to go cross-platform, you'll have to rewrite them to use OpenGL.

Successfully updated karma reason!

I concede my experience is the polar opposite of Cobra's - Linux is my day to day OS, Windows is used to play games, and that's about it.

Now, that experience was vastly different until just a year or so ago - I started on Ubuntu 6.10, and it was the first version of Linux that 'just worked' consistently enough that I was willing to go to the extra effort to fix the portions that didn't.

But at this point, Ubuntu 8.10 comes with such a great loadout of good, well written software, I can't imagine going back to Windows for anything other than a specific program need.

Even in gaming, given some of the games that *are* on Linux, I think it's going to become a full fledged system soon. I would be curious to know from our resident experts - does the Mac's behind the scenes Unix lineage make it easier to port from Unix to Mac? Seems intuitively obvious, which of course means I'm probably wrong - {G}.

Jonnan

Successfully updated karma reason!

I think it's safe to say that porting existing code (like Galciv2) to Linux is definitely out. It makes more sense to software engineer new code like an Elemental or a Galciv3 to be cross-platform compatible from the start.

If enough games came out on Linux, pretty soon it would be hard to justify plunking down $100 on Windows. You could get 2 games for that.

Regarding Linux vs. MacOS, Linux programmers would have no problem porting their programs to the Mac, but they wouldn't be so good at taking advantage of all of Leopard's nifty features. However, with the Mac's Windows emulator, the Mac would definitely be the development platform of choice for applications compatible with Windows, Linux, and Mac.

Successfully updated karma reason!

whismerhill

Join Date 03/2006

+19

Quoting tetleytea,

reply 12

The performance penalty may be a bit much for a Halo or a Grand Theft Auto (I don't know that, though...), but a turn-based game should be fine.

I don't agree

having a C2D E8200@3.2Ghz + 4GB RAM on xp64 + 8800GTS512 I get very slight slow downs on immense map size after a few years (so a lot of objects/ships) : and this is because of gfx since if I turn on permanent icon display there's no slow down (also almost all options are maximum and I use the mod which increase gfx quality ...)

and second point, galciv2 with immense map sizes eat memory for breakfast ...

so turn based games CAN eat a lot of ressources even if they aren't quite the same kind of loads than a GTA 4 which itself drains more from the whole dynamic graphic sub-system and dependancies ... (preloading to prevent clipping and more ...)

Successfully updated karma reason!

Quoting Zoomba,

reply 13

My point is that saying "it works on this application, it should be EASY for games" is a gross oversimplification. Anyone who says "Oh, it should be easy if you..." should put their money where their mouth is. If it was truely easy, there would be a lot more people doing it.

Not easily convinced, eh? No problem, I can understand your point of view. But seriously, I know what I am talking about. Give me an OpenGL code, and I'll port it. If my last link wasn't convincing enough, may be an actual game can show I do put my money where my mouth is.

Quoting CobraA1,

reply 14

. . . and here lies one of the many issues - a lot of games use DirectX, but if you want to go cross-platform, you'll have to rewrite them to use OpenGL.

Excactly, and this is the reason why there aren't a lot more people doing it. On the other hand ID Software develops with OpenGL/OpenAL from the start and, surprise or no surprise, their games run on Linux.

Quoting tetleytea,

reply 16

I think it's safe to say that porting existing code (like Galciv2) to Linux is definitely out. It makes more sense to software engineer new code like an Elemental or a Galciv3 to be cross-platform compatible from the start.

This is very true, once you have a platform specific API intermingled with code all over the place, it can be very hard to make a code work on a different API. This is not just true for the Win32 API, but also for many Linux friendly APIs. For example, it can be hard to port a GTK application to QT or a native Win32 user interface.

Successfully updated karma reason!

Oddly enough, as the guy here who has run GC2 under Linux, I find myself agreeing with, well, everyone, more or less.

Linux certainly is more secure and virus-free; but by the same token, I have never once had any problem with viruses under Windows, either.

Linux isn't great for games, especially commercial ones; but there have been commercial games that were ported to Linux without much difficulty (I bought Railroad Tycoon II for Linux ages ago, for instance), and others that have run fairly cleanly under Linux without much difficulty (lots of older FPS games ran nicely under Linux).

Oh, and I've had real troubles running GC2 under Vista on my brand-new laptop, as well (of course, I've had real troubles running Vista under Vista on my brand-new laptop -- even after SP1, Vista, well, sucks).

Yes, there are lots of great free programs for Linux; and yes, most of them also exist for Windows.

Yes, Linux is good for poking around in; and yes, it is nice to no longer have to oke arund in it to make it work (glory be, I no longer have to edit /ect/fstab by hand!).

Yes, Impulse requires .NET, but I have gotten it to install under Linux using Crossover. No, however, I have not gotten Impulse to subsequently run correctly under Linux. Grrr. But Stardock installed and ran very nicely indeed, and that was sufficient to install GC2 and Sins of a Solar Empire.

My analysis: If you have Linux, and you have GC2, then it's probably worth playing around with getting GC2 to run under Linux, if you're interested. But if you have Linux and don't yet have GC2, it probably is not a good idea to buy GC2 just to run under Linux. At the moment, I would not rate the resulting experience as being worth the cost. GC2 under Windows? You betcha. Yummy. GC2 under Linux? Not really there yet, pending better DX/D3D emulation under WINE.

Successfully updated karma reason!

Sir, you seem to have gotten the impression that we're holding a reasoned debate here. If you can't pick a partisan ideologically based position and hold it regardless of any facts that might be brought to bear, then dammit get out of the way for those of us who can!!!!!

Down with the evil Micro$oft!!!! ({--- see, you can tell I is a manly linux rebel cuz I used a dollar sign! Someday soon I will rite a bash script and speek leet! I heer th3 gurls like that!)

Oh - wait, GC II runs on Windows. Well, Down with the evil Micro$oft, as soon as Galactic Civilization III is released for Ubuntu then!!!!

Jonnan, a happy user of Linux for Wimps - {G}

Successfully updated karma reason!

Oh, and I've had real troubles running GC2 under Vista on my brand-new laptop, as well (of course, I've had real troubles running Vista under Vista on my brand-new laptop -- even after SP1, Vista, well, sucks).

I'm curious to know what troubles you've had - I've had almost no troubles with Vista since SP1, and I've never had troubles running GC2 in Vista.

Successfully updated karma reason!

I experienced considerable graphics corruption and instability running both Sins and GC2 in windowed mode on my Vista laptop (an HP 6915nr, FWIW). Both run reasonably in full-screen mode, however, so it's all good for now, even if I prefer windowed mode (a lot).

BTW, as an aside, I'm typing this on the miniscule keyboard of my fun little Fedora 7-based One Laptop Per Child X O laptop. I have not yet attempted to get Galactic Civilizations II to run on this machine yet. Heh.

Successfully updated karma reason!

Qt has a dedicated QtOpenGL C++ module. I would love to see a benchmark of some graphics-intensive applications written for QtOpenGL vs. someone who used vanilla Visual Studio. My money says there would be no visually noticeable difference in performance on Windows.

...oh, I can see one problem, though. The video drivers. Video drivers on Linux SUCK. Can you imagine what would happen if someone ndiswrapper'ed their video driver just to get it to work? You'd be getting a flood of support calls at Stardock (or wherever...) saying, "performance on Linux sucks". You'd have to get AMD and Nvidia to consistently put out good drivers for Ubuntu, Fedora,RHEL, Suse, ... in addition to XP, Vista, Windows 7.... They don't have cross-compilers for that.

Like I said, this should be a topic at the Gamers' Developers conventions.

Successfully updated karma reason!

OpenGL needs a surface to draw on. There are several library that can provide OpenGL this surface, the normal unportable way to do it in Windows is via DirectDraw. If you then port to Linux you need to rewrite this code, because on Linux you need an X11 surface. This is still considered "easy to port", because only the OpenGL initalization is platform specific, while all the game engine code is portable.

There are several ways to make this portable, one being GLUT, another being SDL. These give you one API you can use on all platforms, so you just need to compile.

All these methods are equally fast, because only the OpenGL initialization is different. I am not so sure for QtOpenGL, because it is a windowing toolkit that draws its window in one draw operation to the operating system. If you have an OpenGL widget on your window, OpenGL needs to be initialized to draw to a memory surface, so Qt can then write the window then in one go. But perhaps this has already been optimized by Trolltech.

Regardless of the answer, games will likely not use QtOpenGL, because they generally do not want drop down menus & scroll bars, they just want a full screen OpenGL widget or a window that is entirely covered by an OpenGL widget. This makes the Glut & SDL the preferred ways to do portable OpenGL for games.

I agree with the concern about drivers, but I disagree with part of your post: Both ATi & Nvidia offer drivers of sufficient quality and Nvidia's Linux drivers nowadays achieve higher frame rates under Linux than under Windows. The driver black age is over.

Successfully updated karma reason!

I'm looking at the QtOpenGL class right now. I don't see anything that necessitates that you use Qt's other widgets in order to use QtOpenGL. All it does is subclass QWidget, with a bunch of virtual functions which you must define using standard OpenGL calls instead of the QPainter class (or, you could just use the QPainter class...). You should be able to make the whole window one QGLWidget without too much trouble. That would let you write that and the rest of your code in Qt without having to compile in a bunch of other libraries as well. There's plenty of other stuff in Qt besides just the widgets--there's the event-handling, database queries, multithreading, network traffic, multilingual support....

Successfully updated karma reason!