Almost 2 years after I made the initial commit, I came to realize that it might be a good idea to finally perform a brain-dump of sorts and share the thought process behind development of vkQuake2 - at least for the sake of knowledge sharing and being able to get back to it in the future if I get another idea for a project like this. I often regretted not writing down how things were progressing - now I finally decided to redeem myself!

I recently hit a milestone in my professional career – it’s been exactly 9 years since I made a move into games industry. This may not sound like something profound or significant but the circumstances of my transition from regular software development were rather interesting. I think it’s fair for me to say I was quite lucky and found myself in the right place at the right time. Today I want to share something I always bring up when talking to students or people who want to get a job in games REALLY bad but don’t know who to ask or how to start. This is the story of how I unintentionally and accidentally started making in games.

Even though it’s been many years, I can still remember my first days in school after I started education as a little kid. I truly admired and looked up to teachers who, to me, were the living embodiment of knowledge. I think I was really lucky because I was taught by people who truly had the calling and for a brief moment I even wanted to become a professor myself. However, as the years passed on, I developed a feeling that I would not make a good person to share what I know with others. My patience was low and I found it tremendously difficult to discuss things that were obvious to me but a novelty to others. Becoming a teacher turned into a nightmare job for me and I quickly realized this is something I want to stay away from as far as possible.

I recently overheard a rather interesting statement concerning programming and thought I’d share it with the world via a Tweet and a small counter example. This started an interesting discussion:

TL;DR; It’s not as hard as people think! Full source code on GitHub.

Disclaimer: this is not a step-by-step introduction to raytracing, rather the fundamental components I needed to get it working in DOS. Sorry! 🙂 Check out the GitHub link if you’d rather jump straight into implementation details. And now, with that out of the way...

I recently spoke to a couple high-school students who were eager to learn how to become programmers. They wanted to jump into it without any indication on where or how to start, which made me realize how difficult it can be for people without any prior experience. This inspired me to write this post and share my thoughts on what any programmer initiate should know and realize. This is not a programming tutorial by any means, just a set of guidelines which I would follow myself, knowing what I know today.

TL;DR; download code sample from GitHub!

In all of my VR applications thus far, I’ve been using separate eye buffers for rendering, seeing it as a convenience. Recently, however, I started wondering how I could improve drawing times and reduce unnecessary overhead, so my attention turned toward single render target solution and how it could take advantage of instanced rendering. Here’s a short summary of my results.

Disclaimer: The following is based on experiences with early releases of hardware and software for both Oculus and Vive, so your mileage may vary!

It’s that time of year again – recruiters on LinkedIn are starting to send out messages and job ads faster than anyone can read them. This is something I think every tech person experiences after spending substantial amount of time registered there. What suprises me is that a vast majority of people I know despise getting this kind of mail which, at the first glance, seems contradicting to the purpose of being on a professional social network. While different people may have different reasons to being registered on LinkedIn, I seem to have a rather unpopular approach of treating it as an opportunity to possibly land my next job – something that happened to me before, twice. With that being said, I accept all contact invitations unless the account is clearly recognized as spam or completely unrelated to my line of work (and that doesn’t happen very often).

I’ve been experimenting with Rust for over 6 months now. Most of that time I spent playing around with a C64 emulator I wrote as a first project and initially I thought about creating a series on that topic. However, since there’s so much reading material on the Internet about it already, I figured maybe it would be a good idea to write an intro for C/C++ programmers on Rust. But then I found this article, so I decided to take a completely different route.

One of the first things I stumbled upon in the beginning of my adventure with graphics programming were types of matrices and view spaces. I remember it took me a while to wrap my head around different naming conventions (is clip space the same as screen space or...?) and how each and every projection worked from theoretical standpoint. With Internet around it’s so much easier to figure things out but there’s one thing that I remember baffling me: the relation between different forms of perspective projection matrix.

Recently I’ve been working on a VR port for Rage of the Gladiator, a game that was originally released for mobile devices and used OpenGL ES 2.0 as the rendering backend. This seemingly simple task soon created several fun problems resulting in limitation of this graphics SDK in relation to “full-fledged” OpenGL. My initial idea was to rewrite the entire renderer but very soon this approach turned out to be a dead end (suffice to say, the original codebase was slightly convoluted), so I decided to stick with the original implementation. To run an OpenGL ES application on a PC I used the PowerVR SDK which is an excellent emulation of mobile rendering environment on a desktop computer.

If you ever worked with high performance 3D applications you know that every cycle counts. One of the issues programmers try to solve is reducing computation time when dealing with matrices and vectors, especially if calculations are done very frequently each frame. Here’s a little trick that can save you some memory and cycle counts when determining projection. Consider a typical projection matrix P:

This is the book I’ve been wanting to read for a long time. With close to 1000 pages of pure content, you get a heavily condensed compendium on good, bad and typical practices in game engine design. What’s great about this book is that even though it reads like something straight out of a university library, all the information is based on the author’s practical experience. This means that there’s relatively very little “dry” theory in favor of analysis of real life applications and how each component may perform on current gaming hardware. The latter was something I found especially interesting, since there’s very few articles out there that give you a decent comparison of the XBox or PS4 hardware against a desktop PC. If you never worked in AAA gamedev, you will definitely learn a lot. That said, the book is clearly aimed at people with various programming or industry experience. If you already shipped a title, you may find some parts of the book rather obvious. Nevertheless even having prior knowledge of the covered topics didn’t prevent me from catching some interesting quirks, making going through the entire thing worthwhile.

December 2014 and January 2015 mark the dates when my simple puzzle game “Hazumi” came out for the Nintendo 3DS. It’s been almost 6 months and only recently I started feeling the whole production pressure wearing off, so I decided to share my story with other inspiring game developers out there in hopes that they don’t repeat the mistakes I made. You won’t find any marketing tips here nor how to interact with the social media to promote your work – there’s a ton of a lot better articles on that topics out there. What I could seldom find was sort of a personal confession from the developers on how they felt during the development and what they had to go through over the course of their work which should be as important in order to maintain mental health. I’m writing this in hopes that someone benefits from my experiences.

If you’re dealing with templates a lot in your C++ code, then you’re likely familiar with how template type deduction works. It’s an extensive topic which I’m not going to cover in detail here but while reading this book I found one aspect of it quite useful in my work.

I always considered the C union to be highly underappreciated ugly-child that nobody cares about in high level programming. Not really meant for persistent storage (specific cases excluded), it’s difficult to see any good use for such constructs, especially for beginner programmers. Unless you deal with compilers or close to the metal development, chances are you have barely used or spotted a union in an application’s runtime code. But unions can come in handy, sometimes in quite unexpected ways. I often forget about their applications, so hopefully this post will help me remember in the future.

In one of my games I ran into a seemingly simple problem: saving a puzzle state (ie. completed/not completed) for each of 105 available levels. Naturally first thing that came to mind was a static bool array with required amount of entries – both easy to maintain and write to disk without hassle:

If you’ve been on the C++ bandwagon for a while you probably heard about Scott Meyers and his “Effective...” book series. While I haven’t read every single one of them, the ones I did check out always came packed with highly compressed information on how to become a more productive C++ programmer. “Effective Modern C++” is, thankfully, no exception.