What is Fragment Engine?

Ah, Fragment Engine. A project that will probably take my entire life to complete because I am but one man and there’s only so much time I have on this planet (Unless my plans for cybernetic immortality come to fruition, but we’re not there yet). Since literally nobody but some friends and a few of my lecturers at university have ever heard of this thing, I’ve decided to write about what exactly it is.

The Name

Why did I call it “Fragment” Engine? To be honest, I was doing a lot of GL shader work when I started work on this, so the phrase ‘fragment shader’ was drilled into my head. I thought it sounded cool and – as I thought more about how I want the engine to work – it also became more appropriate. I’m planning to create the engine so it could be developed in a ‘fragmented’ way (Basically just a modular engine) and from that point on the name just stuck.

Core Info

Fragment Engine will hopefully be a full 3D game engine along the lines of Unity and Unreal. I’m using it to learn about all fields of game engine development, as well as the development for tools necessary for game development. It’s written in C++ (I am thinking of porting it to D, but more on that later) and currently only supports Direct X 11. As of this post, it also lacks anything but a graphical engine – no sounds, no networking and very basic physics. Even so, I’m happy with the progress I’ve made on it, and it helped me net a very high mark on one of my university modules.

Current Features

Currently, FE has support for some pretty advanced features. These include:

• Full DirectX 11 Support – Packaged as a subsystem so that I can hopefully implement other rendering systems as well.
• Support for the full shader pipeline, including Hull/Domain and Geometry shaders.
• Deferred PBR rendering with HDR texture support.
• A full reflection engine, allowing automatic serialization of game objects (More on this in a future post).
• C++ coroutines built in a similar fashion to Unity’s coroutines. (More on this in a future post too. I suspect this might be Windows specific, but hopefully I will be able to make it portable).
• Chromium browser as a UI. I find that HTML+CSS+Javascript to be an obvious choice for UI development, although at the moment there is significant overhead with using Chromium. Even so, this also allows essentially webpages to be used as textures in the environment, making things like control panels extremely easy to make.

Future Features

These are features I plan to implement in the immediate future. Some of them will even be implemented within a month (At least at a basic level) due to another pending coursework. These features may include:

• A bespoke physics engine with support for rigidbody and soft body physics. This will be run in at least one seperate thread.
• Implicit networking using my reflection system. The aim is that a programmer can just tag a variable as ‘replicated’ and the networking subsystem handles it all for you.
• A proper editor, either built into the engine or as a seperate runtime alongside it.
• Some form of portable shader support. This will probably be done by writing the shaders in Cg and/or having a node based shader creation system, similar to Unreal Engine’s. I’ll probably implement both.
• Support for OpenGL and Vulkan. While it’s unlikely, I would even like to support the ability to switch rendering engines at runtime.
• An audio system of some sort. I plan to implement one where the programmer can extract audio data at runtime such that they can use it for DSP effects and visualizers.

Far in the Future Features

These are things I definitely won’t get done soon, but which would be nice.

• Platform portability – Mac and Linux support!
• Extreme platform portability – Game console support!
• Super extreme platform portability – Android, iOS and all the others!
• D conversion. I really like the concept of D, especially with it virtually being C# but in C++ land. I feel it could make development a lot easier at the expense of C++ purity, but it’s not something I’m able to do until at least my course is over.
• Some form of scripting engine. Whether it’s Lua, C# or something completely custom (Probably not), I’d like the ability for arbitrary code to be written outside of the C++ code but can then interact with it. This would make the engine a lot more accessible to those new to programming, and would allow rapid iteration of things in game. I might even attempt a system for non-programmers like Scratch or Unreal Engine’s Kismet/Blueprint systems.
• A bespoke HTML+CSS+JavaScript UI engine that’s a lot more lightweight than Chromium. It should still support most of the expected modern features (Including things like and tags), but lack many of the things that give other browsers their overhead. By being integrated with the engine directly, it also means that Engine specific features could also be introduced such as positional 3D sounds and sending image data to the UI for things like render targets.
• VR support. Naturally.

Can I Use It/See the Source Code?

No. At least, not yet. I’m still using this in my university coursework, and I don’t want to be accused of plagiarism or helping other people plagiarize my work, so for now it’s a completely private personal project. Around July/August time though I’ll probably reveal it properly to the world to judge my awful programming practices like how I use Allman indenting or how I use the C# naming conventions.