This weekend was also pretty good and I wasn't playing any games - I was learning about how they are created.

I started off with becoming a little more familiar with the 3D graphics pipeline theory, understanding the details about the transformations from local space, world space , view space and screen space.

I've been trying to do more of this for a while ever since DirectX math, coursework and some films but i had to study for exams last week (Software Engineering) and that pretty much took priority.  One of the interesting aspects of the pipeline that I read about was around the geometry and techniques that eliminate back facing polygons  and view volume clipping - all in an attempt to select only the necessary polygon details/vertices to process. 

I also learnt a lot about the latter parts of the pipeline, specifically the view-space process which dictates which part of the world space the player is looking at. This involved defining new terms such as the view plane(the 2D screen that will hold images from the world that fall within the view volume that the player can see) and various other terms such as the viewpoint C, the direction of viewing N and the concept of surface normals - indicating which direction a plane or surface is directed at. Quite interesting theory.

I also, through this process got to learn more about viewing co-ordinate systems specifically the LH viewing coordinate system that I previously came across in DirectX 11 and didn't really know what it was and was just told to "use it" in this one tutorial which always annoys me - just like math, you need to understand why things are the way they are! This actually reminds me that I need to refer back to my DirectX 11 notes.

I also learned a bit about the Z-buffer algorithm, which was also explained very robustly in Frank D Lunas Direct X 12 book but i got another interpretation of it this weekend. Its all about depth and polygonal surfaces sharing the same pixels and determine how best to render one over the other etc.. I also learnt about the view frustum and clipping techniques using spheres to determine if objects fall outside this view (which represents the players view). 

I also switched midway to concentrate on the mathematics and learnt a lot about linear geometry, lines, gradients(slopes) and why they make lines parallel etc, also spheres, circles, porabolas and how they might intersect and how this might be used to determine game elements colliding with each other etc. I didn't spent too much time on this, just enough to understand the ideas etc. I also spent some time going through calculating distances between points using the distance formula derived from Pythagoras and trigonometry - which really helps with vector maths. That said I spent some more time on vectors and learnt a new representation of them that I never really knew before and in doing so increased my understanding of them. The new perspective was that of polar coordinates and more specifically cartesian coordinates as a means to represent vectors. This really helped me understand why notations with figures i and j were always included but not explained!

 I went through the dot product and cross product again and at the end of it was pretty happy with my Saturday.  I then switched to studying Digital Forensics for a while which I found also pretty interesting.

I then doubled back and read a different book about  some more game programming theory - this time mostly about how best to setup a game loop but I did read a chapter on the history of gaming which was nice. That was from non-programmable hardware solutions to pong, aratri, nintendo, sega etc all the way up to today with 3d Graphics cards and the likes of Sony and Microsoft's consoles. Then a bit of study into real-time programming and the game loop which was really interesting - basically this resulted in me going back to Game loop and my 2DGameDev code.

I spend a bit of time just understanding the different elements of the update-render process within the loop, the critical point being that to maintain a consistent update rate, irrespective of the speed of the processor, which will provide a constant rhythm of speed (in terms of how often changes are reflected in the game) and still trying to render as much and as fast as possible, you need to restrict the number of update calls and skip them sometimes while trying to run as many render calls as possible. The code is quite fiddly around this part but the idea I've grasped. 

At the end of the day I'd received a good grasp of where all the theory behind the pipeline operations come from, basically how they work and felt a lot better about some of the unknowns I'd previously been concerned about.

I ended up swapping out my C code in here for C++ code in 2DGameDev code and setup that project in VS2017 using SDL2 and SDL2_Image.

Should've gone to bed much earlier... 

Since Old school, bare-feet and gangsters I've had some success with getting my AWS Lambda function being invoked by an upstream API Gateway managed by another part of our business. You can see how this is done in Lambda Cross Account access with Serverless framework. Recently however I've been focusing on my C++ library. I've implemented a timing function that will help me determine/measure how long my functions take to run. 

I've always done this in C# by passing around delegates and anonymous function that I've book-ended by a start-time and a end-time like setup. The duration thus, is the elapsed time since the end-time less the start time. I thought I'd do a similar thing in C++ using the new C++11 lamdba expression feature like so:

#include "Timing.h"
#include <chrono>
#include <functional>

double Api::Timing::GetTimeIn(void (*functionToMeasure)(), InDuration inDuration)
{
	auto start = std::chrono::high_resolution_clock::now();
	functionToMeasure();	
	auto finish = std::chrono::high_resolution_clock::now();
	double elapsed;
	switch(inDuration)
	{
	case InDuration::Seconds:
		elapsed = chrono::duration_cast<chrono::seconds>(finish - start).count();
		break;
	case InDuration::MilliSeconds:
		elapsed = chrono::duration_cast<chrono::milliseconds>(finish - start).count();
		break;
	case InDuration::NanoSeconds:
		elapsed = chrono::duration_cast<chrono::nanoseconds>(finish - start).count();
		break;		
	}	
	return elapsed;
}

Now the interesting thing is that I've used a function pointer to pass the function to measure into the GetTimeIn() function. You can also use the std::function<void()> class that serves as a wrapper to a callable function, which would achieve the same thing. I've not actually tested this in great detail other than sleeping for about 1ms in a lambda and seeing that the result of the measurement was about 1ms.

In other news -It being Friday and all, I decided to run into the office today, I got off at Finchley road and quickly changed(The toilets were actually closed but I convinced the cleaning lady that I just wanted to change into my running kit). I headed out and then about half way my enthusiasm caught up with me and I got lost. Technically I only got lost because I could not take my planned journey in. They had removed the entrance to the canal. I Usually run along the canal so its the only way I know, So I had to improvise. I ultimately used google maps and I got back on track. A little less smooth than I otherwise hoped for but it was fine.

I’ve been recently reading about an architecture design strategy for games described in Game Coding Complete 4th Ed. I've been resigned to design a game engine in pure C and I started to try and do it here: SDL and stuff and while I didn't go into much detail, it became clear then and more so now that describing and managing architectures are more suited to an object orientated language like C++. So I've started piecing what my C++ code will need to represent. Here is an architecture that really shines in an object orientated world mostly because it uses some well-known patterns from OOP.

It's very much like MVC if you're familiar with this pattern. I’m very much interested in system architecture and when I have the opportunity to design and see these architectures in play, it fills me with child-like glee. No seriously, it does!

Anyway, here is a drawing I put together to demonstrate the simplicity of an MVC-like architecture:

The main crux of this model is two-fold:

1. It is separated into one set of view components which are both event consumers and command producers.
2. Events occur in the game logic when world state change occurs.
3. Commands are instructions from views to the game logic.

This has a few powerful results. Firstly, you have de-coupled the game logic with the views: Views speak Commands and Game logic understands commands. Many different views that speak commands can interact with the game logic in a uniform way without themselves manipulating game logic code. Simply put, The command system is an interface to the game logic. Particularly when coming from views and going to the game logic. Events that occur in the game logic trickle up to the consumers of these events, which are the views. So that going from the game logic to the view, whereas the commands go from the views to the game logic.

The 3 boxes above represent the 3 layers, much like layers in the layer pattern. They layers talk to each other view commands and events such that the layers are coupled to the event/command bus/channel so that the components within the layers don’t talk directly to other components in other layers(no coupling).

Some obvious links in the picture are that the script interpreter like the views communicates with the game logic through the commands mechanism. So hooking up a scripting language into the game engine that issues commands works with the same commands the other views would (AI view and the Human views).

State changes to game objects emit event triggers and event subscribers/consumers get those events and can deal with them.

This is a nice decoupled system which simplifies coordination and communication. This is quite important as games are real-time, multithreaded systems much like an OS kernel that doesn’t inherently have a logical flow of execution that one can follow or reason about easily.

I’d like to talk a little about the Command Interpreter in the Game logic as it gets hot being the central point of communication between it and other layers, particularly the game views and the script interpreter.

The script Interpreter would read tokens from the script its given and translate the tokens into commands like this:

if(command == Fire):
    gameLogicLayer.ProcessFireCommand() 

 which in turn would call the firing logic which would no doubt raise some events with the event manager and those events would get to the game view which would then depict shooting of say a weapon graphically as well as sending a sound to the speakers.

Next time I'll talk a little more about the various layers and components and their interactions that make up the layers.