On Wednesday, I had a day off and I spent most of that day trying to figure out 3D graphics. I’m talking about the theory and to a little extent the mathematics involved. Today I’m going to share a little bit about it and the progress I’ve made. But first let me start by talking about some of the concepts that you really need to get your head around.

An immediate context: performs rendering onto a buffer

A device : Creates resources and renders them onto a buffer

A resource: Anything that you want to draw like a texture but in most cases this resource is represented as a simply a chunk of memory.

Resource view: Is an interpretation of the resource’s chunk of memory.

Swap chain: A thing that is composed of two buffers, a front and a back buffer. The front buffer( and thus what's been rendered to it by the device and the immediate context) is shown to the user and the back buffer is the staging area of that data before it is shown to the user. So you render to the back buffer and then you swap it so it becomes the front buffer and vice versa.

Render Target buffer: This is the buffer you set up and designate to be the back buffer

Render Target view: This is the interpretation of the back buffer that you can render to – this is what you tell the device about and it renders to…

If you put all this together you get a very crude diagram from me here:

In most cases in DirectX, you create the swap chain object, you create a buffer that you designate as the back bufffer and then you hook the two up so the swap chain knows about the buffer. Furthermore you associate the device with the swap chain.

Some more terms worth knowing about:

Vertex – a 3 point, defined by (x,y,z) such that you need 3 Vertices say to define a triangles points.

x,y axes : are the same things you learned about at school.

z axis: Another point which defines ‘depth’. So a verex can be a point x,z fine but particularly its at those points but specifically where the depth of x,y is z. Its the 3rd dimension in “3D”! The X and Y alone are the 2D points. So normally you could have a cube like this:

And that dot you see is on a point with might be x=1,y=0.5 but how far “in” to that cube(ie, the depth) is it? Well that would be defined by z. So if it was at x=1,y=0.5 and it was a little bit inside the cube z might be 1 or if it was a little futher than that, it might be z=1.5. If z=0 then it wouldn’t be ‘in’ the cube, it would be on the front of it. An by the way that point is a vertex.

To render a triangle you send 3 vertices to the GPU.

So at some point you’ll need to send that vertex information to the GPU. In Direct X you need to put all that information in one big chunk of memory and tell direct X to go and read that bit of memory. You also then have to tell direct X what order your vertex information that you stored in the vertex buffer(chunk of memory) is layed out. For example, in most cases the vertex buffer will be a result of casting a C structure that holds vertex information over that vertex buffer and then you need to define the layout that describes the members of that structure in the vertex buffer.

Why go to so much hassle? Well you can store anything along side the essentials of x,y,z that represent that vertex. You can store some colour, some texture mapping coordinates etc. So this buffer is totally defined by you and as such you need to map those things you define as making up your vertex information to stuff directX and the GPU need/want.

So you create a buffer of memory somewhere, that will be called the vertex buffer – the list of the vertexes you want to send to the gpu along side any data associated with each vertex. You do this by defining a structure and overlaying that structure to the vertex buffer and then you create a definition of that structure’s layout. This definition that describes your structure is called the “layout” and is basically the definition of your structure(which becomes the buffer as you’ll typically cast of array of these structures, the structure represents on vertex’s info) on the vertex buffer.

So some new definitions:

Vertex buffer: raw piece of memory that will hold your raw verte data such as each vertex’s x,z,y coordinates

Vertex buffer structure: The C structure that will be cast to that memory (vertex buffer)

layout: a description of your vertex buffer’s layout and thus your structure for your buffer.

So at this point you have stored a whole bunch of vertices in a chunk of memory, you’ve defined that chunk of memory and now the GPU can fetch stuff from it and then render it. The GPU has a pipeline, the graphics pipe line which is a series of stages that the fetched data is then used/transformed ie. rendered.

Vertex shaders are the first to get the data(vertex information) stored in the vertex buffer. It does what it needs to do with it and then sends it onto the next phase, pixel shaders.. Pixel shaders to their business and more it to the next stage so on a so forth.

Vertex shader: a piece of code that gets one of your vertex structures at a time and does something to the data(vertex) – in most cases is changes the coordinates of your vectors on the fly(why do vertex shaders do that? see below).

Pixel Shader: a piece of code that gets the output from the vertex shaders and colours in the pixels on the render target which is what that will represent your vertexes.

I think thats about as much as I’m going to do right now, I’ll probably add more as and when I want to.

Last weekend I spent a bit of time, well ok a lot of time – the whole weekend practically learning about DirectX 11. Woah, what a lot of stuff to do just to render a cube on the screen! The thing about it I suppose is that you’re doing a little bit of GPU programming on the chip which as it happens is quite different to what I’d normally be used to. Pixel shaders and vertex shaders being the prime areas where you’re writing code for the GPU. So you got to do things a bit differently.

What I must say is that the tutorials provided by Microsoft are pretty good. You can check them out here: https://github.com/walbourn/directx-sdk-samples – I cloned the repo and to my surprise it was about 300MBs and i was doing that on my data plan on my phone. wowsers. So a lot of good stuff there.

The nice thing about graphic programming is that its totally different to what I'm used to and as such I’m totally out of my comfort zone, and so is game development for that matter, in most cases but in other cases I feel right at come – C/C++, Win32 and COM to a certain extent. The interesting thing about graphic programming as I said is the newness for me. Learning about the device, immediate device context(apparently dropped in DX12), swap chains and front and back buffers is interesting.

The aspects about 3D theory is something that’s taking a bit of time to master. I can get the 3D coordinate system, mostly and I’m happy with vertexes and describing them and laying them out and then sending them into the graphics pipeline. I say I’m happy with it – I basically understand it. The tricky stuff is the math around matrix transformations. Its something that I’m doing to figure out soon.Basically the idea is about doing affine transformations to objects(objects don’t change fundamental form) – basically manipulating the objects so that they say move and stuff like that. Most of this is geared to 3D graphics programming – like simulations and stuff like that, especially games.

Objects, so far being things made up of triangles so far. And boy does it take a lot of work to send a couple of triangles in! The idea I suppose is to build up on the tedium of this and abstract it and I guess this is true of most complexity in this world but understanding it and appreciating it is what makes developing a suitable abstraction possible. This is what i suppose a game engine does. But you got to know what you;re doing first and that's kinda complex.

The HLSL shader language that you use to define your vertex and pixel shaders is kinda, sorta like C which is good. I’m still trying to get my head around that. I’m still trying to get my head around the projection space/view calculations too as this is a conversion that takes place to represent your 3d world in a 2d space and mostly this calculation happens to the vertexes you pass in to the GPU by the vertex shader. Direct X seems to have easy methods to do all the work for me but I’d like to understand it more. I was flipping through a game engine design book and they just copy and paste the methods that do the magic and move on. Makes me thing that I should perhaps to the same.

Took the day off today because I got a dentist appointment and a hygienist appointment back to back and I will be having someone over on Wednesday so I need to make the place presentable – all things I can do just before I head into London for the dentist.

Back to game development now - I’m still trying to get my GCC4 compiling so I an follow the game engine design but for some reason the objects aren’t linking – specifically the bullet physics library. It was compiling about not linking with VS12 binaries while i was in VS15 which i guess is understandable so I downloaded VS12 and still nothing changes . So obviously I don't understand the problem yet and need to do that before I do anything else.

I’ve also been watching the world athletics championships too, and a bit of the highlights in the cricket. I enjoy watching athletics the most though. Always have. Its a tough life being an athlete.

Currently annoyed with Windows 10 because its the latest version of windows and I like being on the latest but Windows 10 is just not as good and refined as previous versions, namely Windows 7. That being said, I’ve been working on Fedora 26 for some time now and did some cool perl scripting recently on it – Long Live Linux! The problem is that I’m dual booting with windows 10 and I dont have enough space to compile the Linux kernel. The other problem is that while I’m annoyed with Windows 10, its up-to-date on my PC and I’m using it to learn DirectX and other windows specific stuff like my whole Visual Studio is on there. So I’m between a rock and a hard place I think, though things could be worse i suppose so I’m not going to complain anymore.

Been working on a new feature at work which is pretty cool and I’ve refactored the pants of the codebase. I love refactoring. maybe too much. We’ve also got this push to automate every feature we release which is cool and good but I’m not quite ready yet. So I’ll need to start thing about that pretty sharpish.

This weekend was all about resting. I almost decided to go running but I figured that I really need to use what extra time I have to rest. I’ll have plenty of time to go running this week. That was a good because my run today was great.  I slept most of Sunday and it was beautiful.

I got reading about 3D graphics from I book that I got at a great price over the internet. It basically was supposed to by a book that would give me a good introduction into 3D game graphics. It turned out to be pretty tough going in this respect as it was basically an advanced description of the mathematics used in various aspects of computer aided graphics with a lean towards game programming. It was heavy in the mathematics department without much context into gaming. It was pretty boring. Sure it talked about various kinds of things like polygon meshes(which is pretty much the only thing I enjoyed) but it went into concise detail regarding Bezier paths, patches, Constructed Solid Graphics, and everything that sort made reference to gaming seemed totally un-relatable in a practical sense. For instance there was stuff about terrains but nothing I read about that peaked my interest in a way that I might use what they were saying in gaming – it was just so out of context. Also there was too much stuff that was so complicated and that just irritated me. Its a big book so I just moved on. It was just too much about advanced geometry that I didn’t understand and not enough about gaming and game engine stuff. I got an appreciation though for what kinds of boring stuff you need to take into consideration(maybe not even that as most of the stuff is in hardware now) when considering the graphics side of things. I think I will come back to this book when I start figuring out what half of this stuff means or is – Interpolation, matrix transformations and scaling and crap like that. I did learn about the z-axis however – not in the book but on you tube because I was confused about what they book was going on about.

I also downloaded the source code for a game engine that is used/developed in the Game Coding Complete book I’m reading. Then I downloaded the windows 10 SDK because that’s where the DirectX SDK is not incorporated only to find that the source code can’t integrate with the SDK in this way . The DirectX Extensions SDK is no more and the source code relies on it. Well thats sucky as it was a 2GB download. Anyway I’ll just have to get the last Direct X release with is the june 2010 release…

I also downloaded Blender and launched that in the hopes I could get an appreciation for it. I can appreciate this much: I have no idea how to use it and I don't know what it does and nothing makes sense to me. But I know one thing, I’d like to use it to make models and texture maps.

Oh and I downloaded a library which claims to allow shared_ptr<> type tracking of pointers like C++ but in C! Its called libcptr but I’ve yet to look at it. I like the idea that you can not care about your pointers with shared_ptr in C++ but in C you’ve got no such option. This ability in the one thing that makes C++ really appealing to me – not really the OOPs stuff(which is used to make shared_ptrs anyway).