Brahma engine

Check out the current public test version here!

Brahma is a 3D game engine with a rather retrofuturistic design, intended for small studios and solo developers. It's being written from scratch in C++ using standard Windows API and no third-party libraries. This technology introduces an entirely new class of low-latency real-time engines that make special timing requirements, treating frames as video fields with a target time budget of 2-4 ms each, down from 16-33 ms frame budgets normally seen in game engines. It evolves in a different way than other modern engines, rejecting conventional BSP, Z-buffer, floating-point coordinates, and most of the lame screen-space effects in favor of innovative and efficient techniques. The engine is non-Euclidean capable to some degree; also it supports true displacement mapping for sectors as a means to virtualize geometry that affects collisions. The engine is also carefully designed to be easy and convenient to develop for, yet versatile and adaptive to any needs.

Highlights

• Lightweight, instant warmup, loading any content in background
• No Z-buffer, G-buffer etc.; no near/far clip plane required
• A custom software-based rasterization pipeline not governed by triangles
• Full support for non-power-of-two textures (up to 65535 px wide)
• Correctly ordered transparency without compromise
• 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 edit tools with game logic
• Importing 3D models from various formats, supporting N-gons with up to 255 sides
• A caching system for voxel sprites and auto-generated impostors
• A hybrid bitmap/audio format with unique features
• Optimized for stable and stutter-free high framerates (in the 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
• A physical sky system with actual stars drawn as points
• Heightmapped surfaces without tesselation, affecting scene collisions
• 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 various things that were inspired by my favorite games. The digital world was my escape from the gloomy post-USSR life. I was in Windows and MS-DOS environments and got used to them. My first programming language was Visual Basic 4 (I quickly moved to VB6 that was mainstream at the time). Although my first attempts to create an engine were pointless garbage, some of my results were promising, and I remember coming up with my own vector graphics format and a simple editor back in 2001. I loved drawing and 3D modeling as a kid, and enjoyed making short animations in early 3D Studio MAX versions. I also enjoyed using ActionScript in Macromedia Flash 4, but dropped it since I was passionate about programming all graphics by hand. It was fascinating to allocate a byte array and send it to the screen. I'm also into music and sound, and have used a lot of sound editors since Cool Edit '95.

Things have changed a lot in 2006 when I 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 used to code some crazy things with EDuke32 source port. Since I had some great ideas for my own games, I was striving for independent game development and chosen to use my own technology started 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.

Nobody has recognized my dedication back in the day. My father told me it's impossible to achieve any success by working with personal passion and intuition, meaning that one should obey and do what everyone else does. But I can't buy it. I have to pave the way on my own despite my disability and life's challenges. I studied in a technical college once, but dropped out in 2012 to devote more time for hobby projects and self-education. At the same time I felt the urge to learn about artistic, music and design related topics, being kind 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 other developers. 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 and immersive gaming experience than use of complex shaders and high polygon count, for instance. Also, I'm convinced that mesh support shouldn't be limited to flat 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 is what you interact with" approach. As a sidenote, if a small indie game is built with the use of a modern tech, it tends to be overly bloated and typically feels kind of fake and generic, 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 built-in facilities to automatize content generation and management, making games take up less space, load faster and be easier to create at the same time.

Development notes

Although it's deemed to be a massively-parallel task (exploited by dedicated graphics hardware), the entire process of rendering of a 3D scene is rather serial by its nature. Unless you are using a culling technique like Z-buffering, you can't draw an object into the frame buffer 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 one chooses 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/ray marching). 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 partially parallelizable, requiring some careful effort to keep your execution units synchronized, and the overall performance being limited by Amdahl's law. This and seeking for maximum flexibility is the main reason why my renderer is implemented in software; also any accelerated versions are expected to have the software renderer as a reference.

In addition, I require the pipeline to be deterministic and well-standardized on all supported hardware so the output frames could be used by the game logic when necessary. The engine also doesn't use a conventional Z-buffer, using span records instead and rendering game entities along lines of constant depth in a back-to-front order, what ensures correct order of transparency while keeping the renderer rather fast even without specific hardware acceleration (which normally requires to trade flexibility for speed).

Despite being written in C++17, the code relies on generic programming rather than object-oriented programming, with minimum amounts of machine abstraction and mostly manual memory management with grouping all similar items into arrays. Basically, the engine is a huge ass C program that utilizes C++ templates and member functions to reduce repetition and facilitate internal code reuse. 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 reasonable precision. I have also designed a custom character encoding and string object.

Engine progress

In early 2018, I've learned how to scan sector-based maps like the classic Build engine does, and began experimenting with various CPU-based rendering techniques. Later I managed to achieve free look with a correct perspective, native room-over-room rendering, true planar reflections with Fresnel falloff, anti-aliasing, a limited form of HDR rendering, post-processing effects, and more. With the multiprocessing engaged, the engine can easily surpass 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 it was implemented from scratch and has evolved its principles far beyond with a ton of new features like heightmapping that can be used together with slopes, multitexturing with possible reuse of the same material on many surfaces, reusing the same floor or ceiling surface in multiple sectors, and referencing objects directly without tag attributes. I propose support for a variety of rendering techniques not limited to flat polygons only.

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.