Month: January 2019

I’m writing my graphics engine, again. I was probably supposed to be writing tests for my on-going code audit, but they are boring and I don’t want to right now. (So there.) The alternative path I’m following is to start over with my graphics engine coding. This has resulted in a handful of changes.

First, the entire previous attempt at an OpenGL based graphics engine has been balled up and thrown into the temporary package com.qubekwest.graphics.old so I can use it for reference, but where it doesn’t get confusingly mixed in with the new stuff I’m writing. Second, I have switched entirely to Vulkan (from OpenGL) for my graphics library of choice. That decision comes with some serious baggage.

Vulkan offers a lot of cool things that make it better (in my opinion) than OpenGL. Some of these things make it faster and more powerful. Such as the all new way of telling the video card what to do from a multithreaded environment. This lets you use as many CPUs as your computer can throw at it without them getting in each other’s way. Another thing makes it vastly harder to learn. To give developers more control over how things work in Vulkan, they well, gave developers more control over how things work. To accomplish this, they make most of the things you want to do take way more steps than they used to. Finally, Vulkan comes with some fun things that make it require newer hardware (and/or newer drivers) than OpenGL. This one means Raspberry Pi is just not a valid development target anymore. At least not models 1B through 3B+, maybe the 4 will have Vulkan capable hardware.

I’m trying to build the concept of a graphics engine as cleanly as possible and in a way that would let me implement a second one in OpenGL in the future if I want. There are some decisions I’m trying to make as I go that I’m almost positive will be just flat wrong because I made them before I understood enough of what I was trying to do for real. Thus is the side effect of the learning curve I figure.

There are lots of semi-related things that go with this, such as the management of the main game loop and of accepting user input. Admittedly they are mostly only related because GLFW (Graphics Library Framework) includes stuff for creating windows, accepting input, and managing the game loop. I am likely to use all of those things, but I haven’t figured out if I’m going to call them all part of the “Graphics Engine” I’m building or treat them as separate entities glued together into a “Game Engine” or something. I guess we’ll see.

The code base has come a long way since my last code audit, and worse, I got lazy and never really finished the last one properly.  There are more sub-packages in the data package than there used to be, there are more classes in the math package, and in general just more.  Since the last time, Google Sheets finally added support for making text in a cell conveniently crooked, that’s helped too.  Now I get to track my progress in a spreadsheet instead of on hand labeled sheets of graph paper in my notebook.

This is actually a bit handy since I haven’t touched the code in nearly a year and I really need to relearn what I was doing in the code before I stopped.  I’m actually almost completely done with the code portion of the audit (added around 3500 lines of code) and I’ll be moving on to auditing the tests and coverage next.  I’m not going to lie, this process is tedious and boring, but I’m still feeling rather motivated to do it as I gear up for another big graphics push toward getting a cube on the screen.