# Game development on: Linux or Windows

## Recommended Posts

arnsa    127

Hello, folks!

I've got a dillema here. I've started to learn game development, more specificaly -- OpenGL. My GPU supports OpenGL only up to 3.1 version, so drivers on Linux isn't the problem here. The problem is, that most of the companies create games or game engines only for Windows or OS X, so I thought an experience in working with Windows would be good. But... I'm a total Linux lover and after installing Windows... I just hate them and I very much miss Linux. I've been thinking a lot,  but if I stay with Windows, I'll have more pros. I look forward for any opinion on what should I do, what are the advantages on staying with Windows, or working on Linux etc.

--Arnas

Edited by arnsa

##### Share on other sites
arnsa    127

Anything regarding the future of gaming on Linux as a result of Valve is just speculation at this point, so I won’t consider it in my answer.

There are several issues to consider and you will have to consider them for yourself.

Firstly, if this is just as a hobby, stick with what you love.  If you plan to go commercial, which is unlikely for a long time, Windows may be a better choice.  Sometimes making money means making sacrifices.

Secondly, if you do plan to go commercial, as an indie it would be more practical to target iOS (target Android only if you are masochistic).  The level of quality a game needs to be marketable on Windows is above what most individuals can achieve.  This would be true even if you stayed on Linux, but with the added hurdle of a smaller potential customer base.  iOS is OpenGL ES 2.0 anyway, which is really better to learn than OpenGL since it doesn’t have all the deprecated/excess cruft OpenGL has.  I see people even today learning OpenGL who somehow managed to do so via immediate mode.  OpenGL ES removed all the crap that should never have been there in the first place, so you are fairly safer in your learning process by starting with it.

Thirdly, if you did decide to go with Windows, it wouldn’t make sense to use OpenGL.  You would want to avoid a lot of headache and use either Direct3D 9 or Direct3D 11.  If you are fully decided that OpenGL will be your API-of-choice, Windows it still an option, but a less-sensible one.  Not because OpenGL on Windows specifically has problems, but because OpenGL itself has problems with the large variety of vendor implementations etc.  It is easy to see questions here constantly about how it works on nVidia but not on ATI.  My own engine has the opposite problem, as I just discovered after buying an nVidia card (whereas it functions identically in Direct3D 9 and Direct3D 11).  This is a problem with the vendors and the multitude of implementations out there, which means it is not just Windows, but Linux too.  So if you do go to Windows, Direct3D * would be a better choice.

L. Spiro

Actually, I'm not planning to create mobile games at all, because I don't like them. Will I go commercial? I don't know. Currently I'm only at 11th grade, so I will still be studying at school for 1+ years, plus minimum 4 years at the university. After that, I might go commercial, because atm I want game development-related job, and yes, game development is my hobby now.

What about Direct3D... I heard it's API is really crappy, so is the documentation. So, it could be hard to learn it, true?

##### Share on other sites
Enalis    333

I encourage you to spend time and look at a few different operating systems, APIs and development environments in general. I found love with OpenGL and KDevelop on KDE in Linux (Kubuntu). I haven't looked back in quite a while. I keep my engine/games cross platform so they'll run on Windows, OSX and Linux though, just for good form.

##### Share on other sites
Mike.Popoloski    3258

What about Direct3D... I heard it's API is really crappy, so is the documentation. So, it could be hard to learn it, true?

False. It's actually the opposite; OpenGL's API hasn't changed much since the 80's and the documentation is practically nonexistent (in fact, if you go to the OpenGL website, it says "The two essential documentation resources that every developer should have are the latest releases of:" and then gives two links to Amazon books you need to buy).

It's much harder to learn to use effectively, since the API no longer reflects much of what happens in modern hardware, and there are multiple paths to accomplish most tasks, the right one being non-obvious or even changing depending on which hardware vendor or driver version you're using.

That said, if you're targeting any platform other than Windows, you don't have much choice but to suck it up and tough it out anyway.

Edited by Mike.Popoloski

##### Share on other sites
larspensjo    1561

It shouldn't be too hard to port the Linux application to Windows, whereas it is not realistic to port a D3D Windows application to Linux.

If you use a library like glfw (portable context and input device management), then you are already half way.

In Windows, you set up MinGW, to get a similar environment. There may be problems depending on what Linux libraries you used, it depends. In my experience, OpenGL is not one of the problems (except for Intel graphics).

##### Share on other sites
Vilem Otte    2938

Basically it's up to you. Linux applications are common to be portable (unlike for Windows application). Although it's all about your will (do you want your software Windows-only, or portable).

It's possible to write easily portable software on Windows, and it's also possible to write non-portable software on Linux. For example we're sticking in all our applications to standard libraries (basically *just* bare standard of libc, (sometimes libstdc++ - depends on language we use)) and portable libraries (OpenGL, OpenAL, DevIL, GTK, ODE, etc.) - most of them are also open source by the way. E.g. we're basically trying to make our software system independent.

We're writing & testing all our software under both systems. So far we haven't met any system-specific problem!

#larspensjo - I object to port of D3D applications. If you rewrite your D3D functionality to WineD3D (this actually makes your software portable - and use OpenGL instead of D3D in the end), although I don't actually know how much work it is, because I haven't worked with WineD3D.

Edited by Vilem Otte

##### Share on other sites
larspensjo    1561

If you rewrite your D3D functionality to WineD3D...

I didn't know of WineD3D. On the other hand, it hasn't changed for 3 years. Doesn't have to be a problem, but usually a sign of a package in decline.

##### Share on other sites
Butabee    274

Use Unity 3D, you can build for PC, Mac, and Linux with the change of an option :)

##### Share on other sites
Xanather    782

If your going to use something like C# you should look at MonoGame. You would be able to develop your game on Linux and very easily port it over to windows (In most circumstances I think MonoGame has over 95% code compatibility).

##### Share on other sites

linux is still great to fiddle with for multiple reasons. It is the most used operating system in the high performance computing world. And the most important system to know as administrator of those HPC, administrator of data-center, websites hosting services, administrator of universities IT, some domains/companies with Unix history, hospitals IT service.. etc you name it. Linux is handy.

Next thing, it is great as a student because in the future linux takes a lot of time and has few commercial uses, and even at home it gets tiring. get a wife and children and linux is almost forgotten the first time you see yourself opening a .conf file.

BUT if feels so good to have another engine running the whole damn thing under the hood. it feels neat. windows has very old histerical raisins and some stuff are just so bloated and slow. whereas linux has refactored 100 times to get where it is now. But let's not go down the slope of troll-land.

What Spiro said can not be more true, except Android has its SDK available on windows, linux and OSX. Seems pretty logical, Android is a linux distribution. Google has linux expertise, they are a web company...

A last word about University, if you go to a respectable curiculum with a bit of history and not some new age private school that will give you 100 certifications from Sun, Oracle, SAS, Microsoft and other ridiculous papers that are pure management bullshit, you'll learn the unix way, because computer science originates from there, and widnows has just been re-inventing the wheel in a square shape.

What I mean by that, is that knowing how a linux works (but use debian for that, not ubuntu because you'll see nothing, just cute GUIs..), you'll have a step back and get a more canonical approach to computer science which I believe is great to have when you come back to the windows world.

Not only that, but for university work, you'll have to work with ssh to log on the university servers, and the correct way is from linux. (ssh -X, zsh, csh...)

However, for pure graphics, linux is a PITA if you don't have THE graphic cards for which you COULD have "nice" drivers if you happen to have a distribution that lets you have them. (hint: get an nVidia and don't be afraid of having to have to rebuild your kernel (if you have debian) or just use ubuntu its easier... at least at first.)

There are difficulties to get correct acceleration, and the multiplicity of systems in place in the community doesn't help. (Gallium, DRM, DRI, Mesa, Xorg, Compiz and the driver hell, nouveau, renouveau, fglrx, nv, nvidia and i'm not even talking of the issues with dual screen... that makes me cry)

But its a lot of fun :)

also the compilation process if just so simpler than on windows.

"apt-get install build-essentials" is the only thing you need before you can code.

I don't know how many URLs you have to browse before you can download a compiler on windows, and how difficult it will be to setup all the libraries you need to link correctly with your project.

on linux its often all prepared. you have autotools and cmake , everything is tightly organized in the distribution and libraries install all in the same place, so cmake package finders never loose whereas on windows....

for example, boost library, the most useful libraries set for C++ ever, you guessed it, one apt-get install only before you can use it in your code, in windows you are usually HOURS away. you need to build it, configure the projects .. aaaargh the pain, i can still feel it. fortunately there is a guy who does a binary package for windows but it  matches your compiler only if you're lucky anyway.

another thing : Emacs. of course there are Vi people who will want to argue otherwise. But really knowing Emacs (or say Vi) will give you some edge in code-text edition power over the people only knowing IDE like visual studio. (poor guys they don't even know what they loose) Downside, learning emacs is looooong, and difficult, and almost impossible alone. Also it requires knowledge of lisp to edit the unavoidable .emacs config file.

But you probably already know that

just for an ending word, many companies run some servers. these servers are greating running linux for remote administration comfort. So knowing linux.. again a plus. for middle sized companies without admins where anybody can do a bit of admin job from time to time, if you're the only one knowing how to configure iptables and to a little ./configure make make install, you'll have a serious edge in the eyes of the management. particularly when you install an apache server running some django magic with a buildbot along a gitosis service ... or whatever other stuff that are needed in companies. (mediawiki, mailservers, NFS, backups...)

If you go work at some famous big ones out there later in your life:

- intel, very active in linux development, because it is easily recompilable they can test lots of their CPU features there. c.f. powertop utility, intel c compiler...

- every single researcher out there. may it be in forest and nature (my sister in law did her thesis on a kind of forest growing model with a demonstration app using C made on unix environment), or computer scientists, biologists, doctors.. c.f vizualisation toolkits like VTK (Kitware Inc.)...

- nvidia, the fermi strategy has lead them on linux because aforementioned HPC reasons.

- IBM, Red Hat, Novell for the most famous.

excellent report that shows that:

http://go.linuxfoundation.org/who-writes-linux-2012

##### Share on other sites
brycethorup    101

I think the real question here is how deep into code do you want to get. If you want to get into the nitty-gritty of every aspect of your code you are going to end up having to lock-in to a specific platform (i.e. Window, linux, mac, etc.). It is true that it is possible to maintain cross compatibility, but the more complex your game becomes the more difficult it is. Frankly, unless you are planning on someone's platform specific engine, or building your own from scratch I would avoid low-level APIs entirely. Let me throw out a few options to look into that are both very simple to code for, and provide cross-compatability: ShiVa 3D, Unity, Blender. For someone starting out I highly recommend Blender. It is fully integreated, meaning you don't have to use one utility to make objects another to make textures another to manage code and then pull it all together somehow, it's all in one place. It uses Python for it's game language. Lastly, it is completely open-source, and free to download. It isn't meant for crazy complicated games, but for a place to start in game dev it is the only one I can recommend to absolute beginners. They have a few tutorial resources on their site (blender.org), but remember Google and Youtube are your friends.

##### Share on other sites
kop0113    2453
If you prefer to use Linux/UNIX to develop your game (i.e because you use it as your day to day OS) then you might have some success with wine-g++ and DirectX.
You probably wont be able to use closed source engines with this solution though because I doubt they would be able to link with GCC objects.

Engines I have used that work pretty well on both platforms include include Ogre3D and Irrlicht

I have not had great experience with Unity's Linux support. It only really works on the very latest distributions. RedHat Enterprise 6 couldnt run it due to incompatible glibc versions. This isn't really Unity's fault but is a symptom of using a closed source engine. Linux doesn't really maintain backwards binary compatibility in the way Windows does. (Which is why NVIDIA and AMD's drivers tend to be problematic).

OpenGL works on every platform I have ever used so I always strongly recommend this, even some people tell you that it isn't quite as "good" as DirectX. As an indie developer, it probably wont even make a difference to you. Personally, I find it much easier to get started with. Edited by Karsten_

##### Share on other sites
cr88192    1570
yes, personally I found OpenGL to be a little more accessible than D3D, and the portability is a bit of a plus-point (partly as I develop for both Windows and Linux, and was also considering possibilities like NativeClient and Android as well).

not to say that everything about it is necessarily good, but it works.

I had generally been using the full-featured OpenGL, and also using a fair amount of "legacy" functionality, but trying to migrate things to be able to work with OpenGL-ES is also a little bit of a challenge, mostly as lots of functionality that was taken for granted no longer exists (not all of it for entirely clear reasons), resulting in a fair chunk of the renderer recently being migrated to wrappers (for the most-part, the "fixed function pipeline" is now largely faked via wrappers, errm, partly as wrappers were the path-of-least-effort, and it was admittedly a little easier to move what bits of code that were still using glBegin/glEnd over to wrappers, than decide whether or not to prune them, or rework them to use VAs or VBOs or similar, and likewise went for faking the transformation matrices, ...).

but, in general, it isn't all that bad.

my exposure to D3D has generally been as a bunch of awkwardness involving DX version specific COM objects, PITA getting things linked correctly (since the Windows SDK and DirectX SDK are separate, and it essentially amounts to hard-coding the DX SDK install path into the build-files), and all-around a fair bit of general inconvenience doing pretty much anything, and all this with the code being largely platform-specific anyways, doesn't seem like a good tradeoff.

most of what functionality I have needed, can be found either in OpenGL or in the Win32 API (most of which is wrapped over anyways, via OS-specific code), making these generally a lot more convenient.

advanced rendering features and high-level API design issues aren't really such a big deal in this case.

EDIT, did find this:
http://en.wikipedia.org/wiki/Comparison_of_OpenGL_and_Direct3D Edited by cr88192

##### Share on other sites
SimonForsman    7642

Karsten_, on 09 Feb 2013 - 19:13, said:
Linux doesn't really maintain backwards binary compatibility in the way Windows does. (Which is why NVIDIA and AMD's drivers tend to be problematic).

Actually Linux distributions are binary compatible with eachother and the LSB mandates that they support the old ABIs(Which means they are always backwards compatible), drivers are a different matter since the kernel interfaces change frequently, but that goes for any OS, (Microsoft have changed their kernel interface with almost every single kernel release they've made and it breaks driver compatibility almost every time.

If you want to use proprietary drivers in Linux and avoid problems the only thing you have to do is use the kernel that ships with the OS. (And use an OS that doesn't push out new kernel versions as part of their normal update routine or atleast one that installs new versions of any proprietary driver you're using at the same time)

The fact that Unity3D doesn't work well with RHEL6 has nothing to do with backwards compatibility, glibc is backwards compatible these days(it wasn't back in the 90s, but this isn't the 90s) but old versions of glibc does not magically support software that requires newer glibc versions. (Just like you can't run a game that requires D3D11 on Windows XP).

If you want to run modern software on Linux, do not use RHEL, it is ancient before it gets released(RHEL7 should be able to run games made with the current version of Unity3D). Its great if you need stability, but if Microsoft did like Redhat the latest Windows release would be Windows 2000, SP13 and the only feature updates we'd get would be for things like Hyper-V or MSSQL.

Personally i wouldn't use Unity3D to target Linux today though, if i sell a linux game i have to support it, and offering a unsupported linux client to those who buy the game for Windows or Mac is pretty pointless. Seeing how much problems Unity3D has had to get Android support working reasonably well i'd prefer to wait until others have run over and exposed most of the pitfalls, once that is sorted i might consider supporting Ubuntu and possibly Mint. Edited by SimonForsman

##### Share on other sites
L. Spiro    25620

cr88192, on 12 Feb 2013 - 06:47, said:
PITA getting things linked correctly (since the Windows SDK and DirectX SDK are separate, and it essentially amounts to hard-coding the DX SDK install path into the build-files)

Huh?
Adding linker/header paths to the IDE search directories is fairly standard practice and if you have to hard-code anything you’re doing it wrong.
If you are not using IDE’s and using makefiles directly, firstly, that’s just pain you are bringing onto yourself and you have no one else to blame. Secondly you can still use environment variables ($(DXSDK_DIR) would be a good one!) to avoid hard-coding paths. If the fact that the Windows SDK and the DirectX SDK are separate (as they very-well should be) caused you even the slightest inconvenience, I think you need to gain a bit more experience in general programming, because linking to libraries is a fact of life in the world of programming. The concept of “search paths” exists whether you are using an IDE or raw makefiles, and every programmer should know about this at an early age. Speaking for myself, my first word as a child was “Mamma”. My second was “Chocolate cake”. My third was “Search paths”. L. Spiro Edited by L. Spiro #### Share this post ##### Link to post ##### Share on other sites _the_phantom_ 11250 If the fact that the Windows SDK and the DirectX SDK are separate (as they very-well should be) Although they aren't any more; June 2010 was the last DX SDK update for DX11. With Windows 8 DX/D3D is now part of the platform SDK and will be updated (or not) as that is updated #### Share this post ##### Link to post ##### Share on other sites cr88192 1570 cr88192, on 12 Feb 2013 - 06:47, said: PITA getting things linked correctly (since the Windows SDK and DirectX SDK are separate, and it essentially amounts to hard-coding the DX SDK install path into the build-files) Huh? Adding linker/header paths to the IDE search directories is fairly standard practice and if you have to hard-code anything you’re doing it wrong. If you are not using IDE’s and using makefiles directly, firstly, that’s just pain you are bringing onto yourself and you have no one else to blame. Secondly you can still use environment variables ($(DXSDK_DIR) would be a good one!) to avoid hard-coding paths.

If the fact that the Windows SDK and the DirectX SDK are separate (as they very-well should be) caused you even the slightest inconvenience, I think you need to gain a bit more experience in general programming, because linking to libraries is a fact of life in the world of programming. The concept of “search paths” exists whether you are using an IDE or raw makefiles, and every programmer should know about this at an early age.

Speaking for myself, my first word as a child was “Mamma”.
My second was “Chocolate cake”.
My third was “Search paths”.

L. Spiro

many people still build from the command-line using GNU Make, FWIW...
this has the advantage that many core files for the project (much of the Makefile tree) can be shared between OS's.
(vs say a Visual Studio project, which is only really useful to Visual Studio...).

but, yes, although a person can get it linked, it is less convenient given it isn't kept along with all the other OS libraries.
like, in the top-level Makefile, a person may need something like:
export DXSDK="C:\\Program Files..."

as well as passing this back to CL as part of their CFLAGS and similar.

not that it can't be done, but a person can just as easily not do so, and instead just use core libraries (those provided by the Windows SDK for Windows builds, which happens to include OpenGL and the Win32 API, but not typically DirectX).

but, the bigger question is, how worthwhile is it to have a big dependency for something that is largely Windows-specific anyways (and can't really be used to any real non-trivial degree without putting portability at risk)?... Edited by cr88192

##### Share on other sites
cr88192    1570

If the fact that the Windows SDK and the DirectX SDK are separate (as they very-well should be)

Although they aren't any more; June 2010 was the last DX SDK update for DX11.
With Windows 8 DX/D3D is now part of the platform SDK and will be updated (or not) as that is updated

yes, this is good at least.
too bad that Win8 itself isn't looking terribly great though.
will probably have to see how things go in the future.

##### Share on other sites
MichaBen    481

What about Direct3D... I heard it's API is really crappy, so is the documentation. So, it could be hard to learn it, true?

The fanboys here will probably never admit it, but D3D is a horrible API to work with for beginner programmers. Basically it uses extremely outdated pre-standard C++. You will find yourself using pointers and pointer pointers all over the place rather then references, it uses global functions rather then constructors/destructors, and COM is just a nightmare. Unless you mastered object oriented programming first, I would strongly recommand against jumping into Direct3D, as it will teach you lots of bad practices in modern C++. For the same reason you should avoid using WIN32 API like the plague when you are new to programming, and once you mastered C++ you probably still want to avoid it, but then at least you can tell it's bad, rather then get confused of what is proper modern C++ and what is pure evilness.

##### Share on other sites
L. Spiro    25620

Direct3D didn’t work out for me so I hate it.

Fixed.

Basically what I gather from your post is:
#1: You are a fanboy of OpenGL. Anyone who talks down on OpenGL, realistically or not, is a fanboy of Direct3D.
#2: You are an amazing master who knows “proper” and “modern” C++.
#3: You have a chip or 2 on your shoulder regarding Win32 as well.

We try to put our biases aside here.

L. Spiro

##### Share on other sites
SimonForsman    7642

Direct3D didn’t work out for me so I hate it.

Fixed.

Basically what I gather from your post is:
#1: You are a fanboy of OpenGL. Anyone who talks down on OpenGL, realistically or not, is a fanboy of Direct3D.
#2: You are an amazing master who knows “proper” and “modern” C++.
#3: You have a chip or 2 on your shoulder regarding Win32 as well.

We try to put our biases aside here.

L. Spiro

Allthough to be honest, Win32 is pretty awful if you compare it to for example .Net or QT. (Its better than X11 though, but that isn't really much of an achievement).

The whole COM thing takes some time to get used to and it does raise the barrier of entry slightly, i fully understand why michaben hates it, the open alternatives (CORBA etc) aren't much better though and it is one of the better ways to share compiled classes between languages and compilers. It would have been worse if Microsoft had gone with CORBA instead of COM and having a procedural API that requires a wrapper library for each language that uses it really isn't much better.

Using Direct3D from python vs using OpenGL from python(Without a third party wrapper) is a good eye opener for how useful COM is.

To use Direct3D from python all you need is the PythonCOM package(Which you can use to take advantage of any COM based library such as those that are included in Microsoft Office (creating a word document from python is just a few lines of code for example, all thanks to COM)), to use OpenGL you need to create a binary (.dll/.so) module specifically for Python and OpenGL(Now since OpenGL and Python are both fairly popular there are allready several such modules to choose from but the same isn't really true for other languages and libraries.

Edited by SimonForsman

##### Share on other sites
MichaBen    481

Basically what I gather from your post is:
#1: You are a fanboy of OpenGL. Anyone who talks down on OpenGL, realistically or not, is a fanboy of Direct3D.
#2: You are an amazing master who knows “proper” and “modern” C++.
#3: You have a chip or 2 on your shoulder regarding Win32 as well.

Oh please, grow up kid. I have been using both Direct3D and OpenGL for ages. Maybe if you would actually *read* my post, you would see that I didn't advice the usage of OpenGL at all, only state the truth about Direct3D and try to safe people from learning C++ the wrong way by jumping into it to soon. But of course, I could have guessed some pathetic troll would come in...