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 mixiamo.com.)

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)

invaders.gif

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:

snake

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:

tron

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:

tetris

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.

scroller

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.

Advertisements

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:

ParallelDraw

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:

Draw

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:

frame

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:

tetris

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.

Physic frameworks from hell

Hey guys, let’s get straight to the point. I am developing an own small game engine at the moment (the physic framework of the engine in particular) and I wanted to give you some opinions about rolling your own engine.

This post won’t feature any code since I don’t want to bore you with C++.

My first advice to you is: If you want to understand features which are implemented in other engines, don’t try to roll your own ones to get a feeling why they might be designed like this. You will get frustrated, I guarantee it. That’s a totally stupid idea (that’s why I am doing it 😉 ).  Try to stick with the documentation and tutorials of the engine you are using and you will come out much wiser than you are now.

Well this advice only addresses big features and core libraries, it won’t hurt to take plain DirectX (or at least XNA) to look how to implement a little render backend (and if it’s only for drawing lines). When I tried to work with DirectX first, I was really confused and experienced a rollercoaster of emotions from joy to hate to despair and back to feeling like a god when my first mini-game worked (a space invaders clone). But at least I understand the basics now.

Drawing lines with DirectX is no big deal. You initialize your components (swap chain, dxdevice, dxcontext etc.), you take some vertices and put them in the buffer and then you swap the buffers. But you won’t know that if you haven’t at least read a bit about the basic functionalities of DirectX and co and the naming scheme of DirectX is hell (at least for me). What you shouldn’t do (at least if you aren’t one of those mega mind programmers who read something and instantly know what to do…. I am not on of those guys…).

Well that leads me to my next advice. If you want to develop a serious game and you not part of an AAA studio you don’t want to roll your own engine. Trust me, it’s not worth the trouble. There is a really good chance someone somewhere did id better anyway.

Unity, Unreal and co aren’t around for all this time without a reason. They are well-tested, good developed and very comfortable to use. It’s ok to roll your own engine if you have the experience, time and money to do so, but overall you will be doing better with a third-party engine as a beginner and/or indie developer.

Well I can tell you a lot….. really I can… and you know what? I do! And you know what’s next? I will give you an example how annoying it get’s to roll your own engine features. That’s where my little physic framework enters the game.

physic

It’s nothing big, it’s nothing shiny but it’s mine, and I love it for being mine. But here comes the problem…. While watching the gif you may recognize some of the little squares vibrating instead of coming to a resting position. I recognized it to late and that’s where the trouble started… It took me 4 hours to figure out what’s wrong with this stupid physic calculation. 4 hours of my life.

When I found the issue I got mad. Really mad. Basically when I calculate my speed I round to whole numbers since my minimal motion range is 1 pixel. And that’s where the problem was. By rounding the numbers the falling speed of my squares sometimes if I hit an unlucky number remain at 1 and go down to 0.9 and then they get rounded back to 1. 4 hours for this little shit of a bug. And this is actually a very simple (and not very realistic physic) framework.

I am doing this for training purposes. I am planning to get my hands on Unity 3D (yes I could also start with Unreal or s.th else but I decided to go with Unity). But until I start using a “real” engine (every engine is a real engine… is it a good one, that’s the right question) I want to learn a bit about general design possibilities of engine features and since I feel pretty secure in C++ I decided to do what I told you not to do. And you know what? Sometimes I hate my self for not listening to my own advice. Actually I could be much smarter than me…

Ok enough trolling for one day, serious guys. You will do yourself a favour if you use a third-party engine. If you learned how to use them, you can start customizing them and if you learned how to do that, it might be a good idea to roll your own engine. But until that happens, the chances are good that you will destroy your motivation with rolling your own stuff. At the very beginning I got really frustrated (exactly by doing this kind of mistakes) and stopped trying to learn more about game development. I had a functionally little 3D graphics engine (very basic, bad graphics etc) but it was a start… and then I stopped working on it.

Now I went back to a little 2D engine which is much easier and is really enough to learn the basics. Sometimes even this is a start. If it get’s to hard, go back and start with something smaller. Just don’t stop trying if you really want to do this.

I hope I helped someone with that advice.

Hello World

A short introduction of myself and what I want to achieve with this blog

Well, I thought a lot about how to start this and I came to the decision to tell you guys why I am actually doing this.

First of all, a bit about me.

I am 22, I am trainee (in my last year of apprenticeship) as a software developer. My main programing language is C++ but I am also familiar with C# and Java. (Java only a bit).

My dream is to become a professional game developer and I am trying to teach myself the basics of game development.

I am interested in software design, gaming but also the most recent hardware, and that leads us to one of the points why I am doing this blog. My friends and family are asking me a lot about hardware and computers in general and want some tips which hardware they should buy, and that is one of the points which I want to cover in this blog.

Ok what does that mean? Well, I will try to give some thoughts about new hardware (like AMD Ryzen etc) for different use cases (video editing, gaming and media stuff for example) which you can take as a base for buying a new PC.

But that is only one part of this blog. I will also try to share my thoughts and lessons learned about game and software development on this blog so those of you who are interested in that topic may have some ideas or starting points.

I will try to share good sources and protect you from bad ones. I am still in the process of learning so I am always happy about advice, constructive criticism or corrections from your side.