Immediate Mode GUI

Anthony Salter has created another update to Planitia, his sorta-Populous non-clone. I can’t wait to try it out.

In the comments following the article, I found this exchange:

sol_hsa: I wonder if you used the IMGUI paradigm =)
Viridian: Why…yes! Yes, I did!

IMGUI paradigm, eh? I think I had heard about it (it’s not very new), but since I wasn’t dealing with GUIs at the time, I didn’t feel compelled to learn about it. Now that I’m focused on the GUI for Killer Kittens, it sounds like something to research!

One thing I found was a tutorial on the same site that explained how to do framerate independent movement to me. Sol on Immediate Mode GUIs (IMGUI) on Sol Tutorials offers a somewhat detailed tutorial. Casey Muratori or Molly Rocket created a video presentation on IMGUI back in 2005. And of course, I can command Google to bring me more information as I desire.

So rather than using the standard decoupled, event-driven GUI development model, IMGUI seems to promise ease of development without many disadvantages. Anyone else get good mileage out of IMGUI practices? I’m not so sure if I want to abandon Guichan just yet, but if IMGUI is as nice as people say, perhaps I might have to change my mind.

Share this post with others: These icons link to social bookmarking sites where readers can share and discover new web pages.

Posted by GBGames on Thursday, July 19th, 2007 at 10:43 am.

4 Responses to “Immediate Mode GUI”

I was already using IMGUI before I knew it existed :). I think it flows naturally from the fact that every game uses a game loop. And it’s much easier to just check the action in the game loop itself rather than handle an event in a seperate function.

Left by Koen Witters on July 20th, 2007

Well it’s the same thing as doing it manually. Which I’ve done on my games. You simply make the menus. I usually have a variable that’s a selector… and then as you push buttons it moves it up or down… (++ or –) and then loops back around, then depending on what menu option it’s on, execute when enter is hit.

At least that’s what I get out of IMGUI — I mean it’s just a fancy name for something people used to do along time ago.

Left by Keith Weatherby II on July 20th, 2007

Heh, it’s always interesting to open up your morning web pages and see your name on a page that isn’t yours

I do mine slightly different from what the programmer from Molly Rocket suggests. He talks about actually running code when you press a button, which I found to be a bit limiting (oddly enough).

Instead, I have GUIs encapsulated as objects that are owned by the states that will use them. The state calls the GUI’s “draw” function as part of its update, and then updates itself based on the GUI’s new state.

For instance, the GUI object has a m_Active variable that represents what GUI element is active this frame. The state looks at that variable and then does stuff (changes the mouse cursor, etc) based on that variable. This also lets me do things like move sliders around in the GUI from the main state based on state variables, which is how I’m doing my mana bar.

Left by Viridian on July 20th, 2007

I have many years of experience with Microsoft MFC as well as a number of custom created Retained Mode GUI systems. In my opinion IMGUI is vastly superior in that it caches the minimal amount of state required to do guis well.

RMGUI is just like RMGraphics, it’s an artifical and potentially buggy cache of your application state. Drawing graphics, like doing guis, is not state in itself, it is an operation upon application state. That’s why I feel it is a very bad idea to encapsulate graphics concepts or guis in objects.

All of our stuff over att www.spellofplay.com is done with IMGUI these days, and we’ve experienced a huge productivity boost as a result.

Left by johno on September 14th, 2007

Something to say?