-
Notifications
You must be signed in to change notification settings - Fork 0
v0_1 First Window
"Yes, I did some research on using the built system and I indeed chose Makefile afterward because it provides greater control over the build process, but in return, setting up the project with it is pretty cumbersome in the long run. Anyways, a decision to make." - PolyWCube (in the past)
Maybe this is my biggest mistake so far as I wasted most of my time to get the built system to work, compared to using CMake, which uses about one-fourth of the time needed to set up. But in the end, I got something pretty exciting to work with, which I think it worth it.
During the process, I got stuck with DLL Hell, and I managed to solve it by switching to static library creation instead of creating the dynamic library. This should be the temporary solution as I think I will use the dynamic library creation in the future for faster engine compilation, just a thing to keep in mind.
About the base of the engine, I designed (or tried to) the architecture for my engine. It should be something like the following:
[ Application Logic ] <-- (Event/Data) --> [ Application Logic Layer ]
----------------------------------------------------------------------------------------------
^
| (API Calls)
----------------------------------------------------------------------------------------------
[ Event Manager ] <--> [ Layer Manager ] <--> [ Physics Layer ]
^
| (API Calls)
----------------------------------------------------------------------------------------------
[ Resource Manager ] <--> [ Rendering Layer ] <--> [ Core Engine Layer ]
^
| (API Calls)
----------------------------------------------------------------------------------------------
[ OS Abstraction Layer (OSAL) ] <--> [ Input Layer ] <--> [ Hardware Abstraction Layer (HAL) ]and source code be like:
source
+--> component (the core component of the engine)
+--> graphic (windows, GUI, draw,...)
+--> physic (movement, collision, constraint,...)
+--> log (message, file in/out,...)
+--> ...
+--> utility (the "helper" needed for communication in the engine)
+--> math
+--> event
+--> layer
+--> ...
+--> base of the engine (entry-point, application handle,...)Then, I implement the essentials needed for the application to create the window such as Win32 API interaction, event conversion, and vector math.
I tried to make sure everything worked first then defined the necessary parts to optimize. In this way, it's much faster than focusing on writing the perfect code.
A good event technique that I found is using this structure:
template<typename T>
using EventFunction = std::function<bool(T&)>;and bind it will a specific function callback, which makes everything tied together.
About the log system, I tried utilizing the MACRO to define a custom log format and level. That's kinda unsafe but it is nice to work with. By the way, I learned some compiled-time optimization from here that I think it's useful.
And in the end, I got a Win32 window display along with a console window logging event and write into a log file. Not bad at all.
v0.2 should give me a nice GUI to work with, along with some abstraction for the graphical library.
- Currently, I'm looking forward to implementing my GUI framework into the engine, which I think will be a challenging task to accomplish as there aren't many resources out there, but it will greatly boost the developing time and my motivation in the future.
- I thinking about the parallel built system idea that I have in mind but am still on the prototype about utilizing both static and dynamic libraries, which people usually call the hybrid approach, for better control of the project.
- Add
Makefile(as built system) - Add event system (Event and simple Manager)
- Add log system
- Add window creation (Win32)
- Add math (mainly vector math)
Copyright (c) 2025 CUSTOM (the "Organization") - PolyWCube/PWC (the "Author"). All rights reserved.
