Current design decisions for my game engine:
Uncategorized
85
Posts
1
Posters
0
Views
-
Also I want a preview of shaders and support hot reloading them.
In-editor code editor is out of scope, won't reinvent the wheel there and just use an actual IDE for that.
Rendering goals:
- Forward+, at least in the beginning
- Bindless
- I'm considering going all in on raytracing, and add fallback solutions for shadows etc only later
- GPU driven rendering, wanna minimize the amount of CPU to GPU communication to a minimum
- I guess I'll do PBR, at least until I have a more creative idea or find a stylization I like
- Photorealism is NOT a goal, but I do want shadows to not look awful
- Targeting medium vertex density for meshes
- 3D only (except UI) -
Rendering goals:
- Forward+, at least in the beginning
- Bindless
- I'm considering going all in on raytracing, and add fallback solutions for shadows etc only later
- GPU driven rendering, wanna minimize the amount of CPU to GPU communication to a minimum
- I guess I'll do PBR, at least until I have a more creative idea or find a stylization I like
- Photorealism is NOT a goal, but I do want shadows to not look awful
- Targeting medium vertex density for meshes
- 3D only (except UI)For input management I might take heavy inspiration from the OpenXR API. I like how it enables extreme flexibility for remapping actions by players.
Speaking of OpenXR... I know the scope is already huge but this is gonna be a lifelong project anyway. VR integration is a stretch goal (_if_ I can even get my VR headset to work properly on Linux and find a way to make it comfortable to wear)
-
For input management I might take heavy inspiration from the OpenXR API. I like how it enables extreme flexibility for remapping actions by players.
Speaking of OpenXR... I know the scope is already huge but this is gonna be a lifelong project anyway. VR integration is a stretch goal (_if_ I can even get my VR headset to work properly on Linux and find a way to make it comfortable to wear)
To be fair basic VR support should be pretty straight forward. The OpenXR runtime does most of the heavy lifting, you just need to render two images (for two eyes) and hook up the head position to the camera. The hard part is making good controls that don't nauseate people and gameplay that makes sense for VR.
-
To be fair basic VR support should be pretty straight forward. The OpenXR runtime does most of the heavy lifting, you just need to render two images (for two eyes) and hook up the head position to the camera. The hard part is making good controls that don't nauseate people and gameplay that makes sense for VR.
Regarding licensing: My thinking so far, and it may change in the future, is open source editor, open source game application (at least the parts written in C++), but the actual game data like assets, quests, levels, gameplay scripts etc. will be non-open (but allowed to be modifed and redistributed when it's for a free mod for the game)
License is currently set to MIT but there is a non-zero chance I'll go copyleft at some point. (Or even closed-source, not committing to anything yet)
-
Regarding licensing: My thinking so far, and it may change in the future, is open source editor, open source game application (at least the parts written in C++), but the actual game data like assets, quests, levels, gameplay scripts etc. will be non-open (but allowed to be modifed and redistributed when it's for a free mod for the game)
License is currently set to MIT but there is a non-zero chance I'll go copyleft at some point. (Or even closed-source, not committing to anything yet)
Ah, and I should mention the primary goal of the engine: maximum moddability. Much of what drives me here comes from playing Dark Souls and thinking "man, I really wish this were as moddable as Skyrim"
The editor I'll use to make levels and quests etc. is the same one that modders can use to extend the game. That's why it must be easy and fun to use and learn. Modding shouldn't be restricted to technical people.
-
Ah, and I should mention the primary goal of the engine: maximum moddability. Much of what drives me here comes from playing Dark Souls and thinking "man, I really wish this were as moddable as Skyrim"
The editor I'll use to make levels and quests etc. is the same one that modders can use to extend the game. That's why it must be easy and fun to use and learn. Modding shouldn't be restricted to technical people.
(this thread is brought to you by a sleepless night where I could not rest until I got up and wrote down all my hopes for the engine in a notebook. Anyway time to get back to waking reality and actually follow through)
-
(this thread is brought to you by a sleepless night where I could not rest until I got up and wrote down all my hopes for the engine in a notebook. Anyway time to get back to waking reality and actually follow through)
Ok I'm way too tired to code (or to be awake at all, really) so here's more non-goals instead. They're just as important to define as goals after all.
- No mobile support. Android GPUs work differently and supporting them has major implications for the engine architecture. Do not want to deal with all that. Best explained by this official manga by ARM: https://interactive.arm.com/story/the-arm-manga-guide-to-the-mali-gpu/page/2
- Similar story for web. Browsers are a pain to support and I don't care about them.
-
Ok I'm way too tired to code (or to be awake at all, really) so here's more non-goals instead. They're just as important to define as goals after all.
- No mobile support. Android GPUs work differently and supporting them has major implications for the engine architecture. Do not want to deal with all that. Best explained by this official manga by ARM: https://interactive.arm.com/story/the-arm-manga-guide-to-the-mali-gpu/page/2
- Similar story for web. Browsers are a pain to support and I don't care about them.
- Multiplayer: I'm actually not ruling out the possibility of it later, but I have no immediate plans for networked multiplayer support. And since adding it later is very difficult if not planned for from the beginning I will likely never do it. But who knows what rabbit holes I get sucked into in the coming years :D
-
- Multiplayer: I'm actually not ruling out the possibility of it later, but I have no immediate plans for networked multiplayer support. And since adding it later is very difficult if not planned for from the beginning I will likely never do it. But who knows what rabbit holes I get sucked into in the coming years :D
- Espresso: There are no plans for the engine to support brewing coffee of any kind, even if you manage to install it on a smart coffee machine.
(I should really go to bed now)
-
- Espresso: There are no plans for the engine to support brewing coffee of any kind, even if you manage to install it on a smart coffee machine.
(I should really go to bed now)
I had intended to roll my own logging, but I've heard enough people recommend spdlog that I'll probably use that (but with my own wrapper code around it)
-
I had intended to roll my own logging, but I've heard enough people recommend spdlog that I'll probably use that (but with my own wrapper code around it)
Also regarding embedded scripting language besides Luau I will also evaluate Angelscript, and look for more options. Requirements are:
- Fast JIT compilation
- Battle tested
- Secure sandboxing (to support modding)
- Easy integration with C++ codebase
- Static typing -
Also regarding embedded scripting language besides Luau I will also evaluate Angelscript, and look for more options. Requirements are:
- Fast JIT compilation
- Battle tested
- Secure sandboxing (to support modding)
- Easy integration with C++ codebase
- Static typingI thought about using VK_EXT_shader_object again but I did some more research and it seems the extension, which would make life easier by eliminating pipelines and making _all_ state dynamic, needs more time in the oven. It has some bugs in the drivers that support it natively, isn't guaranteed to be as performant as using pipelines, is missing some features like raytracing support, etc. So I'll stick to pipelines after all for now
-
I thought about using VK_EXT_shader_object again but I did some more research and it seems the extension, which would make life easier by eliminating pipelines and making _all_ state dynamic, needs more time in the oven. It has some bugs in the drivers that support it natively, isn't guaranteed to be as performant as using pipelines, is missing some features like raytracing support, etc. So I'll stick to pipelines after all for now
We have pixels! It's only earlier than anticipated because I hardcoded a graphics pipeline after all instead of doing abstraction first. And it was good, now I have a much better idea of how I want the abstraction to work.
Btw ImGui's docking functionality is great :D
-
We have pixels! It's only earlier than anticipated because I hardcoded a graphics pipeline after all instead of doing abstraction first. And it was good, now I have a much better idea of how I want the abstraction to work.
Btw ImGui's docking functionality is great :D
So typically, tutorials will tell you to create one Renderer class that holds everything - VkInstance, VkDevice, the graphics queue, frames-in-flight data like command buffers, semaphores, fences, swapchains etc. This is a good starting point.
Now I'm thinking about how to split all this up to support multiple windows with multiple viewports that can be rendered to. The game won't need multiple windows, but the editor does.
-
So typically, tutorials will tell you to create one Renderer class that holds everything - VkInstance, VkDevice, the graphics queue, frames-in-flight data like command buffers, semaphores, fences, swapchains etc. This is a good starting point.
Now I'm thinking about how to split all this up to support multiple windows with multiple viewports that can be rendered to. The game won't need multiple windows, but the editor does.
So, I want to support having multiple windows. #ImGui has a "multiviewport" feature for that where the ImGui context can be shared, but it's not supported under Linux with Wayland. So my only option is initializing multiple ImGui contexts and rendering them separately.
That's all fine. I'm just wondering if doing so will prevent me from doing drag-and-drop operations with ImGui across windows 🤔
-
So, I want to support having multiple windows. #ImGui has a "multiviewport" feature for that where the ImGui context can be shared, but it's not supported under Linux with Wayland. So my only option is initializing multiple ImGui contexts and rendering them separately.
That's all fine. I'm just wondering if doing so will prevent me from doing drag-and-drop operations with ImGui across windows 🤔
Guess I'll just use multiple contexts for now and not worry too much about drag and drop. I don't need it super badly to move panels from one window to another, and for simpler stuff like dragging a resource over everything _should_ be able to be handled with lower level API.
The refactor is interesting - there's different swapchains but still only one thread so using fences correctly will be fun!
-
Guess I'll just use multiple contexts for now and not worry too much about drag and drop. I don't need it super badly to move panels from one window to another, and for simpler stuff like dragging a resource over everything _should_ be able to be handled with lower level API.
The refactor is interesting - there's different swapchains but still only one thread so using fences correctly will be fun!
I guess there isn't actually a reason to give each window its own command buffer. And it's not like there's any multithreading involved or that windows would need to run at different framerates. So the window-specific data will be the surface, the swapchain, and the related release semaphore. Frames-in-flight will have one command pool/buffer each, and they'll record commands for all windows. Then each frame there's a single vkQueuePresent, handling all swapchains. Yeah.
-
I guess there isn't actually a reason to give each window its own command buffer. And it's not like there's any multithreading involved or that windows would need to run at different framerates. So the window-specific data will be the surface, the swapchain, and the related release semaphore. Frames-in-flight will have one command pool/buffer each, and they'll record commands for all windows. Then each frame there's a single vkQueuePresent, handling all swapchains. Yeah.
Wait! But one of my monitors is 60Hz while the other is 144Hz! I _do_ want windows to run at different framerates or else windows on my main monitor will be bottlenecked by the other one! Ahhhhh
-
Wait! But one of my monitors is 60Hz while the other is 144Hz! I _do_ want windows to run at different framerates or else windows on my main monitor will be bottlenecked by the other one! Ahhhhh
Ok after doing some research my preliminary conclusion is that the only way to reliably have multiple windows with independent refresh rates is to use multithreading, one render thread per window. Threads are a blind spot of mine that I've been meaning to overcome anyway, guess the time has come 🥴
-
Ok after doing some research my preliminary conclusion is that the only way to reliably have multiple windows with independent refresh rates is to use multithreading, one render thread per window. Threads are a blind spot of mine that I've been meaning to overcome anyway, guess the time has come 🥴
Once I have my game engine where every panel in the editor is detachable I'll get a third monitor to make it worth the effort
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!
