Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

387 Neutral

About ocornut

  • Rank

Personal Information

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. ocornut

    How do you create your GUI?

    While Nuklear has some skinning options, one thing is take into account is whether it goes to point that is satisfactory for the needs of your game. Dear ImGui is less skinnable but arguably has more ui features, e.g. drag and drop api, tab bars, docking, gamepad controls and some keyboard controls, support for extracting windows as native OS/platform windows, a larger community of users and widgets, etc. and upcoming ones: automation, tables. Whereas Nuklear appears stagnant by now (vurtun moved on to something else?). My personal answer to the OP is that neither Dear ImGui nor Nuklear are designed for high quality in-game UI and you are better off writing your own. Game UI are very custom and simpler to write than productivity/tooling UI.
  2. ocornut

    Anyone use Dear ImGUI?

    But you are not answering the core question of what you are looking for in a GUI toolkit. Does it need to be pretty and skinnable? How UI intensive is your game? What sorts of control do you need, do you have a mockup or your target UI? Are you focusing on mouse controls? Do you need keyboard and/or gamepad controls to be function? How far do you wish to push localization, would you want your UI to show Japanese? Chinese? Arabic? Those languages have different constraints and different GUI won't support them the same way (those 3 are listed here in a typical "easier to harder" fashion). Are you displaying user-generated strings or only strings that you know ahead of time? Do you intent to allow users to input text in their language? If so if your game is a fullscreen game you have different constraints as you can't use native IME controls in the same way. I'm genuinely asking this because those different requirements would lead you to radically different solutions. Dear ImGui is good at what it does but it doesn't do everything.
  3. ocornut

    Anyone use Dear ImGUI?

    > I'm mostly interested in HUD You'll find feedback from users e.g. on twitter but you need to clarify your use case because "GUI API" can mean ten different things. It's definitively not designed to be properly skinable. So if you intend to make those UI available to your players and expect them to look like fancy game UI it is not a good choice. It's designed to be very-high productivity/flexibility/portability for tool making.
  4. ocornut

    ImGui questions

    Are you running on latest? There was a bug in 1.51 which I think is what you are having here. For general imgui questions may I suggest asking in the imgui github, this is where all the other questions are being asked. https://github.com/ocornut/imgui/issues
  5. ocornut

    ImGui questions

    1) When calling ImGui::NewFrame() it is updating the io.WantCaptureMouse and io.WantCaptureKeyboard fields. You can use those fields to hide the inputs from your own application/editor. The most obvious case is that io.WantCaptureMouse will be true when hovering an ImGui window (in reality the logic is a little more complex than that, it tracks clicks/drags and active widgets). This is answered in the FAQ under "Q: How can I tell when Dear ImGui wants my mouse/keyboard inputs VS when I can pass them to my application?" 2) You can use ImGui::SetNextWindowPos, ImGui::SetNextWindowSize(). You do need to manually calculate the size but you can also create one fullscreen window (position = 0,0, size = io.DisplaySize) with a MenuBar, it's equivalent to creating a main menu bar. 3) I don't know what "input fuzziness" means. It should be fine to create an entire editor, many people have been doing that. One limitation of imgui with it handles inputs events is that if you expect to run at very low frame rates (e.g. 10 FPS) you will want to create a queue events and defer passing all of them to imgui at once (e.g. if you received 2 clicks in one frame). This should be handled by the library but eventually but it's not at the moment. If you don't expect to be running at super low framerate it won't be a problem.
  6. ocornut

    Handmade Hero after two years

    I don't think anyone pretended that he detains the unique universal correct knowledge. It doesn't matter if Casey is an idealist elitist who maybe wouldn't function well with a team of newbies. What matter is that the knowledge and techniques he shares goes way beyond the average clueless stackoverflow poster who never made something serious.   The majority of contents in HH aren't "development practices" but discussing technology and issues that are quite universal. The development practice part amount for like a quarter so even if you didn't agree with all of them the rest is worthwhile if you can afford to follow it.
  7. ocornut

    Handmade Hero after two years

    The point of this series is that people who are _actually_ deep into game or game technology-making rarely have the time or patience or interest to produce learning material. As a result _lots_ of the learning material on the internet are really disconnected from the actual complexity and issues or real quality game development in the field.   Or course Casey is improvising, but with the experience he has, his improvising hold more useful information than the quintillion of unfinished tutorials of the internet. He might be a little extremist in his views (I find so) but it is better to be extreme rather than mild, when 90% the learning material available otherwise are extreme in using techniques that misled a generation of programmers toward writing code and software that are terrible, and techniques that don't scale for advanced game development. This knowledge is genuinely disappearing because young programmers or schools don't feel they need to learn/teach it. But if nobody learns those proper things, what is at the core of programming and computer, we'll be all massively fucked.   It is an amazing gift to the world that those video exists. I hope someday they will get indexed / transcribed in more details.
  8. ocornut

    Gui Libraries?

      Also, what is the reasoning behind using immediate-mode style? The way I see it is to collect all these commands and run them in a batchjob in my renderer, directly into the backbuffer after all 3D-rendering is done. Not sure if immediate-mode complicates stuff in that case.   This is exactly what dear imgui does. It generate command buffers to render later. It is really simple to integrate. "Immediate-mode" refer to the api style it's not related to the way you would access your GPU (it doesn't access your GPU at all).   About the styling limitation, as Mussi pointed out it wasn't designed to be very skinnable. My opinion is that lots of UI _pretending_ to be skinnable are still not fit for high-quality in-game UI. What people refer to as "skinability" encompass lots of usability issues, controls, animations. Replacing a few visuals is merely 10% of what you'll need if you want a beautiful game ui. Few classic UI toolkits are great enough to provide in-game quality, unless you want your game UI to look like a 2002 shareware.   For in-game UI just bite the bullet and write custom code IMHO. it's actually fairly easy, the needs for in-game UI are much simplier than for tools, and they are more custom.
  9.   That's how the dear imgui console example looks like (upper-right) It shows ways to do completion, history, filtering. It is merely a sample that is, so probably need readjusting but can be used as a base.   It's ok and not too hard to roll your own but with an existing library you'll probably be able to do much more.   Skinning wise, one reason the default skin in dear imgui looks fugly are that a) the font is embedded in the code b) most rounded shapes have been disabled by default. c) the color scheme isn't good (the buttons are horrible). so that's something to work on.   This is what some people have been working on. Notice it is still close but you can get a long way by changing font / color / rounding settings.   OdenVR https://cloud.githubusercontent.com/assets/840235/13230096/55e766f6-d9a4-11e5-9d30-419f0f2576e2.png   Some OSX looking color scheme https://cloud.githubusercontent.com/assets/8225057/12702454/ecd396b6-c829-11e5-9501-1b507a305395.png https://cloud.githubusercontent.com/assets/8225057/12702458/f23eddae-c829-11e5-8188-b4a6b60b0b36.png https://cloud.githubusercontent.com/assets/8225057/12702456/f20d4618-c829-11e5-9dfd-045e267ccdde.png https://cloud.githubusercontent.com/assets/8225057/12702459/f26f22fc-c829-11e5-96cc-2f2d035dd0cc.png   LumixEngine https://cloud.githubusercontent.com/assets/153526/13794457/2665936c-eafc-11e5-811d-9757b24b8d05.png   Tools for Lumote game https://cloud.githubusercontent.com/assets/4952023/13963091/3f8caedc-f021-11e5-8709-90c8ea7df1c0.png
  10. ocornut

    GUI for tools

    Thanks for your answer and feel free to move this discussion over to the github if you don't want to hijack this topic. I'm not entirely sure why you aren't using TreeNode(), your code seems to attempt to replicate a behavior similar to that but with a slightly unusual construct. But it may just be because I don't understand the exact needs.   Based on your snippet it looks like you could use TreeNode(), a typical simple use pattern would be: // Identify by pointer (obj) // Display name + size as in the tree label if (ImGui::TreeNode(obj, "%s (%d)", obj->Name, obj->Size)) { UserCode(obj); ImGui::TreePop(); } One of my tool looks like that: (Colored button + TreeNode() + SameLine() before adding the extra 2 checkboxs and the drag showing "100" for my alpha settings.)           Or a more property tree in imgui_demo.cpp - ShowExampleAppPropertyEditor()     If you are really desirous of implementing a custom version of TreeNode() you can copy the MyTreeNode() code from here and adjust layout:   https://github.com/ocornut/imgui/issues/282#issuecomment-136011369   Arguably TreeNode() is missing a setting to adjust with precision the difference between hit-test behavior vs visual highlight behavior, this can be customized by copying the example code above, but ideally we should add those options in the stock library. The two screenshots above don't use any custom stuff.   Hope it helps. Sorry again for somehow hijacking this thread.
  11. ocornut

    GUI for tools

      Could you post on ImGui github about your issues, what you are trying to do and what is difficult or you are failing to figure out? I'm interested to figure out if they are shortcoming of the library or misunderstanding about how to use it. Not sure what you refer to by "complex" hierarchies but I saw several editors made with it and always interested in further improvements. Thanks.
  12. ocornut


    I don't really understand why you would have any frame of latency passing data from one thread to another, but then I don't know the restrictions your own code/engine have. Anyway Dear ImGui is definitively not designed for in-game end-user UI primarily because it doesn't look like anything you'd want your game to look it. It's definitively a library for tools.   Back to OP, if you were to design a game UI, the IMGUI idea of submitting items every frame would apply as well. Regardless of UI it is generally sane to avoid state duplication.
  13. ocornut


    0. You are hitting on the very reason why I renamed it ImGui : the library used in cmftStudio is a different one with same name except from casing =) that one is based on an older imgui library extracted from Recast. I suppose the dark color scheme is more pleasant. The library isn't as full-featured and has pretty much stopped definitively unfortunately (but you can look at it). If it is about the color scheme, I'm sure you can get the same scheme with mine as well, and the rendering is very close in the first place. I'm fully aware that a better visual/color scheme is a commonly asked feature but I'm tackling that very cautiously because there are countless subtle side-effects to productivity, software design and performances and I can't just nilly-willy make those changes. Looking pretty is Dear ImGui isn't firstly designed to be pretty but to handle large software easily and efficiently. Prettiness is evolving little by little and help is welcome. (I also have a personal roadmap/agenda of mine, that the library is already taking too much of my time and I don't want to attract too many people on it too fast before I am done with more essential features, and I know revamping the theme will attract more people, but it is coming). *EDIT* Here's with a different color scheme https://cloud.githubusercontent.com/assets/8225057/7023421/f47d7f3c-dd2c-11e4-9d27-937a37b3e9b3.PNG   1. Mouse/cursor centric. Agreed. It is one of the major feature that has yet to be developed in mine. It'd be a rather big task and in my list, but when, I don't know. That said, using Synergy+mouse/keyboard on consoles is really really great for efficiency. Bite the bullet of setting up the system (half a day?) and you really won't consider having people using tools with a gamepad. Another possibility on PS4 is to use the touch pad for mouse cursor, it works relatively ok for that. Productivity tools aren't great with a gamepad.   2. Not sure to understand the nature of your problem. That sentence "the user interface is setup from scripts which run in the logic thread; while the actual UI runs in the Graphics thread" doesn't even seem to translate to IMGUI. Whoever wants UI call the UI functions (you'll have to lock for concurrent access). ImGui doesn't touch any graphic state. Once your are done with logic you can request your graphic thread to render the triangles.
  14. ocornut


      First and as Glass_Knife said, nothing is good for everything! Regardless of being IMGUI or RMGUI I don't think you'll find a library that is both satisfactory for tools AND for in-game if you expect in-game to look all super visually fancy and super customized. Unless your game wants to look like an OS, you are probably better off writing something custom for your game, IMGUI/RMGUI won't matter much. Game ui are generally simple. Then when it comes to tool it really depends what your aim is, who and how many people are going to make the tools and use the tools, how complex is the tool, etc. There are as many solutions as they are situations.   We need to differentiate USING the library and WRITING the library. It is probably easier to write a very simple IMGUI yourself but probably easier to write a little more elaborate RMGUI yourself. However from the users perspective I believe IMGUI are always easier and more efficient to use. If your editor is complex, you don't want an UI library that makes things tedious.. And the typical off the shelves RMGUI tends to be tedious.   The biggest difference that weights in the mind of people in the RMGUI<>IMGUI debate is that gigantic companies with lots of resources have developed competent, gigantic and full-featured RMGUI API (QT,GTK,Win32,all the stuff DotNet have, etc.) whereas no-one has attempted to develop an IMGUI at a scale that big. And a single attempt wouldn't be enough to make a fair comparison. So we just cannot make a fair comparison. The best and reference RMGUI libraries are huge complex beast. The best IMGUI librairies are pretty simple. We don't have a hugely complex and full-featured IMGUI available (even if I don't favor complexity, it would be nice to have one).   My ImGui library (very recently renamed to "dear imgui" to reduce ambiguity) which has been the "popular one" this year is probably the most developed freely available implementation of an IMGUI but even so it still only support a very small fraction of what established libraries support. Also it is a one-pass IMGUI that was developed for convenience and tools and it has its own shortcomings. So it's probably not a fit for all cases. If you are writing authoring, visualisation and debugging tools for a game the library might be great for you. It is a library that was designed by taking some shortcuts to make things easier. You'll encounter some issues but they'll probably be simple to understand and fix/workaround.   So the question here isn't just about IMGUI vs RMGUI but probably and mainly about Simple vs Complex. Writing complex tools with a simple and competent library can be a pleasure imho, feels very fast. Fighting against a big opaque mess can be very frustrating.   The person who wrote Lumix Engine has been switching from QT to ImGui and wrote a comment here: https://github.com/ocornut/imgui/issues/123#issuecomment-142700775   Cons: - I am still afraid I will not be able to do some things with ImGui I can do with retain mode GUI. However I have not found anything impossible yet. - Less options for skinning compared to Qt. I am not even sure whether this is a disadvantage, since I am satisfied with default skin, but maybe some users will want it. - The biggest issue for me is that some basic gui elements are missing, e.g. some equivalent to Qt ListView with several columns (I had to do it in a quite complicated way), progress bar, advanced color picker, ... Maybe these can be plugins to keep the core ImGui slim. - No docking - second biggest issue - Multiple monitor support - this is questionable - Not possible to select values from histogram, or at least render one of the items in a different way so I can select it with a slider Pros: - Pleasure to use, when I go to sleep I can't wait to wake up to work with ImGui :) - Faster to do things than with Qt. Literally 100x faster. - App in ImGui tends to end up much more polished, because it's easier and faster. - Most of the missing features are very easy to add. This is extremely hard in Qt and I would never try that. - Basic widgets (drag float, ...) work in fact better in ImGui than in Qt, e.g. in Qt, if I have a float value e.g. 1.23 in an input limited to 2 decimal places and I want to change it to 1.24, I can not just enter 1.243, I have to delete 3 to get 1.2 and than I can enter 4 to get 1.24. This is extremely annoying in Qt. - ImGui is a GREAT way to do property grids. In Qt I had to connect milions of signals/slots and I always miss some. In ImGui, this just works. - There is 20MB dll just for UTF in Qt :(, It can take several seconds to start Qt app. ImGui is extremely small and ImGui app starts immediately.
  15. Points above also very valid. There's not a single answer because it depends so much on your overall architecture and development. With QT you will tend to build more offline tools (game/engine may be running but you probably have tool development isolated from the rest, manipulating your data through some sort of abstraction layer. Essentially as you depend on all those features that QT gives you, your tools gets more and more isolated from your runtime, unless your game isn't targeting consoles - note that some see this property as a benefit), whereas an integrated ui like imgui will enable you to build more online (in-game, in-engine, touching your raw structures directly) tools with a more blurry separation between game and tools. There's uses for both and there's ways to make games that are 100% on either side or 80/20 or 50/50. I know that I've always wanted to build extremely live and dynamic tools and I've moved away from the likes of GTK/QT a while ago now because they got in my way. But people have different styles and it works for them very well too.
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!