Fatal crash when running the new Lighting tests on Linux

1. Build with GCC or Clang on Ubuntu
2. Run
3. Notice the black screen that only displays ImGUI, but does not update FPS

Eventually there should be a scripting language bound to the gameplay framework that makes it easier to iterate on games.

Right now I am leaning towards Python, because I think it would fit well into our object model.

Another option is Lua, but I don't like how easily lua can break typing or change global variables.

It would be really nice to have a docker file that can build on Linux with your local changes, so that you can quickly test clang compilation and unit test suites.

The goal for this project is to use a deferred rendering pipeline. Currently out PBR and MSAA are both using forward rendering. We need to get our G-Buffer set up to use deferred rendering!

With Entt integrated and the ability to load both models and textures, we can now create a MeshRenderer component. The MeshRenderer will be POD

• Pointer to the Model that it uses
• Pointer to the Material that should be uses

We should have a pool allocator for things like the Buffer class and other graphics resources that are gonna stick around throughout the lifetime of the program

https://blog.molecular-matters.com/2012/09/17/memory-allocation-strategies-a-pool-allocator/

This will be a really nice feature to provide to people for the Gameplay framework

A good place for this to go is in the FlingEngine/Utils folder.

We need PBR and deferred rendering in the engine.

The pipeline should include point, directional, and spot lights.

See the Acid Engine for an example of this in Vulkan

We need to do this to keep stability over time, because I really don't have a ton of time to work on this engine. EnTT is ever changing (for the better) and being upgraded, and its one of the only submodules we are using that is not in our own fork.

In json.hpp and <cereal/archives/json.hpp> there are multiple warnings about unused private fields, unused member functions, etc.

We should wrap include of these into our own header so that we can disable the warnings for our builds

We should have a set of different example scenes that we can use to build some basic worlds in our engine.

This should take the form of Level files that the user can load in (there is an example of saving/loading in the SandboxGame.cpp.

Throughout this process it might be useful to provide some basic editor functionality through ImGui as we see fit (File menu, transform editors, etc)

We need to provide an extendable layer for editor utilities in the engine. Right now the ImGui setup works but is NOT extendable and only exists in the engine module. This is a known issue and we are working on getting a better solution up and running

Here is a basic layout of what we need:

• Pre-processor definition that can be set from CMake such as WITH_EDITOR
• Editor Class that has a simple draw callback for our ImGUI renderer. Allow this editor class to be set via template when the engine is created just like our Game class

The base class should provide some easy to call functions such as :

• FPS Graph
• File save/open for loading of our level files
• Component editor (such as this)
• Material viewing

If anyone thinks of other useful features then please post them here!

An extra null pointer check is not needed in functions like the following.

• Engine::Shutdown
• MeshRenderer::Release
• VulkanApp::CleanupSwapChainResources

After coming back to this project it seems that we can no longer load the world file (json) and the engine crashes when you try to. Uh oh!

We should move the level files to be binary anyway, json is way too slow

We need to separate out each feature of the engine into a modular build target. We should have "Modules" for different parts of the engine to reduce dependencies and make for a scalable compile infrastructure.

For example, no gameplay code needs to know anything about rendering, so it should be in it's own separate build module and have a separate "_API" export.

We can accomplish this with CMake I think, but I'm not an expert in CMake by any means to this may be tricky to get to a state where adding new modules is simple and easy. I basically want something conceptually similar to how Unreal handles this with the build.cs files, so that for each module can have it's own set of dependencies.

We could even go as far as to break certain modules out into their own Submodules, so that active development on something like rendering for example has no effect on development on Gameplay.

Right now the codebase uses xml style comments. These are pretty ugly and need to be updated to use a more standard style like this:

/**
* A general description of blah blah 
* 
* @param Foo bar param
* /

Right now we just read all files in right from disk and read them in with some trivial JSON parsing. We need to create an actual Fling asset type that we can add metadata to, have work with version control, and be loaded in with a database to be displayed in the editor and at runtime.

This issue is obviously pretty big and needs to be broken up into smaller tasks for tracking