Edict.20170904

The bulk of this weeks work focused on integration of game logic with the render libraries, chasing up toolchain issues, and investigating an OpenGL state management bug. I’m still well and truely focussed on fairly dry technical and internal development details here.

Simluation reintegration

We’re now back to the point where we can perform terrain picking and basic zone management, but with the newer and more performant render infrastructure (as opposed to the original OpenGL 1.x system which was… lacklustre…). Updates here touched a lot of the older simulation code which hasn’t seen much attention for at least a year and as a result uncovered a number of minor issues where terrain generation has changed in the interim. As a side note it was fairly interesting seeing the obvious differences in coding style since I adopted cpp17.

What was previously known internally as ‘game’ has been split into pure simulation logic and a more concrete ‘glue’ library holding the terrain, simulation, render, and GUI layers together.

Toolchain Issues

While I’m glad I’ve made the switch over to GCC 7.x and Clang 4.x with the associated bump in cpp17 features there are some number of problems dealing with bleeding edge code ranging from “syntax highlighting is a little flakey” through to “gdb will crash when you single step on certain lines”. I spent a day following up with CLion issues that turned out to be (multiple year old) gdb issues. Thumbs up to the CLion guys for being responsive to bug reports here. In the end I’ve grabbed a handful of unoffical patches from the gdb issue tracker and recompiled gdb locally. It works for now, but makes me feel a little uneasy…

OpenGL state (mis)management

I was previously fairly ambivalent towards OpenGL. It contains enough functionality at a high enough level that I don’t need to get bogged down in the details. However I wasted half a day this week chasing an issue that came down to global state management which came down to: binding a vertex buffer will update the currently bound VAO. This is how VAOs operate in OpenGL, which is fine. However this interacts poorly with some assumptions my renderer makes about state management.

It’s an easy fix and it’s obviously entirely my own fault. However I’m starting to ponder the merits of switching to Vulkan sooner rather than later to eliminate classes of errors like these. I’m currently performing a reasonable amount of tedious render management as it is, so the added complexity isn’t an issue. But I’m a little wary of spending so much time integrating a new rendering API when the current one works ok and there are more pressing issues like continued development of the world simulation.

I’ll perform a little more investigation into Vulkan over the weekend and see how things look on Monday.