Multithreading - A world of hurt
by
, 02-06-2011 at 02:37 AM (36189 Views)
So you'd think multithreading is hard, until you get the baseline multithreaded console application, and then its easy. Untill you delve deeper into actually integrating it into some useful code and the it isn't...
Multithreading: dum all the engine's stuff into its thread and let that do constant housekeeping while you write your game code - perfect. Or not really: turns out that my initial fear of two threads accessing the same memory address at the same time is invalid, or rather misplaced. It has some truth: synchonysis. I saw that on my first live particle effect demo app. My main code hadn't finished drawing all the particles they were already on screen! And then they were gone at the same time when the engine thread decided it was going to clear for a re-draw. Hmm...
All that aside, I've now spent 3 hours burning the midnoght oil and beyond (now 3:32 AM) with an end in sight. Its all synchronized thanks to a single procedure called at the end that tells the thread something like, all data is drawn, you may now handle the video data and we will wait for you to finish instead of letting it handle my windows and etc...
All in all its quite nice, I cal one procedure once every game cycle, it handles the window, flipping, events (updates a variable to check later), keeps my FPS stable and lets me get on with whats what.
However, there is 1x weird occurence: it ignore the last draw. Seriously. I don't know if it's to do with render code or the multithreading but hey thats the way it is. And calling
from within the thread has no effectCode:glClear(GL_COLOR_BUFFER_BIT);
So far so good though, I have a standard procedure that does that for all game modes. If there is any interest in this, I might add it to Prometheus, but its a royal pain. Now implementing a random 'dummy' draw before the thread so it all works - its cheating I know but voila.
cheers,
code_glitch.