Diamond Engine
C++/C# Game Engine
C++/C# Game Engine
Diamond Engine is a lightweight 3D (and future 2D) game development engine. This engine was developed as part of a college assignment. The engine supports almost every editor feature that you could expect from a game development engine, but the most relevant feature is the added support to interpret and work with C# code on a component-based GameObject system.
The C# implementation was mainly focused on making it as fast and reliable as possible. This implementation uses the mono runtime working with JIT to execute C# code at runtime. With this implementation and the app-domain system, it is also possible to recompile code at runtime to make the iteration time as fast as possible.
Apart from the performance and reliable dynamic memory management, the engine is also focused on being visually attractive to the users. Also, new features are being added to make the engine able to generate bigger and better games.
Hi, I'm Mayk. I'm the only developer involved in the "Diamond Engine" project and I've been working on it since early 2020.
I've been coding and making "games" since I was 14 and when I saw a chance to start developing my engine I tried my best to do something I could be proud of. My first contact with the Game Development word was thanks to the Unity Engine, and I always wanted to know how it was made.
Working on Diamond Engine was and still is, the better way for me to learn new things, and I enjoy 3D math and coding so it was perfect. I think this engine reflects what I'm capable of as in 2020, and I plan to get better.
Here's my LinkedIn page if you are interested in some of my other work.
All my other projects can be found in my GitHub page or in this portfolio display.
OpenGL rendering was optimized avoiding deprecated methods and systems, and its performance was also improved by rendering as much as possible with retained mode.
Texture transparency has been added too, and models are rendered front to back to allow transparency to work as expected.
Scene rendering time was reduced with camera culling, camera frustum, and AABB boxes to discard all the meshes outside the camera view. A future improvement will be made by adding space partitioning (a field I made a small study of back in 2018 that can be found here).
Thanks to ImGui's docking, adding docking was fast and cool. Windows can be docked and moved around the editor and can even be moved outside the main viewport.
Right-click inside the Assets window to use the script creation popup. With this popup, you can create scripts that will be added to the .sln file and will be created with template code and an Update() method.
These new scripts will be added to the C# Visual Studio solution and can be directly edited with no restart needed.
A script editor was added to allow fast script modification, but I recommend using Visual Studio 2019.
MSBuild was added as a portable exec to allow everyone to use the engine without any kind of installation nor external software, and also to avoid problems with the C# compilation. (Missing dotnet or MSBuild paths).
The engine works with a GameObject and component system which means that each entity is known as a GameObject and this object contains components, each component derives from the same class but has different functionality.
Giving each camera component its buffers allowed me to create multi-camera rendering, which means that more than one camera can be rendered at once in different windows.
Memory has been closely monitored to avoid leaks and unnecessary usage increments. The use of containers was selected with performance and memory in mind, and I can proudly say that there are, at least not detected, any memory leaks.
Also, memory usage is kept flat and straight during the majority of the engine usage time and it only changes when loading scenes and assets as nen memory are temporally allocated, but at the end, all memory is deleted.
Even some tests have been made while creating ≈ 2000 objects and deleting them 5 seconds later, and the memory usage is kept almost the same, when all created objects are deleted, memory usage is the same as before spawning anything.
The time management system makes it possible to start/stop/pause/step a simulation that will also run other systems (Like shaders, particles...). The content played during this simulation will be the exact content played/displayed when the game is compiled and executed as a standalone application.
Resource management systems make sure that we don't use more memory than we need by only loading resources once to memory, and then the system will assign references (pointers) to those loaded resources. This system drastically reduces the usage of and the game.
Editor camera movement options are smooth, and there's a lot to choose from, Fps, orbital camera, panning, zoom... All those types of movement have been made from scratch because I like 3D math and it was a cool moment to dust off my quaternions old notes.
The user can create, edit, and save their editor styles, custom colors, and shapes to go with every different work style. The dark theme is the default, but themes can be created and share because they are saved in a JSON file.
A small screenshot system was added to the editor that allows the user to capture simulation moments or editor frames as .PNG files.
There are more sub-systems to talk about, but those are the most relevant ones.
As mentioned above, Diamond Engine has a C#/Mono implementation, making it perfect for faster code iterations.
This implementation makes heavy use of extern methods to send and receive data from C++ and C#, which are connected.
One of the biggest performance optimizations was achieved by sending C++ pointers to the C# objects as UINT64 values, and then, when we need to retrieve some data from C++ to use on C#, we just have to send and cast that pointer UINT64 to C++ and then send the data that we need to C#.
As trivial as this may sound, this small detail reduced considerably the C++/C# communication time, which also made Update times a lot faster.
A simple exception handling system was also added. The display fields are saved and serialized and will auto-fill on scene loading. Mono also generates 0 memory leaks and creates almost no increment on memory usage, even when spawning new objects.
Scripts created via the Assets window will be automatically added to the Visual Studio solution. This also allows the user to iterate faster with the hot-reloading system.
On the left gif we can see a script being modified via Visual Studio and how it hot-reloads when we focus back on the engine. Also how the variables are changed in the inspector.
Also, on the right gif we can see a script being created from the engine and how it hot-reloads to add itself to the solution. We can also see the simulation in action.
AGPL-3.0 License
Diamond Engine, lightweight 3D game engine software.
Copyright (C) 2020 Miquel
Suau Gonzalez.
This program is free software: you can redistribute it and/or modify it under the terms of the GNU Affero General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License along with this program. If not, see https://github.com/MayKoder/Diamond-Engine/blob/master/LICENSE.
Page designed and created with HTML, CSS and JS by Miquel Suau Gonzàlez