Using C++11’s raw string literals to better organize stock shaders

As part of the OpenGL renderer unification refactor, I was looking for a way to extract stock shader’s code into separated files in order to improve the way they’re implemented and make them more readable. Basically, I wanted to avoid this kind of code.

It turns out C++11 provides a alternative way to define string resources through raw string literals. Originally targeted at writing regular expressions, this mechanism allows to write strings without worrying about escape characters and other formatting tools, making it specially useful for big chunks of text (as in shader code).

After extracting the shader code into separated files I can now easily #include them in the shader class implementation, resulting in a much more pleasant code organization. I agree that having to encapsulate GLSL code between R”( and )” tokens is a bit intrusive and prevents such code to be tested on external tools, but it’s a small price to pay for a much better organization.

At the moment, several shaders have been refactored to use this mechanism and I’m hoping all of them will be updated before v4.0 comes out.

Advertisements

Revisiting Text

As I write this post I’m in the process of merging both desktop and mobile OpenGL renderers into a unified one that supports both platforms. Although this is still incomplete, I wanted to share some of its benefits and side effects in the meantime.

A while back I talked about how to render dynamic text in 3D using Signed Distance Fields (SDFs). It turns out that approach is way too expensive for mobile and it doesn’t really provide too much of an improvement in smaller screens. So, no SDF support means that we need to provide two different textures for each bitmap font (with and without SDF). If SDF is supported in the current platform (i.e. desktop), the SDF texture is used for rendering. Otherwise, we use the standard bitmap font without any fancy processing.

Current implementation provides Text and Font classes, but it relies on client code to specify which texture to use. At first it looks like a versatile feature, but it ends up being very cumbersome.

Instead, the changes I’m making make sure this decision is left to the engine. Then, if current platform supports SDF, it will construct Text objects with the appropriated texture and shader program automatically.

In practice, these changes lead to a cleaner code on the client side, which now is unaware of whether or not SDF is being used. Both textures still have to be provided, of course, yet only one of them will be actually used when the program runs.

That’s it for now, but I’m planning on sharing much more about the new renderer soon. Stay tuned.