Sign in to follow this  

simple GUI turned not so simple.

This topic is 4782 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, things are going at a pretty steady pace in my current project, except my next roadblock is writing some GUI routines. in the beginning i didnt see that it was going to be all that much of a problem, but then i started having scrambled rendering sequences and just messy code. i decided a more complex gui sub-system was requried. ive looked into a few things like wxWindows and Tknker (i think its called that) GTK ... but i decided id just write my own becasue i dont think i need all the functionality that comes with those libs, and im not entirely sure how well they will mingle with opengl. anyways basically i have a few design questions yet again. i want to just call a single render function and that will render the entire gui in correct order, and when i want to create a GUI object i just add it to a list or vector and it will be rendered later. the problem arises with constantly changing text output and eventually text input. if i were to have a single render function call for the gui, text would have to be deleted and then created again in the "text" vector every frame, or i would have to make the vector a map and modify it every frame ... but i dont really like that idea for holding strings. ... and im not sure how else i would do this, keeping in mind i want flexibility and effenciency. can anyone give me a few pointers or things to think about when doing some basic gui programming? thanks for any help in advance.

Share this post


Link to post
Share on other sites
Well, I am currently working on a GUI system. This is what I did.

I have a GUI manager which creates, draws, deletes and takes input every frame sends it to the controls to see if any of them need it. Each control has all the information to draw and handle input.

So, Lets say the mouse is over a button and the left mouse button is pressed. That frame the manager get the input then send it to each control if one says the mouse is over me and I handled the button press, it stops looking and the manager returns that it handled the input that frame. also the control now has focus, meaning that if lets say its an inputbox if next I send a keypress it will handle this.

I'm not sure how well I explained this. if I can help you more let me know. or if this is unclear.

look here I made this first but did not like how complex it got.
http://www.gamedev.net/reference/articles/article994.asp

Share this post


Link to post
Share on other sites
There is even better GUI tutorial than those on Ionware, it's here on GameDev but I don't remember adress - Google for sth like "GameDev GUI tutorial DirectX" and I'm sure you will find it.

Share this post


Link to post
Share on other sites
Quote:
Original post by ekrax
... and im not sure how else i would do this, keeping in mind i want flexibility and effenciency.

can anyone give me a few pointers or things to think about when doing some basic gui programming?


Well the main structure of gui toolkit (the widgets) usually implements a composite design pattern plus a thew other design pattterns but the composite is the main structure. Then there is the event handling mechnisim in c++ i would recommend using a signals & slots design notably boost's signal & slots lib.

If you mean't GUI in the sense of UI for a game in GL, GL rendering then that should be enough. If you mean't cross-platform window GUIs then you would probably also wont to apply the bridge pattern aswell.

Share this post


Link to post
Share on other sites
Quote:
Original post by ekrax
ive looked into a few things like wxWindows and Tknker (i think its called that) GTK ... but i decided id just write my own becasue i dont think i need all the functionality that comes with those libs, and im not entirely sure how well they will mingle with opengl.


OK... those are native windows dialogs GUI's, not OpenGL gui libs. Use them if you want to make a Tool or something.

About to much functionality, I don't get that. Just use what you need and forget the rest? I mean, who uses either the entire STL or nothing at all?

I know I've seen a good tut series using XML to configure your menus. But can't remember what it was called.

Well you should still compare apples to apples. I.e. you should check out these (OGL game gui) libs before deciding to make your own, instead of comparing with full blown nativivly compiled widget libraries.
(Agar)
GLOW
GLUI
NUI
GUIde
Those use OpenGL.

Here's a full list of alot of GUI libs, clicky.

I've been writing my own too. But they were all static stuff, user interaction really complicates stuff so I know how you feel.

Good luck.

[edit] added GUIde

[Edited by - Seriema on November 15, 2004 5:45:59 PM]

Share this post


Link to post
Share on other sites
For a simple DIY GUI, i think what you really want is a basic Widget class with a virtual Render() function. Then you can inherit from Widget and redefine your rendering on a per-widget basis. Also, from the little GUI experience i've had, it seems common to have the "master widget" (the window or the screen) draw itself, then all of it's registered children. Each child in turn draws it's children, and so on.


virtual void Render() {
... draw myself ...
foreach child (children) {
child->Render();
}
}

Share this post


Link to post
Share on other sites
Quote:
Original post by leiavoia
For a simple DIY GUI, i think what you really want is a basic Widget class with a virtual Render() function. Then you can inherit from Widget and redefine your rendering on a per-widget basis. Also, from the little GUI experience i've had, it seems common to have the "master widget" (the window or the screen) draw itself, then all of it's registered children. Each child in turn draws it's children, and so on.


virtual void Render() {
... draw myself ...
foreach child (children) {
child->Render();
}
}


sounds like some degenerate form of composite pattern, structurally the heart of a widget toolkit would like something like (my UML might be alittle wrong but you get the idea):



Of-course that is very simplified and missing some info, an instance of it would either be a tree or restricted form of directed-acyclic graph to permit sharing of leafs.

Share this post


Link to post
Share on other sites

This topic is 4782 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.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this