I was only able to fix a few small macros misuses but everything else seems totally fine. But since it works fine without debug calls, I assume that the actual problem lies within the qmutex acquisition. All points to this - especially considering the fact that ALL threads stop working if the error occurs. It's something I forgot about using qmutexes: a thread shouldn't lock itself twice. Simple to prevent when KNOWING that one got locked before totally works but when having just thread numbers and local objects there's no way to do this contextless. The only way I know is using a hash array with process IDs as keys. I don't like this approach but I can't think of anything else that could work.

Fuck! Why does it always have to be the hard approach. I mean everywhere I start digging my head into I have to create something totally out-of-usual in whatever combination. Sure, this may induce that result will be quite a reward but at the moment I was hoping for a finish on this. I mean what's the reason for having a great tech if you can't debug it properly. Therefore, I will fix this debugging shit the next time. Currently, the actual functionality is there, there is a buggy debugging output. So I can safely include it in my application/portefolio thingie. Yeah, I think it's the best idea to freeze it "for display" and work on it in a different version. Today I would've loved to do some graphics coding or so. Something that's not just fixing old stuff. I tell you, this will be one last big modification and after that I only want to look forward with it. It's the last big part of this part of my toolkit, or rather THE big last part on this toolkit I had in mind. The rest is just merging, interface overhaul and so on. I'd like to finally burry it, doing something with rather than expanding. I''ve been thinking about the ASCII raytracer game I wanted to create as a demonstration and I'm right now not exactly sure if that's the best idea. Just because there are so many things I'll have to plan carefully if I don't want to let it become anyother spaghetti code demo like it was in the beginning. I totally underestimated the general idea of it (along with the wanted accuracy of the physics engine, required levels, gameplay, ressources and so on). I don't think it's a good idea to fixate it as the definitive demonstration of it. Even more, I won't my marks on the project itself but on the way I've done the paper, the general explanation, motivation and scientific background of the project. So in essence it's not th main part of my project (the toolkit is) and I can create anything that profits from parallization and so on. But still... the vision of seeing a smooth high-res ASCII renderer with light and HDR is... awesome. Well, I will just focus on the tech to be done and go wild then. Nobody's cares abot the game's crude internal simulation. So I should just go ahead take the next best easiest of what I had in mind. I'll completely focus on very simple mechanics so that the gameplay and it's fighting doesn't base on any value circus. This makes life and interaction a simple logic-base setup Ican design with some if/else constructs. I utilized this system in my 1D game thingie I never really completely started. I actually had some sort of scripting system in it (though table-based and pretty complex to program). Funny that those two projects, rather alternative in nature, where the ones that motivated me the most. And I guess it's only understandable that I want to have something like that back again - not only the primitive atom-by-atom work below.

Hm, have to think about this. I only know that if I don't solve this debug prolem I'll not want to start another thing.

No comments: