It’s a start

Today I finished my first little animation. It may look a bit awkward, but I am pretty satisfied for my first animation and happy that is does not look completely stupid, well It’s a start.

Say hello to Tiki-Jack.


I also started to develop in Unity and by now, it’s really nice as far as I can say. A lot of workflows aren’t new to me and the engine is actually pretty handy. I am looking forward to show you guys my first “real” game in Unity. But until then I will continue practicing drawing and designing.

That’s all for now. For those who are interested, some date next week I am going to release some build suggestions for gaming pc since Ryzen 5 is released and in my opinion it’s a perfect time to give some hints since I can take Vega into the picture later.

It is something

Todays post won’t feature a lot of wise words about technical stuff. Today I am just going to line up some “game” projects I made to give you some hints where to start. (Ofc. that’s not all stuff I made, but it covers stuff from different difficulty levels of development I passed through)

The sprites (and meshes) you see are free ones from different websites, please don’t ask me where I downloaded them, I can’t remember anyway (meshes aside… they are from

The first game project I started has been my biggest mistake in this area… starting with a 3D game while having no idea of DirectX/OpenGL or any other 3D API. For this project I started to learn how to use DirectX with C++ and this almost stopped me from continuing my efforts to get into game development. I never finished it.

3D game

The second game I started were better straight through but still not the best choice I for a beginner since I also used plan DirectX and C++, but the game made it to an actually pretty well working status. (for the beginning)


After this game I decided to go back to more basic games which are a bit less complicated so I can focus on more Important things like how to build an easy-to-use gamedev framework for minor tasks, and that’s where this attempt came to life:


This very basic snake clone is made with GDI+ and runs in the windows console. I decided to go away from plain DirectX since I got the concept, I got the basics and I wanted to see more progress instead of pumping a lot of time into understanding the API. This snake game later became my multithreading test playground. Actually snake is to simple to use concurrency in the implementation but it were a good starting point to learn what kind of workloads you can spread best over multiple threads.

Later on I continued with this one:


That one were my first step back to actual sprites instead of just drawing pixels. Not much to tell about it, tron is very simple so I were able to concentrate on implement a sprite system into my little framework and start using frame animations.

After tron my next project were a little tetris clone:


Actually I made this just for fun.

And my latest project in progress is a 2D shooter I am currently working on. Atm. I got dummy sprites which look like shit but which are serving their purpose and I am working on a level from file system so I load complete levels from files.


Well that’s all I made so far. After the sidescroller attempt I am going to start over with Unity3D for some more serious stuff. Until then I am going to practice with mini games and things like my little physic framework.

I only can show you the mistakes I made in the past. Don’t start to complicated. I can’t tell you often enough. Starting with DirectX and 3D just were too much. Start simple and if you got a feeling how stuff is working you can start to do more complicated projects.

If you feel lost, it’s ok to take one step back to get another 10 steps forward in the future. Just don’t stop trying as long as you have fun doing what you do.

That’s all for now guys.

Of threads and games

Hey guys, today’s post will address threading in video games.

In times where multicore CPUs are pretty common, multithreading becomes a really obvious choice for performance improvements in video games. But multithreading isn’t always the answer. This post is supposed to deal with two common issues I noticed again and again over the last few years.

The first one: Improving (render) thread counts in .ini files of video games to tweak performance.

Well that one might be a bit complicated so I decided to address it first. Sometimes when I read forum entries where people are complaining about bad performing video games, a couple of times someone came up with a lot of .ini tweaks to improve performance. Basically there is nothing wrong with that, but as you might guess already, not all of these tweaks are really helpful. Improving the “render thread count” for instance is not worth it (in most cases). More threads do not automatically mean better performance. Quite the contrary, often this will make things worse.

DirectX x to 11 and openGL aren’t capable of multithreaded GPU/CPU communication (or at lest not very good at it). And that’s one of the core issues. Yes multithreading in games makes totally sense, but only at some very special points and in a “very limited” range. Throwing 32 threads at a game and thinking it will work better is a wrong approach which usually comes from people who have less or no experience with multithreading and/or game development.

Ok back to our DirectX/OpenGL description. I will stick with DirectX in this post since I am more familiar with that, but most of the points will apply to OpenGL in a very close manner.

As I already mentioned: You won’t be able to pass render tasks to your graphics card from multiple threads at the same time. This leads us to a more or less annoying issue.

In a beautiful world, filled with rainbows unicorns and a multithreaded D3D(11)DeviceContext, rendering would work like this:


Sadly our context isn’t threadsafe. What does that mean? Well, it’s actually not very complex. As you can see in the picture above, if the world were a better place, we could draw completely parallel but in reality things behave a bit different. If we want to access the D3D11Context, we will have to hide it behind a lock to serialize the access, otherwise our game would crash or at least begin to behave in a strange way. That means our rendering would look like this:


You might recognize that this will prevent us from taking advantage of our multithreading capabilities in our game, even worse we are facing the threading overhead (yes, spawning tasks and assigning them to threads also takes time) without getting any performance benefits –> our performance decreases. And for the DirectX pros who are laughing at me right now: Yes I am aware of Deferred Context and CommandList but this image is thought to simplify the whole thing for those who have no experience with DirectX since basically you giving tasks to a threadsafe container and execute them all in one thread with an immediate context is the same principe as seriallizing the draw-calls per mutex. The immediate context will execute them one by one anyway. (remember? we are still in DirectX 11)

This might sound like: Multithreading in games is bullshit…. It isn’t. There are other ways to bypass this issue.

Things like animation updates, collision, position updates, sound, physic or even preparing draw-calls can be paralleled very well (that’s why people might have multiple threads for rendering). This is an example how a parallelized frame could be prepared/executed:


This pretty much shows how I am processing my frames (with sometimes more, sometimes fewer threads… it depends on the complexity of my update/collision functions). And yes, sometimes I am doing my collision check twice, first at the beginning of my ->Move() function, one time after my ->Move() function. (One may argue about efficiency but that’s not the topic of this post).

Okay I think this gave you a little insight how multithreading could be implemented in a video game and wich problems you might have, but that’s not all folks.

As a little conclusion you might take the following. There are developers who use multiple threads for graphic tasks (as I already mentioned, to prepare their draw calls), but that’s not the rule (at least as far as I know). And even if there is a render thread counter inside of an .ini file, leave it how it is. In the best case you get 1-5 FPS. In the worst case, the engine can’t handle the increased parallelization workload and your game looses FPS. Developers do not chose this numbers for fun. They know how their engine works (at least I hope so), so they probably will know better how many render threads will be appropriate.

And this leads me to the second issue (I promised you two issues 😉 ):

It’s not always a good idea to throw threads on a game. There are beginners out there who feel forced to use multithreading in games since there are multithreaded CPUs out there. That’s not always a good idea. If you have a game with simple physic, simple collision, low graphics (that does not mean bad graphics), you don’t want to throw multiple threads at it. Take a very basic tetris-game for instance. It could look like this one:


Why the hell should you throw multithreading at this? Actually you will put a lot of work into getting the same if not worse performance out of your engine just to say: Well it’s multithreaded. I know, this is a really trivial example but it suits my needs. Most likely you won’t need multiple threads in your game until physic enters the field. And that’s another point. I can’t tell it often enough… Don’t use too much threads! Maybe you remember the little physic framework I introduced in my last post. It’s back.

less threads

In the right upper corner you see the FPS. (Yes, it’s running at higher FPS than the gif I uploaded does.) Atm, the engine is running at 4 threads and everything is fine. And this happens if you add another 2 threads to the pool:

more threads

Again, FPS counter upper corner. Well you might recognize that the FPS decreased a little bit. (basically 1 fps and the FPS are at a lower point in the average) One FPS might sound like absolutely no problem (and that’s actually right). But it would be performance you might get for free. And if I would increase the thread count even further, the FPS would decrease even wider. The impact on this example might sound negligible, but you are forgetting that this is a really simple example. The framework is very basic and there never were performance issues by now (unless you triple the square number). If the performance draw would increase, the FPS loss might increase as well. That’s the reason I recommend finding the sweet spot where you get the best FPS with as few threads as possible.

That’s all for now, I hope some of you may be smarter than you were before reading this post.