ProgressBar question (how to question)

If my understanding is correct, then the current implementation of progressbar simply scales the actual progress bar (progressbar.green.bar.png) according to its progress.

Let’s assume I got a different setup, like this:


image1 is the container, stays static
image2 is the actual progress bar

the usage samples show, that when the progress changes, the texture shouldn’t be scaled, but let’s call it “clippedâ€

Ah, very good idea! With initial help from theCaptain, we made the Progress bar clip, instead of scale. The problem is that we clipped from the left side, and you need it clipped from the right side. So this tells me we need to make another configurable option, which defines which side to clip from. I'll have to think about how to implement this, keep in mind the ProgressBar supports toggling between left-to-right and right-to-left, as well as top-to-bottom and bottom-to-top.

Regarding your scenario.. what is the reason you want to parent the ProgressBar to the Image? Right now I allow this functionality via add/remove child, but the design I had planned restricts certain widgets from having certain child widgets. For example, you could move a button from one window to another, which is fine.. but what about adding a scrollbar to a button? I want to disable these combinations from being possible. If you have a good reason I can allow this as a valid combination, but in general cases, if the widget can't create it, the widget can't have it as a child.

I believe the reason the code isn't working is because the progress bar is already attached to the sheet. Ogre throws exceptions when this is done with scene nodes, but I silently do nothing. (for better or worse..)


this->hudSheet->removeChild(progressBarTest);
progBGImage->addChild(progressBarTest);


Also, just a heads up. I'm planning to remove the setTexture API in favor of setSkin. The Image widget will still have setTexture, as it will often not be using a SkinSet texture, but I'd like to start moving in the direction of using skin's for GUI Widgets. I will make sure the creation and use of SkinSets will be as easy and convenient as possible. I have made another thread if you have problems with this.

Thanks for the input, always happy to see new widget textures.

This works now, thanks!

@Vertical ProgressBars: yeah, we need them for our project too
(bottom to top)


@Skin-set: basically i got no problem with it.


I got another question though: I was doing some tests with different screen resolutions.
What's the common way for creating layouts/GUIs?
Do games provide a unique layout for each resolution?

How should you handle this with quickGUI?

Let's say I optimize it for 1024x768.
If I want the proportions to stay the same in (worst example) 800x600, is there a possibility to scale the widgets down OGRE-sided?
Or do I have to create my own images for each res?

Do you understand what I mean? =)



edit:
Something like a
widget->getQuad()->setSize( new size... );
which iterates over all widgets and scales em up / down.
Ok, probably if the difference between the optimal res and the desired res is too big, you'll notice the scaling and be better off creating a own skin...

(still waiting for progress bar as child of image discussion.. )

Regarding the resolution, I'm not sure about that either. In earlier versions of QuickGUI, everything scaled with the resolution, but I didn't want to force this design, and combined with using anchors, this behavior was removed.

With vertical and horizontal anchoring, you can force widgets to scale when its parent is scaled. (ANCHOR_LEFT_RIGHT and ANCHOR_TOP_BOTTOM will scale the widget relative to parent) Keep in mind Sheets will always scale to viewport resolution/dimensions. (actually, I think just the active sheet is scaling, I need to check/fix this!)

So scaling widgets is now totally up to the user to decide or not. I didn't like how one of my favorite games warcraft III has a scaled UI (resolution independent), but not supporting this would be an unfair advantage for people with higher resolutions. Tough call.

[edit]
Once I complete the functions allowing for setting widget's skin, you could do something as simple as this, if you wanted:

mySheet->setSkin("zog_1024_768",true);
...
mySheet->setSkin("zog_800_600",true);

The only downside to this currently is that your skin textures will be named "zog_1024_768.button.png", etc. Maybe we can change this when the SkinSet Editor gets to a useable state.

[/edit]

I did a quick test with the anchor, and must say it works great!
If we can, we'll try to stick with them.