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