The-Forge VS ImGui.NET

Oh, I forgot a few major ones:

https://github.com/ConfettiFX/The-Forge was used in No Man's Sky, Hades and Starfield.

https://github.com/jrouwe/JoltPhysics is the physics engine in Horizon Forbidden West.

To my understanding, every source I've read says that this should cause issues, but in practice it doesn't. What gives? Did I miss something? Here are multiple examples using the latter approach.

This is a toy project that I've been working on for the past few months. Essentially, I've rewritten all the rendering code for the engine using BGFX. This means that all the fixed function OpenGL 1.2 code has been removed from the engine. BGFX supports OpenGL 3.3 and DirectX11, but there are still some rendering artifacts with DirectX11, so the engine still uses OpenGL when running on Windows. I've been considering switching to The Forge (https://github.com/ConfettiFX/The-Forge) if I want to have more control over the rendering pipeline. However, this is a complex topic with significant implications for the codebase. I've already done the hard work of eliminating clumsy abstractions in the engine and simplifying the render pipeline, so it's just a matter of deciding what direction I want to take.

The-Forge might fit:

So, I'm not sure if it is widely known, that Starfield is going to be running on a lot of "The Forge." The creators of The Forge says it was added to Creation Kit in 2019. This will open a LOT of new systems for Bethesda games.

Now I'm trying to integrate ImGui into the engine. One solution I found was using this but as far as I can tell it locks you into using OpenGL which is something I would like to avoid as one of the main selling points of SDL2 for me is it's abstraction over the rendering backend.

In additiona to imgui wrapper which works great with NativeAOT, only slight nudge and you have 10Mb executable. With all deps it's 13Mb. Also there Avalonia mentioned in sibling message which work great and in 11.0-preview5 probably would not need any additional configuraiton. In case if OP is have soft spot for web tech, he can use photino.Blazor which also with slight modifications would simply works and produce 27Mb executable.

Imgui gets rendered using ImguiRenderer provided here in the example: https://github.com/mellinoe/ImGui.NET/tree/master/src/ImGui.NET.SampleProgram.XNA

I'm converting rlImGui from C++ to C# so I can use it with ImGui.NET and Raylib-cs but I'm getting stuck at a couple places. I don't know how to convert line 331 to C# since in ImGui.NET cmd.UserCallback is an IntPtr and not something I can call. I did a quick google search and you can use the Marshal library to convert it to a callable delegate but I think you need to also have the delegate known to do that. There's also line 82 but that is specific to Raylib. The function it calls does not seem to be included in Raylib-cs. Also, rlImGui keeps using a Texture type but that is not defined in Raylib-cs or ImGui.NET. I assume I can substitute it with Texture2D from Raylib-cs but I'm not to the point in porting to see if Texture2D has the necessary fields/properties/methods.

ImGui.NET 1.87.3 (using the example implementation)

If you use this example implementation for XNA/MonoGame, you can just use ImGuiRenderer.BindTexture() which returns an IntPtr.

The only thing I could really think of is something like ImGui for C# (https://github.com/mellinoe/ImGui.NET) but I've never used it. It's going to give you some simple wrappers around ImGui (https://github.com/ocornut/imgui) but even this is going to lock you into the UI framework -- you can't just "draw a rectangle" per se and use it as a "control." Do note however this is an "immediate mode" GUI which is different from how most general desktop windowing systems work in "retained mode" (which are typically event driven, which saves on computing power to not draw the same stuff over and over).