Archived

This topic is now archived and is closed to further replies.

Impz0r

GUI Skin handling...how?!

Recommended Posts

Hi, I''m develop a Directx based GUI for a while, and i was wondering how i can handle GUI skins. Should i put all relevant GUI textures within one big texture, or put all GUI control textures within his own texture?! How should i store the different gui control textures, as an example, the button texture, should i store the four states (enabled/disabled/rollover/pressed) as one piece or split every state within 3 pieces, (left/middle/right), for rendering purpose, because if i make a large button the edges would be stretched and this looks bad ... I would be glad if someone could share his experience on this topic with me (maybe some code snipped or so) Thanks in advance Impz0r PS: Sorry for my friggin english, hope someone could understand it *g*

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
There are benefits to putting all your skins into one texture and there are also benefits in keeping them seperated:

One texture:
#1. You know where every thing is.
#2. It''s hard to keep this texture "small" enough to work with cards which only support 256x256 textures(voodoo 1 - 4).
#3. Difficult to edit/change things.

Multiple textures:
#1. Easier to edit/change things.
#2. Might take up extra texture memory depending on how they are organized. (Ex a 36x36 skin needs to be saved to a 64x64 texture)


As for the button question, each GUI object should take care of it''s own states. So it would be logical to place all the button images for "rolled over/disabled/pressed/enabled" into one texture.

Share this post


Link to post
Share on other sites
Thanks for your replay

mhm i think it would be a good choice to save all control relevante textures within his own file.

Now a new question bother me: How should i store the control texture and his state (enable/disable/rollover/pressed/etc..)depending texture coordinates?!
Assumed i have an listbox this listbox contains nine different texture pices, left-top, left-middle, left-right, left-middle,right-middle,and so forth...
I end up with many texture coordinates and different states...how could i handle those cases?!

And a question about rendering those gui stuff, for now i''ve an specific rendering method within my renderer, like the BitBlit method. But i ask my self if this the best solution, or should i put the GUI render specific code within my Skin manager or so, because of these many texture coordinates and states..it''s hard to handle...sigh

I would be glad if someone could help me out of my misery

Thanks in advance

Impz0r

Share this post


Link to post
Share on other sites
Here''s an explanation of what I did in this situation;

Created a CImage class which can be either; a Frame (9 squares when filled, 8 when hollow), a Label (a piece of text) or an Icon (an individual bitmap image).

Frames and Icons are predefined within the gui manager and each requires a texture name, sizes and tu,tv positions. Labels are made through the gui manager in a seperate bitmap font class. So the gui manager is responsible for loading all the fonts and frame styles (especially those used for control borders.

Each one of my controls uses a selection of images to define what it looks like, and it has multiple sets of images to define it''s appearance for enabled, disabled, mouse-over, mouse-down etc. For example a button might have a frame image and a label image for each state.

As for textures.. well I could use one texture for the bitmap font and have room at the bottom of it for all the other control gfx which obviously saves any texture switching, but the way in which the fonts frames and icons are defined at load time I can use as many textures as I wish. All this helps with a texture manager class that doesn''t reload textures unnecessarily, this way I can explicitly name the texture within each image definition, safe in the knowledge it will only ever be loaded once.

Hope that helps a bit!

- Matt

Share this post


Link to post
Share on other sites
hey

thanks 3dModelMan for pointing out your solution, sounds like a good plan, i''ll try it out

But one question: how did you render these frames and images, mean did you have an extra draw method within your renderer or within your GUI manager, or somewhere else ?! Which is the most common way?!

Ok a second question *g*, how did you render your GUI, did you render each GUI control on its own, or did you push all visible controls to an big vertex buffer and render it then?!

Thanks in advance

Impz0r

Share this post


Link to post
Share on other sites
The GUI is still under development so at the moment it works very simply; the CImage has a render function and it''s own VB/IB. Windows and controls are drawn in back-to-front order by calling all the CImage->Render() functions individually.

I use the gui in non-time critical places, eg front end menus, so it''s worked very well so far. I know there is a lot of room for optimisation if and when the application demands it

All this stuff was released as open source here a while ago but it was getting out of date so I took it down (I wanted to use it as a means of demonstrating my skills without having a completed project, but these days I prefer to spend my time on this website and projects instead).

Cheers

Matt

Share this post


Link to post
Share on other sites
While my solution is not the best solution, it allowed
me to get up and going pretty fast. I can always go
back for optimization later. Anyway..

Just like others said here, I first made a Dx3DSprite wrapper
for a picture. I also made a Dx Font wrapper for text. All my elements extend a common interface for updating and rendering.

Already, I had a texture manager that is based off of handles.
Since the DxSprite wrapper needs a pointer to a DxTexture, I used the handle to get the pointer from the manager, making sure I up''ed the reference count.

For my main controls, like a button, it contains 4 pictures (one for each state) and a Label (that font wrapper). On the update call, it gets the mouse coords, and determines its state then. On render, it knows its boundries, and tells the correct Picture to render itself, and the Label if the button has any text.

My ListBox is about the same way. It is also made up of several Labels and buttons. A Picture makes up the bacground of it, and a Buttons make up the list and arrows. The Fonts on the buttons can be changed, so scrolling or selecting up and down only changes the font properties on those buttons.

Share this post


Link to post
Share on other sites
Thans 3dModelMan and Taulin for sharing your experience with me, thats clear alot

3dModelMan i''ll have a watch at the souce and your hompage

Impz0r

Share this post


Link to post
Share on other sites