My first steps in character design

Some days ago I decided to start getting into character design. By now every time I tried to make a little game for practice (for example my sidescroller shooter) I were forced to search for free sprites on the internet (or use dummy sprites) which were pretty annoying.

Starting to deal with character design my self were one of the best decisions I made so far since making games became a lot more fun. My first steps are small ones, but at least it’s a start and I can try to figure out the complete progress of making games.

For those who are interested, this is my first “serious” character project (still in progress).

character_screenshot

It’s far away from finished, but it’s a start and I hope it will be a hilarious sprite sheet and artwork in the end.

If I am done, I am going to release all sketches, or interesting states of this project so maybe it helps someone to give him a point where he/she can start.

Advertisements

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.

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.

(C++) An interesting Container design

Okay, this will be one of my first programing posts. I won’t feature a lot of code since I don’t want this to be a how to tutorial. Basically I will present you an idea and give you some thoughts about it (and I will show a little test).

Some time ago I designed a container class (well I named it mango::vector) since the std::vector made a trade I was not willing to accept so I designed a little container class to suit my needs.

Well, here is the situation. A vector is a dynamic array. That means you have a pointer to an array of elements. if the array capacity is reached, the vector allocates a new array which is larger than the original one and copies/moves all the content to the new array. And there is the problem. A vector is fast as long as you won’t bust it’s initial (or reserved capacity) since allocating new memory and moving all the content takes “a lot” of time.

But that’s only on of a few problems. Another flaw comes with erasing or inserting values from/to the vector. If you erase a vector every element after the erased element have to be moved/copied one slot towards the erased elements index which also takes “a lot” of time. (inserting happens to be the other way around –> moving and index away from the insert-index)

Ok, where does that information lead us to you may ask? Well, that’s a damn good question. Some of you will say now “why don’t you just us a std::list?”. Well that’s also a damn good question.

For those who don’t know: If a vector in your memory looks like this:

vector_memory

Then a list can be imagined like this:

list_memory

Ok now you see a memory model, but why?

It’s easy if you want to access a vector element you just shift a pointer to the begin of the array index * elementsize “to the left”. One operation. If you want to add an element at the end (and we suggest we have enough space in our vector so we don’t have to reallocate memory) we just add it. Also one operation.

Let’s look at the list. If we want to add an element at the end we have to allocate memory for a new element and place the element there. Allocation isn’t the fastest thing on earth, that takes some time. If we want to access for example the 4th element we have to drag ourself along 4 pointers. That won’t take to long but it’s still slower than the vector. Inserting into a list is really interesting. If we want to insert an element in our list, we allocate a new one and add it into our list. That’s a lot faster than inserting into a vector as you may remember (no elements to move).

So basically we can break our conclusion into two points. Inserting, deleting or appending elements from/into a list works at a constant speed.

Inserting, deleting elements/from/into a vector is slow, appending elements to the end on the other hand is really fast.

Each of the above mentioned containers do have their ups and downs, so why no container wich is good at both? And that’s exactly the conclusion I came to when I started to think about that topic. This wouldn’t be an interesting post if I hadn’t a wonderful stupid idea to solve that particular problem (kind of)

semivector

That’s the idea I came up with. Simple said, I made a “vector” with 2 arrays, one with elements, one with pointers to the elements.

What is the advantage of that? Well that’s easy. If you want to access an element you access it over the array of element pointers. That’s not significant slower than accessing them the regular way since you just have to access the array of pointers.

Here comes the interesting part. If you want to delete an element for example (let’s take the second one) you only have to shift the pointer to the second element to the end of the pointer array.

semivector_deleted

Now if you want to access the “second” element in your vector you’re actually accessing the third element in your array, but the second pointer (you won’t spot the difference).

(that’s how the “vector” would look like after an insert)

semivector_inserted

So what is the benefit of this? Also easy: If you make an insert/erase you won’t have to shift the actual elements, instead of you are shifting the pointers to the elements. If you have a custom::vector you will see no improvement in performance compared to a std::vector (the performance will even get worse) since shifting int variable is as fast as shifting pointer. On the other hand if you got a custom::vector your performance will increase significant since shifting pointers is a lot faster than shifting std::strings.

Most likely you will ask now: If this is the holy grail of a container, why isn’t vector implemented that way?

Legit question. The answer is simple. This container has other flaws. Yes it is fast. But you pay the speed benefit by using more memory. On each element you add there comes a pointer to that element. Lets consider we have a 32 Bit system: If you have 200 elements with size 8 bytes we got 1600 bytes (+ ca 16 bytes for the actual std::vector object) for our std::vector. If we have 200 elements which 8 bytes in a custom::vector we will have 2400 Bytes of memory in use (if we consider a 32 bit pointer is 4 bytes). That’s a third more. I still like to use my custom container since in my opinion in the most cases the size difference won’t have to much of an impact since memory isn’t always the limiting factor. The standard container a build to be flexible and with things like embedded systems in mind. It’s not always the raw execution performance that matters.

Well now I threw around with a load of claims and proofed nothing by now, funny aye? But this wouldn’t be fun if I hadn’t tested this at least a bit. (Just for those of you who are curious, no I won’t provide the code for my vector since I did some ugly thing down there which I want nobody to know about, sorry. But you are clever guys and I am pretty sure you will be able to implement this one yourself)

This test only shows the insert capabilities of this container, erasing won’t perform much different. The test is not perfect but it will give you a relation of numbers which will at least give you a feeling for the speed improvement.

here is the test code:

vector_test_code

and here comes the result:

vector_test_result

These results are in seconds, maybe I should have written that. The custom::vector (in my case mango::vector) inserts 100x faster (if you believe this test). That’s a number isn’t it? Well, reality seems a bit difference. The number will change, but in both directions. The bigger the elements in your vector are, the faster your custom::vector will get in relation to the std::vector. The smaller the elements are… well you got it I think.

The test was built in release with activated optimizations.

If you actually made an implementation for this custom container which is clean enough to share it with the world feel free to link it in a comment.

An ancient battle

The story of my life…

So guys, I promised  you some suggestions about hardware, and here we are… just without any specific hardware.

I decided to start with something easy which is one of the most important things when it comes to hardware if you ask me: AMD vs NVIDIA (vs INTEL)

I think those of you who are visiting hardware forums sometime know this annoying never-ending story: Let’s imagine we are a normal 15-year-old boy who is really into gaming but we have absolutely no clue about hardware, but we are in the situation to buy a new gaming pc.

Our first idea is to look into a big online shop which I don’t want to name here but we all know it starts with A and ends with n and got a z somewhere along the way…

Okay, we search for gaming computers but soon we recognize that all the hits we get are really expensive and we actually don’t know what to choose. And even worse, from the back of our thoughts we remember our old school friend who always complained about “those idiots who buy prebuild computers”(no offense guys)… but we are non of those idiots… We decide to give him a call and ask him for help, and you know what? He says yes.

So far so well. Pretty fast we got a build together. I5 7600k, 16GB RAM, ASUS Mainboard, 512GB SSD, RX480 graphics card. Pretty decent for a midrange pc isn’t it? Now here comes the first problem. We got no paypal account so we ask our older brother if he can purchase the stuff for us. Well that’s also no big deal, he says cool story bro, I’ll do it.

Then he asks us what hardware we are going to buy and proud as we are we are listing him our hardware. There it comes guys. We tell him that you we going to buy a RX480. BOOM. He looks at us as we were some idiot who punched him in his face and talked shit about his mom (ok once we did but that’s another story…) and he asks us: “Are you fucking stupid? An AMD GPU really? Are you kidding me?? Don’t you know the NVIDIA 1060 is way better?”. We answer stuttering and stumbling that our friend recommended the card to us but he don’t want to hear a word.

Ok one day later we still don’t have ordered our parts and are more insecure about them than we ever were.

We decide to google around. Google–> Nvidia 1060 vs AMD RX480. We enter the first forum we find and the first thing we recognize: Cool someone asks about the same specs we want in our system, well that’s easier as we thought… and then we read on… and oh my god… everyone is bashing each other: Idiot A: “BUT BUT NVIDIA IS MORE EXPENSIVE!!! MORE MONEY IS BETTER!!!” –> Idiot B: “YOU HAVE NO CLUE HAVEN’T YOU YOU CAPITALISTIC NVIDIA FANBOY PRICK!!! AMD IS MUCH BETTER”.

We are closing the browser and decide to better play outside since gaming isn’t our thing anyway and we never wanted to be one of those nerd idiots….

Well that have been a damn long story and I am sorry that my first post is that damn long… but I really want to give it to you loud and clear.

(mostly) Everybody has his favour if it comes to hardware brands… but the truth is AMD AND!! Nvidia are decent brands. Yes AMD has not high-end cards atm. But that will change. But if you compare the RX480 and gtx1060 for instance (and you really try to be objective) you will recognize that the 480 sometimes beats the 1060 and the other way around. Both are decent cards. im honest… I would totally favour the 480. I prefer AMD cards and you know what? I am damn happy about it. A lot of my friends prefer Nvidia cards and you know what? They are also damn happy about it. So please guys… please stop that fight about which brand is better…

Both of them have ups and downs… (the tessellation issue with AMD cards in the past or the DX12 issues with the Nvidia pascal cards). At the end both cards will work out pretty well. The only thing you are achieving with that battle is to insecure those who aren’t familiar with that topic, and that is not acceptable. Every time I read those battles under simple questions I am getting very sad. Ok not always… sometimes I enter the YouTube comment section of some tech channels to start that kind of fight to sit down grab popcorn and enjoy the entertainment… who could resist that?

Ok back to serious business. Please guys… If someone asks you, consider that your favorite brand isn’t the best choice you can get. Why should you chose a gtx970 for 250 bucks if you can have a R9 Fury for 270 bucks… Or why should you choose a Fury X for 500 bucks if you can get a 980ti for 470? Recommend the better offer, not your favorite brand. If someone ask me for a build usually I recommend card for both brands. If I know there is an offer I recommend the better price/performance ratio and in my opinion that’s the only way to go.

I hope this post helps you to get a better understanding for people who have no idea which hardware is the most decent one out there. And I also hope that some of you might think about what they are doing to the poor guys who just want some hints about what to buy but are getting a wild and crazy lynch mob who is hunting him down all over the tech forums instead…

 

 

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.