Post B6AJhlISv8Z73Wln3Q by tracefree@mastodon.gamedev.place
(DIR) More posts by tracefree@mastodon.gamedev.place
(DIR) Post #AwkwbNDkRUeQ94zTea by tracefree@mastodon.gamedev.place
1 likes, 0 repeats
Current design decisions for my game engine:- NOT a general purpose engine, it'll be tailored to the kind of games I want to make- Open source- C++23- Vulkan 1.3- SDL3 for windowing, input, filesystem interfacing, possibly audio- Slang as shader programming language- Jolt physics- Split into core engine library, game application, and editor application- Dear ImGui for the editor UI- Maybe Luau for gameplay scripting?- Powerful and accessible modding possibilities
(DIR) Post #B6AJhiXbAPt6VapKj2 by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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.
(DIR) Post #B6AJhir5zvU3U3wu7E by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
"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.
(DIR) Post #B6AJhj732cFCHXPdyq by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
(yes this is 100% because I recently read the book Data Oriented Design)
(DIR) Post #B6AJhjKWEX1GxJiOye by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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.
(DIR) Post #B6AJhjZ3MUe5gOW0dE by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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.
(DIR) Post #B6AJhjl6dgHqHm9dQ0 by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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.
(DIR) Post #B6AJhjyvoHLUyecfy4 by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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.
(DIR) Post #B6AJhkC31VpzdKl9Pc by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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
(DIR) Post #B6AJhkKuUYvW4ouEE4 by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
successfully did a math. years of education with vectors have not been in vainturns out in the end I don't actually like what the algorithm does but at least it did the bad thing correctly
(DIR) Post #B6AJhkXfj78QiOsQ7M by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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
(DIR) Post #B6AJhkl8v1uVOBBB7A by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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)
(DIR) Post #B6AJhkwqDXGfySeWLg by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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
(DIR) Post #B6AJhl8BXMLGXdxa1w by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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.
(DIR) Post #B6AJhlISv8Z73Wln3Q by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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
(DIR) Post #B6AJhlSOKEVNYJPiWe by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
#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/
(DIR) Post #B6AJhle5cjrY8at3lA by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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)
(DIR) Post #B6AJhltKi43Wts1EWG by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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.
(DIR) Post #B6AJhm2Y9nQdMSKasy by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
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...
(DIR) Post #B6AJhmC7aD5Jq8oEnw by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Quick (pun intended) status update: I'm halfway through rewriting the editor, moving away from Qt widgets and to the QtQuick / QML framework. Both technologies have pros and cons - initially I had chosen Widgets because unlike QML it has an advanced docking framework. But I since learned widgets are kinda rigid, and the hacks I'd need aren't performance friendly since widgets are drawn on the CPU. QML is more flexible but has its own challenges.
(DIR) Post #B6AJhmRMfXHIbPwPZ2 by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Previously to show a 3D view of my own engine inside a Qt application I embedded the whole window inside a subwindow widget. This worked, but:- requires X11/XWayland- No way for Qt to detect key events for shortcuts while the mouse hovers over the 3D view because that's technically an SDL windowFor QtQuick I made a custom QML element that provides a Vulkan texture, importing the image memory from the engine.
(DIR) Post #B6AJhmfXoocXJOZjfM by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Now the whole window belongs to Qt and it can show 3D viewports. To get input events to the engine I now have to convert Qt events to SDL events and manually push them to the engine. Worth it though, this seems like the right approach overall.
(DIR) Post #B6AJhmsJ3MpRwyXvYe by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Currently working on the scene tree dock. Tree views looked nice out of the box with the QTreeView widget, while in QML they are more basic. _But_ QML provides more tools to style all elememts. Most importantly it has a DelegateChooser element that dynamically chooses the right delegate (representation of an element) depending on the data type, I think QtWidgets had nothing like that.Overall I think it's possible to do most things either way, but QML seems to fit my needs better after all
(DIR) Post #B6AJhn9g0miuoqfndI by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
For the docking system: Gonna have to try and roll my own now in QML, there aren't any libraries for it. But I'm starting to get the hang of QML now and it shouldn't be _too_ hard.
(DIR) Post #B6AJhnOZ7QdJZ1dgq8 by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Seeing the light at the end of the CRUD tunnel, shouldn't be too much longer until the editor (rewritten with QML) is usable for very basic tasks.As a treat I took a break from that and added a rotation gizmo. Still part of the editor but at least it involved writing a shader - feels like ages I got to do that!First iteration is kinda broken still because of course anything involving rotation math needs a couple of revisions
(DIR) Post #B6AJhnbKLyqECbbsjQ by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
The frontend reached a critical milestone, you can now add/delete nodes, move and rotate them, add arbitrary components, and edit the component properties! It's technically possible to use this as a level editor now, with Scrolls-like modding support!Held together by duct tape and hacks and it only works partially for some reason, but the important part is it exists and can be iteratively improved.
(DIR) Post #B6AJhnn1eUCOmt5Dxw by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Current state of the editor: It's tedious but you can spawn, configure, and place objects freely. The scene can be saved and then loaded in the game :)#ScreenshotSaturday
(DIR) Post #B6AJhnwF6DZVFTOaKe by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
I think the next steps will be to fix some stuff that is broken and make the editor more usable and convenient overall. After that... finally time for an animation system?
(DIR) Post #B6AJho9MJS3zu9X3mC by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Today's progress: Fixed the rotation gizmo, it now actually works the way you'd expect, plus you can set the color of point lights from the editor now.
(DIR) Post #B6AJhoIZlBR6MjqQ8u by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Engine Update: Objects can now have their position, rotation, and scale set from text fields in the inspector panel which also update when the obect is transformed via the gizmo in the viewport.Next up: duplicate, cut, paste nodes in the scene tree, then a simple asset browser to click and drag objects into the scene.Also I should go outside, it's super nice today
(DIR) Post #B6AJhoTD7dwWtiouie by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Good news is cut, copy, paste is now implemented :DBad news is it's again nice outside today so I must take a break to enjoy the weather before working on the asset browser feature ;_;
(DIR) Post #B6AJhodUVQANPbd7k8 by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Pretty soon I should finally be at a place where I get to work on graphics again. Skeletal animation will be the first, though that'll also involve lots of editor tooling. Text rendering and basic in-game UI should probably come after that. Really looking forward to tackling lighting and playing around with raytracing eventually :)
(DIR) Post #B6AJhoo7rsfnwabcJs by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Am outside touching grass, but as a compromise I'm reading a book on game animation
(DIR) Post #B6AJhoylELBETZa6tc by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Starting to feel like you could make something with this
(DIR) Post #B6AJhp7GihzAtxYu9o by tracefree@mastodon.gamedev.place
0 likes, 0 repeats
Not much time to do development this weekend. What should I spend it on? I'll probably tackle the animation system (finally!) next weekend. I guess today I should be looking into the memory corruption crash I found recently 🙃 but first, grass touching
(DIR) Post #B6AJhpFQEOVXJFNPrk by tracefree@mastodon.gamedev.place
1 likes, 0 repeats
Couldn't reproduce the memory corruption bug anymore, so I tackled the docking system instead this weekend. Docks are now a container-like QML type and can be rearranged, combined, and detached. There's no pre-made system for this in QML but #Qt makes it relatively easy to roll your own. Very glad I made the switch away from the less flexible Qt Widgets framework.