Vertex Cortex: #2 first steps¶
Vertex Cortex Purified is an ambitious jump in complexity from what it once was. I'd be lying if I said I wasn't unsure of what to start off with, so here is how I've jumped into planning.
Window Creation¶
After researching on how graphics pipelines/frameworks/engines work, (at this point I didn't quite know how to label my project), I made a list of requirements and dove right into the very first one: Window creation.
Now, this project isn't completely free from APIs/Libraries. To even begin creating a window and receiving event messages, like user button clicks, I need to interact with an OS API; and in this case, it was Win32.
API-level question: “wrap Win32?”¶
After going through the tedious set up of creating a window I realised that simply writing code to create a one was not going to work or satisfy this requirement.
If a user of this engine/framework/pipeline were to create a project, I wouldn't want them dealing with any of Win32's code.
I naturally then started creating a window class without much thought. Maybe that could simplify how to use windows, and everything will work out through abstraction!
I felt uncomfortable with this design though.. I realised I needed to think about things in a different way.
Framework-level question: “who owns the window?”¶
The window class, and now "simplified" code in main which was basically doing the same thing before raised a lot of different questions. Mainly this: Would I really need the user to declare or define ANY window?
That made me start to question what I was even building. What sort of experience would I even want.
Maybe window creation could be done under the hood?...
Before figuring out how I could implement it, I was sure that was the only way. The thought of a hidden window creation pipeline sounded great to me, but a lot of different things could go wrong, and were hard to plan out.
How would the user name their program? title the window? access those details while keeping all window creation hidden?
While experimenting, I noticed something else too; if I have an empty loop, what I thought I'd let the user use, the window would freeze and not be able to be interacted with. Upon debugging, I learned that I had to have some form of way to process messages inside the loop or the window would hang.
It felt like I couldn't escape window code being exposed to the user.
damn.
Engine-level philosophy: “should I hide main?”¶
How could I handle this problem? Should the user even have full access to the application loop? How can I really create and initialise the main window without the user's input?
Then... it hit me; in something like Processing I don't ever see the full loop. I just add code to the setup() and draw() methods.
I realised I had to approach this, not like a library that people include and work WITH, but a full on framework/engine they work IN. Mimicing the user experiences that came to mind like in Processing, or even game engines like Unity or Godot.
I was stuck on how to do that, so I headed to the books! More specifically Game Engine Artitecture by Jason Gregory, and API design for C++ by Martin Reddy.
They opened my eyes to a lot of approaches, including but not limited to callback functions.
After reading and working, I wound up with this entrypoint for a user:
Within the VertexCortex header, all the window creation and handling is done. The main function lives there as well with the loop established. The user can set the window title by coding in setup(), and control what goes in update() and render(), which run at different points of the loop.
This seemed like a solid start! But I still need to figure out how to handle input events...