Venom Engine

I always knew i wanted to work in the videogame industry, but as you may know it’s difficult to move your first steps in. I had a strong background in engineering and computer science, but i didn’t really have anything game-related in my portfolio up to a few years ago. I started making my own 2D games in C++ using SFML, during all my spare time, and it was a blast until i realized that i was enjoying more the process of making the engine itself than the games. The software behind game engines is the most complex piece of technology i have ever seen, and i have seen my fair share of applications in the bioinformatics academic background during my PhD. Since i am in love with complexity, i started to develop my own engine from scratch because i wanted to know how everything worked under the hood. After a while i discovered the Handmade Hero project and i knew i wasn’t alone anymore! Casey Muratori was my invisible mentor, while i enjoyed my journey inside the intricacies of C++ and OpenGL.

The Venom Game Engine is the result of my ongoing efforts. It is a game engine created without using external libraries, coding everything by hand, learning from many different sources. Handmade Hero was fundamental, as i already mentioned, but also studying how other engines and libraries were implemented was inspiring: from mainstream engines like Unity and UE, to smaller libraries such as SFML, GLFW, GLEW, SDL, Sean Barret’s stb libraries and many many others. I am also a big devourer of paper books! Game Engine Architecture, Real Time Rendering, AI for Games and the Foundations of Game Engine Development series are my personal favourite references.

I have decided to keep the source code private, since one day i might want to use the engine for something more than exploring game tech or improving myself. That being said, however, i am glad to share everything i know about game programming, as you might see by looking at my blog.  

This is the list of working features of the engine:

  • Custom memory management (big allocation at startup, expanded as needed), with overflow/underflow checks;
  • Hot code reloading;
  • 3D-math library (vectors, matrices, transformations, quaternions, and various shapes manipulation);
  • Multithreading (implemented as job queue);
  • OpenGL graphics with modern context and features (sRGB textures and framebuffers, MSAA, reverse depth buffer, etc..);
  • Order-independent transparency (depth peeling);
  • Audio processing;
  • Asset streaming (Bitmaps, WAV, fonts);
  • In-depth debug system (profiling, introspection, switches, debug draw);
  • Collisions (AABB, Minkowsky);
  • Barebone SIMD library;
  • Particle systems;
  • 2D Animations;
  • Camera-facing cards (billboards);
  • Cutscenes;

This is instead the list of features that i would like to implement in future:

  • Wavefront .obj parser;
  • Lighting system;
  • 3D Animation system;
  • Entity System;
  • Game AI (pathfinding, combat system, etc.);
  • Editor;
  • Physics;
  • Improved procedural generation;

Here is a series of demo showing some feature i recently worked to, divided by categories:


General Programming

I have already implemented many general features, including a complete platform layer for Windows, memory management, I/O functionalities, asset streaming, multithreading, hot code reloading, and many others.


Debug System

The debug system is almost entirely inspired from Handmade Hero. It allows to profile threads, frames and functions, and to control several functionalities. The UI layout is customizable.


Gameplay Programming

Gameplay is fairily behind, since the engine still lacks some core feature. Also, without decent art it’s difficult to create an entertaining simulation. The game right now seems like a version of The Binding of Isaac with a more powerful rendering but just a couple of rooms to explore. Also, animations need to be heavily tuned.


Graphics Programming

Graphics is made with OpenGL. Right now the engine is based on a very complex interaction between depth peeling (four peels), MSAA and reverse depth buffering. Lighting is basically at a primordial stage. The pipeline is entirely 3D but the engine still doesn’t support 3D models. Camera-facing cards are automatically oriented with respect to the default camera position and orientation, but they don’t follow the debug camera in order to allow independent inspections. The depth peeling demo shows the content of all four framebuffers containing each peel.

I would really like to explore the Game AI part, since this is closer to what i did in my PhD, but coding everything from scratch is a very long process and AI usually comes after other core functionalities. Right now i am focusing my efforts in having a robust 3D renderer, and after that i will start my journey into the Lighting System, which is at a primordial state right now. Wish me good luck!