Scripting improvements for UI

For my current project (not that one, the other one) I needed a mechanism to create user interfaces in a fast and easy way, without having to position elements explicitly.

In a recent post, I talked about a kind of constraint-based UI layout mechanism included in recent versions of Crimild that allow us to create interfaces in a declarative way:

Each element in the UI defines a set of constraints related with either its parent another element.

Surprisingly, I (almost) didn’t change anything about that (so far). I know, I know, it’s shocking to me as well.

Anyway, that mechanism is pretty powerful, indeed. Still, it requires us to recompile the game every time we make changes (because C++). Therefore, the next evolutionary step was quite obvious: move that feature to Lua.

Using Crimild’s Coding facilities introduced last year, I implemented decoding functions for all of the UI-related components. The result is a Lua script that looks like this:

local UIFrameConstraint = 'crimild.ui.UIFrameConstraint'
local makeConstraint = UIFrameConstraint.Maker
-- Other require calls remove for clarity

-- Create a Restart Button
local restartButton = Group(
components = {
UIBackground( { color = { 0.0, 0.0, 1.0, 1.0 } } ),
constraints = {
makeConstraint.after( mainMenuButton ),
makeConstraint.bottom( 10 ),
makeConstraint.width( 80 ),
makeConstraint.height( 20 ),
UILabel( { text = 'Restart' } ),

Simple and fast. Nice!

BTW, that script is using a new organization for scripts based on Lua modules. But that’s a story for another time…

Crimild v4.8.0 is out!

Crimild v4.8.0 is already available for download here!!

This new version, which is the first one of 2018, includes many new features and improvements, paving the road for the next major release for Crimild (hopefully later this year).

Key Changes


Introduced in this new version is the new Coding system. By implementing the Codable interface, objects can be encoded to and decoded from many different formats, including binary (particularly useful for production builds), Lua scenes (that can be used for data-driven scene creation) and any other custom format you need.

Here’s how the Node class implements the Coding interface:

void Node::encode( coding::Encoder &encoder )
   Codable::encode( encoder );
   encoder.encode( "name", getName() );
   encoder.encode( "transformation", getLocal() );
   encoder.encode( "worldTransformation", getWorld() );
   encoder.encode( "worldIsCurrent", worldIsCurrent() );
   containers::Array< SharedPointer< NodeComponent >> cmps;
   for ( auto &it : _components ) {
     if ( it.second != nullptr ) {
       cmps.add( it.second );
   encoder.encode( "components", cmps );

void Node::decode( coding::Decoder &decoder )
   Codable::decode( decoder );
   std::string name;
   decoder.decode( "name", name );
   setName( name );
   decoder.decode( "transformation", local() );
   decoder.decode( "worldTransformation", world() );
   crimild::Bool worldIsCurrent = false;
   decoder.decode( "worldIsCurrent", worldIsCurrent );
   setWorldIsCurrent( worldIsCurrent );
   containers::Array< SharedPointer< NodeComponent >> cmps;
   decoder.decode( "components", cmps );
   cmps.each( [ this ]( SharedPointer< NodeComponent > &c, crimild::Size ) {
     attachComponent( c );

The Coding system is an evolution of both the Stream system and the SceneBuilder pattern. Up until now, supporting loading a scene from a binary file or a Lua script required a lot of redundant code. The above code handles both formats (an any other Encoder/Decoder implementation) in a common interface.

Please note that the Stream, SceneBuilder, LuaSceneBuilder and all their related classes have been marked as “deprecated” and will be removed in later versions. 


The implementation of custom containers using the latest C++ features was long overdue. I’m happy to announce that included in this new version are working implementations for:

  • Array
  • List
  • Stack
  • Priority Queue
  • Map

The new containers support move semantics and traversing items by using lambda functions. In addition, they make use of the new ThreadModel policy to define how to handle concurrency.

Many new and existing systems already make use of these new containers. It is expected that the rest of the classes will be modified to work with these containers in later releases.

Please note that existing collections have been deprecated and will be removed in future versions.


Recently added to Crimild, behaviors are already a hot feature and are continuously being improved in each iteration. In this new version, all of the existing behaviors have been enhanced by supporting the new Coding system. No more individual builders and redundant code.


With the introduction of the Coding system, most of the classes available in the crimild::scripting module have been rendered obsolete. The new version includes implementations for supporting both encoding and decoding scenes from Lua scripts and there is no need to maintain separated builders for the Core classes.

An much more…

Check out the complete Release Notes for this new version in Github!

Feel free to contact me if you have any issues or comments. Feedback is always welcomed!





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.