Would be helpful if the window could release its capture on the mouse once something is pressed. The interface should be somewhat similar to quitting, i.e. a default button which always releases the mouse and having a function which can add/delete custom inputs.

The swapchain members get destroyed in different spots in the framebuffer class one by one, probably has something to do with my new destructors

The JSON parser segfaults with the test json string in Tests/Containers when compiled in release mode. I have not looked into this at all, could be therefore be anything. Low priority because It's not that important until the Engine is actually ready and needs release mode.

Currently, mipmapping only applies to textures, because I don't see the reason to add a mipmap to a depth buffer or something like that. Maybe I'll realize this later, for now, this will be put on hold

Game objects can own a mesh and a mesh renderer, which are separate objects. The mesh is just the mesh data, while the mesh renderer is the vertex buffer, index buffer etc., which allows easier use of batch rendering

And yes, I know that the names are TOTALLY original and not "borrowed" from a very popular game engine

I want to make a wrapper around the SDL input system, but it is kind of very repetitive to implement that, but it is still very important

After swapchain and renderers recreate, the next vkQueuePresentKHR crashes with an VkResult of -4 (VK_ERROR_DEVICE_LOST) with additional validation error messages from MoltenVK regarding the failed execution of a command buffer.

Because (I think) you would never know, where a function of the image would be called first and it would be a huge pain to define the device over and over again, so either, I'm going to make the VulkanDevice parameter simply the first optional argument, or overload them, with one having the device as parameter and the other one not, so that the user can decide himself, if to pass in that device again

Right now, quitting is just closing the window, which I would like to keep as default, but I think there should be an option which lets you quit by pressing other buttons.

Efficient heap memory allocators are necessary for the new backend architecture, because it now only works with pointers, and it would be nice if the pointers were arranged nicely in memory without big chunks of empty data between them

std::string would be one of the last major containers in the standard library I haven't made a custom implementation for yet.

Make an asset, material system and a scene system. The asset system should contain pipelines, images, sound, loading files, compressing and decompressing of image, sound and etc. files. The Material system should take the assets and wrap around them for ease of use. The scene system will then take the binding commands send out by the materials, pass them through a quick sorting algorithm and send them to the renderer

Exact details are on a diagram on a poster hung over my PC

Pretty complicated stuff

If you look at the code in VSCode (my IDE of choice) it looks perfectly fine, but once on Github the tabs are shifted around very weirdly. I have no idea what causes this, It's only something minor, but still looks kinda bad.

Although everything works fine as it is, since the custom wrappers have cast operators, it would still be better to pass the new handles themselves into the wrapper functions for a better code consistency.

Implement a configuration file in the data file that the engine will read on startup

Turns out renderpasses/framebuffers cannot share images for whatever reason, which means it would be necessary now to implement the custom targets and to move the images themselves to the render target too.

The Inheriting-Based System that I use now is good enough, but a "proper" ECS system would be much more useful and better

Delete all of those for every current class that doesn't need them (which is basically every one right now) and other unneeded functions and add some real destructors

Since these new systems and the new RAII containers have never been tested before, this should give a pretty good insight of if they need extra revisions or not. Following tests shall be performed on an Windows system with (most likely) RenderDoc.

• #26

• #27

Make a Content Manager that compresses and fuses assets into a single file, one for textures, one for models and so on. The engine itself should only support reading these files, while the Content Manager has full control over the contents

This file has no defines or macros anymore, everything has been moved to inline functions, so it has nothing to do with its name anymore

This is optional, but make a function in the command buffer class, which wraps around the execution of pipeline barriers, so that the code looks a bit better

The Vulkan backend is quite bloated now, where every single Vulkan handle basically has its own class now. The plan is to just merge them together in a way that still makes sense, whilst removing a ton of the bloat

The ECS is horribly slow compared to other libraries. Once it's optimised to a more acceptable speed, I will also change the rendering backend to use the ECS instead of the current setup with pointers in vectors.

Add multithreaded rendering/command buffer recording for speed

I didn't understand the difference between them, but now I do and realized that most functions need them

Pretty self explanatory and simple stress test. I'll check how many of the same (Persona 3 FEMC) 3d Models, all with different materials, it will take to bring the average FPS down to 50. Test will be performed on a Windows system with RenderDoc.

Vulkan throws a validation error every frame, and nothing renders on screen

This requires a engine-wide event system based on one single huge singleton, which is why this will take a while to get done

In the new update, image views have now been separated from the image and are now somewhat standalone objects. This may not be the best way to implement this, since it could well be that a bit of coupling is needed, but since it works for now, I'll leave it be.

The mesh, renderer and pipeline have some circular inclusion problems, so I had to separate the vertex struct and the mesh class, which doesn't make any sense. It's not anything too bad, but it would still look better the other way

The asset manager currently runs on SDL, which is not optimal as the basically useless logging window fills more than half of the screen. It would be nice if there was a preview of the 3d model or texture instead.

In the Mesh and Framebuffer classes is a big problem: parameters of pointers and normal variables passed in as function parameters go corrupt when the function is exited because of local variables or stuff like that. It was fixed in the framebuffer class with hard coding, but that is just a temporary solution, and everything breaks down in the mesh class

This is a pretty important feature, but I personally don't see the use of global transformations in the alpha phase of the Engine, but it will be implemented down the line

As it stands right now, the pipeline base builder class/function reassigns the flag for a DescriptorSystem::PoolBuilder every time if loops though its bindings.

Marked with a @todo comment.

Also pretty simple: Create an array of lyra::MeshRenders with the same Model (Persona 3 FEMC) and check how many of them it takes to bring the framer rate down to 50 FPS.