Silfur Engine # 1: Where the adventure begins...
Hi everyone :)
All started with a tech discussion with a former colleague of master degree. He ask me to develop some utilities of a game engine and tell him if I get the same conclusions as him on these developments. Instead of that, I start to think of a full game engine with utilities. I prefer to start to develop the base of a game engine before develop any utilities I need.
And actually, I prefer develop only the utilities I found interesting to develop. So here we are, with this devlog on the project Silfur Engine.
This game engine only serves our own experiments related to the subject and the goal would be to use it to have a little game made with it in 2D or 3D or even an application displaying a real-time rendering. The source code is available on Github.
The references for its creation are:
Let's get into the heart of the subject !
I will leave with explanations of the first steps that have been made, as well as my feelings about the choices. Maybe you would have done the same? Maybe not ? Feel free to communicate your opinion in the comments.
The first bases currently posed are the launching of the application with an entry point specific to the game engine and independent of applications using the engine. That is, the very first function executed by an application will be the entry point of the engine. This will execute the essential elements of the engine in order to launch the application in the best conditions.
To clarify, the engine runs only under 64-bit Windows at the moment. We'll see later for other platforms.
First, it was necessary to choose a way to use the engine by the application. After research, I really loved how Cherno achieve this.
It involves compiling the engine into DLL and linking it dynamically to the application. It allows to have the engine as a dynamic library for the application.
To achieve this, it is necessary to use the import and export of the public symbols defined in the DLL. As explained on this page and on the Cherno's channel, we defined macros to simplify writing and readability to differentiate between when functions should be exported or imported.
To explain this piece of code, the use of a DLL is unique to Windows. So we check if we compile on Windows. If this is the case, we check if we compile the DLL and we define the SILFUR_API macro for the export, or if we compile the application and we define the SILFUR_API macro for the import.
Then, before we change the entry point in the engine. We defined what an application was from an engine viewpoint:
A constructor, a destructor and a Run() function containing, for the moment, an infinite loop to block the execution. We find the SILFUR_API macro for the export / import of the class from the DLL.
Moving entry point
Finally, to start to modify the entry point, I created a CreateApplication() function in the header of the class Application :
And we defined in a header EntryPoint.h the visibility of this function so that's implemented elsewhere.(See below in the devlog for example)
In this same header, which represents our entry point, we will find the main function of the program, the first function of the program to launch:
It's relatively simple:
- Create an application
- Launch her function Run()
- Free memory because the auto type we always be a pointer
Create an executable to test the engine
And finally, define a project being our executable that we named Sandbox. Because the engine is just a DLL. It currently contains a simple SandboxApp.cpp file:
To describe it :
- A Sandbox class defining the application (of the executable, not the engine) inheriting the class Application of the engine.
- The definition of the CreateApplication function that matches the definition defined by the extern keyword in EntryPoint.h.
Finally, here is how this example works:
- The program starts the main function that calls the CreateApplication function. This function is defined in SandboxApp.cpp. She is content, for the moment, to create a Sandbox application. So the type of car is equal to Sandbox *
- We run the Sandbox Run function which it inherits from Application (we could later overload it)
- The application is blocked by the infinite loop of the Run function.
- When you close the application (by clicking on the cross), the delete statement runs releasing the memory.
If you have any questions. Feel free to leave a comment 🙂
Leave a comment
Log in with itch.io to leave a comment.