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...