Stuff by Aster

An Introduction to DIODE

Wait, Diode? What the hell is Diode? Well if you’re wondering exactly this, just like I am, then I suppose you’ve come to the right post. I’m actually not too sure myself.

Either way, I saw a lovely talk by Tomasz Stachowiak entitled Rendering Tiny Glades With Entirely Too Much Ray Marching, and it inspired me to begin my learning process with game engines again. Now I have done this multiple times in the past, but nothing like this, and with 28 papers and counting that I am looking at, I firmly believe I can do it this time. I must remind myself that this is less for a game and more as a learning experience.

After that, I began setting up a .NET solution to program with, but then I saw even more lovely content that inspired me even more, such as this amazing video from Simon on 2D radiance cascades for realtime GI, and I thought it was amazing. Then I saw this demo from a developer, and was blown away. This technology hasn’t been completely realized just yet, it tends to have some leakage issues due to how it is implemented, but these can be fixed for nearly no cost. The only problem I have with radiance cascades in general so far is that it needs something like a temporal implementation to reduce GI noise.

Now originally I was just going to go 2D for this engine, no big deal, but then I saw this ShaderToy for 3D radiance cascades, and decided that because my primary goal was already to learn so much about graphics programming, I may as well attempt to do this in 3D. Beginner’s hubris really is something to watch out for, huh?

Anyways, wait… What exactly was I writing this for, again..? Ah, yes.

What You’re Actually Here For

Diode is an engine, my engine to be exact, and it plans to support tons of modern technology and features. In fact, here is the full laundry-list of features it plans to support, at the time of writing:

And yeah, it’s a lot, and I mean it’s a lot a lot, like ridiculously a lot. But I’m here to learn and implement, and if I run out of things to learn and implement, I won’t continue with this project. I am also implementing this all in .NET languages, like F# and C#. The reasoning? I prefer both to C++, and modern .NET (.NET 10 at the time of writing) supports the zero-allocation model just fine, with things like ref struct and more, so I can easily avoid triggering the nightmare that is GC for performance reasons.

Engine Architecture

By now you know that the engine is called Diode and is built with .NET. The way I write Diode in these posts will be a little misleading, and by that I mean that Diode’s name is similar to the engine used in Alien: Isolation, CATHODE (yes, this is the best source for information on their engine). The engine’s name is often stylized as DIODE, in all caps, as you’ll soon see with Inlay (also stylized as INLAY), the engine’s UI library, in a future blog post.

Onto the actual architecture of the engine, inside the root of the game folder, there is an assets/ folder. The assets folder holds a lot of stuff, like core game files and mods that the community have created. These folders are entitled core/ and mods/ respectively.

These core files will be verified using BLAKE3 checksums at game startup. I know the first question you likely have is “is this for DRM purposes?” And thankfully, no, it isn’t for DRM purposes. It’s just to protect the average player in case they mod any core files or the core game files get corrupted in any way. It is very important that the game should be able to load loose asset groups as well as packed asset groups. These packed groups are contained within DPA files, which will be expanded upon in a later blog post. Loose assets are much slower to load than packed assets, but are primarily important for development. In the case a modder wants to learn about how the game works and how to script it, they can unpack the files and mess around with the various scripts laying around, if this breaks the game, so be it! If the user is modding anyways, there’s a very high chance they can fix it themselves!

game_folder
├── assets
│   ├── core
│   │   ├── config.dpa
│   │   ├── dialogue.dpa
│   │   ├── maps.dpa
│   │   ├── materials.dpa
│   │   ├── music.dpa
│   │   ├── scripts.dpa
│   │   ├── sfx.dpa
│   │   ├── textures.dpa
│   │   ├── ui.dpa
│   │   └── va.dpa
│   ├── dlc
│   │   ├── dlc1.dpa
│   │   ├── dlc2.dpa
│   │   └── dlc3.dpa
│   └── mods
│       ├── load_order.toml
│       ├── loose_mod
│       │   ├── assets
│       │   │   ├── scripts
│       │   │   │   └── script.cs (On the fence, could be Lua in the future!)
│       │   │   ├── sounds
│       │   │   │   └── sound.ogg
│       │   │   └── textures
│       │   │       └── texture.png
│       │   └── mod.toml
│       └── packed_mod.dpa
└── game.exe (just game on linux)

This is the primary visualization for the engine’s general file and asset structure. You can see that the engine will also support packed DLC. It also supports sounds, but the engine internally uses FMOD Studio, so the default format will be BANK files. I will have to figure out a way to support modding workflows.

The engine’s UI is powered by INLAY, a custom, GPU-driven UI framework I am developing. It uses its own QML-like language for creating UIs, that is compiled down to a flat, allocation-free binary file for the engine to eat and use. This will likely be open sourced once it’s in a position I am very comfortable with. Currently the engine uses Dear ImGui for drawing debug overlays, but this will (hopefully) be switched with Inlay in the future. These .inlay files will be compiled to .ibui files for the engine to consume.

The engine will only use HLSL shader files, and the reasoning for this is just that I’m slightly more familiar with HLSL. Yeah I know, boring, but that’s literally it, that’s why I prefer HLSL. I know this is a very short note on this, but it really doesn’t have the need for me to divulge any more explanation on my shader choice.

So, what are some critical constraints (for lack of a better word) that I’ve placed on Diode? Well for starters, there will be ABSOLUTELY NO TAA! I am tired of abysmal TAA being used as an awful crutch for developers who don’t want to optimize their algorithms. The only place I’ve ever seen TAA be useful is in high-density GPU particle systems that utilize the chaos game to draw a ton of particles on the GPU all at once. Other than that, it just makes games look like absolute smeary messes that hurt my eyes and make me want to cry.

Another constraint is that I’m absolutely prohibiting AI-powered upscaling (DLSS, FSR4, XeSS) and frame-gen. They were initially envisioned to allow lower-powered hardware to get up to higher framerates in intensive games, which is a mission I absolutely support and respect. The problem arises when developers and companies as a collective realized that it was much easier to cheap out and sacrifice both performance and visual quality as they could now leverage things like DLSS to get “free performance,” which is dubious at best, and absolutely lazy at worst. AI upscaling also just turns games into a smeary mess, now with the added “benefit” of AI artifacting at high frame times. Not to mention that DLSS 5 just looks like absolute shit, but I digress.

So… Diode…

Diode is the engine that I will hopefully be working on for the forseeable future! I plan to learn a lot of new things in the process of doing this project, and I am primarily writing these blog posts to hold myself accountable and continue this project, mainly because I will be very disappointed in myself if I drop this, and hopefully, so will you, and wow, what a long post.

The next blog post will likely either be on Inlay or DPA, so stay tuned for that. Thank you for reading though, even if it didn’t fully interest you, or my writing sucks! I hope to see you again at some point.

<< Previous Post

|

Next Post >>

#Diode #Game Engines #Games #Graphics