Closing in on the last bugs!

Ok, so this weekend I got around to addressing another long standing issue in anthracite - how Multi-Sample Anti Aliasing (MSAA) stopped working some time ago. I’d sorted the fonts out a little prior to this and I’ll post about that later but for now, MSAA is fresh in my mind. Now, I suspected that the Angle library (a google chrome library that implements GLES2/3 on top of DirectX, it’s what Chrome uses for WebGL) had something to do with this and I was partly right, it did. Also though, this was around the time I introduced RGBM HDR modes to the engine, which is essentially packing high dynamic range data in to a standard RGBA, 8-bit per channel texture (which are available on just about every device), rather than relying on rarer texture modes which aren’t widely supported - Anthracite can use those but I also needed a workable fall back. Also, MSAA doesn’t (on my machines at least) work with any of the fancy framebuffer formats, so these two need to work together to get things rendering with all the bells and whistles.

About the time when I added that, MSAA stopped working for render-to-textures. First off, I identified some issues in my code around on-the-fly alteration of texture formats, I needed to be able to tweak these settings at run-time (texture format, MSAA sample count etc). Once I’d fixed that, improved my OpenGL error reporting and after a few sessions using https://renderdoc.org/, I could see that my problem was that my target frame buffer to resolve the MSAA buffer wasn’t fully initialised - I’d been skipping a section if the MSAA buffer was created. To perform MSAA, you need to have an MSAA colour/depth framebuffer (and renderbuffer - these are different things, it gets confusing) and also a non-MSAA frame/renderbuffer pair. The MSAA render target has multiple samples which are blended together to produce the final anti-aliased image. Now things get even more prickly - in Angle, all of this only works with the colour buffer, not with the depth buffer! You can’t resolve MSAA depth buffers to non-MSAA depth buffers. In Pilkapel, I need that for those pools of water, so this is a show stopper.

Fortunately, the ‘official’ opengl libraries now support GLES 2.0/3.0 profiles (which I target because they’ll run on the widest range of hardware), so I don’t really need Angle. However, I still like to build for both because Angle is how Google implement WebGL, so the chances are if it doesn’t work in Angle, it won’t work in the same way on webGL (which is another of my targets). WebGL and WASM are currently (or rather, the last time I checked) really hard to debug for, so it’s good to have a build target with similar behaviour but with a much more sanity-preserving debugging environment (WASM and Android NDK debugging are categorically not sanity preserving). Also, the debug version of Angle, whilst now nearly unusably slow (they’ve really messed something up internally, runs like a dog now in debug mode), does allow you to step in to validation functions, which is how I know that Angle for some reason has chosen not to support MSAA->Normal resolves in depth buffers, which is very un-helpful. Finally, I also had problems with MSAA depth resolves on the standard OpenGL drivers - turns out this silently fails (thanks for that, SDK authors) if you have a render buffer format of ‘GL_DEPTH_COMPONENT16’. Instead, if you use ‘GL_DEPTH_COMPONENT24’, everything just works. So, there you have it. Anthracite is finally rendering nicely with all bells and whistles, non-wobbly fonts, HDR, Bloom, DOF, MSAA, etc. Now all I have to do is get it working on all the other platforms (hahaha, ‘all I have to do’. Famous last words.)