1) only the thread that makes the display can load/draw video bitmaps. All other threads use software bitmaps, and those are slooowwwww...

2) You could search the forum for multithreading here on the forum. I have learned a lot from those threads. Otherwise, just try and understand the example programs.(play with their code a bit and you might get to understand threads better)
You might also want to look at some online tutorials about multithreading to get to know what threads are generally used for, what the popular design patterns are,...

Do you mean that you are loading them in a seperate thread? If so, bitmaps won't load with hardware acceleration, thus making the program terribly slow. I have no idea why they would get blacked out though... Did you properly initialize allegro?(al_init_image_addon() etc.)

• separate the simulation logic from the presentation logic.

• update the simulation in a worker thread.

• when the worker thread is ready, send the simulation state to the presentation thread, i.e. the main thread.

• the main thread then draws the current simulation state.

• UI commands from the main thread should be sent to the simulation thread as messages.

Generally, think about the problem has having two programs cooperating: one program does the work, the other displays the work. They communicate by messages.

It should work... could you give us some code?

Do you see that in thread 2, you got a nested loop? you've got one in Thread_2 AND one in NewMain. Thread 1 isn't working because thread 2 never releases the mutex on data(until you exit the NewMain loop)

APPEND: I don't see why your code compiles... main() doesn't return.

You can draw to a display from a thread but that thread has to own the display. Allegro lets you change ownership of a display using the `al_set_target_backbuffer` function. If you created the Display in one thread and want to use it in another, you first have to `al_set_target_backbuffer(0);` in the creating thread, then do `al_set_target_backbuffer(display);` in the thread that wants to use that display. This means only one thread can draw to a display at any one time.

If you want to load bitmaps in a separate thread, make them memory bitmaps, then make the main thread al_clone_bitmap them all as display bitmaps. Loading bitmaps in a secondary thread will cause those bitmaps to not be connected to that display, and make them very slow to draw.

Ah, that clears alot up, although i got one last question your saying that i only should lock the mutex when it's sharing data, what kind of data do you mean and why should i use it than anyway?.

Ah okay thanks i got everything working now although i got one kind of a stupid question, because when i want to load files i normally just would call a void in the main thread for example, although that's now not possible so when i want to load a file for the main thread but don't want to make it freeze i do something like. if(data.load_map == true) map_load(data.map_id); in the (child) thread and in the main thread put the data.load_map = true; are there easier ways to do this? because this seems like a pretty bad solution..

Sorry for that,
Anyway i'm pretty happy with what i've done so far, i'm able to load almost everything in the worker thread, and actually everything is running fine except when the first thread is using the display, and i want to load the graphics in the the second thread the screen doesn't show up normally but goes like
black-normal-black-normal for a few mseconds. any ideas how to fix this?
Sorry for my bad english anyway.

so that means you always have to load the graphics in the presentation thread?
because than the presentation thread still freezes for a second when i load a map that needs new graphics.

You can use al_clone_bitmap/al_convert_bitmap from the main thread (like ex_loading_thread in SVN does): https://github.com/elias-pschernig/allegro5/blob/master/examples/ex_loading_thread.c

It converts the bitmap to the current settings, much like:

bmp = al_clone_bitmap(bmp);

The main difference is that the original pointer is still valid.