🔒 Locked

Help with GUI design

Started by cherryyosh Mar 24, 2009 at 8:38 PM 6 replies 1.7k views

Original Post

Mar 24, 2009 at 8:38 PM

So, I've been talking with a friend for the past few days about a gui class design, namely updating it to take advantage of new features and be fully OpenGL 3.x compatible. And of course speeding it up from the standard glBegin()/glEnd that it is using currently. I would like your thoughts on my design and help figuring out some parts of it. Currently the gui is set up so that it has a manager, When this manager is created it calls a function (ThemeMgr_LoadTheme()) which loads a theme file which stores the location to a monolithic theme image and data for which type of gui object uses what range (close:10,10,40,40 would tell any button marked as close to have a topleft of 10,10 on the image and a bottom right of 40,40 [this would also set the default (1) scale to be 30x30]) once all this data is loaded a large vbo holding both the vertex data and the texure coord data. This VBO is bound as GL_STATIC_DRAW and indices will be created . I am currently trying to figure out a clean way to store the needed offset on a per gui-object-class (button, text edit.. etc) way (perhaps static?). Every frame a simple 2d shader is loaded, and a orthographic projection matrix is sent to it, this is done only once per frame as it is not needed more. from there guimgr->render() is called where the needed things are bound and for each object a new modelview matrix is created, this will be used to scale and translate the object, and glDrawElements() is called with the given objects offset. This should work for simple objects and for containers I can just draw all the objects inside it, however for things such as sliders, I can only guess I will need to actually draw two times. I am wondering what your thoughts are on this design, if any of you have tryed it or any flaws I am missing. And also if there is a better, or faster, way to go about doing this.

andrew111

Mar 25, 2009 at 9:58 AM

Hi

I don't think a vbo is necessary, that is if you are doing it for speed.

What do you mean offset, is it positioning in reference to each other?

Because for my menus I made a layout system which allows you to resize the screen and everything will either stay or expand depending on how you set it.

I made it so you enter the layout into an xml file eg..

<place type="vertical">    <place name="desktop" />    <place name="startBar" type="horizontal" height="30">        <place name="startButton" width="150" />        <place name="activePrograms" />    </place><place>

This would make the windows start bar, and desktop, where you then place your gui elements onto.

Each of the places are rectangles, and when the width or height isn't set, it will expand horizontally and/or vertically.

I could post the code if you're interested.

cherryyosh

Mar 25, 2009 at 12:39 PM

By offset I mean the offset of the texture coords and vertices' in the VBO as they all will be in one large vbo then this is necessary.

andrew111

Mar 25, 2009 at 7:39 PM

I'd think it would be easier to draw each element using the basic glBegin (triangle or quad etc)/ glEnd and store all the gui information in your own data structures, including texture coordinates, texture buffer pointers, button captions etc.

cherryyosh

Mar 25, 2009 at 10:10 PM

Quote:
Original post by andrew111
I'd think it would be easier to draw each element using the basic glBegin (triangle or quad etc)/ glEnd and store all the gui information in your own data structures, including texture coordinates, texture buffer pointers, button captions etc.

As I said before I wish for this code to be fully 3.1 compatible. This includes removing all immediate mode functions. I will also be storing all of the information in the gui data structors. Currently this holds information such as the translation, the state of the button, aka weather it is highlighted, pressed or not, and the width and height which will be replaced by a scale factor.

Also I do not care abotu how 'easy' something is, as long as it is a working fast solution, which can be placed in this format without looking like a complete hack. :P

andrew111

Mar 25, 2009 at 11:26 PM

Oh right, I don't know much about the latest opengl updates.

Do not worry about speed, as I doubt it will ever be an issue.

As for your design, I'm not exactly sure what you're explaining,

With the gl_static_draw, do you never intend to let the screen be resized?

How come the sliders need to be drawn twice?

And to store offsets, I guess you could store all the objects in a tree structure with an x,y which offsets from the parent.

Btw,

I'm currently making my gui system, the layout is a tree structure which stores the offsets and where the gui elements are placed on, I also pass mouse input, and render prompts to the elements via a messaging system, so only the objects that need to be called are.

cherryyosh

Mar 25, 2009 at 11:59 PM

Quote:
With the gl_static_draw, do you never intend to let the screen be resized?

The current plan is to pass in a modleview matrix per object, this will scale and translate (and could be used to rotate the gui, if I ever come up with a need to) each object.

Quote:
How come the sliders need to be drawn twice?

using this method I would have a texture position for both the bar and the slider object, no idea what the name is, this will cause me to draw the bar and then the slider, but I guess I will always have to do this.

Quote:

And to store offsets, I guess you could store all the objects in a tree structure with an x,y which offsets from the parent.

that is exactly what I was plaining on doing :]

andrew111

Mar 26, 2009 at 12:20 AM

Yeah it all sounds good,

just remember to think about input and checking of an object is in a certain state, eg clicked.

And maybe you should have another project to develop this for. As its hard to know when to stop adding features to a gui system.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.