An all-new game engine being written in C++; based on the NipSys64 framework I'm working on. This is a retro gaming oriented 3D engine intended for indie development. It's peculiar in a way that it is evolving totally different than other modern engines, rejecting object-oriented programming, the BSP-based portal system, Z-buffering, floating-point coordinates, and lame screen-space effects in favor of clever and efficient know-how techniques. As a result, the engine is non-Euclidean capable, deals with large open spaces with ease, features a full non-opaque surface support, and potentially enables for lots of powerful techniques previously deemed to be nearly impossible to implement in a realtime renderer. The engine is also carefully designed to be easy and convenient to develop for, yet versatile and adaptive to any needs.
I've always dreamed of making computer games powered by my own 3D engine. I've been learning computer programming since 1999, and although my first attempts to make an engine were pointless garbage, things have changed a lot in 2006 when I've moved my development to Visual C++. I'm a fan of the classic Build engine games like Duke Nukem 3D and Shadow Warrior, having some great ideas for my own games, and 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.
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. Beside that, I wish to learn how the games are created from the basic algorithmic structures, and be free to experiment with them. Doing this, I have strong intuitions and views on what 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 all the high-detail eye candy they've used to put into modern games. Also, I'm pretty convinced that the collision model should 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 retro game is built using a modern bloatware tech (as for indie games), it typically feels kind of faked, tends to use excessive disk space and memory, as the oldschool look and feel is only imitated, not being such "under the hood".
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 flat reflections, sector over sector, vertical 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 ideas far beyond with a ton of new features like heightmaps, fast multiple reflections, HDR, lightmaps, voxels and proposed pixel-precise collision detection, as well as native multithreading support. Supporting a variety of rendering techniques (not being limited to just flat polygons), the engine also doesn't use Z-buffer, using span records instead, what makes rendering very fast even in pure software. Having a high degree of module integration and transparency between engine parts, Brahma engine is flexible and adjustable to any needs. With it, one can create very dynamic games with an oldschool look and feel.
Now I'm developing a working prototype, which features a renderer fully implemented in software (thus, not being restricted by specific hardware features), somewhat inspired by Ken Silverman's Build engine but written from scratch, brought to the screen by the legacy Windows API. Next iterations will bring even more capabilities and speed through integration with CUDA, Direct2D, ASIO and other powerful APIs. Eventually the engine could be ported to other operating systems that use the x86-64 architecture if there's enough interest in doing that.
For 120+ Hz display devices, Brahma engine offers a very efficient anti-aliasing solution called 4xTSAA. Owing to subpixel precision of engine's geometry rasterization, we can shift entire frame by a fraction of pixel in any direction. Doing this and varying the direction on time basis, quickly shifting between four states, we can attain a smoother look with virtually NO performance penalty. The framerate must be stable though and perfectly vertically-synchronized.
Recently I've bought a 144 Hz Full HD gaming monitor to test my engine on high refresh rates and 1080p resolution. Having 144 Hz opens a whole new world of rasterization, since pixels now can flicker so fast that it becomes unnoticeable. 4xTSAA is based on this phenomenon and resembles the near-forgotten interlaced scan, but with modern tech brings to whole new level, giving effectively 4K appearance on an ordinary Full HD screen, coupled with a higher refresh rate!
Unfortunately, so far I don't have a support for a high-quality output API which consistently does not skip rendered frames. I gave the engine a test with the Direct2D API, but this didn't solve occasional stuttering (frame skipping), causing other problems instead, so now I'm stuck with the legacy GDI output I've been using since 2006, emulating vsync with timers (which, however, is reasonably fast and offers maximum compatibility). Still I'm in a need of perfect vsync without any stuttering.
When rendering an anti-aliased scene, frames are organized into four 'fields' cycling quickly with slight sampling shift for each field, creating the impression of a static anti-aliased picture if cycling is fast enough. This also removes the need for anisotropic texture filtering, since whole scene is anti-aliased. The sampling pattern is optimal for a raster display, since the samples have evenly spaced X and Y offsets, effectively raising resolution by a factor of four.
No articles were found matching the criteria specified. We suggest you try the article list with no filter applied, to browse all available. Post article and help us achieve our mission of showcasing the best content from all developers. Join now to share your own content, we welcome creators and consumers alike and look forward to your comments.