Angelus blog

In  Part 1  I described the configuration system in the engine. In Part 2  I described the reason and thoughts behind the topic: Designing intuitive API that makes sense. Now time for Part 3. This time we will analyze changes in script and reason behind it.  Compute shader script Let's start with the simplest compute shader script that doing anything : Compute {      ShaderFile  =   "sys://Shaders/ComputeShader.glsl" } New version: Compute {      Shader .Bind ( "sys://Shaders/ComputeShader.glsl" ); } This may look like a small change but it brings consistency to script. From now on there is only function style calls with ';' at the end. Defines Let's now add Define to script. In original format this would look like this: Compute {     Define ( "MY_DEFINE" )      ShaderFile  =   "sys://Shaders/ComputeShader.glsl" } The new one is more flexible and allows to do it in 3 ways: 1st: Compute {      Shader . Define ( &

In Part 1  I described how my configuration script system works. Part 2 will focus more on the real reason why I decided to write this post: Designing intuitive API that makes sense. The more I code and work on complex systems the more I see how important good API is. There is of course 1001 articles describing how to do that and if you are searching for one of them you are not in the right place.  My focus will be on my personal evolution in a way how I think about API. Whole thought came from improving compute shader scripts. They had a really simple form: Compute {      Define ( "MY_DEFINE" )     Reg (0) = UserImage (0, "Write" , 0)      Reg (1) = UserTexture (4)      Reg (2) = UserTexture (5)      Reg (3) = UserTexture (6)      Reg (4) = Texture ( "sys://Textures/Texture.dds" )      Reg (5) =  UserTexture (7)      ShaderFile  =   "sys://Shaders/ComputeShader.glsl" } This was nice but defining N users texture regis

This may sound weird in days where everything needs to have some kind of UI but the recent time I spend upgrading some of my configurations scripts. My current workflow is to define parsing rules and generate from them parser. To give you an idea what I talk about this is simple rules for the logging configuration file: %name     = LogConfig   %% .input : /* empty */        | LogAllow .input        | LogBlock .input        | AllLogBlock .input        | AllLogAllow .input ; LogAllow        : 'LogAllow' '(' $(CStringID) ')' ';' ; LogBlock        : 'LogBlock' '(' $(CStringID) ')' ';' ; AllLogBlock        : 'AllLogBlock' '(' ')' ';' ; AllLogAllow        : 'AllLogAllow' '(' ')' ';' ; %% It allows me then to parse a file that looks like this: LogAllow("Crash"); LogAllow("Assert"); LogBlock("Scripts"); LogBlock("Audio&qu