Dev Log 2018-05-14

OpenGL Renderer Finished

I’ve been working almost exclusively on the OpenGL code in a branch. I reached feature parity between the OpenGL and SDL renderers. I merged that code line to the main one, since GL is now pretty stable and upcoming work will be easier to do on the main branch. There are minor issues to fix.

Fonts are currently rendered to a texture at the user-specified size in pixels. If the logical resolution is different than the display resolution, those textures are scaled (usually upscaled) to the size of the logical resolution for drawing. This doesn’t look good for anti-aliased fonts, so I’ll need to decide how to improve it.

When using draw-to-texture in GL, the y axis and texture winding directions for drawing seem to be inverted vs. drawing directly to display. I’m confused by this, but decided to move on and come back to revisit it later, when I understand GL better. It may be best diagnosed by creating the smallest possible example application to reproduce the behavior.

The SDL renderer handled everything in display coordinates. Rendering in GL required an additional transformation to normalized device coordinates, which the SDL renderer doesn’t understand. These changes left the SDL renderer a little broken. The next work is a documentation and refactoring effort around the coordinate transformations. If that goes well, I expect SDL to be fixed easily. In the worst case, I’ll leave SDL behind for now and come back to fix it later; GL is the priority now.

Better Development Workflow

I have a few demo applications that have been in the same git repository as the ng engine code. These exercise ng’s features and I use them to verify that code changes haven’t broken things. I frequently make small changes to these to test little ideas, and a problem I’ve been facing is they are consistently in a modified state, making it difficult to switch between code branches without committing/stashing/discarding the changes.

Since I’m compelled to commit changes to the demos less frequently than changes to the engine, I decided the best solution for now is to move the demos to their own repository so they don’t interfere with the engine development workflow.

Better Demos

The demos mentioned above started as freestanding applications without any shared code. Changes to ng APIs have required changes to every demo application. This has become a maintenance issue as the amount of time it takes to update the applications grows with the number of applications.

To improve this, I created a base application class that creates contexts for ng and shared utilities like resolution changing, debug grid and drawing performance statistics. Now each new demo can inherit from this base class. Changes to ng APIs will, best case, only require changes to the base application class.

This is the demo application for the entity graph.

Next?

The next priority is to ensure there’s a well-defined, well-documented path between the user’s input coordinate frame and the final display coordinate frame. This “works” in most 2D use cases right now, but there is some stretching in non-square resolutions and probably other subtle issues.

Entity graphs (work in progress), support for cameras and camera transformations (short-term future work), and full 3D rendering (mid- to long-term future work) all depend on this part of the engine being correct.

I think there are some errors in the matrices and their concatenations, so I’ll start by building some test cases around that. Debugging here is a bit challenging since the final transformation of model space vertex coordinates to display coordinates happens in the shader; there’s no way to test the entire pipeline, including OpenGL, in the Python code. I plan to create some test cases or an application that only does the math and verifies the correctness of the results, with no need for GL or drawing on the display.

Thanks for reading. I’m looking forward to the next update.