Current design decisions for my game engine:
Uncategorized
85
Posts
1
Posters
0
Views
-
I don't know yet how this will change once I add more shaders / material types though. I only have a single graphics pipeline right now, figuring out a system to expand on that will be the next big task.
Also Slang has some stuff dedicated to "bindless" but I didn't really understand it and also it seems to work without it? Might refactor the shader once I figure out the advantage of DescriptorHandle and how to use it
Anyway, possible next steps:
- Mipmaps
- Basic lighting
- Finally start cleaning up resources correctly
- Maybe look into batching the uploads of assets the GPU -
Anyway, possible next steps:
- Mipmaps
- Basic lighting
- Finally start cleaning up resources correctly
- Maybe look into batching the uploads of assets the GPUWith the combined power of albedo, normal maps, and a simple dot product I present: basic lighting
-
With the combined power of albedo, normal maps, and a simple dot product I present: basic lighting
Got a bunch of stuff in mind for where to go next (Qt based editor, copying over more systems from the old codebase, etc) but I have to try to slow down development for at least the next month to focus on other priorities
-
Got a bunch of stuff in mind for where to go next (Qt based editor, copying over more systems from the old codebase, etc) but I have to try to slow down development for at least the next month to focus on other priorities
Despite trying to put my focus elsewhere I've done some experimentation and thinking lately regarding editor UI.
I want to use Qt since it's a mature cross-platform UI framework. But it actually consists of two frameworks: QtWidgets (traditional desktop UI, software-rendered, uses procedural C++) and QtQuick (GPU rendered, mobile support, uses declarative QML and optional JavaScript and/or C++).
QtQuick seemed more "modern" so that's what I started with.
-
Despite trying to put my focus elsewhere I've done some experimentation and thinking lately regarding editor UI.
I want to use Qt since it's a mature cross-platform UI framework. But it actually consists of two frameworks: QtWidgets (traditional desktop UI, software-rendered, uses procedural C++) and QtQuick (GPU rendered, mobile support, uses declarative QML and optional JavaScript and/or C++).
QtQuick seemed more "modern" so that's what I started with.
First major task was getting a 3D viewport rendered by my engine into a Qt window. Qt is quite flexible and there were a lot of different avenues that seemed feasible for this. There were Most of them didn't work out in the end or were intended for different use cases.
What worked for me in the end was:
-
First major task was getting a 3D viewport rendered by my engine into a Qt window. Qt is quite flexible and there were a lot of different avenues that seemed feasible for this. There were Most of them didn't work out in the end or were intended for different use cases.
What worked for me in the end was:
- Render viewport to an offscreen image
- Export the memory with "vkGetMemoryFdKHR"
- In Qt, create a VkImage and import the memory that was exported from the engine
- Extend QQuickItem and QSGTextureProvider to show the VkImage on a custom QML type window -
- Render viewport to an offscreen image
- Export the memory with "vkGetMemoryFdKHR"
- In Qt, create a VkImage and import the memory that was exported from the engine
- Extend QQuickItem and QSGTextureProvider to show the VkImage on a custom QML type windowThe reason for doing it in this roundabout way is that Qt uses its own Vulkan instance and device, and you can't just directly use images in one instance that were created by another one, even if you're in the same process.
I _could_ have told Qt to just use my Vulkan context for its own rendering, and I tried it and it technically worked, but that led to all sorts of synchronization issues and crashes.
-
The reason for doing it in this roundabout way is that Qt uses its own Vulkan instance and device, and you can't just directly use images in one instance that were created by another one, even if you're in the same process.
I _could_ have told Qt to just use my Vulkan context for its own rendering, and I tried it and it technically worked, but that led to all sorts of synchronization issues and crashes.
Right now I _still_ get validation errors, but no crashes (until I close the window, probably because I do zero clean up currently :D)
So proof of concept for the most important aspect: done โ
Next up: finding Qt libraries for some advanced UI stuff I wanna use.
-
Right now I _still_ get validation errors, but no crashes (until I close the window, probably because I do zero clean up currently :D)
So proof of concept for the most important aspect: done โ
Next up: finding Qt libraries for some advanced UI stuff I wanna use.
Most importantly: docking. My vision for the engine editor is that everything is a fully configurable and detachable dock. It should be able to spread over all your monitors!
Qt has built-in docking functionality, but it's restricted to QtWidgets (i.e. not available in QtQuick) and is a bit limited.
First library I looked at was Advanced Docking System for Qt: https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System
Seemed very promising but it doesn't have (and will never get) Wayland support, so not an option :/
-
Most importantly: docking. My vision for the engine editor is that everything is a fully configurable and detachable dock. It should be able to spread over all your monitors!
Qt has built-in docking functionality, but it's restricted to QtWidgets (i.e. not available in QtQuick) and is a bit limited.
First library I looked at was Advanced Docking System for Qt: https://github.com/githubuser0xFFFF/Qt-Advanced-Docking-System
Seemed very promising but it doesn't have (and will never get) Wayland support, so not an option :/
Next most promising library: KDDockWidgets: https://github.com/KDAB/KDDockWidgets
Technically has QML support but I tried it and it doesn't seem to work well :/
The QtWidgets version of it is almost perfect, it does exactly what I want. Widgets isn't a deal breaker, I can just embed QtQuick views inside the docks (and using QML isn't _that_ important to me).
-
Next most promising library: KDDockWidgets: https://github.com/KDAB/KDDockWidgets
Technically has QML support but I tried it and it doesn't seem to work well :/
The QtWidgets version of it is almost perfect, it does exactly what I want. Widgets isn't a deal breaker, I can just embed QtQuick views inside the docks (and using QML isn't _that_ important to me).
The thing is, the license of KDDockWidgets is GPL. Not LGPL, which means that if I use it the whole engine editor must be available under GPL if I understand correctly.
My current intention is to make it MIT, but I'm still open to the idea of putting it under the (L)GPL license. But I kinda want it to be my decision, not be forced by one dependency :/
Soo I'm not sure what to do. Guess I'll try out Qt's built-in docking first. Would prefer not to make my own system...
-
The thing is, the license of KDDockWidgets is GPL. Not LGPL, which means that if I use it the whole engine editor must be available under GPL if I understand correctly.
My current intention is to make it MIT, but I'm still open to the idea of putting it under the (L)GPL license. But I kinda want it to be my decision, not be forced by one dependency :/
Soo I'm not sure what to do. Guess I'll try out Qt's built-in docking first. Would prefer not to make my own system...
The other major non-traditional UI type I need is a node/graph editor (like the one in Blender for materials / geometry nodes). I need it primarily for complex animation graphs, and I'd also like to use it for dialogue trees and maybe quest scripting.
Haven't tried it yet but QtNodes seems promising: https://github.com/paceholder/nodeeditor
It's also based on QtWidgets. Again, not a deal breaker, looks like I could embed it in QML if I wanted to.
-
The other major non-traditional UI type I need is a node/graph editor (like the one in Blender for materials / geometry nodes). I need it primarily for complex animation graphs, and I'd also like to use it for dialogue trees and maybe quest scripting.
Haven't tried it yet but QtNodes seems promising: https://github.com/paceholder/nodeeditor
It's also based on QtWidgets. Again, not a deal breaker, looks like I could embed it in QML if I wanted to.
I wish the situation was reversed - making my own node editor system seems doable and maybe even fun, while making a flexible docking solution for an existing UI framework just feels annoying...
I wonder if it would be easiest to fork "Advanced Docking System for Qt" and add Wayland support ๐ค Tbf it does seem to work under XWayland already, but I feel like if I write new software it should try to support Wayland natively, even though it's a pain...
-
I wish the situation was reversed - making my own node editor system seems doable and maybe even fun, while making a flexible docking solution for an existing UI framework just feels annoying...
I wonder if it would be easiest to fork "Advanced Docking System for Qt" and add Wayland support ๐ค Tbf it does seem to work under XWayland already, but I feel like if I write new software it should try to support Wayland natively, even though it's a pain...
Ok looks like the missing feature in Wayland which was blocking a fix for the advanced docking system has since been merged and this should be doable now. The maintainer isn't interested in Linux support but would be open to PRs.
-
Ok looks like the missing feature in Wayland which was blocking a fix for the advanced docking system has since been merged and this should be doable now. The maintainer isn't interested in Linux support but would be open to PRs.
Alright I checked out the demo of Advanced Docking System and it also does exactly what I need, under a BSD license, as long you force it to run via X11/XWayland. I think I'll just go with this for now and if I _really_ need proper Wayland support I'll look into upstreaming a fix. And maybe someone else will do it until then :D
-
Alright I checked out the demo of Advanced Docking System and it also does exactly what I need, under a BSD license, as long you force it to run via X11/XWayland. I think I'll just go with this for now and if I _really_ need proper Wayland support I'll look into upstreaming a fix. And maybe someone else will do it until then :D
I'm having Rust thoughts again. Somebody stop me please.
-
You know, if I really do end up using Qt for my game engine editor, maybe it'll land under the KDE umbrella one day ๐ค KameEngine
-
You know, if I really do end up using Qt for my game engine editor, maybe it'll land under the KDE umbrella one day ๐ค KameEngine
Quick progress update:
- Implemented prototype of an input system (more on that when the details are clearer)
- Made a simple freefly camera controller with it
- Implemented the Pool/Handle system from the HypeHype talk ( https://mastodon.gamedev.place/@tracefree/115162926709506134 ) for meshes, textures, etc
- Worked around an issue in Qt Advanced Docking System, it's now the most viable option so next step will be making a simple editor -
Quick progress update:
- Implemented prototype of an input system (more on that when the details are clearer)
- Made a simple freefly camera controller with it
- Implemented the Pool/Handle system from the HypeHype talk ( https://mastodon.gamedev.place/@tracefree/115162926709506134 ) for meshes, textures, etc
- Worked around an issue in Qt Advanced Docking System, it's now the most viable option so next step will be making a simple editorDecided not to natively support Wayland for the engine editor for the time being, just via XWayland. I made an honest effort but I already spent more time on this than I did on setting up Vulkan to draw triangles and there's just one hindrance after another. There's extensions for most of them but they're either still planned or not widely adopted yet. With X11 it's way simpler to e.g. embed a window into another window as a dockable widget.
The game itself does support Wayland though.
-
Decided not to natively support Wayland for the engine editor for the time being, just via XWayland. I made an honest effort but I already spent more time on this than I did on setting up Vulkan to draw triangles and there's just one hindrance after another. There's extensions for most of them but they're either still planned or not widely adopted yet. With X11 it's way simpler to e.g. embed a window into another window as a dockable widget.
The game itself does support Wayland though.
The good news is that I got Qt Advanced Docking System to work together with 3D viewports of my Vulkan engine just the way I had envisioned :D
So now I can finally focus more on editor features such as gizmos, scene tree editing, component inspectors, etc
Gli ultimi otto messaggi ricevuti dalla Federazione
-
โข
frugando nella scatola dei ricordi ๐พยซla Mimรฌ col Trottolaยป
mag.1991
-
@thatgiga
La perfezione โค๏ธ
-
@Otttoz ecco finalmente spiegato il famoso detto "abitare nel culo del mondo"!
-
@ibrahim46 @aral
L'Italia รจ con voi ๐๐
-
Il tutto sempre oltre Happy๐ฆ, che รจ molto oltre il "semplice" journaling...
---
Happy๐ฆ รจ il diario della felicitร che ho creato e che vorrei compilare tutti i giorni
Agevolo linkino per chi ne vuole sapere di piรน โ https://adriananselmo.it/happy-mappa-gratitudine-felicita/Per domande sono qui!
-
Nuovo "giochino": riassumere i mesi solo con sticker. Sembra tutto cosรฌ futile, eppure รจ liberatorio: un modo per dire cose serie in modo leggero.
-
Send your message now and tell #Democrats they were not elected to fold. They were elected to fight for affordable #healthcare. https://click.actionnetwork.org/ss/c/u001.qUXRBnqZ7T8nxbpAcIVwoUsWLkUMWlo_0JmZttSlm38hEpOxW5JbSk-4TcBb3ShXzaEY4mFDXqfjF9HadFrBJWV06aL4qiKvadgiYoq9dJQe9ufSsZ4HSLGFrDBzpPpSNBlb4v5Wyw0icmo6lEdQaLMwuaJvm2kb0Nt7-AvHWsSwc6XXUyQnoYGlrFW2ug52psBGKalbhvTx5Ljuv1cel5beFNKwgDRq6Uvbdcco5Tho9AuSqoS_rYsU6mO2HK8dbhXX3MlTquEK5QWQtrecoBy8Uj--ln8YpSNm5dVHoHOfprHy_60gEBCO8wBYb2DIlFCTE6RkMBQslGlToMQ5Ivnzxv3WUK-TuEz8lsvFZw7kb-igocOA7bL08K9Ok1cenB80gm5PsnK0YQHWYsT8zhDGIEtNl-6vJwFVtbR4RpsuowQ053wMrRh2dzq9tYAxkz9RZw46RLuYsx5OWUqXvZrSaU0Nz1kIfxJympwlD73jeHu141X-SfnONXvslpiQCxLJc6V0s512CKnxjjEgw5RLjCtl31p84bWhSCv3Pe5uKnVX9ozwSKlSneT4IrQ0m59CJ6zfQWjPboRfgKRWCzpPSpzPJZTo8h0UJCPtVP8cRyK5VJ7CkWSR_5V3gLO1a5s7a5H3_-uizyXKpgUHQg/4l3/Pn1lttUwRZSn7a2WkQOIDA/h2/h001.pqf0C50U2bEmjD3lQHTGHpmMxqUwKQFFu4l6rV8jTX4
-
Kaspersky researchers love attribution.
https://securelist.com/forumtroll-apt-hacking-team-dante-spyware/117851/
