Addressing Rejection Feedback #2

1. Tooltip Descriptions

So basically the program was hard to use, and tbh, I kinda agree. So I added tooltips on known attribute names to help understand which attribute/value does what.

2. Rethinking the Tutorial

In addition, the tutorial was a bit hard to understand. To address that, I simplified the tutorial and made it easier to understand what’s going on. While the previous tutorial was changing a texture, that required the user to understand where the change texture button is, and then locate the texture itself, requiring some understanding of the program. This defeats the purpose of a tutorial.
My new and improved tutorial involves removing textures, a simplified process that can be done with a click of a button. This helps the user understand how removing the normal, for example, affects how lighting calculations are made.

Something I noticed reviewing feedback videos.

In addition, I noticed that ImGui windows are really small at first launch, requiring the user to adjust its size before doing anything. With this update, I bundled preconfigured imgui.ini files for ImGui to detect and automatically scale windows to an appropriate size.

Addressing Rejection Feedback: Fixed a minor issue related to display scaling on ImGui that may cause small interfaces on high-DPI screens, such as laptops and high-resolution displays.

The brush up update

• Changed up the style to feel more fun.
• Updated the tutorial
• Minor QoL features.

The User Friendly Update

New features

• Added scene loading/saving
• Added tutorial and documentations
• Added a output log
• Added Markdown/XML editors for both tutorial and documentation

The Templates Update

As a part of making Vibrant easier to use, I added templates.

Finished my attribute based object management. Fixed attributes by using high-level C++ objects such as std::variant. I also added tags to help determine which objects should be worked on by which system. I think I need to work on my game systems now, like physics and audio, then I’ll probably be finished with the engine phase. I might take this project and use it to make a full-blown game.

Added attribute based scenes. The program finds objects with a specified tag to work on (ex. sprite), then fetches data about the object based on the attribute’s name and data (void*). I’m not sure if it’s good or not to do so, but I guess I wanted to experiment with different ways of managing data.

Fixed frame buffer scaling. It looks more retro now.

Added z component influence on normal maps to improve user customization. The attachment below is the difference the height of the light makes, with the light at 0 being influenced the most by normals, while a larger z component is less influenced by the normal map.

I added uniform buffer objects to optimize performance. It also served as a learning opportunity for me, since this is a realm I haven’t stepped in yet. Was interesting to learn.

Made create functions for vertex array, buffer and texture creation to reduce the number of API calls and keep the codebase D.R.Y. (Don’t Repeat Yourself)

I added 2D normal maps to my engine, and tweaked the shaders a bit to better mix them together. The UI is really jank and there’s a whole lot more to go until this thing can ship. Motivation is down a bit but will keep it going.

Added basic window creation, shader loading, vertex/indices, etc. Still very early stage stuff.

Added project boilerplate (CMake, vcpkg, main.cc)