ImGui Renderer

[MrBrixican]

@NoelFB

Is an official ImGui renderer for Foster something that would be a good fit for this repo (I was thinking Foster.ImGui)?

I already have a functional implementation that I'd be more than happy to share/support. It even supports ImGuiBackendFlags.RendererHasVtxOffset for certain edge cases. Obviously, the renderer has a dependency on ImGui.NET, which isn't ideal from a zero-dependency standpoint but I don't have much interest in maintaining yet another ImGui wrapper (despite recent advancements).

It could optionally be a sample if you think it would fit better as one. That being said, I think that ImGui has extremely broad applications so first class support would be a great feature for this library.

[NoelFB]

Yeah I'm interested in this for sure... I am also using ImGui in a personal project and have written a lightweight wrapper for ImGuiNET which you can see here. I'm definitely interested in seeing what you're working on as well.

I'm unsure about whether it should live inside this repo or not. I like that this project is currently self-contained, so adding dependencies to external projects and pre-compiled binaries is something I'm trying to avoid. I wonder if it makes sense to make it a separate repo?

I've also been looking into the dear_bindings repo you linked to see how complicated it would be to use that over ImGuiNET but I think it would be a considerable undertaking...

[MrBrixican]

Perhaps another repo may be the best option. I agree that keeping this core codebase free of dependencies aside from the mandatory ones is a good priority to have.

However, any additional repo would probably need to reference this repo via some means. Whether that be with git submodules (optionally paired with dependabot) or NuGet dependency.

Both of those options have pros and cons and would be based on whether you want to follow the NuGet-less design philosophy of FNA or not. Personally, I think NuGet has allowed Monogame in particular to thrive in terms of third party extensions.

Regardless, that's probably a conversation for another time.

For now, I think we'd be best served by either a:

• a) Simple single file repo/gist linked by the main readme so users know that an initial solution exists
• b) Small sample with the redererer and NuGet reference to ImGui.NET so it's easily testable for any prospective users

---

My implementation is pretty similar to yours with a few key differences

• Compound all lists into just one set of vertex buffer uploads
  • I'm not sure if that's truly more performant or not, but it's a key difference between the official ImGui OpenGL and DX11 implementations.
• Manual conversion of 16-bit indices to 32-bit with ImDrawCmdPtr.VtxOffset addition
  • This is definitely a compromise since the ImGui binary that ImGui.NET uses is compiled to use 16-bit indices and vertex offset is not part of the current Foster API (at least for now).
• No support for UserCallback
  • That's a really good idea on your end.
• Different per frame io setup
  • My implementation passes a larger set of inputs to ImGui, uses events where possible, and also sends state based on Keyboard.Down().
  • I'm still not sure what to do regarding input events (Down vs Pressed/Released) due to the potential for multiple updates to be called for every render with FixedStep enabled.

I'll probably take your implementation as a base and use my input logic. I may also modify the render lists to use a single buffer update depending on what kind of benchmark results I get.

[NoelFB]

I'm going to investigate what is involved in setting up a NuGet package - I'm not against it at all.

Otherwise this makes sense to me ... I feel like for now it could almost be a simple gist, but maybe making a repo with it already setup could be nice, and just link to it from here. I'll look into doing that!

Also your implementation is nice! I think the larger sets of inputs is a good call. I also think doing a single buffer upload is a good idea, it seems nicer to do that.

[NoelFB]

I've committed a Sample project that implements this. For now it's not in the .sln as it has a dependency on ImGui.NET being in an adjacent folder to the Foster repo... I'm not sure if this is how it should be set up long term but at least it's a start!

It's also just using my version but I'm happy to tweak it / take some of your changes.

[MrBrixican]

That's great! Was actually just working on some tweaks.

Also, I'm now noticing that in your implementation ImGui calls are meant to occur completely within the Update portion of the game module. That's absolutely fine, but pretty different from most examples I've seen for Monogame/FNA.

Separating render/update has been discussed multiple times (example) in the ImGui repo and is essentially a use case that it doesn't support well at the moment. That is to say, as long as the possibility of multiple updates being called per render remains, a user essentially needs to choose whether or not they want to do ImGui calls in the render or update. Obviously, if they chose render, they will need to aggregate any input events collected in the update(s).

From a surface level, I can see separation of concerns indicating ImGui calls should be made in the render method, since they are drawing to the screen. But on the other hand, they are technically input that affects game logic, which belongs in update.

So my question to you, as someone who has worked on numerous projects, is whether you believe ImGui calls best belong in the update or render?

[NoelFB]

I missed this earlier! But yeah, honestly I'm not super sure .... I like keeping it in update as that feels like it makes sense for any input/logic to happen. Currently I basically just do everything in Update except to actually render the buffers to the screen which seems to work fine but might not be what ImGui actually wants.

[MrBrixican]

Makes sense. I think the way it's present in the sample is fine as is and agree that since it deals with input logic, update is probably an ideal place for it. There's a small risk of "wasted" imgui draw list preparation, but that should be negligible in the long run. Thanks for sharing your perspective!