Thursday, December 21, 2017

December, it’s the end of the year. This year at devcry we’ve spent a great many time doing OpenGL programming, and a fair bit of C++. The goal of all of this is really to go and build some fun retro-style arcade games. As I have said before, the amount of technology that goes into games, even the simple ones, is staggering. So much even, that you must be a little crazy to set out and go write a game from scratch these days. Yet that is what I did, because I love tinkering with what goes on under the hood: deep inside the bowels of the machinery.

OpenGL is a quirky API that is difficult to control. That’s because it was made to control the hardware. Think of it as a sound mixing board (but now for video) where you have all these knobs and sliders and switches, and then you press a big red button and an image comes out. Or it doesn’t, when you put one of those knobs at a wrong setting. Go fix it, and try again. You might be inclined to think of OpenGL as a toolbox for making higher-level graphics libraries. It’s not that simple though. OpenGL is at such a low level, it’s really not what you expect when you want to produce some graphics.

So what can you do. The answer is to write a higher level library around it, and even that is way harder than it sounds. OpenGL is just difficult to work with. It doesn’t let itself get wrapped into C++ objects easily because it is very stateful. Turning a knob on the mixing board here affects what is happening over there. That’s just the way it is, and when you look at github projects that do wrap OpenGL in C++, they are typically not done all that well in my opinion. A thin OOP layer around OpenGL is useless, you might as well call plain OpenGL straight away.

For a game code, I’d rather have a thick layer with few functions on the outside, while the inside does all the complex machinery in a most efficient way. This means that I want an API to be like: grab this shader, use it, grab this framebuffer, draw my objects in it, apply post-processing effect, dump it to the screen. Optimizing efficiency can be tricky because in graphics, the order of operations matters much. For 2D games, you need sprites and spritesheet code, and Z-layering would come in handy. For 3D games, you need accessible math functions for object translation and rotations, and you want to have some easy lighting functions, including shadows. So this is what I’ve been working on, a generic game library that ideally would allow me to create simple games more easily.

What feels weird is that I was making a game last year, and I’m still making that game today. Progress has been made, but overall progress has been slow. Most time has been sucked into making the generic game library. I should mention also that there has been a huge gap in development, for at least six months I have been busy with other stuff. To be frank, a lot of code presented in this blog this year was actually written at the end of last year. It was an incredibly productive time, and it gave me months to write about here at devcry.

Never mind the title of this article! It’s sweet irony. What does bug me though, is that all of this low-level stuff consumes way too much time. OpenGL is soon going to be forgotten, being superseded by Vulkan. The times have caught up on us. For now, I will stick with my game library. As much as I love tinkering with the low-level stuff, I would really love to learn Unreal Engine. It looks quite complicated, but on the other hand I can hardly imagine it being more difficult than core OpenGL and doing everything from scratch.