3D Game Engine

By the end of 2020 I started working on a small engine to use as a playground for personal projects, in the end, the engine became my main personal project. Each time I want to work on something new, it’s a matter of extending the engine.

Features

This is a list of the most relevant features I implemented so far:

• Multiple Renderer backends: OpenGL implemented, currently porting it to Vulkan.
• Asset hot-reloading for faster content iteration.
  • A separate thread monitors all loaded assets so that when the file in disk changes it can reload the resource. his way artists can keep the game running, hit Export in Photoshop or Blender and see the results instantly.
• Game code hot-reloading for faster logic iteration (C++ code compiled to dll).
• Memory Layer with debuggable allocators: stats, leak tracking and corruption detection.
  • Inspired by the CppCon2015 talk by Andrei Alexandrescu on allocators.
• Support for Text and Binary serialization.
  • You can find the initial version of the serialization code in Serializer (although I’m no longer happy with that implementation, for several reasons).
• Property Editor using ImGui and the engine RTTI system: Copy/Paste and Undo/Redo support based on Text serialization.
• Project generation using Sharpmake.

In this post I talk about how useful Asset hot-reloading together with Text serialization can be during the development of the game.

Renderer Backends

Below you can find a comparison between the OpenGL and Vulkan renderer backends.

You might notice there are some differences, those are because the port is not finished:

• Bloom intensity is lower in Vulkan (I still need to debug this problem).
• Vulkan implementation doesn’t support multi-sampling yet.
• Shadow Peter Panning on the Vulkan implementation.
  • Reason: In order to avoid shadow acne, I’m using glPolygonOffset on OpenGL and VkPipelineRasterizationStateCreateInfo::depthBias* variables on Vulkan. Either the implementation of those functions is different, in which case I would move the calculation directly to the shaders instead of using the built-in functionality; or there’s a bug in my code 🙂

Future Work

• Port to Android.
• Implement DX12 Renderer Backend.