It looks like you're new here. If you want to get involved, click one of these buttons!
I'm looking at
igtest.cpp and trying to figure out how Dear ImGui fits with Orx.
The wiki points to
main .cpp which I used.
Within /ImGuiOrx/imgui/examples I find several
main .cpp versions for a variety of APIs.
Regarding the high framerate at the beginning, some OpenGL drivers go into busy loops with VSync if VSync is requested too soon after the creation of a window. To prevent this, we request VSync only half a second after the window's creation.
I realize I am using the "GLFW + OpenGL2, using legacy fixed pipeline" which may account for those behaviors.
Which APIs does Orx support and which does
igtest.cppis just that, a test. The actual imGUI wrapper lies in
orxImGui.cpp, from the same repository.
The wiki entry you're referencing is about @ainvar's first test implementation.
All you need to integrate ImGui with orx is the file
orxImGui.cpp+ ImGui itself, both can be found in https://github.com/iarwain/igtest
Then you need to call
orxImGui_Initin your init function and
orxImGui_Exitin your exit function (the ones you register through
You can then all ImGui functions anywhere after that.
igtest.cppis, is simply a new project created with the
initcommand line tool in which I added both aforementioned calls.
Thanks, I realize I can use
If I may ask to clear up one point.
Orx is written in C. To use Dear ImGui, I now compile C Orx with a C++ compiler knowing that ImGui minimizes using C++ features.
Can you think of any "pointers" and / or caveats or pitfalls when mixing C++ and C in Orx?
Note that there's a C version of Dear ImGui as well.
In any case you won't have any issues mixing C and C++, all my own projects using orx are coded in C++.
Thanks for pointing to C ImGui
I integrated my code within
igtest.cppand I get the same window items: close button and moving windows remain to be addressed.
igtest.cppuses version Dear ImGui version 1.64 vs. the current 1.75. As per ocornut as of Dec 2019 this was a 16 month old version.
I get the VSync behaviour. Demo would use GLFW + OpenGL2 API?
This only occurs for the windows I created vs. the provided demos.
I'm not ImGui expert so I don't think I can help much about your window issues, sorry, but it doesn't seem to be related to the orx integration.
As for a more recent integration, I can have a look one of those days, I've never used ImGui myself and haven't touched that integration for about a year, since I first wrote it.
I'm not sure I follow your question about GLFW/OGL2 though. What do you mean by that?
/ImGuiOrx-test/imgui/examplesthere are several API implementations, several DirectX versions, vulkan, SDL, glfw opengl 2 and 3.
The test application I'm currenly using uses glfw opengl 2.
When I give a shot at glfw opengl 3, I'll report and also see if other API have the same issue.
I was wondering on which API your integration is based.
My integration isn't based on any of those examples.
I only used the documentation I believe (it's been a while, I don't remember the details), and the integration is using orx's rendering pipeline, which isn't really directly connected to any of the underlying APIs like SDL or GLFW.
In any case, the integration itself doesn't do much, it only relays the inputs and buffers and that's about it. There's no logic behind it, so it shouldn't affect ImGUI's own behavior.
Where can I find more information about orx rendering pipeline?
I am trying to wrap my head around how orx manages to support many different graphics card.
Could you please describe your entire stack along with the libraries used if any?
Sure, the actual draw calls are abstracted by the
orxDisplayplugin. At the moment, we have the following plugins:
The rendering itself is abstracted in the
orxRenderplugin (we only have one single implementation, common to all the supported platforms), which will gather information on Viewports, Cameras and Objects before issueing draw calls using the