Current design decisions for my game engine:
Uncategorized
85
Posts
1
Posters
0
Views
-
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
-
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
Hmm I wonder if it's worth checking out Qt as well as an option for editor GUI... it seems like a heavy dependency but it might be more suited for what I want to do. ImGui is great for in-game debug UI but is not really meant to be used for a full application
-
Hmm I wonder if it's worth checking out Qt as well as an option for editor GUI... it seems like a heavy dependency but it might be more suited for what I want to do. ImGui is great for in-game debug UI but is not really meant to be used for a full application
Should... should I write my own UI library? I'm gonna need one for ingame UI anyway, could do it like Godot did and make it so it's usable for an editor as well.
But I was kind of hoping my ingame UI tooling wouldn't need to be constrained by having to support regular desktop widgets and interactions, so I really should just pick a third party solution for the editor... nyeh
-
Should... should I write my own UI library? I'm gonna need one for ingame UI anyway, could do it like Godot did and make it so it's usable for an editor as well.
But I was kind of hoping my ingame UI tooling wouldn't need to be constrained by having to support regular desktop widgets and interactions, so I really should just pick a third party solution for the editor... nyeh
Ok I think I'll stop shedding the bike for now regarding editor gui and multi-window support. Just thinking about it was valuable and clarified some future requirements, but they can be implemented later. Next steps:
- Hardcode a 3D pipeline (like a cube)
- Load a gltf and render it bindlessly
- Dehardcode the pipeline -
Ok I think I'll stop shedding the bike for now regarding editor gui and multi-window support. Just thinking about it was valuable and clarified some future requirements, but they can be implemented later. Next steps:
- Hardcode a 3D pipeline (like a cube)
- Load a gltf and render it bindlessly
- Dehardcode the pipelineLast time the internal mesh data format I used was huge - it was just the vertex and index buffers dumped into a file so they could be memcopied into the GPU quickly without processing. This time I'll also add a (de)compression step, that should still be pretty fast. And use meshoptimizer during the import step.
-
Last time the internal mesh data format I used was huge - it was just the vertex and index buffers dumped into a file so they could be memcopied into the GPU quickly without processing. This time I'll also add a (de)compression step, that should still be pretty fast. And use meshoptimizer during the import step.
ok forget hardcoding a cube mesh in the shader, going straight for glTF model loading. I can copy paste parts of that from the previous iteration of the engine, while improving it at the same time.
Gli ultimi otto messaggi ricevuti dalla Federazione
-
Che poi, spacciano per Made in Italy ciò che non lo è, ma il vero Made in Italy costa. Gli italiani, in massa, hanno perso la capacità di capire la qualità, quindi vanno di schifezze a prezzi bassissimi. Il Casentino ti dura una vita ma costa. Quando avranno capito che il low cost non esiste perché qualcuno il prezzo lo paga, la filiera italiana sarà morta e sepolta. Amen.
-
@Linkshaender
che meraviglia!
buonanotte Armin 🌌
-
•
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.
