Logging and Events (and refactoring Input)

I took a break from the renderer as the next step involves getting render passes setup so I can render shadows and do fun stuff like post processing etc. This poses two problems for me..

• Once I get started, I won’t have a lot to show for a while because I’m sure it’ll involve a lot of refactoring work
• I actually have no real clue what I’m doing, or what order makes the most sense to do things in

Thankfully on the latter point, I found a YouTube channel called “The Cherno” which has an incredible amount of content, one of his series is an educational series about building a Game Engine from scratch which is very pertinent to my interests, his Hazel engine is definitely a much more ambitious and fully featured engine than I was ever planning, but it’s been very helpful to see how a professional approaches engine development.

After watching a few of his videos, I had to face the reality that I was approaching things the “wrong” way by starting with the renderer, where someone with more experience would probably have a lot if infrastructure setup well before they begin looking at the renderer.

One of those key pieces of infrastructure is a robust logger, and I always knew I needed this, in fact until now, I have had a lot of “TODO: Logger” comments scattered around the place.

So with some help from The Cherno, I’ve now got a logging system built on spdlog running which is great, it prints to the terminal and syncs to a log file on disk which is really nice. I plan to implement a developer console at some stage so being able to direct the log is great.

Another element I always knew that I’d need is an event system, I honestly didn’t really know where to start with this so I had put it on the back burner and intended to do some research later. Of course, this is another part of the infrastructure you should really do as one of your first steps, because it obviously impacts user interaction.

So with an event system up and running, I was able to rethink the Input system and now things feel a fair bit cleaner, as an example the CameraComponent is now effectively standalone, all it needs now is to be told when to update and what the delta time is where as before it had to know about the Input system and the main window (as that held some properties which made sense without the Event system).

I’m not quite sure what is up next, if I keep following The Cherno, then getting some kind of debug overlay in place with a GUI system is probably a good idea.

So… Qt, or not Qt, that is the question.