Current design decisions for my game engine:
Uncategorized
85
Posts
1
Posters
0
Views
-
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 -
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, etcAlso I removed all QtQuick (Qt's more "browser-like" UI framework) dependencies for now. It seemed nice but two of the libraries I want to use are based on QtWidgets (a more traditional C++ framework) and I'd rather not mix and match unless I find a good reason for it.
This also simplifies viewports. I no longer export/import memory between two Vulkan instances and instead just embed my game's SDL window in a Qt dock widget.
-
Also I removed all QtQuick (Qt's more "browser-like" UI framework) dependencies for now. It seemed nice but two of the libraries I want to use are based on QtWidgets (a more traditional C++ framework) and I'd rather not mix and match unless I find a good reason for it.
This also simplifies viewports. I no longer export/import memory between two Vulkan instances and instead just embed my game's SDL window in a Qt dock widget.
What makes a 3D editor a 3D editor? That's right, an infinite grid!
Implemented the shader from this excellent article by @bgolus: https://bgolus.medium.com/the-best-darn-grid-shader-yet-727f9278b9d8
-
What makes a 3D editor a 3D editor? That's right, an infinite grid!
Implemented the shader from this excellent article by @bgolus: https://bgolus.medium.com/the-best-darn-grid-shader-yet-727f9278b9d8
Now with major and minor grid lines and colored x- and z- axes
-
There's this philosophy that you should be very conservative with the C++ features you use, only use those that are at least a decade old, and that ideally you'd just write C.
I'm of the philosophy that I wanna see for myself if a feature is problematic, even if I might have to suffer the consequences.
Anyway last week I learned about C++ "concepts" and over the weekend I already found a use case for them. Terrible name but cool concept!
-
There's this philosophy that you should be very conservative with the C++ features you use, only use those that are at least a decade old, and that ideally you'd just write C.
I'm of the philosophy that I wanna see for myself if a feature is problematic, even if I might have to suffer the consequences.
Anyway last week I learned about C++ "concepts" and over the weekend I already found a use case for them. Terrible name but cool concept!
In a similar vein, I tried out C++ modules in the previous iteration of the engine and learned first hand why people warn against them. No regrets though.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Certo, resta da capire perché, con questi sponsor
https://www.python.org/psf/sponsors/
abbia un budget annuale di 5 milioni di USD, perché 750 k facciano quindi tanta differenza, e perché questi li sponsorizzino malgrado non abbiano un sistema di protezione della supply-chain e dei pacchetti del repo principale.
Però è vero che se riuscirei a fare quei soldi con le donazioni dei singoli avrebbero gli stessi soldi e meno padroni.
Ricordo, quindi, che il FOSS è gratis ma molto costoso. Donate quanto potete
-
@Uilebheist ma nemmeno lo fa in allegria
-
A 19 anni ero convinto che di lì a poco sarei partito per un tour mondiale con la mia band hard rock.
A 24 rispondevo alle chiamate in un call centre.
Wat de fak is andato storto in quei fatidici 5 anni?
-
-
Viaggiatori, è quasi tutto pronto per il mio viaggio a La Gomera (isole Canarie).
Durante il viaggio cercherò di postare foto e pensieri, si Pixelfed, e sul neonato gruppo "Viaggi e Foto" su #Feddit (https://www.feddit.it/c/viaggi).
Ogni giorno scriverò qualcosa, Nun mini blog del giorno, anche sulla sezione dedicata del mio sito:
https://simoneviaggiatore.wordpress.com/la-gomera/
Restiamo in contatto! 🙂
-
La targa per Giuseppe Pinelli è stata vandalizzata per la sesta volta
È stata vandalizzata per la sesta volta la targa in ricordo di Giuseppe Pinelli, ferroviere e attivista anarchico morto il 15 dicembre 1969 nei locali della questura di Milano. La targa è posizionata in piazzale Segesta, a San Siro, non lontano dalla sua abitazione.
da https://www.milanotoday.it/politica/vandalizzata-targa-pinelli-ottobre-2025.html
Aggiungo un'altra foto, che nell'articolo non compare, di un cartello apparso questa estate "tra una vandalizzazione e l'altra" che riporto testualmente:
"Giuseppe Pinelli: assassinato e vilipeso. Il Cippo in Piazzale Segesta, in memoria di Giuseppe Pinelli, partigiano-ferroviere-anarchico, ancora una volta è stato vandalizzato per mano della topaia fascista, avvalendosi delle coperture del governo di destra.
Un governo che vuole riscrivere la storia e che utilizza il Decreto "Insicurezza" per reprimere le lotte rivendicative di lavoratori, studenti e movimenti vari.
Una legge bocciata anche dalla Corte di Cassazione, ma l'attuale governo, come già nel ventennio fascista, risponde: "Ce ne freghiamo".
-
I made a couple of points where #Linux excels over #Windows
https://youtu.be/pkvTIrKRLas
-
The Supercon 2025 Badge is Built to be Customized
For anyone who’s joined us for previous years, you’ll know that badge hacking and modification are core to the Hackaday Supercon experience. While you’re of course free to leave the badge completely stock, we encourage attendees to tear it apart, learn how it works, and (hopefully) rebuild it into something unique. There are even prizes for the best hacks.
As such, every decision about the badge’s hardware and software is made with hackability in mind. It’s why we always try to add an expansion port to the badge and, in recent years, have leaned into MicroPython to make it easier for attendees to modify the code.
But one thing that’s been largely missing in previous badges is aesthetic customization. Sure, you could strip out the firmware and write something entirely new, or hang some oddball peripheral off the side of the thing, but ultimately it still looked like the badge we gave you at the door. That’s because, at the end of the day, the badges are just PCBs. Short of designing your own enclosure (which has certainly been done), every badge looks the same. That is, until now.
This year’s badge is unique among Supercon badges because it isn’t just a PCB. It’s actually a stack-up of two PCBs! That might not sound like much of a distinction, but in this case, the front board has no electrical function — its only purpose is to hold the keyboard membrane against the dome switches on the rear PCB. The only reason we made it out of a PCB in the first place is that it was convenient and cheap at the scale we needed. But if those weren’t concerns, it could just as easily have been 3D-printed or cut out with a laser or a CNC router.
While the necessities of running two hacker cons on opposite sides of the planet within a couple of months of each other meant we needed to think at scale, attendees are free to do whatever they want between now and when they get their badges on Friday. Want to carve a front panel out of aluminum on your CNC? Awesome. Perhaps laser-cut some thin plywood and give it a nice stain for that old-school look? We love it. Want to see what that fancy multi-material 3D printer you’ve got is capable of? So do we.
Some Assembly Required
Hailing frequencies open, Captain.
Spacing between the rear and front boards should be approximately 2 mm.The area around the keyboard should be roughly PCB thickness (~1.7 mm) for optimal typing.You’ll need to provide hardware (M3 nuts/bolts work well) to attach the front panel to the badge.
Want to make the 2025 Hackaday Supercon badge your own? Just head over to the “hardware/mechanicals_and_models” directory in the badge’s GitHub repository and you’ll find STEP, DXF, and SVG versions of the front panel. We’re eager to see some wild and wonderful front panels, but there are a few things to keep in mind:If you’ve got other questions or need some assistance, leave a comment below or check in on the #badge-hacking channel in the Hackaday Discord server. See you at Supercon!
