RieEngine 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.
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.
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
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/
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.
Current status: Giving QtQuick/QML another try, to see if that has better support for the kind of composable UI elements and model/view delegates I'm looking for.
Really hope I can move on to gameplay in a not too distant future, or at least rendering code, but the foundation must stand first...
8Bit | 
| 🍶🦊@tracefree I always expected it like this: One axis - easy. Two axes - also easy. Grab all three axes - completely random - never where the user expects it - may as well not be possible - less pain that way.
@memoriesin8bit Well one axis is predictable from the user perspective, but you still have to decide how to deal with the placement with the mouse at arbitrary positions, and whatever you choose probably involves more math than you'd expect. I have the suspicion that every 3D editor handles it differently. Not really something you notice as a user though
@memoriesin8bit I think three axes free grab is usually done by keeping the object at a fixed distance from the camera and otherwise moving it on the 2D plane defined that way? But yeah that feels really random, might as well not exist
@tracefree Oh so you mean the user selects the X axis which - in the current view perspective runs from center of the screen towards top/left and into screen where the user just moves the mouse up?
@memoriesin8bit Yeah, you move the mouse and some part of the direction you move it in is parallel to the axis but not fully. So how do you map that action to a concrete movement of the gizmo? I've tried three methods so far, all valid (okay the first one felt like trash but the other two would probably be fine), but I think only now do I understand what I'd actually like it to behave so a fourth time hopefully will be the charm
@tracefree Yeah it's an interesting problem and hadn't I made Marble Game from a FPS-VR idea I would have encountered it myself by now.
I remember in my first game I had a laser beam I wanted to emit a sound along its entire length. But sound emitter in Unity is spherical. There was a simple formula that mapped the emitter on the position of the beam closest to the player. Assuming the beam is the gizmo vector and the player the mouse cursor position mapped to 3D space - that would work.
@memoriesin8bit yup that's more or less my current implemenration! Mouse cursor position does not correspond to a single 3D world position (the depth isn't specified) so what I do is interpret the mouse as an infinite line just like the gizmo axis and then take the point on the axis that's closest to the mouse's ray.
@tracefree Yeah and you gotta consider the mouse being a line and the axis directions of the gizmo being a line... I am sure there's some weird math (all math is weird to me) that allows to check where these lines are the closest. Be interested to see which solution you end up with.
@memoriesin8bit Yes that's what I mean. The proof doesn't fit on the margins of this toot but basically you derive it by realizing the shortest line connecting the two lines must be at a right angle to both of them. You express this relationship with dot products being zero, writing all the equations and solving for the unknown parameter.
It works well enough but doesn't _feel_ quite like I want it to, can ket you know once I have the next iteration
@tracefree Yeah sometimes the most sound solution isn't what feels right in practical use. And just looking at how other engines feel may not be very revealing... but that's what I'd do until I get an ideal...