I had my thoughts about hash arrays today and whatever way you try make them useful, you'll either end up with too much required memory, horrible performance or a limited number of keys to store per hash array cell (can be increased, too, but will then result in poor performance, too). The best approach is then always to have an awesome hash function. Therefore, hash functions are very most important thing an hash array (interesting that I'm going through all the stuff from the first few semester...). And since I'm friend of tinkering too much with hash functions, I'm tried to somehow find a new way of storing the associated hash values with static memory. This is not trivial I have to say. Using new and delete for linked lists is very easy way to do this, but personally I want to use hash arrays to map indices from the hash array slots (n per hash array, forming a twodimensional array) to an array of actual data. This is of course not a very popular way of using hash arrays, but it's more dynamic than using a pool with an iterating index cause you WANT to directly the associated hash array data and don't share with anyone else. So it's more like a pool but with the possibility to get data by a key value. Anyway, I want to give the possiblity to occupy and de-occupy slots in the hash array to make it function more like proper pool. Occupying an entry is rather simple and only requires a few iteration through the hash array until a valid one was found. But - and that's the point where I annoyingness comes in - when do you if the requested key does already exist? When do you that there's no associated entry so that you'll have create a new one? This is exactly the thing that's bugging me. You'll probably need to iterate through all cells (or maximum number of them, limiting a cell to only take from n close neighbours) to cover this problems if you don't want to utilize linked lists. So what I'm trying to figure out is a way to not use linked lists but still have a runtime behaviour until you notice that you'll need to allocate a new entry. Currently, I'm thinking about splitting the key into several parts and split the hash array slots/cells into different dimensions. That means that I'll be able to sort large keys with different binary signature into different parts of a multidimensional array. This Each part will be hashed on it's own, using a different direction in which they will go if all associated slots got empty. I think this could work better than a plain single hash array and I can use some more fuzziness, utilizing the randomness of hash keys that are system handles or addresses. Good thing is, it's a bit different from the project itself and I'm glad that it doesn't have to do anything with mutexes or threads. I mean the tech is working quitely nicely right now, though I haven't done any more wild tests. However, I'll this project in the current state, comment the critical debug sections and be done with it for now.

Aaaaand, I'm gonna buy a headset for doing Let's Plays! Yay! That'll be fun I tell you. Will cost me quite a bit but good hardware doesn't usually come at low cost. Especially not for a Sennheiser fanboy.


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.


Debugging the debugging

I took the time to reject some of my condition/debug macros and directly used them in my code. It seems to work fine (which means that I can put almost anything I want into them) but noticed something weird that's related to the debug module itself: strange random freezes when debug is on. At first I though it may be related to too few qmutexes in the debug pool and increased the number. Even with 100 mutexes, I got the same error. But choosing only one (means a lot of asynchronous debug message), I even got segmentation faults. So I has to do with the debug system. That's totally ok because this eliminates another one of the sometimes random freezes I had in the past. However, I didn't use my macros before that, so it's probably a new circumstance showing up a previously uncovered problem. Anyway, completely omitting debug messages showed up no problems, therefore I think that the system works perfectly fine with the current tests. Anyway, there are sometimes situations in which the execution takes considerably longer. I know this behaviour from previous tests and do atleast know that it comes from some sort of loop in which the a tasker does repeatedly pause itself while another threads seems to resume it. Haven't yet seen it happening in a reproducable manner but I'm doing my best to fix it later. First I need to find out what's fucking up my debug system. However, I'm very glad that the rest is working so well. All I need to do is to include a single file and #define options before including. it's very nice to have such a simple setup that gives me the freedom to auto-log everything. So for now let's get back to work.

Some more thoughts about Skyrim and conjuration

Today I started Skyrim out of total randomness and played around 16 levels or so and simply can't get this conjuration stuff out of my head. Right now I'm playing a stripped-down version of my very first character with focus on more magicka and sneaking: heavy armor, destruction magic, bow for physicals damage and sneaking plus some bit of smithing to get a decent armor set. I've put points into life every third level and dropped stamina completely. I do have quite a lot of mana now and it has useful effects to combine multiple elements together depending on the foe you're facing. Melee characters can be frozen and stamina-drained with a small ice blast and killed with powerful projectiled spell on the other hand. For mages the tactic goes but with electrification. This works well so far but I've already started to use smithing to often and I think the best thing is to just ignore until everything else is maxed in terms of potential damage. And I also have enough mana this time! But still, I'm once again thinking about conjuration. I can remember from my last character that an extremely offensive build did work quite well but the mage armor was a problem in close-quarter combat and damage receiving in general. To avoid this, heavy or light armor is the way to go. However, there's still the problem that conjured weapons will never deal to damage one can get with smithed weapons (I read something a third of the smithed/improved versions). I wasn't quite able to get a better damage output for my last conjurer but I think that was rather related to me beeing unable to get damage and not having upgraded fighting skills. I still believe in the power of dualwielding, but it takes too much stamina for a character needing mana for casting as well as life to survive. Additionally, the shortcuts for spell/item selection are a pain too switch when needing to conjure two weapons at once. Dualcast equipped mage armor, dualwield conjure sword, dualcast sword, start fighting until spell or mana runs out. Quite annoying to cast all the time and you also need to conjure a creature or two in time to support your weak armor/life. So my new idea is to use an armor from the beginning on (heavy armor once again, gives best protection in the whole game), use mage armor for limited but additional support and use a conjured battle-axe that requires only one hand to cast. The idea is to shorten the fight readying with only mage armor and the bound axe, casting mage armor a bit earlier and then having axe and armor ready to go. Not using smithing but mage armor for additional protection give a similar affect, though not as awesome as completely upgraded dragon armor or so. So we have two-hand specialization, alteration, heavy armor and conjuration. Sneaking or archery is no viable options since we'll need to more skill trees and conjuring weapons is just too load. Sure, we could use illusion to bridge that, but this will require even more skill trees and the whole reason for fighting with sword and armor would be gone. I was never a fan of illusion and only used sneaking for bow kills - even in Oblivion. I was never able to get close to enemies and still prefer to take them from a distance or up-close right in the face. Four specializations is the best way to get through Skyrim without feeling weak I think. Personally, my problem is that I can't leave any chest (increases lockpicking) or not sell any stuff I find (increases speech). Thus, I'm often stuff with a mixed character with experience in stuff I don't really put spells into. This could work for skill trees with few multi-tier upgrades (like Destruction or alteration) but not really for fighting trees or even alchemy. These requires so many points, it's hard for me to not level up with speech and lockpicking. I also don't get any advantage of it. Money is quick to get and locks are picked equally quick. I've never spend points in these two trees cause I just don't need to (yeah, I'm that badass, I can pick master locks with no needed skills... seriously, it's very easy once you get a feeling for it - just like in Oblivion). So it's a bit tricky. I might consider resetting everything once again. I feel bad for having screwed my character with two levels completely made of powersmithing. My bow makes more damage than my spells, this is no good thing I say you.

Also, I want to get a better microphone to do some sort of Let's Play. Don't know whether I'll do in German or English, really not sure. Since I'm blogging in English all the time, this would of course be a valid reason to make the Let's Play English, too, but it's not exactly the easiest thing. I'm not too used to speaking English, I just got used to consuming it in every possible way I could right now imagine but did not do any actual mouth-to-heard practicing.

Anyway, if I'm ding this Let's Play thing I'm probably gonna try my conjuration character. I'd like to finally have one beeing able to bash the hell out of others while beeing quite the tank. With some companion and conjurations, this should be boss for most boss piles.



Now that my task system works, I can safely overhaul my set of debug and function return macros. Instead of using three or four they can be put them into a few more compressed ones. Since I want to have extensive logging functionality and possibly failsafe execution for all possible functions, I'm hardly using macro-less C code anymore. It's pretty comfortable as I don't need to manually add any debug message, return commands and so on. I'm speaking about a bachelor project right now, so anything to make it better is a plus and should be kept in mind. Also, it makes development and bugfixing faster since you don't add any tracing, external debugger or so - everything your need right there with a few macros!

So yeah, that's the way to go for the next few steps. I only have to pack my demos and binaries for my intership application this weekend, so I can fix up ITK with these macros to make the whole stuff looks less patchworked (seriously, it doesn't look appreciatable right now).

Some games are made for watching

Not exactly, but I noticed that the more I'm watching videos of a game I did not find completely suitable in the beginning, the more I find it entertaining to watch players having their different experiences with it. That's especially the case for games that are exciting to watch in gameplay, like Demon's Souls or or successor Dark Souls for example. Sometimes I'd like to play it - the sudden urge for trying out a few on my own - but most of the time I know that I'll have trouble with games that don't suck me in right from the very first moment I saw them animated. And, to stick with this game, Dark Souls is one of these very games that are highly interesting to watch but don't try to at least motivate me to play them. And I should be thankful for that! Because it means that I'll always something to watch if I want to. Finding good Let's Play's or even Let's Play-ers is very hard on Youtube, you know. Additionally, playing a game requires active time investment and drains the entertainment factor cause one will always think in terms of a player and not a watcher. I can't exactly explain it but it works for me. I longed for more parts of a Terraria Let's Play before I started playing it on my own. That simply reduced after that and it's a bit sad I think. However, the "long-term investment" of actually playing it was quite worth it since the game is forgiven enough to let me have fun with it. That said, I'm sure that I'll not try to play Dark Souls unless it's for PC one day and available via Steam as well as not too expensive. So if all three things come together, there might be a moment where I buy it to have a bit of fun.

But well, there are many more games that give me fun more instant. And they don't let me die all the time.



I found and solved the problem. To avoid having a list of dynamical or pool-managed mutex/qmutex allocations inside the thread manager I simply stored right in the thread itself, making the overall implementation a bit simpler but more difficult to use in the end. However, due to thenature of a qmutex, each currently or previously involved qmutex must not be deleted until all threads that may still be in the qmutex query left it. More specific, the problem lies within the per-qmutex linked list data cause every qmutex is also an item in a linked list. And what happens when a linked list entry gets deleted? Right, it cannot be accessed and thus not everything will work out fine. But that is not the actual problem, it's it associated mutex object that will be deinitialized before the thread manager doesn't use it anymore. It's a very fragile system and there's not really a way around to solve it without more system objects (and I'm really using a lot right now). However, keeping these rules in mind and also writing them down so that others may follow them, I can build a more comftable interface doing all this stuff for me. Cause in the end every game or simulation has a fixed number possible threads and one can prepare them in the beginning. So yeah, riddle solved! That makes me happy. And it also means that I can upload it in the current version, add some documentation and have a good example of what and how I'm currently working on it! Good for my internship application. I mean it's an internship after all and no test or run for a job. A good friend was kind enough to mention it to me once again. I tend to forget that and bury myself in unreal expectations about what is expected from me. Nobody can't really expect from a fresh student to already have production-quality experience - that's what a student's internship is for! Anyway, I'm happy that I didn't do anything wrong in the library code but only just used it improperly. Well yeah, that's always the problem with newly created technology: one always has to test out how and where to use it, even it theory and implementation are totally your own. Also, I'll upload some Windows and Linux binaries of the old 3D chess game viewer I was working on for an uni project as well as a small OpenGL graphics demo I did out of a similar reason. Even if both of them are rather not what I'd call proper, they are a good representation of what I usually in limited time and a bunch of more or less complex problems. In fact, the chess game viewer has some pretty non-trivial things in it (the parser to be exact). I didn't cover the concept formally in the source code since it's all very, very chess-specific and time was limited. Well, I think those three are totally enough a long with this rather pathetic Java game for which I did admittedly quite good-looking graphics! Definitely have to say what I did where to not let the spaghetti code or other people get on my account for sure.


I'm doing a bit of bugfixing for my engine right now and I'm far enough to only have one anomaly left: sometimes the lock object for the thread manager will kind of freeze and stop every accessing function as well as the manager itself to to anything. It seems to happen when unbinding a thread from it's manager, so that's the part to debug I guess. However, I realize how useful it would be to have all return values from my function return/condition system (and maybe the state stuff, too) inside the debug output will less stuff to write. I have to define a debug variable, a parameter condition and enter/exit log message all the time. I could put it all into the parameter condition and the function return. That would do the same as well as freeing me from typing it all the type. It'd also cover a significant amount of function call I don't always extend from debug messages. Some #define statements for per-module adjustment and everything should just work out fine. But that's the next after I fixed this last bug. Don't want to overhaul something doesn't work totally correctly.


First try, hard fall

I'm quite confused about using Visual Studio's "New Project" possibilities. Normally, taking my Linux approach of course, I'd simply put all required libraries and includes into the compiler's directory stuff (lib, include and on Windows bin, too). But since it's Visual Studio on Windows and not Linux, I tried to follow a "guideline" for how to setup an OpenGL project using Visual Studio but quickly failed due to the fact that essentially all project types will add some that's not simple, plain C code. I didn't want to create a Windows GUI application or something else specific - just a plain project with OpenGL. After trying a so damn primitive and simple empty main function project, I was able to just do it the same way I'd due it under Linux: add libs to the compiler, include in source code and compile. Simple, clean, works! No damn extra layers, no extra functionality and no Windows compiler code stuff. Exactly the way I prefer programming. So yeah, it's up and running and I can and I got my small Computer Graphics assignment executable. That also means that I can now do the same with SDL and continue my roguelike raytracer when I find the time for it. I'm glad it's that simple. I know that there atleast projects for console applications with Windows-specific console commands, normal Windows targets with WinMain and event stuff as well as some rather very, very specific thingies I didn't really now know. I mean I don't care for Windows forms or DirectX. It's one thing to create a library or even custom language to do a task, but everything else... Well, let's just say I'm not that much into things work like a lot of custom Microsoft tech - and I doubt that I ever will...

I feel so bad about this

I feel so bad about including my roguelike raytracer. I mean it's exactly that kind of thing I simply didn't finish for a dozen of reasons but it always stays in my head and I can't get rid of it. It seems like a big wall behind which I can hide all the strange things I did between now and before, you know. All my optimization-for-nothing freakery, all the stupid "I wanna make this programming language" stuff and so on. Right now I feel that really, really need to make this renderer happen and look so damn good that it'l rock off your socks in the second you don't even know about it. But I don't have to time for that right now. Exams come, need to make my expose and my application for the internship and so on. I mean I have a million of reasons and you can't show your slowly revealing skill with a dozen of last-minute projects and one that doesn't even compile anymore cause it was so long ago that every exe or main file you had simply vanished. I only have this gif and I'm very sad about about not having done a proper demo where you could move around and so on. The point that the project WAS in such a state, I simply didn't think about that fact that I'll try to carry it THAT far! Man, I feel so bad for this. For the fact that I didn't start continuing it earlier, for the fact that I can only show an animated if as "how it looks", about the fact that I didn't start with 3D earlier and so on. I mean in end the generalized tech between games is almost always the same, but I didn't do anything for showing that for months, not to say YEARS. I stopped working on it when I started studying and now I have to pay it back with only having a few gif animations. It's so sad. I have to change that. I'll start using Visual Studio for my project, will get ITK to work with it and then finally pass this renderer to the glory I didn't give it years ago! But until I can do that, I'll have to cope with other stuff... It's so annoying. Though I'm looking forward to do an interesting internship, I can barely show off what I'm capable off but only how well I spend time getting good at C and C++, nothing else. Atleast the chess game viewer works fine. It was very easy, but the Qt runtime is too big for an email attachment... I'll need to use Dropbox for that I assume. Will also try to get a little demo OpenGL to run on Windows, this is definitely something that nice to present, too. Oh and this damn JavaME game. Since I don't have any emulator anymore and I doubt the dudes checking my application have one, I managed to let my friend take a few screenshots of it. So in all cases I got four things that actually look like something, one WIP project with as-is code and two projects that are actually visible live and in motion. Gotta say the chess stuff looks still nice but since the actually visible part was totally last minute, I'm not sure if they even look at the stuff I was originally working on (if they even take a look at it). It'll probably be just as worse as if I had nothing but code. Oh dear.

Whoever keeping track of this - wish me luck. I could use it.


Windows 7, Visual Studio and the miraculous working of my previously non-working mainboard

Alright, for some very wondrous reason my new mainboards actually started to work after playing a bit with the fan settings. Though very unexpected, I saw this as a reason to continue, install first Windows XP, then downloading a my student version of Windows 7 via stupid Windows-only download manager and eventually having a 64bit Windows 7 version. And I have say that was really worth it. Quicker in start and response, some very nice features (though other, equally annoying ones as well) and an overall better performance makes this change very recommendable. For some reason I decided to do some substantial changes to my old setup. These include randomly choosing Opera as my default browser, installing a student version Visual Studio 10 Ultimate and having only the necessary things I really need for playing and browsing the internets. I want it as clean and comftable as my Linux setup - just more media and game-oriented, you know. Less programming-only. That said, I installed Visual Studio out of pure randomness as well as curiosity cause I'll definitely development using Windows while doing my internship (for which I'm really care, trying to collect as much stuff that really represents my knowledge and experience - not an easy work if you're me). And I have to say that I'm very surprised how well this program feels. Interesting settings, good customization options... I wonder why I didn't like in the past. But I think I know why: bad german translation at first (I never tried the English version) and a strong anti-Windows attitude. However, setting up Windows 7 with such ease and sudden good experience compared to the know completely outdated and annoying Windows XP, I'm almost sold. Yes, that's right - me the one not wanting to use Microsoft software finally had a some experience with it! A miracle, I assure you. However, I said almost... Because VC++ still doesn't support C99 and C in general. My totally valid macro header file was barely understandable for VC++. And I really mourn over that. Right now, I'd totally use VC++. But if it doesn't support C99 and my macros, this won't work. It's said. Very said. Especially because I don't have personal code I'd write in C++. I'd rather code personal projects in Erlang than in C++ (oh and I think this a cool thing to have as a scripting language for a game engine or so). Well, too bad it can't be. I can't really blame Microsoft for having to proper C support as it's always a good decision for a company to use C++ methodology instead of C because it's quicker to development and easier to maintain. And I'm not saying this just of another randomness or so - I'm currently a lot of C coding and for everyday coding it's way nicer to simply write clean C++ programs. And I'm thinking about mixing C and C++ code in my final game, especially for the game's actual logic and mechanic besides physics and graphics engine. Hm, maybe I'll once again try to get it running under Visual Studio. I mean there must be some way to solve this problem. It's not that macros and parameters and not in C++, you know. I bet I simply did something wrong. Can't harm to give it a shot some day. However, getting anything else to run compile under Windows is a pain. I can't understand how I ever started using Codeblocks. It's total garbage and a commandline compilation with gedit is a lot easier than using Codeblocks under Windows. Linux is really a pleasure for such things. Just take a random library, use it's headers and link it. Done, program works fine. Even easier is GCC's library directory, makes stuff dead simple. But on Windows? I gotta admit that the crux at all. Microsoft isn't very friendly there, but I don't want to start a personal war in my mind. That's stupid cause it won't help me in the future and never really helped me for anything. In fact, I had equally annoying problems with Linux, though not for development but installation and end-user experience. It's simply the opposite side of the medallion I suspect.

So anyway, my computer is running again with a new and nice system, no real ballast and some nice IDE. That should work fine for now. Development will be done on Windows, too, if I can figure out how and 3D gaming works fine as well. Oh and Opera is really a breeze to work with. Loads of great features, an admittedly peculiar interface customization but nontheless as likable as Epiphany, which I'll replace with Opera on Linux, too. And I need to find a way to move the bookmarks without per-link copying. Oh and I'm so damn glad that I don't need a CD/DVD burning program with Windows 7 beeing able to do so! Very pleasant, I can tell.

On a sidenote, I bought a very small but totally amazing to operate wireless keyboard with builtin trackball and mouse keys. Seriously, this thing is way better for certain things than my big and clunky keyboard. I can sit on my bed and watch a DVD with remote control without having to sit infront on the screen. I can grab the whole thing like a gamepad and also so everyday browsing with needing to move my mouse between laptop and desktop PC setup. Additionally, the small USB plug sending and receiving it's wireless data can be plugged into the keyboard itself for easy transport. So I got a low-dpi mouse and a keyboard in one. It wasn't cheap, rather an early birthday gift I made myself. The typing itself works astoundingly smooth and quick. I'm currently typing my whole post with this keyboard and it feels great. However, it's not as ergonomic as a big keyboard (could be training, too, as it is with laptop keyboards) and I wouldn't want to do some too critical spots in a game with it (where one has to feel the key that was pushed). But playing Terraria and Dead Island worked out totally fine. I'd use as my sole keyboard if it wouldn't require a bit of battery power to run. There's also no battery power or caps/num lock indicator which I believe is because of the fact that it only sends data to the USB plug and not the other way around. So in essence it seems like a very great, tiny keyboard. I'm glad I bought the more expensive version and not the cheap one. Wouldn't want to put it back now.

A great day I have to say! And even more great that I decided to freeze ITK for now until the exams are over. I'll need my sanity and brainpower to get as good marks as possible - they are the last one I'll get this semester. Plus that I need do some Prolog, too. Also, the sooner I get an internship and expose, the better are the chances that I get the internship I really want and so on. I'm confident that I'm not useless to the studio I'd like to go to - provided there website is up-to-date with their latest requirements. If not, I'll simply ask every developer using C++ for a possible internship with my "portfolio" of completed projects (funnily, only uni stuff so far as well as my roguelike raytracer...) as well as source code and so on. I can remember that the 3D chess game viewer was sort of GPL-ed... Dunno exactly. Whatever, I'll ask everyone, try to get in everywhere. I don't expect money, I just wanna get experience with professional development, do some game stuff with them, hopefully solve a few the occuring problems (I'm not afraid of long-taking nut cracking) so that there's atleast a win-win situation. And hopefully I can get the opportunity to meet some guys that can explain some of the more common used 3D game world techniques, how they solved problem xy and so on. That's the stuff most I'm most interested in, really. It's one thing to just read and let your brain work, another one to talk to and ask about specific details.

Oh boy, that'll be awesome! Only that was needed to bring this realisation to mind was a bit of gaming. Fascinating!

A sudden try

Out of sheer video game need, I desperately tried to find some BIOS settings to let this damn mainboard run properly and I think it has do with the fan settings. It was the only setting I changed, so I hope that it WON'T give me a random bluescreen. Atleast Terraria should run properly. But if other games works fine, too, there's hope that I'll play other stuff again, too. I really need to play a game before continuing with programming on ITK. At the point were rewards seem to abandon you, playing a good video game will usually give back enough spirit to remain motivated. It's the way I sharpen my sword and if it's getting dull and blunt, one will only be able to pound as heavy as one's own breath. And I have asthma, that's quite to chew you know.


I hate hardware

After the success I've had with my programm stuff, I've decided to give my desktop PC another and finally install an OS to play some games. You know what? It gave me a fucking bluescreen. I tried Windows and Linux installers, I ran memory and harddisk test, I tried tryed playing with the BIOS settings - nothing. There are a lot forum posts on the internets directly indicating that this is normal by this board and that my purchase was a total failure. However, I can't get another board supporting my old hardware and I'd therefore buy completely new hardware. Try getting a proper, unused board for am AM2 socket with DDR2 and PCI Express. I'm not into a dozen of online shops and don't want do so just to maybe get something. A friend mentioned some realiable shops to me and I think I'll either give them a try or ask him to help me assembling a new system. This is exactly the part I hoped not to happen. I'll need need a new processor, new RAM and a new mainboard. Atleast I can keep my graphics card and my harddrive. *sigh* Hardware really helps me. I'd always prefer having a system that'll work more than just 2 years, but that exclude an up-to-date graphics card I can run my games with Fuck it! Now I'm stuck with programming and watching videos. Shit.

State strings

I've tinkered with different state machines definitions and I have to say that I didn't the performant realtime variants. The most simple and fastest one is defining a multidimensional array having state enums as rows and columns and the from/to state as array indices. if the array value is true, the transition is possible: simply and effective. However, defining new states on demand is very hard to maintain since one has always to insert and expand the given array. Furthermore, the definition of transitions is error-prone, too as only has to constantly look up state values, rows and columns. And I can't simply accept this. Therefore, I've decided to use a state system that works with a "string" of states the object can transition to depending on it's current state. See, the actual path and life time of an object is defined by functions that can be called on it. If the functions des not change the object's state at all, there's no need to checking for a transition. Most of the time functions have rules in which order they have to be called, though this is irrelevant in the final code if everything is called in the right order. Therefore, I can create a state for every important function and define it's path with this string of states. State null would be the state terminator, thus each state should atleast be one or greater. However, this comfort and maintainability comes at a high performance cost as one might imagine

Fucking YES!

Holy shit mother of hell! My fucking system works! More than awesome! Hell of a success I say you! Freaking cool. Now I can do all the wicked stuff I always wanted to with multiple threads! EYAY!

Oh boy, that's makin me so damn lucky! Only thread yet to do is to prevent that threads will wait on their own, generating a deadlock. For this I'll need my state machine system and I thinkg it's the best idead to not just make some simple static arrays but do the whole stuff dynamically using variadic parameters to connect one state to many. The advantage of this is taht I can define a state, it's name and all of it's connection in one human-readable line and also iterate it's name later for easy debugging and display of object states. This is the best and most comfortable way to do. So since this stuff is almost completely sorted out, I can focus on some assignment stuff and the expose. I'll include a lot of stuff - possibly also ways of dbugging, safety assurances and so on. I guess there's nothing to stupid to mention since it's my own project. As long as I do and present it properly, everything should just work out nice. And if I got my expose, I can create some sort of loose game design document/plan with some mockups, ideas and the stages between the limited bachelor project and the additional stuff that will be added later. Maybe also use the archieved stuff I did with the bachelor as a base for the master...? Well, you see there's a lot of potential for project abuse in this!

Yay! Got no motivation to do my assignment for thursday or so, but I need to do it anyway. Will work on the expose during free days and weekends. This way I should have it done before the exams and ask my prof about it. I hope I my timing's well enough this time!


Bug termination

Ok, I think I found a bunch of smaller problems and two problems of more systematic nature. One results from the fact that SDL's GetThreadID returns the own thread id when passing NULL. A behaviour which will effectively leads to point where for some reason everything get's deadlocked or something like that. Shortly, I should build a state machine to prevent a non-starting thread from beeing waitable. The other problems comes from the unsurprising disappearance of a local variable which's needed beyong the function calls lifetime. Simply put, eliminating both of theses bugs should actually result in no flawless execution and further testing fun! Right now, I'm very convinced that I've become in analysing my own system with proper debugging messages. Well... I'd prefer to have my message a bit more "sorted" right now - a single stream of, though correctly timed, wildly mixed messages from all threads with no optically distinguishable differenciation except the thread number is a bit nasty to read. Therefore, I'd like to have a layout in which every thread gets his own column in a table. With some nice seperators, it should be way more easy to distinguish threads this way. However, I'd need some sort of clever "hey, detect whether this thread popped up, or isn't there anymore and also just find his column" mechanic to do this properly. You see, I don't want to pass thread-wide debug variables to every function - a criminal approach if you ask me. No, I'll probably create some sort of list and check what thread had which column. I could also use a hash array, so that list flexibility is only required when values look to similar. But darn, that would be a problem if a new thread kicks in. So it HAS to be a list. Anway, the whole debugging output is so damn non-efficient in terms of performance, it won't actually hurt I think. And if I want to use this whole system with custom task content and some more nicely done interfaces, I WILL want a good debug output - you'd want to, too, then!

No Terraria yet, but some bits about my bachelor project

I'd love to have a prof that does actually care about the topic I'm working on. And since it's my game engine and the associated game, it'd be quite beneficial if he'd atleast be into some bits of game programming or graphics or sound. However, my multimedia prof takes the "multimedia" term quite classic in terms of how to store, stream and play audio and video content. Thus, he wasn't really happy when listening to the topic I've chosen and it sounded rather disappointed about it cause it's not as multimedia as I think it is (and let's be honest, where else would a focus on overall game tech fit better than there). Well, I could try finding a game design/interaction design prof, but those would definitely not care about the tech behind or so. So I've decided to make the topic a multithreaded/streaming-focussed engine/framework for simulations and games. That is a good fit I think and will way better be a topic for the system/multithreading prof I know from a few semesters before. I'll create an expose of it and explain him the problems I have categorizing it and hopefully he will accept. He's a good prof in his area I think, but also a bit strange. He does seemingly never focus anyone with his eyes when speaking, due some of eye/lens problem I think. Dunno. Strange dude but very competent in his area. Therefore, I hope he's willing support my thesis and help with a few problems I might have in time.

Speaking of that, I've managed to update all files with the new thread system and am currently catching some bugs. Continuing waiting threads seems to work flawless with fast enough done task to possibly miss signals as well as with those of very long execution time. The only problem left is the correct ending of a paused tasker. For some reason the tasker will sometimes not end, though resumed and ordered to end in one sitting. Also, I've tracked down a bug to point where I know it's null pointer. But even after I've apparently fixed it, there are more coming up and it sounds like just false pointers to me. I'll track them down, all of them. Die, bug!



I'm so eager to play Terraria. I've been watching a Let's Play Together for a quite while now and I'm even more eager to play than in my previous Terraria post. It's one of those games that only reveal their full potential after you've played it for a while it seems. I'd even call it hot right now cause I'm having a some sort withdrawal related to not beeing able to play something. It's not that I can't get around with it (most because I'm having a programming goal right now), but it gives a lot of energy and satisfaction to do so. It simply makes me happy. And my only source of happiness right is the success of module test or watching entertaining Let's Play's as well as Sinfest of course. But that's all not comparable to the full joy of joy of playing a game together with another human. Or an NPC. Or even beeing able to fluidly run around in Minecraft. However, I'd love to play Terraria with my friends. Compared to Minecraft you won't run out of challenges due to it's extremely long way up and down and many more monsters, ores, items and traps inbetween. I wanna play it right now! Gonna install Windows before that, though...

New Mainboard

Hooray! I did successfully install my new mainboard and now I'm having a Desktop PC ready-to-rock, I just a need a 64bit Windows 7 version. So, in essence, I'll get it from somewhere and copy all my harddrive data to my laptop. It's amazing how fast my USB/SATA converter is. It takes not as much time as copying directly on the Windows PC I used. I believe this has to do with a) copying it on Linux right now and b) that I'm sort getting a certain boost with 64bit system (which I'm not 100% sure of as you might be able to guess). This means that I can now let all the stuff copy and continue coding. I had to change a bit more I guess (incredible how complex the strings between almost all of my modules become), but I'm almost there to test and verify full functionality of it. If that's done I'll finish an assignment I still have to do until thursday and work on some sort of expose, comment to full code and upload it under a license to have something to "fish" companies when applying for an internship. However, I'm not exactly sure what they expect to see then. There's a certain studio I'd like to get my internship from and they expect me to have "worked on a game project" in any way (they didn't really mention in what way). Well, I mean I can actually list some stuff. Some very, very old games from Blitzbasic/Purebasic times, I made music for "Das Püzzelchen", also worked on the graphical part of a JavaME game, created a simple chess renderer/animator in OpenGL for a 3D chess viewer and so on. And I've created several graphics demos (including my own ASCII renderer) and am working on my game right now. I think that's enough to clarify that I DID work on games or game-related stuff, though I really didn't completely finish a game due to my rising perfection madness in terms of output. So I shouldn't hide, I know the drill.

Oh man, that was confident. Didn't expect that from me!

Nah, drop that

I think I'm gonna use some of my function return macro thingies a bit more less. I noticed uselessly cluttered code becomes when using those macros infront of every command. I wanted to reduce error with this, but now I loose motivation just by looking at how unreadable it looks. Was no good idea to rewrite so much or it!

So I think I'll only check parameters. I mean really, most of the time system calls will simply work. And since my own calls will work if the system calls work, there's no actual reason to do this... Even if a system call will NOT work, I don't see a reason to carry all the return values from one end to another. It's like exception handling then, very bad idea. Guess I'll rather focus on state transition, which's just one line for the whole function...

However, I'll do this when I finished all the other rewritings. This time it'll be the last real rewrite for this stuff. After that, I FINALLY want to program something else...

In a not so totally far future

Some day I want to use all my tech to create some sort of gameboy - maybe on the NXT or with a more or less emulated performance behaviour. With a virtual LCD, slowly colors from state to another and so one. This would make a great hobby project and give me the lowlevel aspect I always wanted but never completely reached (due to the fact that noone really wants to give marks for such stuff. Would be lovely to have something like that. However, I'm currently rewriting the stuff of my engine that needs to be rewritten, so that I'll hopefully be able to use it soon enough - event for stuff that totally doesn't need the tech to work pretty.

Wish me luck! I could need it this time. Not that I'm complaining, but I'd really like to have easy way to my goal this time.


More eventing!

Ok, I shortly before doing the actual tests whether it now FINALLY works and have to say that I'm quite nervous about it. I modified the event system to support event IDs: each event starts with number one and will increment after it happened. When listening for an event to happen, you can pass either null for the next future event or a specific event that may happen in the future (will stay in the event listener list until this will happen) or have happened in the past (in which case not waiting will be done at all). I dropped the event data because past event data can't be restored. Using increasing event IDs can be very useful for avoiding exactly those problems I had with condition variables and signal. I had to take a long way but it should pay off now. I was not able to find any problems but one that would happen in combination with a task pool when tasks get reused too recently, thus rendering threads still waiting for missed signals due to reuse and event id resets etc. Don't really want write any more about this, but I solved by using another event fired by the ressource loading functions themselves. This makes having direct task completition feedback rather useless, but I can still use it for comftable use later (don't need put the event firing code into the actual task functions). Arghh, I'm so excited. It's the only thing I can think of except using polling that could work in my project. And I'd not know what to do if it doesn't work. I mean this is for my bachelor, it HAS to damn work!


Ok, I got a little event system down that will (and already does) simplify everything I'm doing right now. Having this done means I only need to return a task's event and wait on it for becoming complete and that I can use exactly the same mechanic for the ressource loader. But while thinking about it I wondered: what's with event data and so on? I mean currently there just the firing of events, nothing else. One solution would be to use a seperate structure where the event sender can put in data, but let's not make the whole thing more complicated than it already is. Too bad that I definitely need a memory to store the event data as seperate copy from the original, meanwhile probably already changed event data! I'm currently abusing the thread's own list item when doing stuff in the thread manager's request list. I only need to find some value in the thread that's not busy all the time... like maybe the parameter pointer which's already copied as an actual parameter for the thread function. Yeah, the parameter pointer. Why I didn't I think of that before? Well, this value is totally useless most of the time (except when starting threads for the first time). However, I feel bad about completely abuing it. I usually prefer to not abuse structure values for temporary stuff like that. Hmmm. Difficult. But nothing to keep me back from using it.


wait and schedule

I tried to fix my tasker/ressourcer loader system with the new thread manager and pause/resume functionality but did at first have a shitload of problems with waiting on tasks from a higher level than the ressource manager itself. The point is that if provide some waiting functionality for a task, you'll eventually have the same problem with gaps where the finish signal could get lost - just like before. So I didn't right knew what to do, becoming pissed about my blindness and so on but noticed that the solution was actually so simple: if I can have my task to maintain and resume a list of waiting threads, I can do the same for ressources as well! Means that each ressource will have a list just like the task itself, storing all the threads that want to get a resume once the ressource got loaded. It's only easier to maintain it this way. And provides a better response to events happening without delays.

Such a simple idea. And now I'm having the exact same functionality like an event system! Therefore, I'll create some event functions, I think. Having a simple and unified interface for this is the best I can do to maintain my overview. Interestingly, I'm now having those features from Actionscript I always wanted. Let the challenges come, I'm prepared now! And I got into my code again as well.
Hmpf, I think I'll have to work on my object state machine stuff. The optimal version would be some sort of namespaced enum without having the module a part of the name. Same goes for the state transition as I'd like to not put the object module name in every call. Though this wouldn't be that bad. My main priority is to somehow avoid neding to type still during initialization. But I can't avoid this with C at all. If I want to identify something, I need an identifier. I though about abusing the implicit namespacing of structure elements so that I'll only need a single globalvariable to get state values. Well, it's not a very good solution and I'd rather prefer having constants at all. But if I used constants, I need to find some naming convention for quicker access via macros (requiring to used macros for definition, too), or I simply drop it once again let my write lots of things all the time. *sigh* This is one of the moments where I'd like to have a language expansion.

thread manager tests

Did two more tests with threads waiting on dead/non-pausing threads as well as resuming resuming threads. Worked quite well, the only "problem" is that resuming a dead thread will of course continue the thread (which's a good thing) but without informing about why is wasn't a real resume. There isn't even a mechanic to decide between a dead or a running thread and I doubt I'll have used of that. Anyway, one should careful read my documentation when using it - should everyone one let know of possible behaviours. Combined with a thread-safe state machine, this could prevent any bad thing from happening. I'm really confused about it's seeming effectiveness. So I have no more excuse no not make the tasker and thread manager work. I could also drop that and try fixing my desktop PC with a newly arrived mainboard but I think I'll do this monday and leave the weekend for either work on my project or some more Legoing.


Lego, for a change

Since I've solved my pause/resume problem and some other things, too, I took the opportunity do something else that's related to programming: Lego! I was working on a claw gauntlet one or two evenings ago but didn't want to continue it immediately (though it already looks quite badass). So, what I really liked to do was working on another Lego gun! And well, it's currently the muzzleloader I wanted to do a while ago. I kind of realized all things I had in my mind while building the barrel. The rubber band has a central alignment and snaps right into a groove in the bullet (2x2 profile, random length). The barrel has a length of over 30 studs with atleast 25 studs for direct acceleration via the rubber. I was able create very stable layout along the whole barrel to have no friction between the rubber band the barrel insides. Quite interesting look, reminds me of a rail gun or so. However, this will of course useful all my later models (if I get more of the parts I used). The real clue comes in with the rubber band's fixation. Usually I'd use a shorter rubber band, stretch it a bit to fit less loosely and get durability problems over time. The new version uses rolls to form a shape similar to the stylized E used in sum notations. This way I can store rubber band length compact and perfectly stretchable without durability decreseases. When charging the rubber band you can the rolls move because the rubber band will automatically compensate any stress it gets to the length. When using rolls in the bullet grooves, one can reach an even better stretchability. I'm surprised how well this works - it's thickness is completely the samecompared to all other fixations I used. Awesome! I also need less force to charge it completely and stretching using a ramrod makes the potential charge longer, more powerful. So yeah, great improvement this time. Guess changing activities is the best I can do to get good results more often in whatever area. Anyway, the shot release itself will need to have a hammer to activation. Due the held back force beeing way stronger than in other models, I can use the bullet lock and hammer of my previous gun. Which worked very well and will also work well in a bigger scale and higher power. Using a ramrod, the bullet should lock automatically. What's important is a small powerful hammer which I want to deliver in a more compact way this time. But since I was able to compress it before and the current rubber band fixation, I'm certain that it'll work just right. I'd love to have more gun-like internals for my Lego guns. The last hammer/striker I did (and still haven't shown off here) was really massive. Most cause the whole model was rather special.

Yay, it works

Yay, exactly what the title says. My thread manager with pause/resume function works! It's wondrous how easily it went today and I'm glad I took some time the last days to do something else. That dude from Coding Horror ones expressed that sort of thing as "sharpening your sword", which's maybe what I did today (watching movies and building Legos is always good). So where do I begin? Firstly, my new debug toys are so damn useful. Couldn't have it without them and I'm really appreciating that sort of output I do have right now. First of all, I wrote about 400 lines of code without debugging and compiling, so I knew this would be some sort of syntax fixing for a few minutes. Meanwhile I corrected half of the code with the mutex/qmutex/thread seperation, added some useful functions and did my first test run. I only had 2 segfaults due to forgotten pointers and all other problems where wrongly passed qmutex and a deadlock I logically fixed with another necessary mutex. After that, initializing, binding, starting, waiting, pausing and resuming work fine! And without all the CPU hunger I feared in the first place. The only thing requiring high CPU is the thread manager debug output while polling! Exactly what I wanted, only CPU use for this very short time. However, I did not yet test a few special situations but I'm confident since my test scenarios went correct when I went throug them. Awesome to see this going on and working. I think I can be proud on myself. Something that's worthy to have in a bachelor thesis. So what's next is some more testing of potentially happening scenerios and building it into the tasker and ressource manager. I also started documenting my code a bit and it makes no sense to keep several nice-to-have but never-of-use modules, which I refuse do document until I really need them.

So yeah, successful test scenario! What a great result. Im beginning to become good at this. I also finished a multithreaded Erlang assignment in a few minutes for which I'm still having three weeks ago. The only thing that took time was to explain the program to my fellow students... So I guess I'm good enough to create such stuff rather quickly. Feels good becoming better, improving your ability the think in that matter. And I'm more often aware of my love for night work. It's completely dark, no distraction but full concentration on you and your problem. I don't get this during daytime, you know. Must be some sort of phase shift I got the last months.


freeze, doc, WIP

Awesome plan to solve my programming and bachelor ambitions: I'll use my game and all of it's technology with less features as a bachelor thesis and start documenting it right now. This way I'll have something properly documented to show off as a WIP project with certain technical completition status while functioning as a bachelor exposé at the same time, which I'll need to validate my bachelor thesis. Add some mockups and you got a win-win-win situation for all three goals: personal work, bachelor thesis and internship application. Plus a well-formed doxygen documentation showing what's already done, what's still to do and so on.

On a side note, I designed three awesome macros for my linked list system. Since I know that every way of iteration through lists can be done with a simple for-loop header. I've used this very often so far and it did serve me well. The macros I designed do two things at the same time: providing per-element code and an evaluated expression if a passed condition is true after an iteration. This condition can be related to the current element or whatever else, as well as the expression. Thus, filtering, moving, sorting, counting, alterating and whatever else is possible with it. I'm very happy about this find. However, the conditional expression is still an expression - one can't do endlessly complex stuff in it (sadly). But I don't intend to change it. If one wants to do more complicated stuff, he can do it manually. Oh and I should add a list macros for splitting lists, in time.

So I'm feeling much better today. Got great sushi and will now watch some nice Batman movide to round it off.


I've been watching a Terraria speedrun for a while now and have to say that I feel urged to play it. Not that I need to buy it - I've bought my game a while ago but didn't find it as entertaining. However, one of my fellow students is playing it right now and promised to give some sort of proper introduction and explanation about the mechanics goin on there and so on. Al in all, I can't say that I'm more intrigued by Terraria than by Minecraft. Minecraft has mechanics and simulation where Teraria only seems to have fighting and building. The only thing I really love is the use of lightning and the fluid dynamics. Fluids are ridiculous in Minecraft, awesome in Terraria. It simply applies a few rules to each water tile and what you get is wonderfully beautiful to look at and play with. I guess I'll have more fun killing monsters and surviving in Terraria than in ;inecraft. Due to it's 2D graphics, fights are less of a surprise compared to Minecraft - one can see all over the place. I'd like to appreciate the playing of it. Those liquids are too cool for not doing so.

loop abuse

I love building those ultra-compressed and versatile for-loop constructs. You can put in everything you want in those three expression as long as you can make an expression for it. You don't even need to use a following code, it's totally open to your own code. Though I love the possibility, I'd never use it explicitely in production code. In a macro with proved-to-work code, I would not say no if it's faster to type and with no disadvantage in speed. But often I use simple expression for such thing, like when calling an iteration function or so. For my list item macros, I did now found out a greate how to simply do some filtering or moving of entries where a condition and the moment they get checked. Thus I will, depending on macro used, still have an iteration through all items and removal for specific ones. I can also use it clean single lists up and so on. I'm confident that this will be a great way using my list macros. You can't do such great things inline functions - another reason how macros can make programming easier and more rich, if you got the disciple to use them properly for sure.

Stage fright

Due to some very annoying characters around me, I started looking for some video game companies where I could do an intership and found around four or five in my living area. All of them take C/C++ programmers, so I can do the stuff I'm training for since school. Actually I didn't want to do this that fast, giving me a bit more time of less stress until I think I'm ready. But meh, it was too early and started getting visions about all those web fuckers defaming everyone not making OOP all the time, me beeing not exepted as C programmer, having not enough stuff to show what I'm capable of and so on. I wasn't even able to do anything productive due to that but run around and calming myself somehow. I'm very sensitive about everything related to proving knowledge and experience and so on. It is some sort of constant fear of not beeing allowed to do what I want to do for my living as well as again having someone to tell me that he thinks I'm not good enough. I know I'm good enough but all this officialized shit is beyond my stress resistance. I can live with knowing that there aren't many people in the team where everyone sort of has it's task to do and where I'm also a part of it (and not just a doodad doing occupational therapy). And I sort of believe that this fear will become true somehow, in whatever way. Oh my, I'm such a nervous wreck. Believe or not, it's the only real thing that ever mattered in my mind. Working in a video game company. My only realy motivation for programming - making games in a company of certain caliber. But until I need to learn for exams and do the very last assignments, I do not want to think about this. Makes we way too nervous fragile in mind.

Whatever, I'm on a good way to get my pause/resume function to. Combining it with the existing code is a matter of utmost simplicity, what I really wonder about is how to make list management more comftable. I've noticed certain problems when working with my self-managed sentinel node list entries. Writing some sort of removing/inserting algorithm with them is a bit difficult since I want to keep everything as small as possible without any temporary variables and at best within a loop header. Therefore, I sat before all this and thought writing some more list iteration macros that sort out elements on condition, delete them and so on. It'd effectively be the set of functions I did before in my C++ template lists with lots of options where the list selection should go after deleting and inserting and so on. I'll do this. Something simple and elementary. Something that's not made of mutexes and so on. I'd appreciate this for a change. It got far too much thread shit for now. Gonna stop that soon and go on with actual game engine content.

So yeah, I'll stay cool and focus. Also, I'll take this game as my bachelor project, thus those guys will see that I already have a good plan of everything and that half of the problematic stuff is already done. I mean if that's not convenient for them, I don't know. And I'm fast in learning and adapting new stuff, so I can adapt to whatever has to be done. Shouldn't worry me about that in any way. If one company doesn't want, I can pick up the next one. And I bet that most smaller ones are a bit more easy on their mind with how to handle I-work-for-nothing internship candidates like me. Well, maybe I can even be of some value for them! Should really, really see it positive and convinced.

So my plan is do some more convenience/used-anyway macros and go on then. The disadvantage of doing everything by yourself is of course not only the work to do but when to do. Usually, I'll only continue if I'm comftable with way and result and only add stuff if I don't feel that the next task will be a quick one. This means that there may be many interruptions of the original goal - like having to code some clever macros inbetween. However, if it's more about some data handling or challenging problems requiring clever solutions, it can actually cheer me up due to the change. Looking at what happened today, I guess my I need to other stuff between the hard, more annoying tasks. I can analyse whatever to discover it's problems, but my psychology and fear behaviour is still a miracle to me.


A general debug decision

I've decided to drop all checks for false data in objects and functions but only check the parameters and return values of used calls. Since every function will return some result to the user, it's easy to only call the function in the way they should. I just have so much left to do that I don't see a reason for pulling off that much wasted coding time. Instead, I'll implement a state machine later which safes a current state in each object. If new desired state transition is not valid, the function will debug-dump the false transition but continue everything else and evaluate in either true or false for further processing. I think this is a way better solution always checking a million of values. And if a function fails, it can simply reroll the state transition, it's that simple.

I'd really like to see the this buildin in a programming language, but I guess I'll to wait on this for some time. Atleast I can use my own C macros. These make C programming so much more nicer but still very effective.


The manager's gauntlet

I'm in a bit of an hardcore coding session right now, but my concentration starts to reduce. I noticed a few unclear combination of functions running parallely and decided to write the whole interface in a way that one will at first set up the thread manager and then init all threads that one wants to run with this thread manager. The manager doesn't keep keep track of it's threads but locks on pause mutexes. The threads themselfs know their manager and use it for pause operations with a lot of thread-related qmutexes, so it's very important that threads to that threads handle each other carefully - this is especially important when killing each other. It's not as complex as my tasker/ressource manager system, but still no to underestimate. I've used some sort of mutex-based polling mechanic which's able to either work with no delays (when stuff's getting busy with a lot of thread control request (requiring high performance) or with a custom delay after getting no requests n times or so. So it's atleast adjustable and I think I can life with that. Not that ressource loading suffers from a 1 ms delay or so.

I feel kind of out-of-power right now. Didn't work that frenetic on something for a longer while. I usually have quite some delay between coding sessions cause I got a dead end or so, but this time there do not seem to be so many, so I guess it's good. Anyway, I do know me and my way of depleating my motivation. I shouldn't work too long on it tomorrow (which's actually today) and do something else. I'm found some very inspirating things on Wikipedia about gauntlets and gloves used in hand-to-hand fights and I think want to create on using Lego. Sme sort of armored glove with talon for each finger, movable plates and so on. For flexibility reasons I'll probably use a soft, buffering cloth for the inlay, an inflexible plate or frame around the wrist and the back of the hand (preferably with a lock to fit it properly). Not sure whether I want to use the wrist piece combined some with some "thimbles" for the talons or throw in some slings to hold all in place. In any case, I won't let the fingers joints bend over the hand's back, so I can entirely focus on an armored, plated layout. Hm, for flexibility's sake, I'll probably make the thimble not completey cover each finger but only the sides not adjacent to other figures. Means you'll the full armor when forming a fist but still enough flexibility to move fingers individually. If this doesn't work out I can still do some claw-type weapon out of it. Those look cool, too.

Gonna get some sleep for today. Five hours is definitely not enough for regular sleeping.


Your inner big brother

I got my concept down and I'll try to getit finish in the next hour and testing it tomorrow. It's a pretty complicated concept and I don't want to go too much into it. However, I noticed how fragile it is when calling it in the wrong oder, just like all my other modules. Sure, I'm checking parameters and there's the possibility to accumulate results into something (though I'm not doing that all the time). But this does not prevent me from accidently calling stuff in the wrong order. The idea I'm having to avoid this is to define a tree of possible pathes a program can take from one function to another. Like a state machine which cannot just go from one function to another but has a certain flow. The only problem with this is that the number of possible functions and pathes is huge, simply huge. Bearable for a limited set of functions (you mostly only need to define pathes from one module call to another via some other module's calls), it's impossible for so many functions you don't know or maybe know but not making any rules about their call path. The mechanic behind ignoring the unknown but detecting the unknown is rather irrelevant for me right now. Fact is, that C99 defines __func__ to be a pointer to a function's name, thus beeing a unique string and identifier in overall program. So you can, in fact, just dump out an error if you're not calling the right function. I find this mostly interesting. But now I have to go back my thread pause/resume stuff.
Ok, I calmed myself down and will create a different approach: imitating arbitrary pause/resume functionality for threads using mutexes and a helper thread. This helper thread permanently locks a number of qmutexes and will release them for a short time with a combined lock/unlock call (the relock I implemented for something though) to resume the thread. How other threads should the helper thread is something I'm working on right on. However, to prevent the exact problem I got with condition variables, I'll now drop the event stuff and introduce a preemptive thread resuming. That means if a thread wants to resume another threads while it's already resumed, a counter will increse and the pause by the thread will be skipped. Using this I can simply tell the tasker to continue a list of threads waiting on an event. And when the waiter thread misses the currently dangerous gap and wants to pause itself, the resume counter will be other than null and no pausing will happen cause it's not necessary. The tasker should also only try to resume if the thread allows preemptive resuming. In the tasker/waiter case, this should only be activated if the waiter thread really already wants to wait on something. Meaning that if there's a finished low-priority tasker increasing the waiter's resume counter, the next waiting will simply not continue due to that.

So that might be a solution. I'm trying. I'm goddamn trying. I knew I used pause and resume in Purebasic a lot. It was very useful and I'm still annoyed about the fact that SDL doesn't have anything like that. Oh man.
I found a massive problem while designing the new event system that may be the reason why SDL's condition variable didn't work for me. If that is case, I was more than wrong and shouldn't blame anyone but me. The point is that my toggle object, signaling on true or false or a change of these states, had a gap in it's logic which would effectively prevent a waiting thread from catching his signal. I wasn't to notice that before cause it worked fine in my test. But now I see the real problem and have to reorientate. The good thing about it is, that if SDL's broadcast function really, really actually works, I won't need to rewrite my current tasker system (which I prefer over the other I designed after the last blog post). And now I'm really asking myself how to solve this. The real problem I have right now is that a signal send by a condition variable has exactly the same problem as my own qmutex/event implementation: a sent signal will be lost if it's appropriate receiver started waiting too late. A naive approach would be to use a mutex to lock the event one would wait for, blocking the sending thread from sending the signal too early. However, this would simply block the sending thread and nothing could ever work. So I'll have to say the thread that he should simply only start signaling after it's waiter started waiting. Which is totally impossible with only threads cause after starting the process, now signal can be initiated by this thread. It's such a fucking stupid problem, seriously. There's no real feedback in SDL for whether a thread went waiting, nor is there any way to poll it. Fucking stupid. The only thing I can think of is to use polling and a signal buffer. I can't really use the waiting on a mutex or condition variable cause I still need to shoot the event after intiating the waiting, which's once again no possible when waiting. Even if you could manage to have a third thread waiting a short time to let the waiter start waiting and then shooting the event, you'll still need some sort of delay or a function to fucking wait for a thread status change!

Who in hell did design something so incredibly useless? All just based on fucking mutexes! I had so much trouble to find this out and now it seems all totally useless and wasted. You know what, it's done for this weekend. I don't wanna hear or write or code something about until monday. I'm pissed and off. Stupid multithreading.

Not exactly perfect

Now I see why my concept wasn't all that perfect. I can't just create an event for each task cause the event-sending thread needs to lock the event. Thus, a thread will never know when someone inserted a thread and thus not when there an event to fire. However, this can be overcome by rewriting the whole system to have a taskpool for each tasker and exclusive acces to all events possibly fired by those task. But, to be honest, if you got 100 tasks and need to bind all those to a single thread, allocating a total of 200 mutexes forthem, I somehow think that the solution isn't really ressource-friendly. Um, lemme think - I'm using a mutex for every currently loaded/to be loaded ressource in the game, thus potentially creating a huge pool. If I do now add another bunch of mutexes, I'll have several hundrets of mutexes. This is quite a lot, simply too much if you ask me. So wit only one event type and one tasker per type, it should work fine enough I think. Geez, I didn't really thinkg about this. However, since I don't exactly need ressources to stay persistent all the time, I should use some sort of ressource pool to dynamically create runtime ressource structures. I know I want a ressource tree consisting of ressource pathes, their corresponding types and a ressource pointer for the current ressource task structure. This way I can dynamically take stuff from the pool until the maximum amounts of loaded ressources is reached. More complex than I thought, but I don't want to have so many synchronization objects active. Especially if I ever want to use this code for smaller platforms, namely the NXT. Also, I'm thinking about wrapping the whole threading and time interface stuff in it's own set of structures to have a unified way creating and destroying stuff. Ok, I rwally need to make a plan for all this.

On the watch

My event system seems to work! Woopeedoo! Atleast my test worked as expected. The event code itself is so somewhat exactly like the the qmutex API. It only differs in an additional event data setting, so that I code make a pure macro variant out of it. This should definitely be enough to get my ressource manager properly working. And I'm ready for even more perverted threading stuff, if I'll ever need more than my tasker and ressource manager system. I wouldn't say this event system is comftable to use. One needs to initialize the event. the qmutexes one wants to use and bind the event to a single thread. Each event must be bound to a thread and will fire all the time one is waiting on it if there's no thread bound to it. I know this is sort of off, but the system can't work differently. And I won't even try to make it somehow "safe" cause nobody's checking all return values by hand, not even me. So, I do deem it done for now and get the portion of sleep I really need. It's 6:43 AM in here and I can't stay awake anymore.

I feel so satisfied right now. Didn't have this feeling since... um. I don't know? Since a while. I'm getting closer. So much closer. I'll be able to get my engine to work in time and so on. Finally, I've been looking forward to this. I don't think anyone but me will understand this at the moment. Took me so much time to reach all these things. Oh geez, it's already 7:00 AM, really gotta go to bed.

Don't explain something if you can't express it correctly

Seriously, it's all about expressing it correctly. I was talking with my sister who is having an internship in a video game company as a concept artists and said she learned how those tree generator program work when inputting custom tree graphics and so on. Actually, the only thing she was able to state was they are taking the tree polygons and it's leave sprites and somehow generate something else 3D out of it. What great accuracy! It took me three tries to get something mildy detailed out of him. Still, what she described sounds rather like image analysation, which would surely be an effortless approach to this problem. However, it wasn't quite clear what she wanted to say with this due her lack of technical expression power. But still, humans always try to explain stuff to other cause they hope it'll be implicitely clear to them. I am not somehow beeing able to understand somehow if he doesn't express it in an exact manner. Call me whatever you want, I'm a purely logically thinking person who doesn't like implicit rules and, neither will I understand something with too much implicity in the whole system. Strangely, if I try to truly something to somebody, I'll dissect the facts and begin from the very atoms. And they fucking understand it if they're atleast a bit of smart. Think what you want, that I'm assy to due to that, an evil misanthrop or whatever else - I don't care and will never understand these rules of unknown implicity. One of the many reasons why I prefer interacting which other persons having atleast a bit of technical or mathematical knowledge. They tend to be way more compatible with my way of understanding.

And hell, who wants to talk with somehow about video game development who doesn't want to have something to do with video game development. I know why I usually don't speak to those, in a video game context I mean. It also explains my tendencies to like speedrunner cause those dudes usually need to know about the game mechanics and how one can (ab)use the system behind.


So my rewrite of the qmutex apparently works. Locking, re-locking and unlocking worked as expected and even my older test results were as expected, too. So I assume this works fine and that I'll now be able to to some nice event framework around it. I've been thinking around since I woke up and I think it's the best idea to only use this system to continue a set of threads, not doing any logic inbetween to avoid any sort of waiting. I've thought about using some sort of event type system where all threads look if it's the right even and so on, but using this consistently is hardly of any performance advantage. I mean imagine 30 threads all sequentially looking for a matching type each time an event happens, one after another, you'll need to wait for all those threads to check and cycle. So, combined with the fact that there maybe only one sending thread but 10 different event types, you'll end up with 30x10 type checks for only 10 events of 10 different types. 300 checks, isn't that a bit too much? My idea is to create a single qmutex for each event and only notify those threads waiting on the specific event type to fire. Thus you get only 10 interruptions with no per-thread checks at all. These only this very small overhead when passing control to the other threads (for example, three threads each wait for the same type type to fire and you'll only need to wait for the number of threads that enlisted for waiting - 30 to be exact). Way more efficient for obvious reasons. I'm once again not too fond of those highly theoric constructs they did over 30 years ago. And they still teach it universities cause they are not as complex when assuming they are atomatic parts of Java. *sigh* Whatever.

So I'm going to design some interface for this. I'm confident that'll have the complete ressource system working until Thursday or so. And that means that I'll finally be able to start my work on the world map stuff and the renderer. What an odyssey! Didn't expect it to take that long. But atleast I'm quite good at writing multithreaded stuff, you know. I think that's worth it, definitely.


Custom condition variable

This morning I had a phenomenally clear head and realized that I can the same effect of a condition variable by using my almighty qmutex construct! Since a qmutex always guarantees that everything will be in order and only at once, I can define an event sender locking it's qmutex by default and several receivers that try to lock this qmutex if they want to wait on an event. And now comes the part where it gets so similar to a condition variable: when sending an event, the event sender will at first write some event information and unlock it's qmutex. the event access will be passed from the first waiting thread to the next one while every receiver will copy the event data before passing. If it's the event he wants, he doesn't need to re-lock the qmutex anymore and is done waiting. But if it's not the event he's been waiting for, he can simply lock back in while all the other wait on it. The event sender will generally always lock the qmutex cause he wants to have control over the whole setup and maybe shoot another even later. Sooooo, it's in essence the same as a condition but more automated and ordered thatn SDL's condition variable. There are of course some spots where I'd say that it depends on whether the event receiver was quick enough for a re-locking so that he will definitely catch the next event. This can be done by locking a "wait, I still need to re-lock!" qmutex activated before unlocking the qmutex in a sender. The master will then try to lock/unlock this qmutex to ensure that. So there'd two queries working with each other to ensure that everything occurs in the right oder. But that's a lot of performance loss with so many lock/unlock and list edits, even if it's multithreaded... Ah, fuck that, I can put this into the qmutex itself! There should effectively no problem combining the lock and unlock operation. I already have an idea how to do this smartly, so I'm gonna get my own condition variable this way! I didn't expect this to be the background of a condition variable to be honest. I mean it's then totally possible with mutexes and I do now see how they must've been out of mutexes. But my version will work then, so that I can rely on it much more and guarantee that it'll work, no matter what stupid operating system wants to come in my way. I can make my own event system with this, my own fully multithreaded feature set. I always dreamed of something like that, having an awesome toolkit I can totally and always rely on. And fuck yes, if this all works out I can friggin say that!

Multidimensional bug hunting

I was wrong about my previous assumption that I actually proved the condition variable to function correctly. I tested with two threads but not with three! In my testing scenario I used one thread for signaling and another for waiting on the signal. Then I changed the direction and test was done. But what about two threads waiting on it? I build exactly such a scenario and when using SDL_CondBroadcast I got the same effect as when using SDL_CondSignal. The difference between those is that broadcast messages all waiting threads and signal only one. And I'm close to believing that broadcast doesn't function correctly in SDL. However, I also made the mistake of not locking the mutex before waiting, though this didn't change anything. According to this page I found, condition variables are used totally differently. From watching as their code I'd either say they simply didn't label their variables correctly or that condition variables need to be used completely different. I mean look at this code! To work in the expected way, they'd need to start B after thread A. Anway, this is pretty much like my toggle module functions but the fact it does just not work for multiple threads is pissing me more than off. I mean I didn't create all this stuff just to end here because SDL can't do this. There must be something wrong in own use of this mechanic. I fear that I'll need to something for this on my own, that my whole concept won't work anymore with this functionality. I don't know. Maybe it's something so trivial it's too hard to notice for me right now. Wouldn't be the first time happening, but I highly doubt that for obvious reasons. Even if I copy the code they provided and use exactly this way, it will simply not work, I tested it just a few minutes ago. The mutex passed will keep beeing locked the whole time and block any other attempts to signal the waiting threads. It's simply totally dumb. Hm, I'm having any idea. If this wiki states that the mutex be locked and then unlocked by the function while the signal wasn't sent (it worked for me without, too), then it might be the opposite: the mutex will be locked from outside and the thread will wait until it's unlocked and then lock it. But it's the same as I'm doing right now, so I'm stuck again. Stupid false statements. Oh, wait. They use SDL_CondSignal in there, not the broadcast variant. Still, wouldn't broadcast have the same base? Wouldn't broadcast be compatible with waiting, just not taking only a single waiting thread but all in the list? It should, but I don't see that it is working in the way it should work. Whatever fortifies my opinion even further is this helpful article explaining more detailed what a condition variable is meant to be. From what I understood is that the concept is that threads will pass control to each other using mutices. So if I can't rely on broadcast to work, I'll need to make my own. And cause my toggle object thingie is the only using condition variables, I only need to make it work somehow and don't need to find bugs that actually only exist in SDL itself.

Anyway, I won't do this today. It took me the whole day to get the debugging right and analyzing this specific SDL problem so that I don't have the energy anymore. I don't know how exactly I want to realize it. Maybe without the signal functionality (guess I'll definitely need it) or I'm trying to play some tennis with mutexes to possibly wasting some more time upon realising that it may not be possible without signals. Anyway, I'd prefer creating my own version of this just because I can and because I don't want to depend on something that's not implemented correctly. They could be honest and say it doesn't work, but no, they pretend it does. Maybe it works for others, who knows. It certainly doesn't work for right now. I mean what can I else do than exactly what's portrayed there with no success. I know it works for one, but I'm getting tired of fixing stuff up that's not my problem. I can imagine making my own event-shooting system based on one or two seperate threads giving control to other waiting threads in a bit more complex system. Would be definitely less performant than direct, builtin system functions but I can't stand using something which's ensured functionality vanishes depending on the library or the system. I can assume that mutexes will work on every system, so I'll rely on it. If condition variable would work as expected, there wouldn't be any reason to build a qmutex cause I can get the same effect with condition variables.

Oh and the weird reason why I got no segfaults with debug on was cause the expression I used a debug message parameter disappeared together with the debug message of which it was an expression of. So an operation was not executed when it should've been, explaining the segfault. Now it "only" freezes due to the mentioned condition variable problem. And I just had to create multithread debugging functionality. I'd called it a cheap victory if it weren't so sad.

So I'm once again going back to creating the atoms of atoms... The whole operating system and library world simply stinks today.


New Categories

I was thinking about a recategorization of future blog entries. Point is that I'm currently clicking a bunch of tags for each post without actually categorizing it. So it's almost always a impossible to say one post is about this the other one about that. I mean who cares whether I found something awesome or if that's part of my elementary precept. In the early days of my blog I cared, but now the perfectionist in me wants to categorize stuff exactly, which's hard with so many but inaccurate tags. So I believe it's a better idea to find some new categories. However, I'd like to keep all the post I did here but somehow put them under a seperate link in the menu or so. But hm... is it a good idea anyway? I mean the concept working fine so far and maybe I'm just going through some sort of redesign mode today. Another reason for why it's not that much of a good idea is I'm linking to this address from everywhere and I can't remember all the places I linked it. Even if I continue what I did on my previous blog (linking to the new one), it'll result in some sort of stray content. Well, since I'll probably never do anything else than blogging about random computer geek stuff almost all the time related to vdeo games, I'll have no need for a real website. And the idea about publishing my toolkit or engine or whatever it is now became more and useless to me if I don't have a proper documentation of it. This takes time, I don't have the time right now because I want it's functionality to increase and form something like a demo to show off my abilities to get an internship I want and so on. All in all it makes it rather useless to form something new right now but I'll eventually do it one day.

And I also didn't make a photo series of my latest Lego gun. I know I said I wanted to post it here but I can't motivate myself to do any off-showing here. Everytime I do something else that's not working on my engine is kind of like deliberately ignoring a danger to my very life. It's more important to me finish this as quick and good as possible than doing something I mentioned to do in the past. This doesn't mean I don't do my more important study work or other way more important stuff, but it's my next most important after all that to atleast have something o show the folks I'll be working with. I don't know anything about what studio I'll be able to get in or if they even want me to have something like that done, so I better prepare myself to be able to do many of those challenges facing videogame programmers.

Let's continue multithreaded debugging

I spend the last 8 hours or so finding a good and actually working solution for my multithreaded debugging and succeeded so. It was a bit tricky but now that it's done and working, I already have found out some very interesting things isolating the reason why everything freezes from time to time. It happens when two or more threads wait on a ressource to become loaded for the same time: the thread that started waiting in the first place will be able to catch the task completition signal, all others won't continue, stopping the whole problems. There must be some sort of deadlock, waiting on a deleted ressource or just a missed conditiona variable boradcast. The last isn't possible as I already proved this behaviour to never happen with the current code. A deadlock is unlikely cause both threads clearly enter the part function waiting on a condition variable to fire. A deleted object is quite likely because I noticed occasional segfaults when deactivating all debug messages except in main, the threads and load/release functions. Why this only happens with deactivated debug messages is not quite clear. On one side, all each debug output will triggers it's own series of locks and unlocks, possibly changing the thread switching order and preventing the segfault from happening. Also, debugging adds some more mutex/qmutex objects that be stored for each program in a way that accessing a release mutex object will result in it just not beeing deleted but reused until the program closer. Though this is really quite far-fetched I have to admit. So since I've seen this segfault, I definitely know that I have to check for objects becoming released to early and I guess this happens because of the first thread beeing ended. I'm de-initializing a qmutex and a mutex there, so this might be the actual program of it. Let's test it!


One day a racing game

Though "one time" would be more precise, the title says almost all: atleast one time I wanna be part of a team developing a racing game with as cool music as F-Zero GX. It's totally awesome music. I hear so many lovely patterns and flows in the stage musics I'd totally adopt right now in my music. Or better said it comebines all the things I love about electronic music and it's sound! It's totally awesome, can't state this often enough. It's like Crystal Method combined with Buttrock Goa, Acid and Space Music. Totally genious to my sound processor! Somehow I feel that I need to get this game before I forget about all that.


Hah! My debugging didn't fool me. It's more than useful to have something that automatic if you're doing it more than often. And I can exclude debug output for modules directly in the code, something really useful. Anyway, those segfaults and endless loops were simply related to a false cast I didn't end before, so it wasn't a fundamental algorithmic problem at all. But I noticed how incredibly mixed the log time is. Things get printed before they'd occur and so on, something I can only really react on with a qmutex. I guess his time I'll definitely need to wrap a qmutex around it. Can't decipher those rather massively long logs with unknown order and or detailed time stamp.

Edit: I think I found a good solution only requiring a single single debug initialisation by using a qmutex pool I'm occupying dynamically on each debug operation. Therefore, a debug output would be like three function calls with the lock/unlock around. That's totally ok if I can get my output ordered. Furthermore, since the modules will be compiled individually, I can put different debug flags in the header and have their output formatted differently. And that means I can also cut out the synchronization to have a more lightweight functionality. Still, I'd need to use a temporary variable for storing the qmutex adress. I've come across an interesting abuse of parameter evaluation for this. It depends on the parameter evaluation order, so I won't use it in the real code, it's just something I found very interesting. Imagine you're calling the qmutex giving function that'll also lock it, passing it to the qmutex release function as parameter which will then unloc it. To do something with it before it'll be released, you can call your printf function and use it's return value as a generally ignored parameter to the releasing function. There's also a bit of unlock wrapping involved. Let's assume this:

create() as the creator function,
release(qmutex) as the releaser function,
lock(qmutex) for locking,
unlock(qmutex) for unlocking,

to create this:

unlock_and_release(qmutex,integer) { unlock(qmutex); release(qmutex); }
as a wrapper for release with additional int parameter,

create_and_lock() { qmutex = create(); lock(qmutex); return qmutex; }
as the create/lock function to be called first.

So when we have these two, we can pass the printf after the lock occurs if parameters will be evaluated from left to right:

unlock_and_release(create_and_lock(), printf(...))

In case of such an evaluation order, we'd at first create the qmutex, lock it, store it for later, call printf and then passing the printf result together with the qmutex adress. Too bad it won't work this way cause evaluation is not defined in the C standard. Still, wouldn't it be lovely to control some temporary this way? Anway, it wouldn't be as performant as a simple temporary variable. And without initialization, I'd need some sort of ifndef shit with variable definition out of place or a global, mutex-guarded stack for getting local variables. Well, my qmutex pool has a mutex, so I could theoretically abuse this but it's no good solution. It's not worth it, rather use some initialization or so.

Offline Repost

At first beeing annoyed about the fact I tried mutexing printf operation but noticing that file calls are, atleast when using glibc, already threadsafe, I then found a neat solution for using variadic parameters in macros/printf but still having string pre and postfixed. I actually never use implicit constant string concatenation, so I'm glad I found it in the GCC manual. However, it will still not guarantee that message will get there in the right order. And my qmutex system requires a sync object in any case, just like all locking mechanics do. Simply adding the current time infront is too inaccurate with SDL's millisecond accuracy. Shame! I could of course demand the user to create synchronization objects, but this is the same as writing a log in terms of overall using. So I'll stick with thread and status messages. I hope I'll be able to debug this way. I'd like to get this shit working.