24 replies to this topic

[Johnell]

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. 

Edited by Johnell, 25 February 2013 - 02:48 PM.

[frob]

As this is a For Beginner's post, I *STRONGLY* recommend you avoid multithreading for now.

 

 

 

Multithreading is an incredibly difficult thing to get right.

 

It makes existing bugs an order of magnitude harder to fix.

It creates new bugs that are almost impossible to trap in a debugger or logger.

 

After you are an experienced developer you will eventually be ready to handle multithreading.  For now just realize that it is an advanced programming topic, mainly for those interested in masochism.

[0r0d]

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.

[Sollum]

If you wan't to learn MT, go for simple app, like FTP Client-Server. Write it with C for the fun of it.

 

It'l teach you one thing i learned - Don't resort to MT.... like ever... unless really needed.

Edited by Sollum, 25 February 2013 - 04:17 PM.

[KnolanCross]

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:

http://en.wikipedia.org/wiki/Dining_philosophers_problem

[Johnell]

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

[nife87]

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.

[alnite]

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.

Edited by alnite, 25 February 2013 - 05:15 PM.

[Khatharr]

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.

[ic0de]

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.

[King Mir]

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.

[DevLiquidKnight]

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.

Edited by DevLiquidKnight, 25 February 2013 - 07:35 PM.

[hikarihe]

does OpenGL handle multi-threading in the GPU for you when drawing?

 

 

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

[Milcho]

I haven't dealt with SDL that much, but I can tell you SFML actually has multi-threading, made relatively easy - there's a brief overview of the 1.6 version here: http://www.sfml-dev.org/tutorials/1.6/system-threads.php

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.

[Olof Hedman]

does OpenGL handle multi-threading in the GPU for you when drawing?

 
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.

Short Answer: its impossible to tell in general.

Edited by Olof Hedman, 26 February 2013 - 06:20 AM.

[Johnell]

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

[hikarihe]

POSIX looks good

[Nercury]

I recommend boost::thread if you are comfortable with C++ STL.

 

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.

 

I did a quick glance over several recommended guides and this one seems to be quite good: http://www.paulbridger.com/race_conditions/.

Edited by Nercury, 26 February 2013 - 12:19 PM.

[King Mir]

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.

[King Mir]

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.