weblog/_posts/2025-01-14-journey-into-3D-game-engine-p1.markdown

---
layout:     post
title:      Journey into 3D engine design - P1.Introduction
author:     JackCarterSmith
categories: Programming C++ GameDev
thumbnail:  build_an_engine
highlight:  true
---

* Contents
{:toc}

For many years now, the performance of computers has been constantly evolving: the number of transistors 
has increased transistors, reduced size, increased speed, reduced power consumption...
All these improvements have enabled computers to carry out more and more complex calculations in large 
calculations. One of its applications is the display of a virtual 3D environment on a physical 2D screen 
(your computer screen)! 3D rendering engines are now used everywhere: in entertainment but also in 
architecture, aeronautics and the automotive industry.

Nowadays, it's very complicated to define what a 3D engine should be able to do. is accompanied by extensions, 
generally related to the use of the software, but which end up hiding the the "basis" of 3D rendering on 
a computer.

In this "*Journey into 3D engine design*" series, I'm going to look at the basics and write a pared-down 
engine, retaining only the minimum that's useful. This base can later be used to understand how graphics 
APIs work (Vulkan, Direct3D, Metal, etc.) and to create portions that can be reused in embedded systems 
that don't have hardware acceleration (GPU).

I haven't planned any particular guidelines for these blog posts. I'll be writing the various topics 
progress and the various issues I come across!

![SFML exemples]({{ "/static/images/posts/computer_nerd.jpg" | prepend: site.baseurl }} "Trust me, I'm an engineer!")

### __My problem with Unreal, Unity, Godot, etc.__

The WWW is full of "how to make a 3D game" tutorials. In fact, there's no shortage of these videos and blogs... 
However, there are 2 types of tutorial: those that explain how to use an engine and create a game using it, and 
those that explain how to create a game using graphics APIs such as OpenGL directly. There's actually a third, 
less ordinary category (and here we're curious about the unusual!), which really starts from 0, no APIs or very 
few libraries (apart from stdlib), including 3D maths libraries. This might seem like reinventing the wheel, but 
you have to ask yourself: is my aim to study the wheel? Then yes, reinventing the wheel is essential.

So yes, in this series, no explanation of "how to make AAA with UE5" but rather details on how and **why pixels** 
**are displayed on our screen simply from NUMBERS!** Do you think I'm making a fuss? It's up to you, but we're going 
to eat maths, a lot! Guaranteed.

For the start, I'm going to use [SFML][link_sfml] (Simple and Fast Multimedia Library) for simplified management 
of the OS window, without messing up the rather *OS-management-oriented* function code too much. I plan to remove 
it later in the series, for a possible port to embedded. In addition, in order to have a practical example of 
my post on [CPU optimisations]({% post_url 2024-03-01-cpu-vectorized-acceleration %}), I'll be adding **SIMD** 
**instructions** equivalents alongside the implementation. This 3D engine will in fact be CPU-only in order to ensure 
that it is as portable as possible on architectures that don't have a dedicated GPU or compatibility with standard 
graphics APIs (although this is rare when a GPU is present).

Some engines are in the form of a framework or library and need to be used by a master application to tell it what to do, 
while others combine the engine directly into the application, sacrificing the engine's modularity but making the 
code easier to read for our purposes.

In conclusion, there are no good or bad reasons for creating your own engine, whether to achieve something very 
specific artistically, or to get the best performance for a given gameplay. Obviously, this involves going down 
the "long path" and often spending several hours on basic notions that are essential to the concept of a graphics 
engine in general.

No pain, no gain.

![SFML exemples]({{ "/static/images/posts/sfml_games.jpg" | prepend: site.baseurl }} "A lot of indies games have been develop using SFML")

### __Minimum equipment__

SFML offers several function groups for graphics, audio and networking. For the moment, I will only need 
the graphics part, in order to manage the system window and the rendering display. SDL was also a 
potential candidate for this use, but for this project I wanted to make up my mind about SFML.

Apart from SFML, the mathematical part will be supported by a slightly modified and reduced implementation of [Direct3DMath][link_d3dmath].
The SIMD acceleration it offers is not negligible for CPU-only.

Multi-threading is also envisaged through the use of the **pthread** lib. More versatile than std::thread from 
libstdc++ and less obscure than OpenMP in use (we'll come back to this).

Since we're recreating a graphical flow from scratch, we'll need to create our own tools for debugging rendering 
and performance measurement tools.

I often work with the GNU toolchain (version 14 at the time of writing) and with the [Conan][link_conan] package manager.

The project itself is configured with [CMake][link_cmake]. From time to time I check compatibility with Windows 
via the MSVC compiler. **MinGW** can also be used without contraindication.

And we'll try to keep to this strict minimum in order to lighten the code by keeping only what is necessary 
for on-screen rendering, and also to improve the portability of the programme to more critical platforms 
in terms of storage and performance.

See you in the next post! 

**[END_OF_REPORT-250114.1459]**



[link_cmake]:           https://cmake.org/
[link_conan]:           https://conan.io/
[link_d3dmath]:         https://github.com/microsoft/DirectXMath
[link_sfml]:            https://www.sfml-dev.org/