I'm currently ITK's modules, functions and macros and think that I'll remove a bunch of thingies that should not be included in ITK since they don't quite match the game dev toolkit theme. I'm probably gonna create a seperate toolkit for more memory-related topics and so on. I don't really use memory functions at all - created them for fun and cause I wanted to - nothing else. Also, it's usually better to insert a simple array copy loop than a random memory move function. I'll also need to overhaul the collision with some more appropriate macros for subtracting range from each other, implement macros that work more like vector operations or so. However, this is stuff for a release after I finished all documentation for release 0, ultimately creating release 1.

Oh and as a more surprising event of today, Sennheiser finally moved their asses and send my money back. I can assure that after this product torture, I'll always buy hardware in local shops to never have the problem of needing send stuff back.

Yay, fps boost

My bucket sort was a total success: about 1/3 more fps than before! Yep, was totally worth I'd say. I was able to increase the number of automatically sorted sprites up to 2080 with around 30 compared to the 20 I got with no bucket sorting. The higher the amount of sprites goes, the more one will notice the speed gain (for around 8000 sprites it's four times faster than insertion sort variant) but I doubt I'll render THAT much stuff on screen. It's for simple stuff after all - totally enough. I'll update the demo as soon as I get a bit of rest, worked all night on that stuff. Also, one can now define the z axis ordering on his own, choosing the best behaviour for his own code.

Bucket Sort

I took the time to implement a few list macros that become useful for sorting the sprites in IGE with more performance. Previously I've used some sort of custom, admittedly bad n^2 sorting I'm not really proud of - even Insertion Sort was faster in the best case complexity. However, I thought about how to split the whole stuff into smaller sortings and noticed that all I'd need is a bucket sort algorithms with insertion sort for each bucket. I must admit that I like insertion sort because it doesn't require recursion and is trivial to implement with linked lists. Combined with an array of bucket lists, it works quite well on static memory and I'm wondering what sort of performance boost I might get when choosing a lot of buckets for a lot of z coordinates. The idea is to distribute the distribute so that they cover the area between the min max of all z values in the display list. Thus, one only needs to create a lot of buckets and the mapping is done. I like the idea. Especially because one bucket set is enough to feed to recursive render algorithm. Gonna implement this and do some Realease 0b or so. If I can implement this that quick, I definitely want to do it before writing my internship application to put insert even more sprites for the atom demo.



Ever checked your marks after a semester and compared them the whole list you've collected before? I gotta say that I'm quite surprised how comftable I'm with my marks right now. Seeing them all together makes me actually happy because they aren't as bad as I had in mind all the time. One can clearly see where I'm not to fond of: databases, business, certain math things and one fucked one exam in basics of informatics where we had to do sorting and compression algorithms by hand. Yes, by hand. I mean what idiot can only can honestly think of not just writing the algorithm once and looking it up later. Whatever. I was never into compression and all that sort of stuff. I'm also not fond of security and operating system bs. Too bad that threads and multitasking was considered a part of this failed exam. Guess it saved me from failing this one.

Anyway, I'm feeling reliefed. Something I didn't have for a few weeks.

Hooray, what an update

Whoooot, I was able to pull myself together and add the lasting bits of uploading my stuff here. I bet I forgot an important detail or something like that... Well, lincensing checked, readmes checked, images and previews checked, binaries checked. Seems everything's alright I presume! Soooo, yeah. Didn't "publish" anything program-like since a few years, wonder whether I'll find a format to be comftable with. I mean even a simple readme file has to formatted and designed in some way. Ok, ok - I cheated and didn't included very much (also left out much of the WIP documentation of ITK and IGE). But atleast I know what's next for Release 1. I dubbed it "Release 0" to illustrate the missing parts I yet have to fill with some proper material. I'm glad that a praxis oriented documentaton doesn't need to cover all the scientific pros and cons like I'd discuss them in my bachelor thesis. All in all I wonder how I'll manage this. Hm, still have to write my application and hope that I'll get an internship there. I won't rely on this to work - just hope that I can find another studio in case of rejection. But I'm optimistic at this one! I mean what else but concentration on certain aspects of game programming can be expected from a student applying for a internship in a video game studio. Sure would've loved to have a game done before going this way. Fate's not always to be planned with wishes in mind.

Code and projects

Most of my time I spend on programming stuff for my own video games, thinking about certain problems and appropriate solutions. Over time I found my way into focussing on a single game idea on which I've been working on almost exclusively since. However, I still did games for study projects or just their graphical parts. Some of them resulted in very nice projects in the end but most vanished in the depths of oblivion. Due to my everlasting quest for getting better and shaving off those projects not meeting my standards anymore, I have only a few things to show in here I wouldn't be totally ashame off (demos and last-minute codes excluded). I'm also having a crush on everything that's related to programming cleaner and more efficient. Therefore, I don't always choose to use common approaches and try to find my own way with more custom code than required to just get it done. Let's call it a perfectionist's way of not getting mad over existing libraries - if the time allows it.

Everything here is released under a Modified BSD License, so that anyone who might want to take advantage of it is free to do so. After all, nobody profits from stuff rotting away on my harddisk - I'd be glad to help someone with my own code.

Graphical demos
  • OpenGL crane
  • OpenGL chess
  • IGE atom

  • Imperial Toolkit
  • Imperial Graphics Engine

  • ASCII raytracer
  • 2.27.2012

    Almost done

    I'm almost done collecting and compiling all the stuff that's "show-off-able" in it's current and there'll be a blog section the next days. This will also be the very moment where I'm releasing a barely documented version of ITK and IGE under a Modified BSD license (as well as the other stuff as fare as possible). I noticed how I hate theses tiny bits of developing: getting stuff to the public, doing a doubly-covering readme, thinking about to leave enough informations for those who didn't directly download it from my blog and so on. A lot of small things to think about and the most annoying is to compile SDL and OpenGL stuff under Windows. Well, it's not actually annoying but just not as comftable as under Linux. There's no system-wide include directiory, no central library management and so on. Everything graphics-related under Windows and MinGW requires a dozen of linked libraries and the most comftable IDE to me is still Dev C++ for such stuff. I tried to compile my stuff under Visual Studio but for some reason I could only properly combine OpenGL with C but not C++. So, to shorten the whole process, Dev C++ work almost perfectly after a bit of tweaking. Well, can't expect everything to go smooth with this IDE, eh? I wonder whether all more or less running video game studios use Visual Studio or if there are some completely defying it, using other stuff.

    So yeah, the big day has come! Not today but soon enough. And I wonder whether this is enough for one of the local game studios to let me do an internship. I mean I am and always were more of a behind-the-scenes dude having little visual output except for a few fully planned things. Well, let's see where this is going. Atleast I got some purdy pictures-

    IGE atom


    Animated version (~20MB)

    A little demo I created to demonstrate the z ordering in IGE. 2081 sprites ordered in one display without any further display list branching to have a raw, unfiltered z axis ordering. The farther away from the camera the images are, the more transparent they become. Nothing fancy but creates a nice effect.

    The animated version of the image above is only a fifth of the actual frame rate - the demo itself runs of course way smoother.

    Download (64bit Linux, 32bit Windows, C source code)


    ASCII raytracer


    Animated version

    Several years ago I started to work on a tile-based ASCII game, similar to roguelikes in appearance, with a certain twist: It had multiple layers of level data and a raytracing algorithm to calculate light and shadows, all fitted into a grid with carefully designed ASCII characters. There were multiple light sources, light maps, line-of-sight style visibility limitation, and transparent map tiles to form a complex and dynamic looking light system. However, I wasn't the best programmer at this time, nor did I take backups, commenting or maintainability serious enough to guarantee that I'll ever be able to expand and run this code later. The only thing that's left is a bunch of non-runnable code fragments and a sequence of screenshots that still persists on my harddrive to remember how well it looked.

    I had a lot of ambitious goals: adding a physics engine, light/day cycles, different light types, making a complete game with it and so on... Well, the framerates became more and more horrible the more I added and gave it up after a while. I knew I couldn't make the renderer faster without multithreading, I knew I was too ambitious with video game development and too proud to drop this project. I started to get better at programming in general - with a focus on C/C++. It took me about three years to feel able to tackle this once again. With ITK and IGE as a base, I'm now reimplementing the renderer to get atleast the same visual quality it had before and improve performance where I can. The plan's to make a complete game engine out of it: graphics, physics, permanently modifyable map data, streaming, GUI and scripting. Everything you know from "next gen" engines, just for ASCII graphics. I've already taken a long way to reach this point, so I'm fierce and firm enough to continue were I left the last time.

    How the renderer works:
    There are three phases each visibly transparent or opaque tile will undergo: a) clip if not visible to camera, b) clip if not visible to player tile and c) clip if illumination is not high enough. All steps will be able to mark the tile as invisible and carry a filter color mixed into the final tile color when drawing to the display. Step c) is composed of adding illumination per light and lightmap affecting this tile. The alpha value of each tile is especially important for stopping light rays from going through walls though they won't be seen in the final image. It'll be subtracted from a light ray's light level (starting by 1.0) and stop the rendering if it becomes 0.0. Lightmaps will be applied like a normal light source but don't need to be traced since their light level is fixed. It is to note that shadows of tiles that weren't present while rendering the lightmap will be updated for each tile when it changes it's position. Lightmaps were limited to a single light angle, therefore only dynamic lights could deliver more rich shadows up-close. There was a mechanic to blend several lightmaps for smooth transition but were never included in any screenshot.

    What's planned in the new implementation
  • First of all, applying the complete algorithm from before
  • Add a properly functioning physics and collision engine
  • Use ITK to stream map content
  • Try to create primitive bump mapping using 8bit palettes
  • Entities that are larger than just one tile (and animating them)
  • add eye/brightness adaption for HDR effects
  • 2.24.2012

    Added a few more features to my display list/graphics engine. Now one can load sprite sheets with equal size per sprite and pass it to the display list renderer. A few more things like coloring an image's clipping area, having invisible container-like elements as well as a two functions that do not render but trace through which display elements collide with a given point or square. This might come in handy when creating user interfaces or games where I'm using the system directly to render moving sprites or so. Interestingly, I can even use this setup as some sort of scene graph and completely drop any rendering-related information. Quite interesting, indeed. Will have to see whether this pays off in the future.

    I also took the time to create some general descriptions and sum-ups of the libraries I'll upload and publish this weekend. I'm quite pleased so far. Creating useful code for video games has never been easier to me with this toolkit.

    Imperial Graphics Engine

    The Imperial Graphics Engine (IGE) is a simple SDL-based 2D graphics engine using display lists similar to those found in Flash/Actionscript. However, IGE does not (yet) provide fancy scaling, rotation or stretching. It's sole purpose is to be a more intuitive and easy-to-use interface for displaying 2D graphics than the more "manual" way SDL defines. It's possible to use it for a wide range of drawing systems due to transparency effects, palette changes and optional z ordering. Like ITK, it's written in pure C code. The z ordering performance depends on much content is generated dynamically, how many sprites need to sorted for one display list branch and in which order they come in (a combination of insertions sort and bucket sort is used).

    It's not documented in the current state and probably has a number of small bugs. However, a small demonstration can be viewed via the IGE atom demo.

    Current features:
  • Tree-based display list with root and sub displays
  • Most SDL features: alpha, color keys, per-frame palette changes
  • Clip sub displays to the root display size
  • Optional, automatic z-ordering
  • Coordinates relative to the root display
  • Gridbased sprite/image splitting
  • limited point-to-display collision detection

  • Possible future features:
    See this post for a plan to add OpenGL support and a new render system.

    Library dependencies:

    Modified BSD License

    IGE Release 0b

    Imperial Toolkit

    The Imperial Toolkit (ITK) is a project designed for games, software rendering and currently also multithreaded task-based program execution. It's the result of a process of getting proficiency in C/C++, finding generic, reusable and efficient ways of coding frame-based games, simulations and other sorts of related programs. Though there is very little code, it's designed with care and thought about performance, crossplatform compatibility and whatever one might want to have in an actual toolkit - not a framework. Thus, there are very few things actually forcing one to specific ways of coding or programming paradigms. It can be seen as the essence of all the hurdles I encountered during my quest for making "the game", which does of course also include "the technology" - which's definition is still something I cannot exactly define nor find. It started off as a collection of C++ classes with an heavy emphasis on templates and inlining but turned into a C project due to higher compiler predictability and lack of tasks that profit from OOP and C++ features.

    Seen from a more pragmatic point of view, it's a set of loosely bound macros and functions which's actual use depends on how creative one's able to combine them. They can, however, serve as a very competent base for quick coding of mandatory engine features. For example, most of Imperial Graphics Engine's functionality (which can also be found here) was coded in just two days using ITK. More features will be added in the future if I can find worthwhile, reusable additions. There's a basic doxygen-style documentation within the code, but it doesn't cover all details yet as well as important things like certain function call orders. ITK's also not free of bugs and it shoud be used with care in the current release.

    Currently covered functionalities:
  • Sentinel node lists/items/rings and related iteration/sorting
  • Object pool management
  • Simple state machines
  • Patchwork vector operations
  • Loop and index calculation macros for n-dimensional arrays
  • Hash arrays
  • Four-state logic
  • Logic-based function flow control
  • Custom thread system with pause/resume on a pthread base
  • Synchronization with reduced racing conditions
  • Task-oriented program flow
  • Multithreaded event programming
  • Streaming, demand-based ressource management
  • Multithreaded, correctly timed debug logging

    Planned and WIP modules
  • Shape tracing macros (for rendering)
  • Basic serialization
  • Generic text and binary data parsing/assembling
  • Matrix operations

    Library dependencies:

    Modified BSD License

    ITK Release 0b
  • OpenGL chess


    A "last minute" renderer for a 3D chess game viewer I was coding as mandatory assignment in Software Engineering with two other teammates. While it wasn't my plan to do the graphics part, someone didn't took his work as serious as required to finish the project, so I had to spare a weekend to create a renderer for displaying an animated chess game while sacrificing code quality. The final result features chess figures (which's exact source I don't know, I didn't make them) with parameter-based vertex color generation and face normals for the board-centered light source. The demo animation consists of all allowed moves in a chess game, though only a few of them are seen in most games. In the final program, we had a Qt interface that would parse and database a PGN file (my part), convert it's moves into a series of animation commands and replay the whole thing. Since the final program didn't work for every game (well, atleast my parser and my renderer were working fine enough), I decided to upload this animation demo instead. It also solves certain license problems with non-original PGN files, Qt's horribly huge runtime and the fact that I still don't exactly know where the models come from. It looks quite raw in it's current state, no antialiasing and rather simple animations.

    Note: The renderer doesn't properly work on Windows for some reason and I couldn't get it right (probably an OpenGL version difference). It's also to note that I excluded the model files from the source code - I didn't make them after all.

    Download (64bit Linux, 32bit Windows, C++ source code)

    OpenGL crane


    A small OpenGL graphics demo which was actually a mandatory assignment for an OpenGL class (and also the first time I ever coded OpenGL). It had to feature a system of joints the user can rotate/move seperately as well as a light source attached to it's end. I somehow overdid it and added a small bitmap-based voxel character rendering system and a sine-based water surface simulation. All objects will change their elevaton according to the water height, though sometimes they seem to float above it (midnight coding isn't actually the definition of "bugfree"). See the readme file for more informations.

    Download (64bit Linux, 32bit Windows, C source code)

    Display Lists

    Did some quite clever sorting stuff with my graphics engine. I really have to say that I love the concept of Flash's display list concept. It makes a great tech one can still and pimp with his own extensions. I guess I won't even need any sorting for the display list filling I'm using for my raytracer. Whatever. I'm pretty glad that I did not stop working on it, did not choose to start another project, and, most importantly, went through the whole process of getting expertise in C/C++, generalization, optimization and programming in general. I didn't do anything productive in this time but it pays off more than I ever imagined before. Some things just take time and impatience never was a strength of mine. Oh and the hard work of getting the perfect linked list done was more worthwhole than than most other parts of my toolkit. It's so easy to manage and iterate lists with it. I don't need iterators, I don't need to catch special cases - so far, no algorithm I've used in my toolkit had so to special handling of empty lists or so. That's quite a rarity I can tell you. I'm really glad about my progress right now. There's nothing more rewarding than the knowledge of having done the right thing in the past.

    Back to the topic, this display list is totally expandable for more powerful, future graphics displays. I'm not quite sure whether I can combine this z-axis model with 3D but I guess that will be some interesting solution to this. I can't wait to see it becoming something more and more powerful! But for now, this system should fulfill everything I'd ever need for my ASCII raytracer. Did I say I like catchy three character long abbreviations for modules and libraries. ITK as the Imperial Toolkit does also type nicely. My graphics engine is named IGE - Imperial Graphics Engine. But since the ASCII raytracer is something more specific, non-imperialistic in nature, I came up with an ironically fitting name: ART, ASCII raytracer. Yeah, I know. Not very creative but I like the implication behind it.



    I'm quite eager right now, since I've found the "vanilla" version of my chessboard renderer without all the Qt stuff which means that I can comftably upload my code on dropbox or so, link it here and release it as BSD. I'll also make videos of it and upload it to Youtube so that the whole application stuff gets a bit more visual with needing to worry about compiling this stuff as 32bit executables (a bit difficult to get with a compiler where I don't know how to do this). I can't expect everyone having a 64bit operating system, so this solves some problems if they can't execute. Yep, having my own code with all the Qt stuff around makes me way more glad and solves the license problem. I can't express how nervous all this makes me - maybe I can get into a game developer studio where they code their own engine in full C/C++ for multiple platforms! Plainly awesome, especially because I can many people knowing way more about game developing than I do! All the secrets and 3D wizardries I always wanted to have someone telling me about, bundled in one house! Oh geez, the thought alone is enough to approach the application very carefully. I don't want to risk beeing rejected, the child in me would cry by this.

    Designing a 2D graphics engine

    I've started a simple recursive display list system for drawing scenes with SDL surfaces and have to say that I should really take more advantage of palettes and alpha blending. I'll probably never do a 3D mode for it but apply the same concept with 3D some day, for a different game of course. Anyway, SDL isn't the most comftable library but the stuff it provides does usually work in a stable manner. The concept of display lists in display lists is something I've taken from Actionscript - though some minor modifications for whether to z-sort sprites or not will expand the system to something more usefull. And the more I'm trying to incorporate all of SDL's features per sprite which get re-applied every time we're rendering one (to enable a single surface be part of multiple sprites), the more I wonder what graphics effects I may be able to utilize, the more palettized graphics come to my mind. See, I'm already using 8bit sprites for coloring the font characters - so why don't do some more palett magic? One thing I'd definitely like to have is some sort of bump mapping. How to do bump mapping on flat fonts you ask? Well, pixelate the whole thing with different palette colors for different angles and directions! The most basic setup would have a surface directed to the camera and one 45° angle for each cardinal point. this can be expanded to 22,5°, 67,5° and so on for more steep or flat angles. I guess it's even possible to take normal bumpmaps, palettize it, analyze the used color components and generate a vector for each palette index. Yeah, that sounds totally possible and probably not hard to integrate due to all vectors and values present in the renderer. I start to like the palette concept. One only needs to alter a few values and a great 2D was born. Fabulous!



    Woohoo, my convenience modules is done. There are for sure some small bugs in it but I was able to port my test using the sub modules directly with this one in way more comfort and less code. It's very simple to use inside the given functions and I'm sort of proud when looking at my work in total. It's about 4000 lines of code, comments not counted. And the awesome thing that I can put this thing anywhere, even the Pandora! Oh man, I'm a happy person right now. I think I've earned a nice evening of playing Minecraft or Terraria. Now just a bit of commenting and I can put into my portefolio. I've decided to not licence is it right now but later, after getting an internship. I feel a bit safer this way. Who knows. Anywhere, ITK has reached a good level so far and I guess it's functionally ready for release. Requires a lot of parameter check and state machine transitions but that just something to be done aside. And, well, seems that this is also my bachelor work I didn't yet make an exposé of. But even if I won't be accepted by any professor/verifier, it's such an awesome to me - all things I wanted, packed in performance pool! Simply awesome.

    And now it's time for some mind-soothing gameplay voyage.


    On the road to laziness

    What a pleasure to not having to learn for exams anymore! Atleast until the point where I'm starting the master. However, since I'm thaaat lazy, I did of course work a bit on my project and found some acceptably consistent concepts of how the convenience module works in general. Some things I explained before were not quite the best solution. Thus, the stuff I'm using right now is more nice and consistent. And I'm getting more and more fluent with my own logical function return/success system. I didn't knew whether it was a good idea in the beginning, but it starts to pay off. Though I'm using macros on almost everything function call, It enables one to track down almost every possible bug happening via false parameter passing or library function fails. Haven't yet implemented state machines, but these are not of concern right now since I'm definitely in the know of all the annoying caveats that may happen due to false use (oh, yes, the bug hunt...).

    Guess I'll do a little pause after the convenience function with an appropriate demo/test program and start documentating this weekend. Then I'll be able to do a first more or less "release-ready" version of it. It's indeed important to me not use unfinished or heavily disadvantageous code with has definite bugs I know of. It's too bad that I don't have anything else but the few old graphics demos. Damn.

    Whatever, I shouldn't think about that. Stay confident with your stengths someone told me once,


    Less playing, more watching

    I noticed how much I long for new episodes by the few Let's Play-ers I'm watching on Youtube. I wouldn't do this if there'd be something interesting to play and nothing to program. I'm even watching those games I'd never play myself. In fact, game I want to play myself for some reason won't make it beyond the first two parts or so. That said, it's a channel for stuff I just want to see but not play. I've always had some sort of strange relation towards games and watching them like an everyday TV soap makes the whole situation sort of delicate. I mean presentation is what these developers put into their game and thus what they did to sell it. If there would be new games with gameplay I'd enjoy right now, I'd buy them. But everything is completely watchable - now I understand why certain companies want to prevent video game recordings on Youtube. Anyway, they forget that watching stuff online is read-only, non-interactive and bound the once captured quality. It's nothing like experiencing a game when playing it. Therefore, I'm having quite the fun watching those games I'd never play myself - I don't have spend my time with them.


    It's all so depressing

    I took the whole day to find a better microphone for Let's Playing as well as a TV card to play my console games once again but the poor quality of available, payable microphones is just depressing. Really, I can't describe it differently. Well, it's not the sound quality - I can cope with that, it's the fact that most lowcost mics record everything including computer noise. And since my new mainboard my computer has become increasingly loader when playing 3D games. I can't change this and better microphones that have better recording characteristics just cost a lot of money as well as research into what is worthwhile. I mean I just want to record voice for commenting but everything you can get without looking too hard is either a headset with bad sound or microphones that record everything unwanted. I'm beaten, I don't want to waste anymore time on this. It makes me depressing to just this about it. However, atleast the TV card works. Simply composite capturing card with no fancy stuff or required software. Now I only need to find a player beeing to output in realtime and with sound. VLC does work but has a delay of about 2 seconds! Media Player Classis does show video in realtime but the sound is absent. These two things are so damn annoying to get right. All this stupid analogue-to-digital shit makes my cry inside. One of the reasons why I prefer to either do everything digital or analogue.

    That sad, I'm once back in my old loop of manic programming, video comsumption and occasionally playing a new good game. And right now I have nothing interesting to play but Unepic. It's nice but also a bit unforgiving sometimes. However kept telling me that 2012 is full of new games that will come out should kneel right down before my feet to receive beating. I'm hope that Legend of Grimrock will be released soon, I'd like to play some nice alternative 3D game with oldschoolish interaction system.


    Kingdoms of Amalur

    I've been playing this game for a few days now and it's surprising that I even picked it up. Usually, I wouldn't have bought this since it looks like just another generic RPG in terms of gameplay. Anyway, a Let's Play of this made the whole thing very promising and I gave it a try, once again wasting a lot money. It does effectly copy from Skyrim and Fable, takes the rendering style of Torchlight combined with the architecture of World of Warcraft. In the beginning it was interesting how well this seemed to work together but doing side quests beside running through the main story is utterly boring. It's the stereotypical "fetch this, kill that" kind of quest you get there. I mean whatever the frame around it may be like, it's just about killing in the end and I kind of regret buying. What about some puzzle here and there? A nice story to round it up? Well, if there WERE story for these sidequests, it'd be much nicer. I don't purely judge a game from it's presentation but as the second most important point from the way how authentic the tasks are represented, how the game makes you feel compelled to do something - the motivation and implication. This is especially important for an RPG where everything's just the same dull mechanic (most of the time). It does fell that nice anymore, levels are just huge and scatter monsters so randomly that it simply doesn't matter where to go - it's almost always the same. If the fighting would be interesting enough to compensate it, but it's not.

    If you do like dull, repetitive tasks with no motivation behind, where even the reward is so useless that nothing can motivate you to continue, something went completely wrong with. Even Borderlands can compensate it's silly base mechanic with awesome style, great humor, graphics and good-feeling shooting. But since everything in Kingdoms of Amalur is so generic, dull and non-rewarding in ANY way I can imagine, it would barely get 7 out of 10 points. This game doesn't motivate you to do any of it's task. I'd rather play Nethack or Unepic for this reason - Kingdoms of Amalur simply doesn't work out for me. Even if there's backstabbing and sneaking (which both are rather poorly implemented).


    One step forward. Or two.

    Last exam finished! Now I can concentrate on more interesting stuff than networking or security/encryption whatever. That said, I did a bit of brainstorming how the convenience frame around my tasker system should look. In essence, there isn't much to do for it. A few wrappers here, some mallocs in the beginning and the whole system runs fine. The only really special thing about this is the question of how to end running taskers and ressource managers. See, every running task has to opportunity to wait for a nother task to finish, which's also used in a special taskpool system I designed for random task scheduling. If just end all taskers, there's the possibility that there's still one left that has a full task pool and thus will wait on a task to finish that'll never be finished caused we had to shutdown the tasker to finish it. Therefore, we will have a zombie thread we can't stop at all. The only real way to resolve this is to just let all the events happen that are still in the ending tasker's query and inform the waiting the thread about the tasker beeing dead. If the task needs to take of that in a special way, he can know when. If not, any scheduling and waiting will be ignored nontheless and the tasker will end itself properly. Do this for all tasks after their taskers have finished as well as the ressource managers and we solved our little problem. I couldn't find any better solution - this is the most clean, most responseful one. All in all the possiblity I do now have unfold more and more and I wonder how much it I'll actually use etc. It's very flexible and I'm glad I "wasted my time" with it for the last months. Furthermore, this one makes a formidable bachelor project, though I wonder how much of it should of it should be revealed as finished to avoid delicate situations involving our bachelor project rule sets. Whatever. Nobody told me to have done a "bit" of it before officially starting. Also, if I can't find any prof signing my exposé, I'll simply take the game engine itself as the expose or rather the graphical work behind. Whatever it'll be, I do have some great tech to realize it. Hooray!

    Legend of Gimrock

    Just at these visuals. Amazing! The feeling is brilliant as well as the awesome idea of putting dungeon crawling into new quality layers. I really dig what they've done with this! An exceptional surprise, indeed.



    Wow. I didn't except to be able to reproduce the freeze problem with my ressource manager. Apparently, I've chosen some false of this function and it behaved exactly like during the previous freezes. Used with care, this system makes it possible to have 1000 threads managing their parallel access with a simple need/dont_need scheme, waiting for them to be done and so on within around 50 ms I'd say. Sure, you won't want to use that many threads, but I'm really glad that it also works properly for so many. Also, I couldn't find any errors or false - I assume it's done!

    Soooo, all I'll have to do now is to create the actual engine on top of. The convenience layer that will take of false function and memory allocation. For this part I'll switch to dynamic memory allocation because there will a lot of memory to allocate - more than I'd call easy to use. The thing would be to just choose a few parameters and be done with it. Yeah, I'm looking forward to designing some convenience stuff! Awww, great. Finally. I was looking forward to this! And now the time has come. Woohoo!

    So let's just assume that this works properly

    You know what? I tested this code a millions of times now and there was no flaw after another little flaw in the ressource manager. It was almost in the same place as the segfault reason and I haven't yet encountered the freeze problem again. I did a more difficult test scenario: 100 threads parallely accessing three different ressources with a three-step phase for each ressource and also some recursive ressource acquisition calls as well as ones that should be could by the functions. And you know what? It worked. It worked so damn fine that synchronizing and resuming 100 of threads that often in a sequence only costs a few milliseconds executing the program. I'm quite surprised - haven't seen such a good performance coming. However, I noticed that sometimes the release functions will be called one time too often, maybe more. And I do definitely need to check this out. But I'm glad that the rest seems to work. I'll just assume it does, if not. I mean I tinkered with all time. Stuff has to go on.

    Pimp my debug output

    I couldn't find ANY further clue about the lasting problem causing the deadlock in my problem. Well, I just just spam out values everywhere but I have around 5 or 6 threads running parallely and they all want to produce their output, too. That said, I'll build in some features to exclude certain threads from debugging an only display the relevant one. It's like there can't be any situation that may generate this problem at all. So I hope improving my debug system pays off, bringing more information. It's all in the domain of my bachelor topic, so there's definitely a reason to deliver multithreaded debugging, too. Hmmm, that's really difficult right now. It's probably just as trivial as with the segfault.

    Anyway, I've also had a few more ideas about the demonstration game's tech, including background compressing/decompressing if it's not too much for the CPU. In essence, everything that drains CPU and can run on it's own is enough to be suitable for the demonstration. I can combine the raytracing with software rendering of the sprites and some more graphical effects on them like bump mapping or so. Combine this with the background streaming and it's gonna be quite a good demonstration on how effective the system really is. I don't intend to make all this computable in realtime, but it's always good to have something to show off and explain how differently the load balances, wht's too much for the engine on certain CPUs/OS' and so on. All in all, I can put in whatever I feel is cool and be done with it. That's quite important to I'd say since I didn't yet send out any application for the internship and won't know what I'll exactly do there. Generally speaking, if this damn thread system is done, I can start creating a few simple tools for file and game content management and code the game engine itself after that. I'm quite thrilled by only thinking about my dream of a more or less completely CPU-based game coming to reality. I love these tiny bits of graphics programming without having to worry about graphics card bandwidth, their performance and use of DirectX or the now admittedly old-fashioned OpenGL system. You can control every millimeter of the output, get top, graphics hardware-independent quality and high portability on systems that have the required power and multicore setup. That's what I always wanted to reach but where always limited due to missing CPU power and coding skill. Now the time has almost come! Beware of the incinerated game engine of death! Gotta go to playing play Terraria.

    New Category and a small success

    I decided to use a new category for my lengthy debugging sections (namely "Bug hunt" not limited to programming). That said, I can also mark a first first success! Well, sort of. I think I found the segfault-producing code. It was a rather trivial - an old, out-of-use null assignment. Funny, it wasn't my debug system's fault. So I hope that I can know try finding out this stupid freeze/deadlock error.


    If that's not something awesome

    I got a great idea for an "analogue" value/memory system: there are no integers but only float/fixpoint values. May sound weird and utterly useless? Well, let's just imagine you want to do something more "fuzzy" and you know that the systems you're coding in knows no adresses or direct indices but just those floating values and "memory areas" that resemble sets of n interpolated values you can expand by just writing a float value to a floating point position and an algorithm behind will include or reject the new point if it meets a certain difference between the value of the interpolated position and itself. What you get is some sort of string with "floating" values. So why do something like that? Why throw fast index access away and use this vague stuff? Well, because it's interesting for certain graphical effects and simulations of analogue systems. Everytime I played a console game on my old TV it looked exactly like it should because the TV's analogue display has some unique illumination abilities compared to more sterile LCD displays. This makes it hard to completely enjoy an old video game using a TV card for example. Also, a cathode ray is no pixel array, takes it time to display and cycle through the screen. And now let's imagine you want to create a more unique way of displaying your retro video game by simulating those TV screens. Sure you'd start still using pixels and use some filter to let it look right. But it won't look as sloppy as the real thing, ay? Using a more analogue way of storing and displaying data brings the ability to simulate the illumation effect a bit more nicely as you can just "plant" illumination behaviour on your analogue memory and do interpolation models the rest. Even more interesting, values could have an alteration ability where they mutate or age on every access or after a certain time. Iteration may be slower than with an array, but some sort modified binary search or binary tree should do the trick here to find the analogue values you wrote randomly. Yep, I think this can be very interesting, indeed. Something I could definitely use if a huge dynamic field of values is required but only a few of them are actually unique and stretch across the whole area. Moreover, an different interpolation model can be chosen to have some more value-oriented interpolation that resemble illumination of certain curves. I like the idea very, very much and I can also think of a complete game display written using such analogue rendering approaches, floating between sprite arrays and so on. Using n-dimensional floating memories one can directly map multiple graphics to the display, giving a completely sloppy and unique way of rendering graphics and sound. Yeah, that would be very interesting. Definitely need to do this during the term break. And who knows - maybe this can come in handy for graphics effects in my bachelor project.
    Found the reason why I'm getting a segfault. I didn't keep in mind how a ressource's ressource manager pointer was managed when multiple threads access - quite delicate since I deemed it done myself! There's no clue whether this is also the reason for qmutex relock problem but well - eliminating this one can only make the other error more clear. It's slightly reproducable. There are a few situations which definitely produce this error, so I'll can locate it more easily. Seems that I'll have rework this one a bit but I'm very glad that I found this error. It's definitely a null pointer or, maybe in the case of freezes, something else pointing to where it doesn't belong.

    Woohoo, we got a clue! That's good by default, I think.
    Interestingly, there seems no freeze loop when disabling debug in everything the main module with the actual program content. I'm it seems like that because I know how rarely and how sudden this freez could happen. But since I can't simply say anything about the other code beeing wrong, it has to be something in the debug system. I mean the only thing this debug system does is change the scheduling and the delays between action - but exactly this is what worked well before! So I can't help, but is related to the debug system. Well, atleast something I can focus on. Should do some more tests one this - in a seperate test file to keep the actual code from running properly. At last, I fixed a few things that would eventually become a problem. The more I think about it, the more I'd prefer to write a more specialized, event-based system one day. But not this time since it requires way too much work to keep it in time with the bachelor thesis, the game creation itself and so on. However, the thus lasting segfault always happens after attempting to schedule a release task the second time on the same ressource after doing the same on the first ressource. It could be the hash array, though... Yeah, I haven't tested it thaaat exactly, only the correctness of it's output compared to the input in a very controlled 1-N value range, not random thread identifiers. Hm. Excluding the debugging or limiting it to non-colliding threads with one-time use will not result in any problem. But wait, debug messages also come when entering and exitting functions - maybe this has to do with it, too.... Let's see about that. I can think of it beeing a problem involving parallely debugging threads - ultimately doing something false that will result in overwriting of values.


    A few hours ago I was kinda desperate due to the bug I described in the last post. Couldn't really find out what caused to problem, but I knew that the only logical reason for this bug is a flaw in the resume/pause cycle. And yes, after some debugging I found something completely overlooked: the situation that happens when two threads try to resume a single thread at once. Some strange things will happen then: double qmutex locks on qmutex with two other qmutexes. Undefined behaviour indeed and should be prevented by some simple mechanic. I think I already figured a simple one, just need to implement it. I should do some stress testing with random ressource acquisition of multiple threads to see whether there are some more problems I didn't yet detected. One thing I learned with this project is that intense testing with a lot of "hey, what happens if I try this?" intiatives are very important for multithreaded code. The bigger the system becomes, the more unseen problems will happen and you have to find them. Actually, I'm quite happy that I was able to split everything in enough pieces to verify that they can't be part of a certain bug. This helped me a lot and still, there are so many things one should add for better debug output. Stuff like automatically spamming variable and so on - though in a wanted context. Or like masking out threads and whatever else. There are a lot of ideas in my mind but most of them aren't as useful as they are cool to have. Therefore, I'll rely on a simple, consistent setup I into, even if it's harder to decypher and slower to debug. But without a guess, even those nifty features won't help you that much. It's only quicker if you got a good direction, not more. So they aren't that much of use right now. Maybe later.

    Anyway, there are only two exams left and my mood gets better and better as preperation becomes more nicely organized. That's good by default.


    Tiny refactoring and some more debug features

    I added the possibility to also pass debug system-using functions inside other debug calls. It's way more comftable and also easy to implement with my hash array. I'll add some more dynamic hash array use, so that the array won't stay filled in case of repeated starting/stopping of threads. Anyway, I also split up a few functions of my tasker and ressource manager to have finer control about binding and unbinding their threads. It's straightforward in use and also keeps another small bug from occuring in time. However, there's still the rare opportunity of unsuccessfully continuing a waiting thread. It's really rare as it seems but I'm confident that I'll find this one, too. Anyway, the finalization takes shape! Excitement with every new stabilizing, bug-reducing element.

    But it's sad that I don't have the time right no besides the occasitional lookup on my way to work. Semester projects and exams shouldn't be underestimated just because one has a good flow for his own project.


    What great fur, er, chitin!

    Hunted down the last bug I knew of! This little bug in the debugging wasn't really a flaw in the debug system but in a function that called another function in a debug call. The called function just returns a thread ID, so it was simple to fix that. Seeing these things happening I wonder how I can prevent this during compile time and execution. The only things I can think of is to store whether one is currently inside a debug message before starting another and output an asynchronous message. But this will become a bit dirty with the mix of macro an function calls I'm using right now, so it's advisable to check for the debug mode definition with some #ifndef-ing. So yeah, problem solved, woohoo! Too bad I don't have to time for using the system. Have yet to learn for an exam (didn't really have interest in the programming part of constraint logic) and do some bits for a presentation of wednesday which I'm no sure about either. Oh and did I forget the exams on tuesday and thursday? God, I can't say how incomftable this all is. As if it would be of use to cramp it all down in to one week...


    Rejoice, the bug hunt has come

    I was able to identify the bug that caused my tasker/thread manager to take longer than expected. After a rather cumbersome experimentation session I found out that it happens only a tightly timed situation where a thread manager won't be able to notice that a thread got resumed and then immediately paused again. In my situation, this resulted in the tasker not doing a pause at all but actually polling for new tasks until some set it's end condition. Quite hard to track down but I'm glad to say that it finally worked now. Atleast the happening rate changed as I was not able to identify a failed test after the fix. Now, pausing and the resuming threads will both do a second to continue together without any opposite betrayal. Hooray! This is how I like a bugfix reward. Now I only have to fix a problem with the debug system. Not only that I noticed segfaults, I also know that there's atleast another module where a complete program freeze can happen. The only qmutex the whole program uses is the debug qmutex for debug output. Therefore, I definitely know that it either has to do with false use or a general flaw of the debug system. But I'm still wondering whether it was really necessary to create the hash module. The errors are exactly the same and not as fast as before. Therefore, I can of course feel good cause it works as "good" as before, but it also tells me that it was not necessary if it didn't solve the problem... Well, I got a nice hash solution nontheless. I don't give a damn about any different approach than just using module and lists - works fine in every case.

    Anyway, today is almost over and I think I've earned a few hours of playing. Good that I sorted this out. I'll do some more tests later with more special and tightly communicating taskers and tasks. Or I could just continue and do some game engine content! Yeah, some nice software rendering for example. I'd enjoy this - especially with my vector/loop macros.

    Never buy a Sennheiser PC 350

    Seriously, it's the worst price-quality ratio in the universe. If you buy a headset or headphone, you'd usually assume that it sounds either totally tinny if it's cheap, has more bass if something like "more bass" is written on the package or that it just sounds normal if nothing was specified otherwise. But in the case of the PC 350, it sounds like a cheap radio or cellphone speaker. When buying a >100€ headset, I'd assume that the sound is atleast normal and has no flaws compared to the really cheap stuff. But this one sounds artifically tinned and doesn't play ANY bass at all. Start Dead Island with normal headphones and you'll be greated by deep and warm bass sound that is important for feeling and surviving the game. With the PC 350 it's essentially nothing. Some high-frequency critters once in a while when hitting a car, but everything else is either totally silent or just not hearable. Those damn idiots, why would they put such a cheap sound into such an expensive headset? It doesn't whether it's comfortable or has a good microphone if the sound isn't atleast of normal quality.

    If you want a headset for gaming, avoid this product. Get one from another produces, the PC 350 is simply NOT worth and you go better buying a seperate microphone. I'm more than disappointed by Sennheiser. It doesn't say that it's totally killing the bass. Bass at normal volume is the most important part of any game.


    I don't know why but I still get the segmentation fault when using my new hash module. I don't understand this, there must be some reason why the debug systems fails with too many nested debug calls. It's not that I'm using twice (and if I said so before: I was wrong), I'm always properly unlocking everything and so on, there's no false use of it. Well, atleast that's my knowledge right now. Wouldn't surprise if there is a small mistake creating all that. Hm, that's really difficult. The more I debug in a specific functions, the more often segfaults happen. This means that it has to do with when a threads comes in there. I take away the debug messages from a few functions but the closer I come to the most nested on, the more it will solve or create problems. I can't find any evidence about my system beeing wrong since it works totally fine just without these two functions doing debug output! I'm doing random code checks right now - it's a very weird bug.


    Yay for hashing

    Hooray, my hash array works! It's became more complex in the end with a pools, settings about it's flexibility and so on but it works very fine right now. It's in essence a sort-of three-dimensional array with a two-dimensional helper array that'll be linked dynamically depending on how much space is needed for specific array entries. Therefore, one can define the available room with a three-dimensional vector that will control it's behaviour on entry occupation. The width is the classic hash array length - the higher, the more scattering will occur on closely numbered keys. The depth is the amount of "slots" per array entry, the number of entries with different keys that need to fit in one entry. And finally - the most interesting one - there is the height: the number of width elements long rows that will be used to lengthen a cell's slot memory. The algorithm will manage those rows in a pool and occupy/release them on demand, giving fine-grain control about the memory/speed/dynamic/static trade-off. I'll need to document it a bit more clear, but the usage is very simple if you know how to properly dimension the input arrays. However, it enable 1:1 mapping to an array of that same size that will contain the actual data (I think I mentioned that before a few times...). So for example I can just waste memory for sheer access speed or keep fine-grain control about a small number of entries (like in my multithreaded debug system for example). I'm very happy about this creation. It's like having a tool that can prove very useful in the future for a lot of tasks. I'm gonna combine it with my debug system this night and finally hope that this will solve my segmentation faults when using my old debug system. Oh man, I'm so glad that it worked out so well. 150 lines of tightly packed made me realize how comftable my macros can actually be. I only had to worry about the abstract of the code, which's very pleasing compared to completely hardcoded logic. really happy I am right now. If I can get my debug system right with this, I'm gonna be able to proudly assemble it with a few more features and go on with my application. Yes, I didn't really worked on it all the time (exams, assignments yet-to-finish, some bit of gaming to calm down), so I should be able to work on it after the exam weeks. Shouldn't be hard with such a good feeling from a successful and presentable piece of code.

    Glorious days await me! Atleast in my head.

    Thoughts about Erlang and game programming

    Had a very easy Erlang exam this day and started to wonder whether Erlang could make a decent language for programming games. From a C/C++ programmer's point of view I'd say no. From someone who already created and designed systems similar to Erlang in functionalities, I'd say yes. The main concerns of game programming in Erlang would to have global objects accessible in no time. Doesn't work with Erlang, there are no global variables. But, and that's the main point, most game have per-frame calculation that can be split up into several threads or processes, which means that one can manage large objects/structures/whatever in a way that you only send/request data from running threads - these keep their objects alive and will also do their changes on them. We want to iterate through game objects and do changes to the level and renderer? Just send a few message with the changes if needed. Even if there's no logic connected to a process, it can still be used as some sort of data manager that does it's stuff in the background. It enables event-based and waiting-based processing as wel as polling. I have to say that this way superior and I wouldn't wonder if it'd be possible to write complete, big and complex games in Erlang utilizing this approach. Maybe one day. Erlang has a real lot of awesome features, though I'd add a few more things like not always generating iteration values or just some for sheer access speed and array processing in general.

    That said, I'm feeling better to know that there is a language that is not C, offers great comfort for a lot of things, solves programming more elegant than other non-prodecural languages and could also work for video game programming. Makes me somehow feel good. I don't event know why, I'm not even using it right now except to get marks.


    It's been quite a long time since I've discovered a nice 2D game that didn't make me feel playing another boring jump'n run game. And my preferences make it even harder to find a game that's rather hardcore RPG-ish and immersive at once. Dead Island and Skyrim were the latest games I called worthy for my RPG taste but now I found a great challenger which brought almost three hours of highly entertaining and challenging gameplay: Unepic. It's a little indie game I've discovered via an extremely non-indie game magazine (strange coincidence I have to say). Basically, throw in all possible RPG mechanics and MMO quest clichés ou can think of, mix it with an absolutely hilarious pen & paper background and let it look some combination of fixed-screen progression, Prince of Persia perspective and roguelike-like visibility detection. It's simply totally awesome and motivating. It's so classic and well-chosen in almost every aspect that it made a lovely game so far. I'm not very far but I'm already having the feeling that this game will offer a lot of interesting challenges. Reminds of the a more tutorialized Dark Souls with less punishment on death. The fighting system is surprisingly timing based for a platformer look-alike. Attacks take their time, hit only one enemy and enemy do jump up platform, follow light sources, loose track of attackers and so on. It's even possible to do stealthing this way: daggers to 3x damage when backstabbing and enemies won't notice if you put your light source out (doesn't always wit lit rooms of course). Very awesome, indeed. It reminds me of how much love I wanted to put into my own game and how I wanted to base the fighting system on trigger and logic rather status values. Or was this the idea of my old 1D game? I don't know but I want to combine all those things into one game. And Unepic helped to realize my old vision again. I have to thank you for that. I feel way more prepared to fall asleep and wake up early to beat my first exam - something that happens rarely (I'm talking about the exam) and it's the best thing every one can get, having a good time before going to bed and still feeling good with those memories in mind. Yes, this game got me back into what I long lost: the ability to see why charismatic and unique presentation can be more immersive than modern 3D games.