Advertisement Jump to content
Sign in to follow this  
brett01

OpenGL Building a menu system

This topic is 3424 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hello, I am building a menu system using opengl api(not winapi menus) and different menus stay static on the screen.Can some one help me by pointing to some tutorials or some papers please.This is menu system something like we see in rts games. Thanks & Regards, brett [Edited by - brett01 on August 31, 2009 12:17:04 PM]

Share this post


Link to post
Share on other sites
Advertisement
Checkout IMGUI techniques. I think they may be a good fit for what you are trying to do. Watch the video, it's pretty good.

https://mollyrocket.com/forums/viewtopic.php?t=134

cheers,

Bob

Share this post


Link to post
Share on other sites
Thank you very much for the reply scourge.I also have heard about event based systems.Are both Immediate mode and event based systems the same??

Share this post


Link to post
Share on other sites
Only 10min into the vid, but so far it sounds like "get rid of all the elaborate stuff that would create clean and structured code and replace it with a huge-ass spaghetti-code if-else-orgy that only a C-hacking mother could love".

To answer the other question: no, "immediate mode gui" seems to be the very opposite of event based, because so far it sounds like one huge function asking every single interface widget if it was clicked. But I may (hopefully) be wrong there.

Share this post


Link to post
Share on other sites
Quote:
Original post by Trienco
Only 10min into the vid, but so far it sounds like "get rid of all the elaborate stuff that would create clean and structured code and replace it with a huge-ass spaghetti-code if-else-orgy that only a C-hacking mother could love".

That's basically the idea that guy is advocating. While I skipped a lot of the video, it does seem like he did not actually understand the concept behind OO event driven UIs at all.

Quote:
Original post by Trienco
To answer the other question: no, "immediate mode gui" seems to be the very opposite of event based, because so far it sounds like one huge function asking every single interface widget if it was clicked. But I may (hopefully) be wrong there.

No, you're right. It's polling every single UI element in a huge loop, while every single event handler of the entire UI is entangled somewhere deep in one huge if/else tree. In other words, IMGUI is a really, really bad idea.

Share this post


Link to post
Share on other sites
Hi You finally say that IMGUI is bad???Can some one provide tutorials or materials to write a event based menu system please.Are there any other menu systems better than event based menu systems??

Share this post


Link to post
Share on other sites
Quote:
Original post by Yann L
It's polling every single UI element in a huge loop, while every single event handler of the entire UI is entangled somewhere deep in one huge if/else tree. In other words, IMGUI is a really, really bad idea.


In traditional Retained Mode GUIs, you create controls, query controls' state/data, listen for controls' events, and destroy controls. All of this code is in different places.

IMGUI says the application should own the data, and only the caller needs to know about the events. This results in all of the code being in one place, and a complete separation between behavior and visual representation.

You end up with UI code looking like this:
switch (UI::Button(UI_ID, Rect(40, 110, 88, 80))) {
default:
// draw the button's normal state
break;
case UI::State::HOVER:
// draw the button's hover state
break;
case UI::State::CLICK:
// draw the button's clicked state
// act on click event
break;
}





You don't need to manage controls' lifetimes, or query/copy their data because they own no data. You don't need to wire up events, because they return them immediately.

It's the leanest, fastest, easiest to understand UI code I've ever worked with. I'll never go back to CEGUI, that's for sure.

EDIT: And it's not as though you need to have your data defined in code as above. You could easily write an XML representation, and parse those elements into IMGUI calls with no change in the underlying UI code.

Share this post


Link to post
Share on other sites
Quote:
Original post by CadetUmfer
In traditional Retained Mode GUIs, you create controls, query controls' state/data, listen for controls' events, and destroy controls. All of this code is in different places.


If you feel a constant need to query state/data of controls and handling their events is an issue, as well as you make it a big deal to create and destroy them, my guess is that you're doing something in a very weird and basically wrong way.


//somewhere in your app
void Game::buildSoldiers() {...}

//whereever you setup your menu
Button* btn = new Button(10,10, 150, 20, menu);
btn->onClick = bind(&Game::buildSoldiers, gameInstance);
btn->setImage(xxx);



What else would you want to do for a button? Why would you need to query its state? Why would you care about its internal data? Where do you need event handling, if you go for the callback solution? Why would you worry about destroying your controls, when every half decent gui I ever used will automatically destroy all child objects, meaning all you do is: delete menu;

Quote:
This results in all of the code being in one place,


Which can be a good thing, if a) the code has any business all being in one place and b) "all in one place" doesn't equal "one huge if/else switch/case monster function doing everything".

Share this post


Link to post
Share on other sites
This is an interesting topic, as I'm in progress of developing a new GUI system as well. My old GUI code works just like Trienco's example, but I keep wondering if it would be better from an encapsulation point of view to use an event system rather than a callback.

Basically, rather than setting btn->onclick to a function pointer you would set it to an enum value. When GUI registers a click on btn, it adds an event with that value into a queue. Whenever you decide to evaluate user input, you go through the GUI event queue and if there's a button click event with the value "buildsoldiers" you call the relevant code.

What are your thoughts? Is it just a question of aesthetics? I will probably need some callbacks anyway in order to allow more advanced customization of GUI objects (e.g. completely replacing how a button is rendered) but I see this as being a different level of user involvement.

(regarding IMGUI, this indeed sounds like a horrible waste if it works as you say)

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!