• Fly camera (FPS like)
• Test 3D scene
• Phong Lighting
• Multiple light casters: spotlight, directional, and point light
• Mesh-Material system
• Model loading (Assimp)
• Primitives: cube, sphere, plane

Most (if not all) dependencies for ElvenEngine are available as public repositories, and therefore, can be added to the project using FetchContent CMake module.
This would allow:

• Get rid of submodules or including the source code for dependencies right away in the ElvenEngine repository
• Get rid of Windows-specific .bat script
• Allow to explicitly use a specific version of each dependency by specifying needed tag in the CMakeLists FetchContent command
• Automatically introduce cross-platform dependencies setup

This suggestion comes intially from my attempt to get ElvenEngine running on MacOS, and in that case, setting up dependencies and specifying their paths in CMake GUI was a bit of unneeded manual work.

Let me know if you have any objections about it.

P.S. - the only exception I guess would be GLAD, but it's pretty easy to include in project, as compared to other fully-featured libraries

• Asset folder path

Make fullscreen switch support.
Add toggle checkbox to imgui menu.

Brief overview

Implemented using Observer pattern without separate classes for Observer/Subject.
There is global EventManager object to transfer our events to receivers.
There is event queue that will be processed at the end on the game loop to avoid blocking events.

You can subsribe/unsubscribe to any event:
Events::Subscribe<WindowCloseEvent>(EVENT_CALLBACK(Application::OnWindowClose));
Events::Unsubscribe<WindowCloseEvent>(EVENT_CALLBACK(Application::OnWindowClose));

Where Applciation::OnWindowClose is the member function with Derived from Event parameter:
bool Application::OnWindowClose(const Events::WindowCloseEvent& e)

Benefits

• event queue;
• we don't use dependency injection, that can be turn to very deep and dangerous callstack of OnEvent function calls;
• simple subscription model using just callback function with particular Event.

Right now most of OpenGL code is called as-is:

glCreateBuffers(1, &m_id);
glNamedBufferStorage(m_id, size, nullptr, GL_DYNAMIC_STORAGE_BIT);

However, in theory, each of these calls may result in some error in the OpenGL state machine, which is not checked right now and may result in very painful debugging.

I would suggest adding a glCheck macro, like there: https://github.com/SFML/SFML/blob/master/src/SFML/Graphics/GLCheck.hpp

which calls glGetError after each call.

Which then will eventually wrap each OpenGL call:

glCheck(glCreateBuffers(1, &m_id);

For start, it may just log the error rightaway to stderr, I guess.

• integrate freetype libarary
• make Text renderer core class with capabilities:
  • LoadFont
  • RenderText

Although I am not sure on your exact plans for the project and whether 3D-based games would be the main target for the Elven, I would suggest experimenting adding a 3D Physics engine at some point of time, aside from Box2D for 2D.

And for that I would suggest: Jolt Physics which is open-source C++ physics engine with a ton of features. Initially it was created as in-house engine for Horizon: Forbidden West, which I think is a good marker too.

I have personally created simple simulations with it and enjoyed it a lot, a bit more compared to Bullet or PhysX. Aside from built-in multithreaded support, it also supports double-precision simulations and even determinstic simulations. The documentation is fine and even if something is missing - the maintainer helps you quite fast in the Discussions section.

I understand that this can be a pretty broad and complex feature, but here I am just suggesting one of possible solutions to consider in future. Feel free to share your opinion on that.

• integrate json library
• settings config save/loading.
• scene serialization

Use CRC32 to hash string to uint.

• Shader Manager (shader files loading)
• VAO, VBO, EBO API abstraction
• Shader, Texture abstraction
• orthographic camera
• 2D Renderer
  • Quad
  • Sprites
  • Quads and sprites batching
  • Circle and line

Entity, Components serialization.

Try to switch build tool to cmake using tutorial

• clang-format
• clang-tidy

• Render Target (Framebuffer)
• Render Passes based on Render Target with MSAA support
• Post Processor with blur setting
• Uniform buffer
• Cubemap

The core features for now should be:

• Components support
• ImguiGizmo
• Scene loading/saving

• vectors
• matrices
• quaternions

Add doctest or gest lib for unit testing.
Write tests for:

• math lib
• ecs

• Integrate irrKlang sound library
• Support next functionality:
  • Add;
  • Play(optional looped);
  • Pause;
  • Stop;
  • SetVolume.

Dispatch event in camera controller and call SetViewport to Renderer.

Implement thread pool with context dependencies.

Maybe integrate lightweight profiler https://github.com/bombomby/optick

Added custom commands fro cmake builds to copy needed folders and files (like assets and .cfg) to output dir.

• Entity is just integer.
• Component - structs with data and minimal logic (all logic is in systems), but logic like serialization may be exist in components.
• Generic ComponentPool
• Generic ComponentSystem
• For the case when unique Component need extra logic, that isn't covered in the ComponentSystem, then there is a BehaviorsSystem. As I've decided to avoid scripting in my engine, Behavior's system is useful for the case when scripts would be used.

I've decided to avoid scripting in my engine and BehaviorComponent with IBehavior is my replacement for the scripts.
So, I need a way to choose behavior from the list in Editor for the BehaviorComponent.

Make scene mananer and current active scene, that processes all ECS entitiesm components and systems.

• Stack-based (simple and double-ended)
• Pool allocator
• Aligned allocations
• Single-Frame and Double-Buffered Memory Allocators

• Shader Manager (shader files loading)
• Renderer API (VAO, VBO, Shader, Texture abstractions)
• Camera (orthographic, perspective)
• DSA OpenGL renderer api implementation

Investigate issue with rendering trasparent/semi-transparent objects with different z-order.
Possible solutions:
For 2D Renderer (with disabled depth testing):

• (PRIMARY OPTION) Layers system
• Just render in the correct order (sorting) according to Sprite Z position before rendering.

For 3D Renderer:

• Make next rendering order:
  • Draw all opaque objects first.
  • Sort all the transparent objects.
  • Draw all the transparent objects in sorted order
• Order independent transparency technique. Good explanation here