Brain storming Simple UI

Started by
4 comments, last by yewbie 12 years, 11 months ago
I spent several hours over the weekend working with CEGUI and man it added a ton of overhead to my program...
Pretty much all I need was some simple button controls and drawing various UI elements based on gamestate, so I decided to roll my own.

So here is my plan that I am currently working on and I was looking for some feedback to see if this is a good road to go down.

Basically the only thing my UI is going to handle is buttons, buttons are easy enough to track position and draw based on where you want them.
I am handling input on a basic level right from my windows message loop, directly sending any mouse click (up or down) (with location) to my UI class.

Each gamestate is stored in a vector, each gamestate has its own set of buttons also stored in a vector.
For example in the world view in a rpg type game the action bar would consist of 10 buttons at the bottom of the screen.
This gives me the benefit of not looping through every single button everytime I have mouse click input.

Then the function that sends input to the class returns a string if the string is empty no command was processed, when it has a valid string it sends it to a command parser.

This tends to make building a given set of buttons alot easier, and could even allow for outside of program scripts to design all of my UI elements as long as there is a text command that gets parsed out.

Anyway thanks to anyone that made it to the bottom of this, any thoughts would be appreciated
Advertisement

I spent several hours over the weekend working with CEGUI and man it added a ton of overhead to my program...
Pretty much all I need was some simple button controls and drawing various UI elements based on gamestate, so I decided to roll my own.

So here is my plan that I am currently working on and I was looking for some feedback to see if this is a good road to go down.

Basically the only thing my UI is going to handle is buttons, buttons are easy enough to track position and draw based on where you want them.
I am handling input on a basic level right from my windows message loop, directly sending any mouse click (up or down) (with location) to my UI class.

Each gamestate is stored in a vector, each gamestate has its own set of buttons also stored in a vector.
For example in the world view in a rpg type game the action bar would consist of 10 buttons at the bottom of the screen.
This gives me the benefit of not looping through every single button everytime I have mouse click input.

Then the function that sends input to the class returns a string if the string is empty no command was processed, when it has a valid string it sends it to a command parser.

This tends to make building a given set of buttons alot easier, and could even allow for outside of program scripts to design all of my UI elements as long as there is a text command that gets parsed out.

Anyway thanks to anyone that made it to the bottom of this, any thoughts would be appreciated


I use a tree to hold UI stuffs, so that the messages are only handle by the ancestors of the UI element, and itself, something to look into. I'd like to hear more about your command structure as I'm currently using a plan old function pointer to handle clicks and mouseovers and what not

I use a tree to hold UI stuffs, so that the messages are only handle by the ancestors of the UI element, and itself, something to look into. I'd like to hear more about your command structure as I'm currently using a plan old function pointer to handle clicks and mouseovers and what not


I will have to look into trees.

And for my command structure anytime there is a mouse movement or a mouse click my mouse input function is called with location, button pressed, and if it a up click or a down click.
My class checks if this happened on top of one of our buttons and returns that buttons specific text command.

Right now I am not doing anything with mouseovers but tooltips would be pretty easy to implement from this same code.
Each gamestate has its on specific command parser where it actually uses UI commands.

So for instance say we are in the game state GS_WORLD_MAP a game state where the player moves around and can do actions, there is a action bar at the bottom consisting of 10 buttons, each button deals with various commands anything from using a item the player dragged over the button or doing a in game command such as casting a spell or whatever.

When the player drags the icon of lets say item number 10024 over icon #0 of our action bar the buttons command would be changed to "USEITEM 10024"
and when clicked it would send the string "USEITEM 10024" returned after the user has release the left mouse button over top of the button (after the left was down over it also).

Then the gamestate receives the command parses USEITEM and activates the function for that command with argument 10024.

Basically it allows for the buttons to dummies and not know anything about what they are doing.

[quote name='Burnt_Fyr' timestamp='1305127718' post='4809457']
I use a tree to hold UI stuffs, so that the messages are only handle by the ancestors of the UI element, and itself, something to look into. I'd like to hear more about your command structure as I'm currently using a plan old function pointer to handle clicks and mouseovers and what not


I will have to look into trees.

And for my command structure anytime there is a mouse movement or a mouse click my mouse input function is called with location, button pressed, and if it a up click or a down click.
My class checks if this happened on top of one of our buttons and returns that buttons specific text command.

Right now I am not doing anything with mouseovers but tooltips would be pretty easy to implement from this same code.
Each gamestate has its on specific command parser where it actually uses UI commands.

So for instance say we are in the game state GS_WORLD_MAP a game state where the player moves around and can do actions, there is a action bar at the bottom consisting of 10 buttons, each button deals with various commands anything from using a item the player dragged over the button or doing a in game command such as casting a spell or whatever.

When the player drags the icon of lets say item number 10024 over icon #0 of our action bar the buttons command would be changed to "USEITEM 10024"
and when clicked it would send the string "USEITEM 10024" returned after the user has release the left mouse button over top of the button (after the left was down over it also).

Then the gamestate receives the command parses USEITEM and activates the function for that command with argument 10024.

Basically it allows for the buttons to dummies and not know anything about what they are doing.
[/quote]

Trees afaik are pretty common as far as UI is concerened.

In my code, each engingstate has a GUI*, which acts as a container/factory for UIElement objects, and has functions for loading and saving UI's from xml, The base class holds a pointer to parent, next, and firstchild elements as well as a few recursive functions that handle the majority of the work. I've subclassed this for buttons, windows, sliders, text inputs, etc. and IMHO it works pretty darn well.

Overriding default logic for controls though, is currently limited to a function pointer (int fp(void)) which doesn't allow for much freedom. as well, the logic is hard coded(I've no scripting yet) so the xml files act more like CSS stylesheets, I can change the look and feel, but not the function. If your commands are all text strings do you have a std::map or similar that match a command to a function pointer?

If your commands are all text strings do you have a std::map or similar that match a command to a function pointer?


A std::map would be interesting to use.

Right now I am just tokenizing the string into an vector (space delimited) and doing string comparisons.
Each base command controls its own token(s), its not the best solution but its what I have so far =p

IE: the command "TELEPORT ME 10 10" on a button would be parsed out to call the function CmdTeleport(int PlayerID, int NewLocX, int NewLocY) and player id would be obtained by the previous function call by determining if the second argument was a number for a actual player id, or the text ME to look up our current player ID.

I think im using a much much more indirect route for a interface, while this will give me more freedom its really going to be alot slower than your methods.
For anyone that happened to read this, here is a sample of what I ended up with.

It supports:
Dragging of Icons
Swapping of Icons
Destroying Icons
Resizing Tooltips based item / button description and info

Some interesting things I ran into:

Since I was using left click/right click up/down messages only I was having trouble distinguishing when a drag was being started or when someone was activating a item from the inventory.
I was able to overcome this by adding a 100 ms delay when dragging items before it displays the item under your cursor (with a heavy alpha), this still allows for quick dragging of items and doesn't popup the drag image while your activating a item.

Also I had to design the tooltip to draw based on your mouse cursor if you were more than screenwidth/2 or screenheight/2 I would not draw the tooltip on the mouse cursor I would start drawing it negative (tooltipwidth) on the X axis, and the same thing on the Y axis. This allowed for the tooltip to display fully no matter where you were looking on the screen.

But anyway thanks to the people that helped me out with this and here is a screencap of my result.

[attachment=2415:screenshot4.jpg]

This topic is closed to new replies.

Advertisement