rinzii / genesis

A small Vulkan game engine written in C++20.

I take breaks from contributing from time to time to learn new topics on my own. So if you see a gap in my contribution timeline thats probably why. ^^

Repositories

• ccmath ₂₀₂₄₊
  ^{A C++17 constexpr-Compatible cmath Library.}
• Mim ₂₀₂₃₊
  ^{A linear algebra math framework optimized for real time graphics programmed in modern C++.}
• Genesis Engine ₂₀₂₃₊
  ^{A vulkan game engine made with modern C++. Worked on in my spare time.}
• Dragon Archiver ₂₀₂₂₊
  ^{A virtual world creation, management, and note taking tool for tabletop role playing games made in .Net.}

_{You can check out more of my gists here.}

Game Jam Projects

• GMTK Game Jam 2022 - Casino _{2022
  Casino is a game about addiction and the strangle hold it can have on your life. This game was made in 48 hours for the GMTK Game Jam with a team of 6 people using Unreal Engine 4. I was one of two programmers on the team.}

My history on Github

• Issues:   Open   Closed
• Discussions:   All
• Pull Requests:   Open   Closed

genesis's Issues

Integrate std::format into the logger

I've noticed a significant pattern that appears quite often in the logger.

gen::logger::error("windowing", std::format("GLFW Error: {} - {}", error, description));

Where std::format is used near constantly so much so that it'd be nice to just remove the requirement of performing the above operation and instead being able to implement the code as follows.

gen::logger::error("windowing", "GLFW Error: {} - {}", error, description);

It would help out a lot to not have to use std::format directly and instead integrate the functionality into the logger to avoid bugs cropping up such as people forgetting to include format and also saving a lot of typing. ^^

Implement an Input Handler

implement a engine configuration file system

Logger does not output to console when inside of a catch block

While I was working on the rendering pipeline I noticed that inside of the catch block in the main was not outputting anything to the console. After some testing I was able to identify that if std::cout was used I'd output to the console, but if the logger was used nothing would output at all. I've not identified what is causing this issue, but it seems to only happen inside of the catch block of a try catch.

The version of the logger I am using is the same as the main branch.

This is where the issue is arising on my end:

#include <game/game.hpp>
#include <gen/logger/instance.hpp>
#include <gen/logger/log.hpp>
#include <gen/util/version.hpp>

// temp
#include "gen/io/fileUtils.hpp"

// TODO: Replace this with a config file. At least for the startup window size.
static constexpr const char * appName{"Genesis Game - Editor"};
static constexpr gen::Version appVersion{0, 0, 1};
static constexpr mim::vec2i startingWindowSize{800, 600};

int main()
{
	try
	{
		auto logger = gen::logger::Instance{}; // Required to initialize the logger

		gen::logger::general.log("Current executable path: {}", gen::io::getExecutablePath().string());
                // ^This outputs to the console

		gen::Game app{appName, appVersion.getVersion(), startingWindowSize};
		app.run();
	}
	catch (std::exception const & e)
	{
		gen::logger::general.error("Exception: {}", e.what());
                // This does not output to console.
		return 1; // Program returns 1 but does not output to console
	}

	return 0;
}

SYSTEM INFO:

OS: Arch Linux x86_64
KERNEL: 6.6.1-arch1-1
TOOL CHAIN: GCC 13.2.1
BUILD CONFIG: ninja-nopch
IDE: clion

implement a windowing class that can connect to the rendering pipeline

Implement a profiler

Implement asynchronous FileIO

Add stream functionality to the logger

Many times I've found I want to compact a lot of information into a single log message instead of multiple using a for loop. One common area I wish for stream functionality is in Vulkan where I have to deal with a vector of items and don't want to make complicated round about means of grouping that information. I'd be nice to be able to do something like:

gen::logger::debug logger("vulkan");
logger.start;
for (i = 0; i < 10; i++)
{
logger << "hello world";
}
logger.stop; // flush the stream and send the log message

^ This is an example of what the approach could be but honestly it can be anything that makes the most sense.

Allow stream operations would allow to group information together without risking fragmentation of the log messages or extremely complicated lambda functions to group everything together. Along with providing more robust operations.

All of this is of course a nice to have and is not necessarily required, but for sure something worth considering.

Have at least one CI build run without PCH

We are developing with PCH on by default, which hides errors due to missing includes (at least with clangd, as it uses the same PCH while parsing). Since PCH is an optional feature of the engine's build, at least one CI build should be configured with it turned off, so we get notified of any #includes we have missed.

Alternatively, require PCH and remove it as an option from the CMake script.

build the starting structure of the rendering pipeline

We will need a basic structure setup along with all of the boiler plate code implemented for the rendering pipeline with vulkan.

replace std::chrono::high_resolution_clock in time.hpp with std::chrono::steady_clock

Currently our time class is using std::chrono::high_resolution_clock which comes with many different implementation details and is generally an alias for std::chrono::steady_clock or std::chrono::system_clock.

For better consistency cross platform I think we should instead explicitly use std::chrono::steady_clock with the smallest tick period set manually. This way we can ensure a consistent monotonic cross platform clock that won't have platform or compiler specific details we would have to worry about.

Bring back in verbose logging information for the logger

PR #48 removes source_location to allow for access to veriadic logging by requirement. What would be ideal though is to bring back in verbose logging without using source_location.

Ideally the logger should allow for this:

• Allow the ability to configure the logger to perform verbose logging. (with verbose logging set to default)
• Verbose logging should provide information such as what function was the logger called from. What line what the error triggered from and more information that may be pertinent.

Currently, this is not a required feature but is a nice feature to have. We can though implement a solution using C macros like __ FILE __ and __ LINE __ and so on.

Implement the basic structure of matricies in mim

The basic structure of matrix's in mim needs to be implemented for use in the engine. I've so far started the process but its a lot of work so help would be appreciated.

Update log to instead use std::format

Define what the core architecture of the engine will be

We should all get into a call at some point and finalize and discuss what the core architecture of the engine should be.

Implement a means of making IMGUI threadsafe

This is more of a down the line goal, but by design IMGUI is not thread safe, but if its possible I'd be pretty cool for us to implement a manner of making it be thread safe.

Display the category with the logger output

It would be nice to be able to quickly see what category a log message is related to from the log output.

Implement a scene management system

Feature additions for the Logger

The current state of the logger is acceptable for use across the current code base, but is in general quite simple and lacks much control in how a user may want to use it. As such below is a list of features we should aim to add to the logger to improve its functionality.

• Add the ability to control the verbosity of the logger. The current version is quite loud in it tells you a lot of information about where the logging occurred. This can be quite helpful when we may want verbose logging, but should not be the default mode. We should add the ability to turn on and off verbose logging.
• Enable the ability to set if we output logging data to a file or console or both. More control over the ability to set what stream we want to log to would be super useful for situations where say we want to log information but don't want to display it to say the console. Ideally we should be able to control this on a severity level. For example, lets say you want to log information to trace that could be helpful to know in some situations but you don't want this information to be posted to the console. The ability to disable console logging for trace would be useful.
• Add logging categories. Logging categories can have multiple benefits for our logger. The simplest being that it can gives us pertinent information to where the log was actually sent from. Such as the rendering pipeline or the windowing system and can be used for even more advanced systems like log filtering in ImGUI.
• Add asynchronous logging. This is more of a nice to have but is not entirely required.

CMake option for Autoformat

Since the autoformat target assumes clang-format is available in PATH, exposing a CMake option to disable that target will be useful for situations where formatting is not required (eg testing some changes without the intent to push).

Controller issue on GLFW's end

The issue still persists, I used a hack to counter the problem for the time being but it's definitely suboptimal (erased the existence of the back button).

Add .clang-tidy to the project

While Visual Studio has built-in clang-tidy integration, the clangd extension on VSCode does not trigger any checks without this file being present.
As a bonus, with the file checked in we can control exactly which checks we want uniformly for all developers.

Example:

---
Checks: 'clang-analyzer-*,concurrency-*,cppcoreguidelines-*,misc-*,-misc-non-private-member-variables-in-classes,modernize-*,performance-*,portability-*,readability-*'
...