End of weekend progress update: Reduced >500 limes of macro code to a dozen or two :D Realized it really wasn't necessary to stuff so much code into each class when I could use templated static functions instead.

CRUD (create, read, update, delete) mostly implemented. Next up I gotta support resource inheritance (I'm sorry 😔) in the SQL backend. And vector/quaternion properties. And more kinds of relations between tables. And clean up the mess :§

Gonna be worth it though!

mmhh... limes of code...

Implemented* inheritance for the SQL data backend! Now a C++ class "Armor" can inherit from "Item" and a new SQL table with the additional fields is created, with the primary key also pointing to the table above it in the inheritance chain so you can retrieve base class fields.

*By "implemented" I of course mean it barely works and I shouldn't code after midnight

Thinking a bit about design choices for my engine. I can't and don't want to make it general and all-purpose like Godot so the scope is limited. What do I want people to be able to do with the editor?

Priority #1 is level and quest design. I want it to be a tool to easily make content / mods for my type of game. More complex tasks like shaders and gameplay code are fine to be done outside the editor or hardcoded.

Engine update: I might just try to implement my own ECS. I'm so sorry. Release date will be delayed from the original 2070 to Q4 2080.
"If you really need an ECS, why not just use entt?" I hear you ask. An excellent question. I regret to inform you that my actions are irrational and not fully under my control. Thank you for understanding.
(yes this is 100% because I recently read the book Data Oriented Design)

Installed #gram (https://gram.liten.app/) by @krig, an AI and telemetry free fork of the code editor zed, and started feeling my way back into the engine project :)

Doing some janitorial work first, setting up a repo for the sample game now so that there's something for people to actually run. Faced with the eternal question, where do I put game assets? I don't mind just checking them into git but I don't want to overwhelm Codeberg's servers with large files.

GRAM

Gram is an open source code editor with built-in support for many popular languages. Gram is an opinionated fork of the Zed code editor.

Once again an engine update after a two month break. Last time I left off at being puzzled about duplicated nodes in the scene after a major refactor. After digging through the pasta code I realized the model components were initialized multiple times. Not sure yet why, but the immediate issue was fixed by tracking whether components are initialized or not.

The database backend for scene representation is finally falling into place :D Integrated it into the actual engine and updated the editor application. You can load a scene, move nodes around or hide them, save, and the changes are reflected on the next launch. Previously scenes were defined in handwritten YAML files that could be loaded from but not saved to.

There's a million issues still under the hood but debugging will be easier (and more fun) with 3D scenes to look at.

Can't wait to post screenshots / clips again soon. Been over half a year (?!) since I had any visual progress - the SQLite backend is essential but not really exciting to look at.

Still not doing any new rendering stuff in the near future probably, but editor workflow stuff mainly.

On the plus side by the time I return to Vulkan coding the descriptor heap extension may have landed in mesa. Simplifying descriptor set management will be good

successfully did a math. years of education with vectors have not been in vain

turns out in the end I don't actually like what the algorithm does but at least it did the bad thing correctly

It's funny how some things in gamedev you never ever think about as a user are actually non-trivial problems. Like say you have a transform gizmo in a 3D editor. You click one of the arrows and drag the mouse somewhere to move it.

When the mouse remains on the axis of movement it's clear where it should end up. But what if the mouse is not exactly on the axis? You still want to move the gizmo in the general direction but confined to the axis. Where to exactly? There is no right answer

Do you project the mous position onto tge axis in screen space? Calculate the point on the axis that's closest to the ray the mouse shoots into 3D world space? A secret third thing? (that's my pick)
Ugh, realizing now how deeply cursed my thrown-together node component system is... initialization order problems, infinite loops, incorrect cleanup... back to the drawing board I guess and try to solve this for real

Update: Instead of redesigning the foundation I put more duct tape on it. Gonna try to build more on top to see where the system really breaks and learn what the requirements of a better alternative would actually be.

In other news, the SQLite based scene serialization/modding system is more or less fully integrated into the editor now. It works! You can spawn, rename, move, and delete nodes.

Next up: Show components in the inspector panel and make them editable.

Inspector now lists the types of components attached to a selected node. Next up: Figure out how to use a custom widget with its own model/view for each individual components, with specific options per type, in an idiomatic way in Qt

#Qt has a model/view system that I'd like to use for the inspector. But I want to use nested views - one for a list of components of the node, and one for the properties of each component.

Looked at how you would do that idiomatically in Qt with delegates but there seem to be a lot of headaches involved to have a full view widget as the delegate for the items of a parent list view: https://blog.ortham.net/posts/2022-01-15-qt-view-delegates/

Custom interactive list elements with Qt

It’s more difficult than you might think.

Ortham's Software Notes

Thinking of giving QtQuick another try, maybe it's easier there. Problem is I couldn't find any libraries or guides for making a docking system. Currently I use the "Advanved Docking System" library, based on widgets. A dock can contain QtQuick-based content so mixing and matching is technically possible, but then it's probably difficult to handle drag and drop actions across docks.

So my options are:
- Live with widgets
- Develop docking system for QML
- Custom GUI library (pls don't make me)

Actually, rethinking the assumption that I need nested views at all - could also display this with a tree view instead 🤔 Not really how I envisioned it but might be best to do that at least for now.