Weekly Benchmark 2

Progress report for the week of 6/8/2025

This week was a slower one, as I took more time to think through how I wanted to tackle the Game Scene problem.

After talking with some friends about it, I think given the state of the engine (barely an engine), it makes sense to not focus too hard on getting a full-blown scene system implemented. Especially because I don’t have a big enough game to justify it. That being said, I do need more than a simple fixed array, because the games I have involve a lot of tweaking and level-editing.

I also did not want to fall into the trap of creating a level format, which would require alot of pieces, like a text/binary format, a parser, and a serialization system. Ideally, what I have is either raw code or raw struct data. Maybe a compressed byte array is also acceptable.

What I have done

I reworked my quad based rendering system to better reflect a 2D scene, as a simulacrum of what I would eventually need. I think I’ve gotten very far in making this work using only C.

As an example, this is the code needed to describe a UI screen:

ui_quad_layer(layer,
  //All transforms and shapes are based on normalized screen coordinates
  //anchored at the top left

  //app title card
  UI_QUAD( 
     UI_ATTRIBS(.id=tag4_from_cstr("hdr"), 
                .glyph_idx = 3, .pallete_color_idx = SECTION_BACK_COLOR),
     UI_TRANSFORM(.pos = (f32_v2){.x=0.0f, .y=0.0f}, .scale = 1.0f),
     UI_SHAPE(.size_by_axis=(f32_v2){.x=1.0,  .y=0.25f}),
  ),
  
  //red button   
  UI_QUAD( 
     UI_ATTRIBS(.id=tag4_from_cstr("scle"), 
                .glyph_idx = 3, .pallete_color_idx = 2),
     UI_TRANSFORM(.pos =(f32_v2){.x=0.15f, .y=choice_buttons_y_level},
                  .scale = 1.0f),
     UI_SHAPE( .size_by_axis=(f32_v2){.x=0.3f,  .y=0.1f})
  ),
  
  //blue button
  UI_QUAD( 
     UI_ATTRIBS(.id=tag4_from_cstr("chrd"), 
                .glyph_idx = 3, .pallete_color_idx = 3),
     UI_TRANSFORM(.pos= (f32_v2){.x=0.55f, .y=choice_buttons_y_level},
                  .scale = 1.0f),
     UI_SHAPE(.size_by_axis=(f32_v2){.x=0.3f,  .y=0.1f),
  ),
        
  UI_QUAD( 
     UI_ATTRIBS(.id=tag4_from_cstr("rndm"), 
                .glyph_idx = 3, .pallete_color_idx = SECTION_BACK_COLOR_2),
     UI_TRANSFORM(.pos= (f32_v2){.x=0.35f, .y=choice_buttons_y_level + 0.2f}, 
                  .scale = 1.0f),
     UI_SHAPE(.size_by_axis=(f32_v2){.x=0.3f,  .y=0.1f})
  ),
  
  //really thin button
  UI_QUAD( 
     UI_ATTRIBS(.id=tag4_from_cstr("sldr"), 
                .glyph_idx = 3, .pallete_color_idx = SECTION_BACK_COLOR_2),
     UI_TRANSFORM(.pos= (f32_v2){.x=0.15f, .y=choice_buttons_y_level + 0.35f},
                  .scale = 1.0f),
     UI_SHAPE(.size_by_axis=(f32_v2){.x=0.7f,  .y=0.05f})
  ),
        
  //...etc...
);

And this is what the resulting 2D scene looks like using my instanced quad renderer:

What needs work

Thus far I’ve gotten what I feel is a very nice “front-end” for scene description in C. In a lot of ways this is the ideal scenario, because all game scenes I care about can be written in C. The code shown in the example are actually macros that can boil down to either plain C function calls, or C struct literals, depending on what I need. That makes managing scenes as simple as using `#include` for the appropriate data files.

That being said, there’s still a lot of work to do in the back-end. Right now under the hood the UI code boils down to the singular giant array that’s used by both the game and the render system.

Because I anticipate having much larger scenes, I plan to include some form of primitive culling, which means the renderer’s array has to be different from the game’s array. So I likely need a two pass system where I pass in relevant data for the renderer to use.

That means I’ll be continuing work on the scene system until it is to my liking. It’s an investment for the long haul, and I think it’ll be worth it.