Friday, January 1, 2010

ViruZ update 9

I'm now using OpenMP (2.0, because MSVS did not update it) instead of Win32-Threads.
This way, I don't need to re-write my threaded-code for each platform, or disable it on specific ones.
It's supported on the platforms and compilers that matter to me, so it fits perfect.

I also optimized the threaded routine a bit, and I got an even better idea, which is quite simple:
One thread draws, the others update.
Since drawing must be synchronized, this should do a bit better than my current approach, but I have to think of a good solution of how to tell the draw-thread, what it can draw. Maybe a synchronized queue. I think my current approach would be better than this though. We'll see.

Because implementing parallel processing on loops with OpenMP is piss easy, I also added partial threading for my serum, with the result of the frame-drop being almost negligible now. Very nice! <3 OpenMP

And I fixed that bug, which caused the program to hang. After all, it was a memory-overflow. I'm not sure, why the program didn't crash or something... it was very little and I don't understand how that caused the program to not work anyways.
I used CreateRectRgnIndirect on a rect, and passed the result directly to InvalidateRgn. But you have to DeleteObject on the CreateRectRgnIndirect.. I didn't cache that into a variable, because it's still from my early code.
I've also done it in the loop, because I expected the region to be cleared after a call to UpdateWindow. Now I am also just using GetWindowRgn (still have to DeleteObject that though ;)).

I found that out by looking out for unusual processor usage. Since the memory-tab is right besides that, I noticed that it kept going up and stopped right when my application stopped drawing.
I tried out various things, until I just outputted a randomly chosen value each frame with the WinAPI and it still stopped.
I lookout out if I had pointers anywhere and at some point, CreateRectRgnIndirect caught my eye and BAM fixed.

I should also point out my thanks to schnitzl for that bug. Else it might have gone unnoticed for a long time. And more code means more to look after.

No comments: