HexaEngine
Attempting to create a port for Unity
Hello. In my autonomous tests, I found that this library is a good alternative to ImGui.Net, but I had a failed attempt to create a port of it for Unity, it seems that it uses some newer C# features, which have not yet arrived in Unity. Is there any way to downgrade or generate older code with the generator used?
Hi, why do you need to port it, like it supports netstandard2.1/2.0 that should be enough to get it running in Unity. Or do i miss something?
I have attempted something similar as well. I encountered a few issues along the way and decided to set it aside and instead continue using ImGui.NET but modifying that as needed. It would have been great though if I could have instead gotten Hexa.NET.ImGui to work.
My experiments with Hexa.NET.ImGui and Unity were performed on an M1 macBook and using Visual Studio Code. I believe that two components were needed.
- HexaGen.Runtime
- Hexa.NET.ImGui
The DLLs for these need to be targeted for netstandard2.1/2.0 (I chose 2.1) as mentioned by @JunaMeinhold
I think most of the issues I encountered were with HexGen.Runtime. The NativeLibraryLoader.Load() method needed adjustment as it tries to use libdl.so which in mycase won't resolve. Instead We need to use [DllImport("dl")] for newer macOS versions (I guess).
Another issue I came across was that HexaGen.Runtime uses several well known (predefined) paths (see GetNativeAssemblyPath()) which I don't think are compatible with how Unity works with what it calls "native plugins" (these dynamically linked libraries) and therefore has problems trying to load the cimgui shared library. I recall trying a few things before figuring that out. I think I found a workaround so that it could then resolve cimgui but at that point I suffered fatal crashes of the Unity Editor and did not want to spend additional time trying to figure out what was crashing.
I suspect this can still be made to work. But for my needs I knew I could instead update ImGui.NET and modify it for my needs. Some day I hope to revisit Hexa.NET.ImGui. Perhaps if this issue gains traction I will be able to do that, or possibly even help contribute with this effort.
I will look into it after i recover from my cold and other important irl stuff.
thanks for the help, I hadn't realized that Hexa.NET.ImGui supported netstandard 😳
I don't know much about macOS, and my testing was on Windows, and I didn't have much trouble "porting" the package I had already created using ImGui.Net, just one issue where Unity couldn't load cimgui. So I manually compiled cimgui for Win-64 and it worked.
There are still some issues with the way the package was created (to use ImGui.NET), so it will require a bit more work than just changing the namespaces, and I still think it would be a good idea to move some of the code to use direct bindings instead of overloads.
Here's the pull request if you want to see it: https://github.com/MasterSix997/UBImGui/pull/4
You can download the pre-build libs from Github actions (in this repo)
https://github.com/HexaEngine/Hexa.NET.ImGui/actions/workflows/cimgui-cmake.yml Or from here (if the artifacts already expired) https://github.com/HexaEngine/Hexa.NET.ImGui/tree/master/native
And what do you mean with "direct bindings" like my wrapper allows you access the raw C functions? The overloads are just for convince.
Yes, I downloaded the libraries already built, but for some reason Unity can't recognize them, even with the correct settings, it only worked when I built them manually.
And what I meant by direct bindings is that since I wrote the code based on ImGui.Net, I used the overloads of the native functions, for greater ease, but maybe it's better to use "direct bindings" to avoid the GC.
One more thing, I don't know if it's just on my computer, but it seems like the generated code is a bit... massive? My Rider IDE and vscode get extremely slow when the autocomplete opens just by typing "ImGui". I've never had this happen before, and it's only with this class (ImGui) ¯(°_o)/¯
Did you build cimgui in release or debug profile? (because the pre-build ones are build in release profile)
About the native overloads, they are present:
Yeah i know the generation is massive like it uses all my ram (and i have 32GB)
You could also join my discord if you want, i usually reply faster there compared to GitHub issues. (see Readme for link)