Brahma engine

Brahma is an innovative game engine being written from scratch in C++, based on NIPSYS64 framework I'm also working on. This is a 3D engine with a special lean towards retro-feel first-person games, intended for small studios and indie game development. It's peculiar in that it evolves in a different way than other modern engines, rejecting BSP-based portal systems, Z-buffering, floating-point coordinates, and most of the lame screen-space effects in favor of clever and efficient know-how techniques, what potentially enables for lots of things previously deemed to be impossible to implement in a realtime renderer. The engine is non-Euclidean capable to some degree; also it supports true displacement mapping (that represents actual level geometry affecting game physics, not just a visual quirk) and correct non-opaque surface order. The engine is also carefully designed to be easy and convenient to develop for, yet versatile and adaptive to any needs.

Highlights

• No Z-buffer, G-buffer etc., no near/far clip plane required
• Custom software-based rasterization pipeline not governed by triangles
• Inherently correct order of transparency without depth peeling or other complications
• Hierarchical frame buffer for translucent reflections and other effects
• No screen-space mockery of what should be done within the scene
• An intergrated working environment that unifies the editing tools with runtime procedural generation
• A custom hybrid bitmap/audio format with unique features
• Optimized for stable and stutter-free high framerates (in 120+ fps range)
• Favors simple yet memory-efficient representations like indexed color or shaped texels
• Resorts to fixed-point arithmetic and LUT-based functions instead of floats
• Built-in color correction and support for HDR shading even in indexed color
• A full blown post-processing step that models physical camera imperfections
• Heightmapped surfaces affecting scene collisions and drawn without tesselation
• Precise timing of game events and user inputs; no global game tics
• A fault-tolerant design with industrial and CAD applications in mind

My background

I've always dreamed of making computer games powered by my own 3D engine. I've been learning computer programming since 1999, coding things inspired by my favorite games. My first attempts to create an engine were pointless garbage, athough some of my results were promising, and I remember coming up with my own vector format and a simple editor back in 2001.

Things have changed a lot in 2006 when I've moved my development to Visual C++. I was a fan of the classic Build engine games such as Duke Nukem 3D and Shadow Warrior, and since I had some great ideas for my own games, I was striving for independent game development using my technology which has made a start in 2013. The first stone of the 3D part was laid in late 2017 when I tried to replicate the sector-based approach that was used by Build engine.

I was studying in a technical college once, but dropped out in 2012 to devote more time for projects and self-education. At the same time I felt the urge to learn about artistic, music and design related topics, becoming a rare type of an artist/musician who also writes software for his purposes.

Philosophy of this engine

The reason why I've chosen to make a new engine is that I adhere to a different philosophy than one prevalent in game industry, giving the engineering part both an aesthetic and pragmatic value, looking for elegant ways to achieve more with simple means, appreciating diversity and uniqueness. Beside that, I wish to learn how games are created from basic algorithmic structures, go to the basics and experiment with various approaches, in order to discover gems that were overlooked by others. While doing this, I have strong intuitions and views on what directions to prioritize. I believe that having a stable high framerate, a low input lag, and never seeing any loading screens is more important for delivering a great immersive gaming experience than usage of complex shaders and high polygon count, for instance. Also, I'm convinced that mesh support should not be limited to triangles and the collision model should normally stay on par with the visuals, avoiding any simplified proxy models for handling collisions in order to implement an authentic "what you see it what you interact with" approach. As a sidenote, if a small indie game is built with use of a modern bloatware tech, it typically feels kind of faked and generic, tends to use excessive disk space and memory, as the oldschool look and feel is only imitated, not being such "under the hood". My engine is an example of an integrated toolset that has facilities to automatize content generation and management, making games take up less space, load quicker and be easier to create at the same time.

The entire process of rendering of a 3D scene is in fact rather sequential by its nature, although it's deemed to be a massively-parallel task, that is exploited by dedicated graphic hardware with a specialized architecture that performs many independent tasks more efficiently. Unless you are using a culling technique like Z-buffering, you can't draw an object if you have to draw anything behind it first. So, although a simple convex set of polygons can be filled in any order, the order one has to draw a complex scene is determined by its depth relations. As for the general hidden surface culling algorithm, it basically works by means of progressive disclosure of parts of the level which are visible from the preceding render nodes. This is also a sequential iterative task, no matter if you choose to use a BSP tree or sectors. It turns out that only certain specialized types of rendering tasks are easily parallelizable by dedicated ASIC hardware (e.g. vertex transformations, textured polygon fill, shading, postprocessing or some forms of raytracing). The amount of causal dependencies pervading the way from a bunch of 3D geometry data to a complete rendered frame is such that it's only partly parallelizable, requiring some careful effort to keep your execution units synchronized. This and seeking for maximum flexibility is the main reason why my renderer is implemented in software; also any accelerated versions are expected to use this renderer as a reference.

Despite being written in C++17, the code relies on generic programming rather than object-oriented programming, with minimum amount of machine abstraction. Keeping the code as generic as possible helps greatly reduce its size (and subsequent bugs) and improve maintainability without sacrificing much speed. To ensure best performance, I've developed special built-in facilities for fixed-point arithmetics based on look-up tables which dramatically speed up the calculation of logarithms, square roots and other functions, yet maintain a reasonable precision.

Engine progress

In early 2018, I've learned how to scan sector-based maps like in Build engine, and began experimenting with various CPU-based rendering techniques. As a result, in terms of visuals my engine extends far beyond DOS Build capabilities, allowing for true planar reflections, native sector over sector, free look, anti-aliasing, a limited form of HDR rendering and a lot more neat things. And with the multithreading support, the engine easily surpasses Build's performance on many-core processors. I'm still yet to do the physics part and proper 3D sound though.

The map format is sector-based like good ol' Build engine, but has evolved its principles far beyond with a ton of new features like heightmapping, multiple planar reflections, physically-based HDR. Proposing a support for a variety of rendering techniques not limited to just flat triangles, the engine also doesn't use Z-buffer, using span records instead, what makes rendering very fast even without specific hardware acceleration (which normally requires to trade flexibility for speed). Having a high degree of module integration and transparency between engine parts, Brahma engine is flexible and adjustable to various needs. With it, one can create very dynamic games with an oldschool look and feel.

Now I'm developing a working prototype that features a renderer fully implemented in software (thus not restricted to specific hardware features), somewhat inspired by Ken Silverman's Build engine but written from scratch. Further iterations will bring even more capabilities and speed through integration with CUDA, Direct2D, ASIO or other powerful APIs. Eventually the engine (along with the underlying framework) could be ported to other environments based on x86-64 ISA if there's enough interest in doing that.