CMarble status update (August 2019)

It has been some months since the last time I did an update on this page. However this does not mean that I’ve been idle.

Last time I wrote I was presenting the first baby steps of my current pet project, CMarble. A small game engine written in C that uses the Vulkan API for rendering. You can read more about my goals with it in this post I made back in march.

Although I have not built an interesting scene with it yet the engine already has some nice features, and many wheel reinventions, such as.

  • GameObject structure: CMarble uses a custom variation of Entity Component System that I call Entity Behavior System. I’ll write about it in a following post
  • Mutithreading: Achieved using a threadpool of working threads. As a peculiarity instead of giving the tasks priorities the threadpool has been made aware of the ordering of the systems and jobs can be scheduled to be done for a sincropoint before after or in the middle of any of the systems.
  • Memory management: Small and medium block allocators.
  • Memory debugging: Allocations can be traced, storing the metadata in a hash table. This helps a lot finding memory leaks.
  • Vulkan renderer: A simple renderer is working. For now it only supports forward rendering with diffuse texturing of objects and uses a single thread.
  • Projection camera, with a primitive FPS like movement.
  • Containers: Custom made Vector, List and Hash Table Containers.
  • Math Library: Supporting Vector2/3/4, matrices and Quaternions.

If I had to do a postmortem of this months I would say that the decision to stick to C and to set up a Vulkan renderer for the first time have been the major causes of slowdown of this project. Many times I’ve thought that if I had stayed within the realm of C++ and OpenGL my progress right now would had been significantly greater.

However, it is precisely this technical challenges what keep me motivated and this project has already fullfilled its main purpose, making me think in a different manner than any other engine I’ve used before. Just that jusifies this initial slow down for me. In addition another possitive is that C compile times are hard to beat, the whole project recompiles from scratch and links in way less than 10 seconds.

What comes next, in the most likely order:

  • Font rendering, mostly to create some ingame menus.
  • Integrate Dear Imgui.
  • Scene saving and loading. Will probably use JSON.
  • Simple Physics
  • Collision detection and resolution.
  • Model loading, I’m tired of my hard coded poligonal shapes. I’ll probably use Assimp with its C bindings.
  • Deferred rendering, with lights, shadows and post processing.
  • A game/demo design: Bulding tech for the sake of building tech is fun, but I’m approaching the moment when this project needs direction to prioritize what to do.

Leave a Reply

Your email address will not be published. Required fields are marked *