46 replies to this topic

[arnsa]

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, 08 February 2013 - 12:28 PM.

[L. Spiro]

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

[arnsa]

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?

[phantom]

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

Judging by your opening post about loving Linux it isn't overly surprising you've heard this however it couldn't be further from the truth.

Of the two APIs D3D11 is the better of the two; it is well documented and all together saner.

OpenGL, while feature wise is on a level with D3D11, remains tied to the broken bind-to-edit model which makes working with it pants-on-head retarded.

That said working with OpenGL won't hurt you initially so you don't feel you have to swap over to Windows in order to progress; all the basic knowledge of 3D rendering is transferable between the two, you just have to learn a different way of doing things. You'll probably want to pick up D3D at some point however right now you can focus on expanding your knowledge with OpenGL on Linux.

[PaloDeQueso]

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.

[Mike.Popoloski]

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, 08 February 2013 - 01:18 PM.

[larspensjo]

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).

[Vilem Otte]

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, 08 February 2013 - 03:12 PM.

[larspensjo]

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.

[L. Spiro]

I want game development-related job

This is just another thing to consider, but since it is your future career it is probably the most important thing to consider.
I can personally vouch for Nintendo DS, Nintendo Wii, Nintendo 3DS, Xbox 360, PlayStation 3, PlayStation Portable, PlayStation Vita, and Android all requiring Windows for development, and iOS requiring Mac OS X (I have been corrected on Android—it has kits for Linux, but it is the only one in this list that does). The only time I have ever even seen a Linux machine was the one day I worked at Morgan Stanley, which is clearly unrelated to video games.

Not only that, excluding mobiles (since you stated you don’t want to work with them), all current consoles, as well as development for Windows, are much closer to (or exactly) DirectX 11. It is no secret that the next Microsoft console will use DirectX 11, and PlayStation 4 will be as well (or rather extremely similar).  These will likely still be the relevant consoles when you graduate.

 

 

Ultimately, as was said, you can learn OpenGL as a means of learning general rendering concepts, but you can do the same with Direct3D 11 and avoid having to relearn an API in the future.  In other words you can learn the concepts and then struggle with the relevant API later, or you can just learn the concepts and the relevant API up-front.

Besides, as was also stated, OpenGL’s bind-to-edit mechanism is a headache and OpenGL is simply refuses to evolve, sticking to the mistakes of a somewhat naïve upbringing for the sake of compatibility, whereas Direct3D 11 is a recently fully overhauled API designed to match the way modern graphics hardware works, where backwards compatibility has been sacrificed in order to rid itself of design flaws of the past.

 

By now the choice should be fairly clear.  And speaking from personal experience when I had to work on Mac OS X after having avoided it like the plague for decades: You get used to it.

 

 

L. Spiro

Edited by L. Spiro, 11 February 2013 - 05:39 PM.

[Butabee]

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

[Xanather]

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).

[Lightness1024]

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:

- google, already mentioned, they notably contribute to webkit

- 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

[brycethorup]

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.

[Karsten_]

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_, 09 February 2013 - 12:19 PM.

[cr88192]

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, 11 February 2013 - 04:11 PM.

[SimonForsman]

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, 11 February 2013 - 06:03 PM.

[L. Spiro]

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, 11 February 2013 - 05:57 PM.

[phantom]

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

[cr88192]

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, 11 February 2013 - 10:26 PM.