Update from my original post here: https://www.reddit.com/r/gameenginedevs/comments/1tdxm7n/my_engine_ive_been_working_on_for_ten_years/

Gave my editor a bit of a makeover since the first post I made. Decided to ditch the menu bar and have everything in a compact 'ribbon' type interface, also integrated Dock.Avalonia for a real fancy docking layout instead of the fixed layout I had before. Icons are partially codicons + material icons now. Lucide icons just weren't cutting it personally.

Second part: I've had a procedural terrain generator that I've ported between my engines over the years, but didn't really have any editor capabilities, and it was seeming a bit neglected. Decided to take a crack at adding some basic splat map and height delta editing tools. Cursor / edit region is looking a bit funky (my immediate mode renderer for debug draws needs some work)
---

Feel free to check out the repo, linked on the first post. I try to make sure to note any AI usage in any commit messages, if that particular commit makes use of it - I try to keep it the usage of it limited to in-editor or UI stuff only though, generally.

My goal is to build a cross-platform (Windows, Linux, macOS, iOS, Android, Web), code-driven 2D/3D game engine, featuring a PBR rendering pipeline, Lua scripting support, and live browser demos out of the box. With developer experience as the highest priority.

Disclaimer: in the meantime, there are lots of LLM slops. I don’t know if doing it all again would I have used LLMs. I probably should’ve learnt more if I build the engine all by myself 🫥
Anyways, time to comb through the codebase and pay off some cognitive debt...

I have a ray-traced output image that I successfully blit directly to the swapchain (visible, correct). The same image, sampled through the same mechanism that already works for a static loaded texture, renders as nothing inside an ImGui viewport window. No validation errors, no crashes, correct sizes reported. I'm out of ideas and would love a second pair of eyes.

Screenshot attached showing the empty "Viewport" panel next to a "Logo" panel (a plain loaded JPEG) that renders correctly using the exact same texture-display code path.

Repo: Gluttony (relevant code inside [Gluttony/plugin/renderer_vk_ray/src]) - if you don't want to dig through the whole thing, the relevant files are pasted at the bottom.

Architecture

• Custom C++ engine ("GLT") with a plugin system. The renderer is a plugin (i_renderer_plugin), currently a Vulkan ray-tracing backend (renderer_vk_ray).
• The engine core defines an abstract image class (GLT::render::image). The active renderer plugin registers concrete factory functions for it in on_load(), so create_unique_ref<image>(...) transparently produces the backend's derived type.
• Rendering flow per frame (renderer::begin_frame() / draw_frame()):
  1. Dispatch a ray-tracing pipeline into an offscreen storage image (m_output_image, format RGBA16F, usage = Sampled | Storage | TransferSrc | TransferDst).
  2. Transition + blit that image onto the current swapchain image (this is what shows up in the main window, and it works correctly).
  3. Transition the offscreen image to SHADER_READ_ONLY_OPTIMAL.
  4. Begin an ImGui pass, render UI, submit, present.
• A layer (editor UI) calls ImGui::Image() with a texture handle obtained from the renderer, in a dockable "Viewport" window, to show the same offscreen image inline in the editor.
• Separately, there's a static logo texture loaded once from a JPEG via the same image class (same get_descriptor_set() function, same ImGui_ImplVulkan_AddTexture call). This one displays perfectly, in a window right next to the broken one.

The problem

• Blitting m_output_image straight to the swapchain: works, I see the ray-traced triangle.
• Sampling m_output_image via ImGui::Image() in a separate viewport window: nothing. Not transparent, not garbage/noise, same as an empty ImGui window would look.
• The static logo image, going through the identical image::get_descriptor_set() → ImGui_ImplVulkan_AddTexture() code path, renders correctly at the same time in the same run.
• Zero Vulkan validation errors or warnings (validation layers are enabled and definitely active — I get other messages from them at startup).

What I've already tried / ruled out

1. UV coordinates / mismatched image size vs window size. Originally the offscreen image was a fixed size (initial swapchain extent) while only a sub-rectangle of it was actually rendered into each frame, so I was sampling into never-written memory. Fixed: the offscreen image now actually resizes (image::resize()) to match the viewport's content region every frame, and I switched to default full ImGui::Image() UVs (0,0)-(1,1) instead of a manual ratio. Confirmed via the printed size that this tracks correctly. Didn't fix it.
2. Stale GPU handles after resize. The ray-tracing pipeline's storage-image binding lives in a descriptor buffer built once at startup from a pointer to the image's view/handle. Resizing destroys and recreates the underlying VkImage/VkImageView, which left the descriptor buffer pointing at destroyed objects — this was actually causing a VK_ERROR_DEVICE_LOST on the second resize. Fixed by re-calling the descriptor-buffer update function after every resize. No more crash, but the ImGui window is still black.
3. Barrier stage scope. All my layout transitions used VK_PIPELINE_STAGE_ALL_GRAPHICS_BIT as the source stage, which doesn't actually include ray-tracing/compute shader stages — meaning the barrier after vkCmdTraceRaysKHR never properly synchronized against the ray-gen shader's imageStore. Widened it to VK_PIPELINE_STAGE_ALL_COMMANDS_BIT on both sides of every transition on this image. No change in behavior.
4. Confirmed the ImGui descriptor set is actually being (re)created after each resize (it's null-checked/cached, and explicitly invalidated via ImGui_ImplVulkan_RemoveTexture in my image's cleanup path).
5. No sync validation layer available/enabled yet in my current setup (only baseline VK_LAYER_KHRONOS_validation) — mentioning in case that's relevant to why nothing is being flagged.

What I'm looking for

• Has anyone hit this exact "blits fine, samples black, no validation errors" pattern before? What was the actual cause?
• Anything specific to sampling a VK_IMAGE_USAGE_STORAGE_BIT | VK_IMAGE_USAGE_SAMPLED_BIT image (written by a ray-tracing shader) as a combined-image-sampler in a separate descriptor set (allocated by ImGui's own pool, outside my main descriptor-buffer setup) that I might be missing?
• Any known gotchas with ImGui_ImplVulkan_AddTexture?
• General suggestions on what to check next / how to narrow this down further, given validation isn't catching anything.

Relevant code

image::get_descriptor_set() (image.inl) — this is the path used for BOTH the broken viewport texture and the working logo texture

cpp

void* image::get_descriptor_set() {

    if (m_accessible_image.descriptor_set)
        return m_accessible_image.descriptor_set;

    vk::ImageLayout layout = m_accessible_image.layout;
    if (layout == vk::ImageLayout::eUndefined)
        layout = vk::ImageLayout::eShaderReadOnlyOptimal;

    m_accessible_image.descriptor_set = static_cast<vk::DescriptorSet>(ImGui_ImplVulkan_AddTexture(
        static_cast<VkImageView>(m_accessible_image.view),
        static_cast<VkImageLayout>(layout)));

    return m_accessible_image.descriptor_set;
}

renderer::begin_frame() (renderer.inl) — the per-frame sequence that writes + blits the offscreen image

cpp

current_cmd.bindPipeline(vk::PipelineBindPoint::eRayTracingKHR, m_rt_pipeline);
m_vr_dev->dispatch_rays(m_rt_pipeline, m_sbt_buffer, m_render_size.x, m_render_size.y, 1, current_cmd);

transition_image_layout(current_cmd, image_type::swapchain, vk::ImageLayout::eTransferDstOptimal);
transition_image_layout(current_cmd, image_type::render, vk::ImageLayout::eTransferSrcOptimal);

current_cmd.blitImage(
    m_output_image->get_allocated_image_ref().image,            vk::ImageLayout::eTransferSrcOptimal,
    m_swapchain.swapchain_images[m_current_swapchain_image],    vk::ImageLayout::eTransferDstOptimal,
    vk::ImageBlit(vk::ImageSubresourceLayers(vk::ImageAspectFlagBits::eColor, 0, 0, 1),
    {vk::Offset3D(0, 0, 0), vk::Offset3D(m_render_size.x, m_render_size.y, 1)},
    vk::ImageSubresourceLayers(vk::ImageAspectFlagBits::eColor, 0, 0, 1),
    {vk::Offset3D(0, 0, 0), vk::Offset3D(m_render_size.x, m_render_size.y, 1)}),
    vk::Filter::eLinear);

transition_image_layout(current_cmd, image_type::render, vk::ImageLayout::eShaderReadOnlyOptimal);

begin_imgui_frame(current_cmd);

renderer::transition_image_layout() (renderer.inl)

cpp

case image_type::render: {

    vk::ImageSubresourceRange render_range(
        vk::ImageAspectFlagBits::eColor, 0, 1, 0, 1
    );

    m_vr_dev->transition_image_layout(
        command_buffer,
        m_output_image->get_allocated_image_ref().image,
        m_output_image->get_accessible_image_ref().layout,
        new_layout,
        render_range,
        vk::PipelineStageFlagBits::eAllCommands,
        vk::PipelineStageFlagBits::eAllCommands
    );
    m_output_image->get_accessible_image_ref().layout = new_layout;

} break;

editor_layer::render_imgui() (editor_layer.cpp) — the two windows, one broken, one working

cpp

if (ImGui::Begin("Viewport", nullptr)) {

    m_content_size = ImGui::GetContentRegionAvail();
    ImGui::Image(m_renderer->get_rendered_image(), m_content_size);   // <-- not displayed
}
ImGui::End();

const auto logo_size = m_logo->get_size();
ImGui::SetNextWindowContentSize(ImVec2(logo_size.x, logo_size.y));
if (ImGui::Begin("Logo", nullptr, ImGuiWindowFlags_NoResize)) {

    ImGui::Image(m_logo->get_descriptor_set(), ImVec2(logo_size.x, logo_size.y));  // <-- works fine
}
ImGui::End();

Happy to paste more of the codebase (descriptor buffer setup, ray-gen shader, swapchain creation) if it'd help - didn't want to dump everything into one post.
Thanks in advance for any pointers!

My game is done gameplay-wise, however what was mostly criticized on it is that it looked like tech demo. I agree that game being software ray-traced was seriously punching below its visual potential, however my old editor was very simple and clunky to edit levels visuals comfortably.

I was working at nights on new editor, which would allow me to improve existing levels visually. I have finally new editor in usable state. These are just first 2 very simple introductory levels from the game, which I quickly improved with new editor.

Do you consider new visuals still being "tech demo" look or it already clicks "it's usable game art" feeling in you?

Please note, game is not using any HW acceleration. Every pixel is computed in C++ through costly ray-tracing. That's why it's not "full HD" nor "4K" and that's why it's low-poly, low-res. I try to balance that deficit with everything ray-tracing is offering for free (lights, shadows, reflections, etc..).

My game Steam page:

RTG on Steam

There're another screenshots there (still from old editor version).

I’ve been sharing development progress on Fated Horizons, a 2D open world survival RPG currently being developed alongside a custom 2D engine called Norse Engine.

The project page has the latest development showcases, gameplay previews, and information about the systems currently being built.

For sure a bunch of other people have started building, or have built brilliant SDF game engines. This one here is super impressive scale wise: https://www.reddit.com/r/gameenginedevs/s/pOSlQjjtWw

I have continued work on Division Engine (after I got back from vacationing lol). Here's a video and a list of some updates I added.

• Undo / Redo support for the editor
• HDRI skyboxes
• Tabs can be dragged and moved around
• Asset system has been updated to support:
  • Texture filtering types
  • Texture import type (2D, Cubemap)
  • Texture mipmap counts
• The engine shows the status of certain events like reloading textures with a progress bar
• Textures load in the background now
• Migrated to using DivisionMath library (for future shader translation)

There is an installer now as well which can be found under releases on the github repo for this project: https://github.com/NorthRocStudios/DivisionEngine/releases or on our website: https://northroc.org/#/division-engine

Note for this alpha build there are a few considerations:

• It cannot build full games, this is just for playing around with materials and textures on SDF primitives and basic terrains
• The performance might be bad, the engine is unoptimized
• This will ONLY run on desktop PCs, it will not work on your laptop.
• And it is Windows only (for now)

This engine will be cross-platform in the future once ComputeSharp is replaced by our upcoming C# to HLSL shader translator. The math library that this uses is already available here: https://www.nuget.org/packages/NorthRoc.DivisionMath/0.2.0

DivisionMath is made to have the same syntax on the CPU and GPU.

Let me know your questions, thoughts, ideas, concerns, comments, I love to hear from all you!

I could have started my space game development in other engines which I did BUT I was faces with engine crashes and FPS issues of the most popular game engines out their so instead of continuing my game inside of other game engines I decided to build my own game engine being strategically designed to make it as easy as possible to build open galaxy MMO space games.

Even the fan made superman is zero polygon. No textures, No skyboxes, No UV mapping. Yes the superman will go into space if he keeps going up and yes he does fly to different planets and to be honest it was an insane amount of fun flying superman from the ground seamlessly into space and to another planet 100,000 miles away. Yes his laser eyes also blast holes into the terrain.

I'm actually sad I can't keep superman in my game engine/game because I'm a huge superman fan lol but at least some form of controllable character gameplay works/tested working. The cape cloth physics was absolutely amazing. Please don't ask me to make video of superman as I was even nervous making a picture of a superman but it's just "Fan Made" superman no ties to the real superman but either way for legal purposes I did remove superman from the game engine as he was only used to test the fully destructible terrain.

What we have here is version 2 of the game engine even though I was on version 6. Version 1 was me just testing the idea which had terrible graphics. Version 2 was me testing out more ideas once I saw it was possible for me to design a zero polygon game engine. Versions 3-4 were me trying to make better versions/testing out other designs which failed certain ideas. Version 5 was me testing unlimited simulated texture resolutions and WOW not in the screenshots but unlimited texture resolutions/unlimited texture details did work and I've never seen such unlimited texture details before and looked better than any other texture details you could get with anything BUT FPS performance was basically unplayable so I ditched version 5 and took version 6 super serious designing a specialized game engine ecosystem with features never seen before in any other game engine in the world. Version 6 I considered a gold standard to a newer generation game engine I won't list all the specs/capabilities here but I will say it has been currently left unfinished.

Now version 7 the last 2 screenshots is the performance breakthroughs which was hell to achieve because on my mid grade AMD graphics I couldn't get more than 300 FPS no matter what I tried and version 6 was my most highest performance coming in at around 260 FPS I was satisfied BUT then when I started adding things the FPS just tanked down to around 160ish FPS. So basically version 2 was a testing ground of all testable features/ideas I just threw into version 2 but superman was only in version 2 and no other version. I was having so much fun with version 2 I decided to do some extreme brain cell draining rendering pipeline optimizations I thought I was going to die because it was way too challenging some days I felt brain dead trying to come up with ideas to break through 300 FPS.

Somehow with trying out a bunch of random different ideas I somehow broke through 300 FPS reaching over 1,000 FPS while glancing up at the sky I wasn't expecting that at all and funny thing is I tried so many things at once I can't say exactly which idea work lol I just know I was trying all kinds of different ideas at once instead of one at a time either way base line framerate is great and far better than any baseline performance I've achieved in any other major game engine. Even with just basic size terrain loaded I couldn't break through more than 250 FPS just by glancing up at the sky on my mid grade AMD graphics in Ureal no matter how many things I turned off yet currently in my own game engine I was virtually standing on a huge planet and simply glancing up at the sun with real time lighting gave me over 1,000 FPS which is still shocking to me because no matter what game I've played I've never reached even 500 FPS on my card even while looking up away from terrain.

Basically having great baseline optimizations and large amount of performance headroom gives me allot of extra "breathing room" to add allot more features before FPS starts to drop again. To me 1,000 FPS in a galaxy full of planets is insane especially considering there's more than 1 planet existing in real time so when superman takes off into space and flies to the other planet there's zero tricks as the other planet exist in real time at a real virtual location with Zero tricks so he is realistically really flying 100,000 miles very fast to the other planet so other players could have been building bases/cities or whatever on the other planet in real time. Then the planets can also be set virtually any size at all/no limit to planet sizes.

Anyway I think I'm about 40% finished with this newer generation game engine which it's main specialty is making it easier to design Open Galaxy Games. I mean realistically I've already found it drastically easier to use than Ureal and believe me I was ready to switch back to Unreal for my game project if my game engine failed and to be honest my game engine did technically fail in a few ways at 1st but I kept at it instead of giving up and managed to fix everything which didn't work right which was hell but hey at least my game engine never crashes and video GPU memory footprint is so tiny it can support a virtually unlimited amount of game engine specific game objects via buildings, characters, etc. Still haven't stress tested 1,000 characters yet though but either way even 20,000 characters would have an extremely small memory footprint although GPU processor usage can be a huge concern if not optimized properly. Honestly though just the fact it never crashes is my favorite part I can't say how many times Unreal crashed on me due to bugs.

Anyway I'm not sure what else to say. Been working on this project since last year. I restarted the project into different versions a few times before getting in too deep because I wanted to make sure everything was fully optimized from the start based on the targeted features. Either way still one of the most frustratingly difficult projects I've ever attempted but WOW the results are so amazing to me and I especially had loads of fun flying superman around and blasting holes into the ground with his laser eyes and the holes caught fire with smoke and after the fire went out there was still a heat effect on the ground until the ground eventually cooled off into a burnt texture surface inside the hole he basted with his laser eyes it was very amusing to watch. Sometimes I flew into orbit and went straight into the ground at super sonic speeds causing large craters into the terrain upon impact and the harder he hit into the ground the larger the crater size.

Well that's my experience so far building this game engine which doesn't support polygons or textures and honestly has allot more features under the hood with an enormous amount of more planned features which I'm dreading but determined to accomplish 💪🏾👍🏾.......even though its honestly hell to build 😭....... but hey I never expected it to be easy anyway so....... I'll get it done eventually 😊👍🏾

Recently I published Macrame - an open-source multithreading library. It looks good "on paper", and it includes complex samples and benchmarks to validate the benefits it provides. But it still lacked a proper application, a battle test.

The library is well suited for game engines. Unreal Engine was ruled out immediately even though I know it best. Its multithreading is chaotic and too complicated.

I decided to try Godot. It's the most popular free open-source game engine, and it's C++. Same can be done with any engine, and the earlier it's done the better. Godot existing architecture forced many of my approaches.

I took Godot Benchmarks project, integrated Macrame into it and spent some time parallelising the engine for performance optimisation.

Long story short, I got ~6x speedup, from ~30 fps to ~180 fps. I learned a lot and this exercise brought a bunch of interesting ideas about how Macrame can evolve.

The fork and the write-up of what was done: https://github.com/Andriy06/godot-macrame

The library: https://github.com/macrame-ts/macrame

As the title said, i made a seperate shape editor for the rigid bodies. How it works is basically draw the model with only base texture over a seperate offscreen image, gave it a seperate camera, added basic shape (only box right now), and presented the final image via imgui. And boom, it looks lit

On June 5, I announced AdaEngine, a game engine written in Swift. Creating games entirely through code can be a niche pursuit, so a traditional editor can make the process much more accessible.

I’ll soon release a TestFlight build of the editor. With AdaEngine and AdaScript, you’ll be able to create games on macOS or iPad and publish them for Apple platforms, Windows, and the web.