First of all, great job with QuickGUI. This is exactly the type of library that my team was about to start coding up because CEGui simply ran too slowly. So thanks for saving us time
Anyway, we've got a group here working on an MMO project pretty seriously, and since we'll probably be using QuickGUI fairly extensively in the near future, we'd like to help make improvements to the library and share them with the community.
So, to kick things off, there are a couple of small bugs that I was planning to tackle, but I wanted to run them by you first to get your thoughts:
A TitleBar's label does not center correctly if the window's closebutton is hidden. It appears to center as if the button were still there:
It would probably only take a simple if statement to fix this one.
The bar of the ProgressBar widget does not render correctly for small progress values (<0.3). This what it looks like with our skin (similar problem for the default skin):
By now it looks fine:
I'm not exactly sure what this problem is, but it seems that the resizing of the textures does not function properly when they are set to a very small size.
There seems to be a similar rendering issue with the TextBox text cursor, because in our skin, the text cursor is only 1 pixel wide, but is still renders as a fuzzy bar:
You may have been aware of these bugs, KungFooMasta, and if you could take a look at them them, that'd be great. Otherwise, I'd be happy to try some fixes if you'd like. I'm not quite fully familiar with the library yet, but I will be soon. I'm just not sure how to go about fixing #2 and #3 though.
I just remembered another bug.
4)When you display an image using the QuickGUI::Image class, the mouse slows down to ridiculously slow levels when the cursor is above the image, but it still is fast when it is not over the image. This makes me think that the problem might have something to do with the detection of the mouse over the image, but I'm not sure. Perhaps something to do with the transparency collision detect feature? I haven't yet looked into it fully.
Regarding bug 4, I saw that problem also! I think you might be right, I need to investigate that. It was ridiculous to see the fps drop so much when moving the cursor over an image widget, yet not have the same effect when moving of a window or other.
Thanks for the support!
For issue 1, I will have to look into it.
Issue 2, that is definately known to me, but I realized it a bit later after implementing it. The solution is to either have a box-like image for a progress widget, OR, the more elegant way (I hope), is to use an animated image. I plan to fix up this widget soon. Basically I will have to have 100 different images, one for each percentage, and then set the image at each state. For organization and cleanliness, we would probably want to throw these 100 images into a zip file.
Issue 3, the TextBox/TextCursor needs help. Originally everything was done with relative coordinates, but now I've made the slow migration to be able to specify position and size in Relative/Absolute/Pixel dimensions. I am finding there are lots of things that should have fixed pixel dimensions.
I will attempt to address these issues after applying another suggested fix, regarding add/remove child widget function. I've also laid out some groundwork for the editor I plan to make, so my time is short.
I hope when you dig in deeper you will find things easy to understand. So far everybody has been providing good feedback, regarding error reports and fixes. Lets keep it up!
Good to hear your thoughts. I'm happy to see that you're working on the TextBox widget as well (and adding focus support). A couple more things that may be helpful there are:
- Selecting text by dragging the cursor over the text
- Providing the option to change the cursor to a one of those text editing mouse cursors
- Setting the speed at which holding down a key will register as a keydown
I'm not so sure about the last one, but I was thinking it might be a useful variable to control.
And yes, after I get more familiar with the library, I hope to propose some more concrete solutions. I may also try some other approaches to the progressbar widget, because although the animated idea sounds good, it would be nice to not have 100 seperate images
We'll definitely keep it up!
it would be nice to not have 100 seperate images
True, although the zip would pretty much hide it. I doubt the size would be big either. (I'm hoping there is some way to make 100 images without me making them all individually. . .) We could try a hybrid approach, where the left end would be x frames, the right end would be y frames, and the middle would be one image stretched from the left to right. (x + y + 1 images) I haven't made a lot of progress bars, so I'm not sure if this approach would be helpful, hurtful, or neither.
Text Highlighting is a desired feature, but doesn't carry really high priority, compared to the effort to implement it. Especially since highlighted text is usually inverse in color. TextAreaOverlayElements can't have multi colored text, so I would have to override the class, for starters..
- Setting the speed at which holding down a key will register as a keydown
You're refering to the TextBox widget right? If you mean in general, I would say that's external or OIS. But if you're refering to how fast the text cursor moves from left to right while holding down the right arrow (for example), I think that's a good idea.
Somewhat related in terms of optimization, I bet a new pair of eyes examining the function GUIManager::injectMouseMove might be able to optimize the code some. There are a lot of possible comparisons in that function, which is called every time the mouse moves. This may be what's causing a big slow down when moving the mouse around.
I optimized the GUIManager::injectMouseMove function.. feels good inside.
The problem is exactly related to Widget::overTransparentPixel function. I need to figure out a better approach to achieving the same functionality. (This function tells me whether or not the point p is over a transparent pixel. Heavily dependent on the widget's material) I have an idea how I want to accomplish this, just wanted to let people know that I've found the root cause for the crazy FPS changes. If you can't wait for my fix, have this function immediately return false. Of course, then you don't have transparency picking..
I have fixed transparency picking issue, it works and FPS does not appear to change at all. In the process, I added the ability for all widgets to change their material. Basically when the material is set, I look for an image (Texture Unit State in the material script) and load it. If the widget has an image, then it will be used for transparency picking.
1 Issue resolved..
Hey, I'm from the same team as thecaptain and buysacoke. Thanks so much for fixing the transparency picking issue, we were just thinking about work-arounds when someone had the good sense to check this forum. Being able to define widgets in absolute values is a great help to us too.
Keep up the great work!
I found a small issue that you may or may not want to change in QuickGUI::Image.
I was trying to render to texture, using transparency, and I realized that unless I created my own material with scene_blending=alpha_blend, sending the rendertexture to as the image texture would not respect the transparency.
Adding the last two lines of code in QuickGUIImage.cpp fixed it:
mMaterialPtr = Ogre::MaterialManager::getSingleton().create(mInstanceName+"_RenderTextureMaterial",Ogre::ResourceGroupManager::DEFAULT_RESOURCE_GROUP_NAME);
Ogre::TextureUnitState* t = mMaterialPtr->getTechnique(0)->getPass(0)->createTextureUnitState(name);
Of course, this is a design issue, and I think you'd probably want to add QuickGUI::Image.setDefaultSceneBlending( x ) or something if you wanted to allow this.
Just an idea
Actually, I've been using mWidgetMaterial as an Ogre::String type, I'm thinking it might be better to have mWidgetMaterial be an Ogre::MaterialPtr. You can still get the name and check if null, but you can also get the material quickly and modify it.
I'll add in your code for now.
Just a couple more bugs that I've discovered that can be fixed when the time is right:
5) QGUI_EVENT_MOUSE_ENTER Events for buttons occur both when the mouse enters the button and when the mouse enters the label inside the button. Probably indicates that children widgets also throw these events when the parent widget has the event added to it.
6) Disabling buttons and then reenabling them leaves the text grey inside them. Looks like disable properly applies to children widgets, but enable does not.
I can put these fixes in, but I'll probably wait until you get a little further in the new render system. Good job figuring out the mouse cursor rendering! Hopefully the rest will be coming soon. By the way, what's your plan for rendering text? I'm thinking that there's got to be a way to render sharper looking text than what is currently being used (CEGui had sharp text). Does the moveable text code work for this?
5: I believe in all cases, the event fired goes up the parent chain looking for any handlers. Maybe I should remove this functionality? The main idea in my mind was that when you click on a widget that is part of the window, the window needs to know it has been brought into focus, and obtain the highest zOrder out of all other windows.
6: I probably forgot to restore the text upon enabling the widget. Easily fixed.
The biggest problem to tackle is that of maintaining zOrder. I need to make sure certain widgets appear over others, while making it easy to change up their ordering. (using windows for example)
I'm not sure what is meant about sharp text. Currently the TextAreaOverlayElement uses 6 vertices to render text, and I plan to follow that. Improvements would be the ability to stretch/squish text, and have text coloring on a character by character basis. The highest resolution you can get for characters would be the resolution of the characters in the .ttf file. You would have to play with the width/height of the text to make sure the ratio is the same as the ttf.
Moveable text inherits from Ogre::Movable and Ogre::Renderable, and I haven't studied it that much. Its more complex than regular 2d rendering because it occupies 3d space and has matrix transforms, etc.
For 5, I believe that functionality may have to be different for each type of event. For example, if I want to make a mouse-over sound for a button, the sound should only be made when the cursor enters the button itself, not labels within it and not the window that the button is contained in. Perhaps this is just really nit-picky, but it seemed like a bug to me when it made the sound twice (once for the button, and another for the label)
. Perhaps different events affect Zorder differently. Mouse click would probably change Zorder but not mouse over...
What I meant by sharp looking text is, well, that the text looks sharp and clear, not blurry. Here is what a button with a label looks like under QuickGUI:
And under CEGUI:
See the difference? The rendering in the second image is much more precise. Since we're using exactly the same .ttf file and fontdef file in both cases, it makes me think that the text rendering is different. There's got to be a way to have the sharpness of CEGUI without the inefficiency problems that it had rendering text (I think each character was its own quad!).
I thought about bug 5, and I think you're right. All I need to do is to make sure that the parent window (if the widget is indeed a part of a window) is brought to the front of zOrdering. I will remove the functionality of iterating through parents and checking if any events are defined for it. One exception may be with activation and deactivation, although those probably should be done on a widget by widget basis.
I see what you mean with the text, and I agree the CEGUI version of the text looks better. Guess I need to get familiar with the CEGUI code base and see how they're doing the font. This would probably be after v0.9.6 release. Thanks for pointing that out though, the sharp text looks attractive.