Welcome, Guest. Please login or register.
Did you miss your activation email?

Login with username, password and session length

 
Advanced search

1395286 Posts in 67250 Topics- by 60313 Members - Latest Member: alterego35

September 19, 2021, 06:18:15 PM

Need hosting? Check out Digital Ocean
(more details in this thread)
TIGSource ForumsDeveloperTechnical (Moderator: ThemsAllTook)Free ImGui library for tweaking/debug tools in C++ projects
Pages: [1]
Print
Author Topic: Free ImGui library for tweaking/debug tools in C++ projects  (Read 5542 times)
Omar
Level 0
**



View Profile WWW
« on: August 15, 2014, 12:04:25 PM »

Hello,

I have released a small portable library to easily create immediate-mode based interfaces in C++ projects.
The library output vertex-buffers that you can render yourself, so it works with any type of renderer.

  https://github.com/ocornut/imgui

Can be useful for easily tweaking parameters, building your content creation or debug tools, Etc.

The short version of how to use it is:



Some more examples,







I've personally used it on various professional or homebrew projects.
Hope it is useful to someone!

xxx
O.
« Last Edit: September 03, 2015, 05:13:49 AM by ocornut » Logged

Jaddori
Level 0
*


View Profile
« Reply #1 on: August 15, 2014, 01:22:36 PM »

This is awesome.
I always dread the GUI part of development, but using something like this seem effortless.
Kudos man.
Logged
InfiniteStateMachine
Level 10
*****



View Profile WWW
« Reply #2 on: August 15, 2014, 06:39:13 PM »

well this looks awesome. I'm definitely keeping this in my pocket. 
Logged

RandyGaul
Level 1
*

~~~


View Profile WWW
« Reply #3 on: August 16, 2014, 09:23:17 AM »

Hey I've been a fan of this project for a while now! Thanks for sharing it here and posting some information about it Smiley
Logged
InfiniteStateMachine
Level 10
*****



View Profile WWW
« Reply #4 on: August 16, 2014, 06:48:03 PM »

i've been having quite an interesting debate about immediate mode at work today. I really like a lot of arguments made in the article and I think at the very least for debugging and log purposes this is the way to go. For presentation purposes perhaps scaleform/iggy is still the way to go in regards to the freedoms it provides the ui artist.

As we discussed this though, the merits of WPF became a topic of discussion, it seems to carry a lot of pros from both worlds (state is minimal through decent data binding) but of course WPF cannot be applied to the framebuffer. The overall concept though is great.
Logged

epcc
Level 1
*


View Profile
« Reply #5 on: August 17, 2014, 05:02:48 PM »

Wow, this is just what I needed.
Thanks for sharing!
Logged

anthnich
Level 1
*



View Profile WWW
« Reply #6 on: August 19, 2014, 10:03:21 AM »

Very nice!
Logged

Turnover @ Steam
InfiniteStateMachine
Level 10
*****



View Profile WWW
« Reply #7 on: August 22, 2014, 03:04:01 PM »

I've just integrated it into a small opengl framework I'm using for prototying some stuff. It took me all of 45 mins to get it working and it works great!


I'm loving this library!
Logged

eigenbom
Level 10
*****


@eigenbom


View Profile WWW
« Reply #8 on: August 22, 2014, 03:24:09 PM »

Looks great, I may have a play soon
Logged

InfiniteStateMachine
Level 10
*****



View Profile WWW
« Reply #9 on: August 22, 2014, 10:57:55 PM »

I've just finished reading the whole book in progress related to the imgui site and I must say it's a very strong argument. I'll definitely be considering this perspective in the future.

As an aside I see that proggy is used as the default font. Tristan sits behind me at work, I must say Tristan is an amazingly talented engineer I have the up-most respect for. It's cool to see the connection between Imgui and proggy Smiley
« Last Edit: August 23, 2014, 01:32:15 PM by InfiniteStateMachine » Logged

Dissident Dan
Level 0
**

Be different. Wear a watermelon.


View Profile WWW
« Reply #10 on: August 23, 2014, 10:28:53 AM »

This looks great. I've been saying for a while that I wish Visual Studio had some kind of scriptable visual debugging tools. This isn't exactly that, but it looks super useful.
Logged

Run with scissors.
www.PaperboundGame.com
RandyGaul
Level 1
*

~~~


View Profile WWW
« Reply #11 on: August 24, 2014, 09:23:21 AM »

So what is the relation to: https://github.com/AdrienHerubel/imgui
Logged
Omar
Level 0
**



View Profile WWW
« Reply #12 on: August 25, 2014, 05:44:30 AM »

So what is the relation to: https://github.com/AdrienHerubel/imgui
None, unfortunately imgui is a generic name for a concept and I'll have to think of a more specific name to distinguish my library from this one (and others).

Thanks for checking out the library! let me know if you have any questions/requests.

PS: I love Tristan's fonts. note how he moved the website recently -> http://upperbounds.net/
« Last Edit: August 27, 2014, 06:41:11 AM by ocornut » Logged

Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW
« Reply #13 on: August 28, 2014, 05:37:12 AM »

These types are a huge pile of bugs just waiting to happen.  Your vector class really needs a copy constructor/assignment operator, or a C++11 move constructor/assignment pair, or at least explicitly disable copying.  I know I expect objects to have proper value behavior and I'm not the only one.

Also, it's perfectly safe to delete/free null pointers.  In fact, null pointers are the only pointers that are guaranteed to be safe to delete.  Your if (ptr) checks are actually doing the precise opposite of what you intend, you're eliminating the one safe case, and the fact that the pointer is not null in no way indicates that it actually points to something you can free.

I've been on projects where both of these problems have bitten us in the ass.  Save yourself before it's too late!
Logged



What would John Carmack do?
Omar
Level 0
**



View Profile WWW
« Reply #14 on: August 28, 2014, 07:10:18 AM »

AverageSoftware:

- About ImVector<>
You can use your own or the standard std::vector<> if you want. I added ImVector<> to use by default because it is typically faster than most implementation of std::vector<> in debug mode and some people don't want to drag in std:: librairies in their application. The user of ImGui never have to use or access ImVector<>, it is used internally and ImGui doesn't rely on C++ construction by default. So when you say "I expect objects to have proper value behaviour and I'm not the only one" what case are you thinking of, considering that you don't ever need to touch a ImVector<> from the user side? You are commenting on the internals of a library but if the library works it shouldn't be your problems how it works, if it is using C++ constructors or not. I'm not against making this helper more standard/robust (I wrote it in 20 minutes before shipping the first version and added what was enough for ImGui). Did you have a case where you tried to copy an ImVector<> instance?

- The 'if(ptr)' is a convenience to follow the flow of execution when using a debugger. It's not "eliminating the one safe case" since deleting a null pointer does nothing. It's not any safer but it's not worse.



Logged

Average Software
Level 10
*****

Fleeing all W'rkncacnter


View Profile WWW
« Reply #15 on: August 28, 2014, 07:34:02 AM »

it is used internally

If it's an internal type, why is it in the header?  It also appears in types like ImGuiTextFilter, which makes those types break horribly when returned from a function.  If those are also internal types, they really ought to be removed from the header.

Quote
It's not "eliminating the one safe case"

Yes it is.  This isn't really arguable, it's defined by the language.
Logged



What would John Carmack do?
Omar
Level 0
**



View Profile WWW
« Reply #16 on: August 28, 2014, 07:45:27 AM »

If it's an internal type, why is it in the header?  It also appears in types like ImGuiTextFilter, which makes those types break horribly when returned from a function.  If those are also internal types, they really ought to be removed from the header.
Because I want the user to declare helper like ImGuiTextFilter on the stack without heap allocations, so ImVector has to be known in the header (tho I could somehow declare it as an opaque 12 bytes structure but it is really awkward).
You don't need or have to copy types like ImGuiTextFilter. If the way to use ImGui is unclear I can clarify through documentation or example. You are correct that ImVector<> could be more defined or more standard compliant but it's not a strict necessity. In my usage of ImGui I never had to copy an ImVector. It'll happen eventually that'll add those more standard compliant bits (or feel free to add them and send a pull request!).

Quote
Quote
It's not "eliminating the one safe case"
Yes it is.  This isn't really arguable, it's defined by the language.
"delete 0;" is defined as doing nothing. So not calling "delete 0;" does the same as calling "delete 0;". Let's agree to disagree and move on. Peace.
« Last Edit: September 10, 2014, 04:38:40 AM by ocornut » Logged

Pages: [1]
Print
Jump to:  

Theme orange-lt created by panic