Which programming language did you choose and why?

Click here and disable ads!

Though... once you've figured out how to make the context and load textures (for which I'd recommend SDL_image), OpenGL basics are pretty easy when it comes to drawing textured 2D polygons, at least if you use the deprecated Fixed-Function pipeline.
The so called "Core Profile" of modern OpenGL is a whole other ballgame and one I know very little of, but I do know that you need shaders to draw things and you don't have access to the classic glBegin() functionality.

Everything I've heard over the years tells me to avoid SDL_Sound and just use SDL_mixer or another sound library like OpenAL.
FmodEX is also proprietary and requires you to license it for commercial use, which might make it undesirable if those things matter to you.

I on the other hand would recommend you and anyone else to avoid boost like the plague.
But I'll admit that I detest both boost and the STL for being absolutely convoluted and unintuitive...
Have you ever opened any of their header files to figure out how to use them!? It's downright impossible and most of the code I work with (other people's code) isn't even documented!




But yeah... The only other thing I'd add is SDL_image for loading images and textures for blitting and rendering or whatever other reason you need to load images for.

All template metaprogramming libraries get like that eventually as the type bounds are relaxed.
If you want to see a small next-gen java ex, look at this thread:
http://mail.openjdk.java.net/pipermail/lambda-dev/2012-May/004832.html

edit: guys are going crazy, look at this:
http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html

they're going full functional, run for the hills

STL is a part of the language spec. There are several good manuals on how to use it (I recommend Effective STL). If you are not using STL you are not using C++ in its entirety (which is not necessarily a bad thing). SGI's STL page is also very useful, along with C++ reference wiki (not many examples) and CPlusPlus Reference.

Trying to learn STL from reading the implementation is a bad idea. The standard library is supposed to be implemented effectively and to provide maximum performance. To satisfy this requirement you need to use every feature of the language available. It also has to conform to stuff specified in the standard (ISO/IEC 14882:2011 currently, PM if you want to know more), which dictates some naming conventions. This makes code hard to read for beginners. So get a book about it and learn it properly.

Boost is even worse to learn from the implementation. Their docs are very good although a bit light on examples. But there is a ton of code on the net you can see how to use them.

The "unintuitiveness" of STL is a matter of perspective. I don't say it's perfect (or even good) but it does try to be internally consistent and makes a lot of sense once you understand it. My first years in C++ were hard due to it, but now (10+ years of coding in it) I feel pretty comfortable.

The thing with such low-level libraries is that they are not meant to be modified or even read by your average application programmer. This is no different from code of Java or C# standard lib (can you even see this code), libc and all its variants, or kernel code. Learn their interfaces and don't worry about implementation unless you want to go into lib writing yourself.

Yes, but I strongly discourage using deprecated OpenGL pipelines. You will lose your portability with OpenGL ES and therefore with many devices.
I'd say : stick with SDL or go full modern DirectX/OpenGL but it is not the same difficulty.

I'm not in love with boost either but they do some awful protability gruntwork transparent for you, such as typeof or traits.
By the way STL containers are really limited too, especially because of the allocator API.
It makes it a PITA to make proper stateful thread-local, pooled or stack allocations with this API.

I found Direct3D's sprite interface to be much easier to work with than using SDL+OpenGL for 2D. The former was actually designed for 2D, the latter was not. The results are much more predictable with D3D. I got OpenGL to work too, but haven't solved "how to properly imitate 2D colorkeying" issue. Nothing I tried, worked. Fortunately Monsterland actually works better with additive blending than colorkeying, so it was side-stepped.

As I work on a full featured 3D engine, I do 2D casually as a special case of 3D with pixel-perfect mapping (care is still needed for texcoords).
If you have to build your engine from scratch (without D3DX) it is a bit harder.
Is the proper 2D colorkeying you want to achieve in OpenGL the classical SRCALPHA/INVSRCALPHA blending of DirectX? Or do you want something more exotic?

I wanted basic colorkeying that mirrors DirectDraw functionality. It's not about my having a problem though (as I said, it's been worked around), but about the fact that the problem existed. Unlike Direct3D, there's no 2D sprite drawing abstraction with SDL/OpenGL, unless you forgo OpenGL.

Well yeah, that's the whole point, you have to forget SDL blitting and use the full expressiveness of OpenGL blending modes, and then build your sprite abstraction on it.

template<typename SUBJECT> const T& Andhaira(const SUBJECT& a, const SUBJECT& b) { return WhichIsBetterAndWhy_Discuss(a, b); }
Andhaira(OpenGL, Direct3D)?

Dude, this won't compile. It's not written in proper arabic script!

My bad, must be my codepage encoding!

Also you should have written SUBJECT& instead of T& Bonus point for going for const correctness!

Luckily I do C++ and not fucking Python so I don't spend my life relaunching to catch such trivialities

Nice avatar, I love the SKF NNCF 5010 CV (no I'm lying, bad memories from calculating such evil things during my studies)

By the way, for constness, I'm not sure discussing things on the Codex doesn't fuck them badly.

You make it sound like having to build your own sprite abstraction is a good thing. I suppose that's a matter of taste, but still doesn't change the fact that D3D has an actual sprite interface which is much easier to use than "not having one".

Yeah, spending life on reinventing the wheel, instead of simply typing

Code:

from pyslam import answers

is much better indeed.

Luckily there are still people like me able to make wheels for Pythonists to be able to do their oh-so-brillant one-liners.

..I really don't like Python. The syntax is just ugly IMO. However, from a purely technical point of view Python is a good choice if you want to make an old-fashioned 2D RPG. I do not actually recommend using C++ if you are a hobby coder and just want to make games which aren't too demanding. Java and Python are the sane choices there. One of the most complete open source RPGs I know is written in Python: https://bitbucket.org/featheredmelody/lost-sky-project-public/wiki/Home



I thought I could be the first guy to write an open source Tactical RPG (no Wesnoth does not qualify), but then I found out about that project.

Also demonstrates one of the advantages of Python over Java. On Windows you can distribute Python software as a stand-alone executable i.e. no worries about making your users download a particular version of Java.

What makes pyhon more suitable for such things than ruby?

Infrastructure mostly. Ruby is barely used for anything but UNIX hipster webshit. Which is a shame. I love the language, hate the community and implementation. Almost no one writes games in Ruby, thus you are pretty much on your own, have to write your own bindings to C/C++ libraries or rely on some buggy, definitely not industrial strength effort by some lone basement dweller. And good luck distributing the result, most Ruby coders barely care about anything not Mac OS X/Linux and you are supposed to use corporate web server style deployment systems which are unsuitable for distributing your games to the unwashed masses of Windows gamers. Again you can go where no man has gone before, and try to combine that basement dweller wrapper (e.g. Gosu) with a basement dweller Windows .exe builder (if you can find one).. good luck with that.

In contrast, hobby game coding is an officially endorsed use of Python, Windows is a first class citizen, and there is the rather active pygame community. The problems one might encounter when making a game have been encountered by other people before you, thus you can probably google the solution. And pygame has received some serious stress testing by now. Many games are based on it, including the one I linked.

Community/infrastructure/implementation are usually more important than the language itself.

I use C in my professional life (gfx driver developer) and C# moonlighting (with or w/o XNA).

BTW, for those of you complaining about C# not being portable: it is very much portable at this point. Mono supports 95%+ of what .NET and C# compiler provide (and most of the stuff missing isn't compelling for games anyway, e.g. code access security). It does support C# 5.0 features (with lovely async execution which makes AI and state machines so much more easy to develop) and there's a XNA port for pretty much every platform one could care about (OS X, Linux, iOS, Android) in the shape of MonoGame (development branch has pretty solid 3D support as well so we should expect stable release this summer).

So, yeah. Haters gonna hate.

As someone with a limited knowledge in C, what language is easier to learn, Python or Java?
Which of those two is better for some indie developement?

Java.

Because when you give up on trying to make games, you will find a job in software industry.

Languages don't matter for games. Unless you're going INTERCAL or something.

This is because if you're any good, and have any hope of making a good game, you actually need to do a shitload of coding and absorb numerous concepts. You either know how to do it well, or know how to do it shittly. And this comes with practice and reading and thinking.

Java is a language done for teams of programmers that don't want to deal with pointers. Python is the same, but untyped and for cowboy programmers.
you're a cowboy

Go with C# (and XNA). It's very similar to Java, only good and useful

Java is still faster wanker.

(except admittedly on a critical part for games gfx - no union/tagged union types for gfx driver marshelling - for now)
http://hg.openjdk.java.net/mlvm/mlvm/hotspot/file/tip/tagu.txt

Personally i think "java the language" is going to be retired soon in a python 3000 like transition. They are adding the prerequisites for that.
Namely the jigsaw thing - that looks tailor made to break up the JRE, which means embedding, which means android competition project. Hotspot is still the best and most portable VM around. On the pc it means distributing java with your software is not a total pain anymore since just hotspot and a minor part of the jdk can be 2-4 megabytes easy.

Python, unless performance matters.