I'm looking to make a little game project of mine and could use some advices.

I'll be using C++ and i'm aware of both SFML and SDL. Are there any other good 2D libraries out there for C++ that I should know of? Secondly, I wanna learn more about multithreaded programming so I want to make a game that would force me to use this.

Any advices on a game project and what 2D library to use would be appreciated.

If you want to learn about multithreading, why not do a project just to test and learn the MT stuff, outside of a game? Trying to learn MT while at the same time doing everything you need for a game is really hard, and will mostly lead to frustration and pain when you're starting out. Some of the worst bugs to track down and fix are MT bugs. So, I'd recommend finding some project that you can do as a simple console application that is highly parallelizable, and learn the basics of MT from there.

Learn and practice one thing at a time. When you're competent enough with how MT works, then you can start to think how you can apply it to a game engine.

Most engines will hide MT from you, they let you execute your methods/functions every n frames or every n seconds.

If you are looking for a good 2D one that is C/C++, I really like orx, since it allows you to change things in your game really fast and supports nearly everything you need (such as physics and particles). The only drawback is that it has no network support, also, you won't be able to use threads on this one (but as I said, every engine I know will hide MT from you).

If you are really into learning MT, go for the classic problems, such as the dining phylosophers:

If you want top-quality reading material with C++ (specifically C++11 and its standard threading library) and threading in mind, I can recommend C++ Concurrency in Action: Practical Multithreading by Anthony Williams (http://www.amazon.co.uk/dp/1933988770) and Herb Sutter's many articles (http://herbsutter.com/).

Pre-C++11 you can use boost::thread (nearly identical to std::thread in C++0x/C++11), so any articles concerning std::thread can also be applied to earlier versions of C++ supported by boost.

As people have said, multithreading needs to be threaded carefully (pun intended).

If you truly want to learn it, here's a fun thing you can do: make an audio player. With SDL/SFML or whatever GUI lib you decide to use, create a Load, Play, Pause, Stop buttons. Then there should be an audio playing in the background. Try playing a really big audio file (100MB WAVs), without loading it all up at once. Playing audio must be done on a separate thread. Load/Play/Pause/Stop buttons must be able to signal that thread appropriately, and the audio thread must signal back to the main thread.

alnite, on 25 Feb 2013 - 15:21, said:
As people have said, multithreading needs to be threaded carefully (pun intended).

If you truly want to learn it, here's a fun thing you can do: make an audio player. With SDL/SFML or whatever GUI lib you decide to use, create a Load, Play, Pause, Stop buttons. Then there should be an audio playing in the background. Try playing a really big audio file (100MB WAVs), without loading it all up at once. Playing audio must be done on a separate thread. Load/Play/Pause/Stop buttons must be able to signal that thread appropriately, and the audio thread must signal back to the main thread.

That's actually what I was going to suggest. +1

Before you get into that bundle of fun, though, you should probably just sit down and play with making small threaded programs that don't do much of anything, like looping counters and the like. Understand what mutexes and critical sections and such do and how to use them. Understand how to terminate a thread from within itself or from another thread. Get familiar with the functionality of your chosen thread-lib basically.

void hurrrrrrrr() {__asm sub [ebp+4],5;}

There are ten kinds of people in this world: those who understand binary and those who don't.

What kind of projects would allow me to focus on multithreading, while still building something?

I wrote a multithreaded software raycaster one time and it was really fun, I then ported it to the GPU. I find some things work naturally for MT, the two situations I find it particularly useful in is either when you need to do the same thing over and over again on different data (eg. my raycaster) or when you need to do two tasks that have almost nothing to do with each other.

you know you program too much when you start ending sentences with semicolons;

I think a good elementary use for multi threading is when you have a GUI that launches a background task. That's a fairly widely applicable kind of multi-threading. It comes up less often in simple games though, because they tend to need every calculation in every frame, so they just alternate between computing tasks, and drawing to the screen in a single thread.

In general, multi-threading is a way to achieve speedup, so it's not strictly necessary.

The best way to learn multi-threading is probably a book or course. There are a number of techniques that are used and which one is the best varies depending on your application, so you need to know all the tools in order to figure out how to parallelize a particular program. Unfortunately, in my experience courses have not been very comprehensive either, and I cannot recommend a good book.

The book The Art of Multiprocessor Programming, is a pretty good beginners book for this subject. However, it uses mostly java programming. But it can easily be transferred to the language of your choice.

SFML2 has some changes to the threading, making it (in my view) even easier, but the above tutorial is still useful.

Yes, as people have mentioned, multi-threading is a pain to debug and can take some time to wrap your head around it. But there's no clear point at which a programmer can be considered 'advanced' enough to start dealing with multithreading. In the end its just another tool, so as long as you're not discouraged by failure (we all fail when trying to do something, the point is to not give up), and don't mind banging your head against a wall (figuratively) for a while, then you could learn multithreading even as a beginner.

The GPU is it's own hardware that runs independently of the main CPU, so yes, kindof. It's more then just "a different thread" though, since it's entirely different hardware, and your shaders will most likely be run as not only one, but a bunch of threads in parallell.

also is there any big difference in performance if you use multi threading for games, say for your update functions ?

The gain you get with multithreading depends on the problem you try to solve.If the tasks you do in parallell has no dependencies on each other, you might get close to NumberOfThreads times the performance, but a game engine states is by its nature quite dependent on each other, having lots of requirements on what needs to be done before what, and is very tricky to multithread in an efficient way.

If I tried to explain threading in one paragraph, I would say that your worker thread function is absolutely safe if it does not interact with outside world: does not read/write any variable except it's local ones. Of course, this would be useless. But once you have isolated your worker thread, you can begin serving it the tasks to do and receive finished work. This serving/receiving process is the main trouble of threading, but once you identify it, it is a matter of synchronization. The most basic synchronization mechanism is allowing only one thread read/write the serve/receive queue, and we call this mechanism locking, which at lower level is entering and exiting a critical section.

I think it is crucial for programmers to get familiar with threading, learn it and use it when appropriate, because modern applications and our CPU architecture really demands it nowadays. However, you better know exactly what you are doing, because threads are very confusing to debug for obvious reasons.

What multithreading library would you recommend for C++? POSIX, boost?

I would say the most portable and general purpose way to go is C++11 threads + boost. C++11 is incomplete in providing high level threading tools. They put all the basics in, but not all of the high level structures built on top of them.

Unfortunately, beginner material using the two is probably gonna be hard to find. C++11 is too new.

If the tasks you do in parallell has no dependencies on each other, you might get close to NumberOfThreads times the performance, but a game engine states is by its nature quite dependent on each other, having lots of requirements on what needs to be done before what, and is very tricky to multithread in an efficient way.

Slight nitpick: The speedup potential of parallel threads approaches the number of cores, not the number of threads.