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.