ImGui clarification

_N__N_
edited January 2020 in Help request

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.cpp use?

Comments

  • iarwainiarwain

    igtest.cpp is 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_Init in your init function and orxImGui_Exit in your exit function (the ones you register through orx_Execute).

    You can then all ImGui functions anywhere after that.
    What igtest.cpp is, is simply a new project created with the init command line tool in which I added both aforementioned calls.

  • _N__N_

    Thanks, I realize I can use init to generate igtest.cpp.

    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?

  • iarwainiarwain

    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++.

  • _N__N_

    Thanks for pointing to C ImGui

    I integrated my code within igtest.cpp and I get the same window items: close button and moving windows remain to be addressed.

    Note that igtest.cpp uses 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.

  • iarwainiarwain

    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?

  • _N__N_

    In /ImGuiOrx-test/imgui/examples there 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.

  • iarwainiarwain

    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.

  • _N__N_

    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?

  • iarwainiarwain

    Sure, the actual draw calls are abstracted by the orxDisplay plugin. At the moment, we have the following plugins:

    • one for desktops (Windows, Linux & OS X), that relies on OpenGL and GLFW
    • one for iOS, that relies on OpenGL ES and iOS SDK
    • one for Android, that relies on OpenGL ES and the Android SDK/NDK

    The rendering itself is abstracted in the orxRender plugin (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 orxDisplay API.

Sign In or Register to comment.