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
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
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...