QuickGUI for large projects?

I'm developing a rather large game (http://www.vendara.net) and the project is to the point where we need to start implementing a GUI. Right now I'm looking at CEGUI, RBGUI, QuickGUI, or hand coding one if none of those fit. QuickGUI seems to be the most suiting out of the bunch (its lite, easily integratable, etc.). But, after downloading the QuickGUI demos I noticed that it has quite a few bugs. For instance, the console crashes after more than 30 lines of text, when running the demo with the OpenGL engine fps is about half, and some portability issues. How are things coming with QuickGUI; is it going to be a well maintained project or should I look at other GUI systems?

Thanks for the interest.

First of all, I spend anywhere from 10-30 hours a week adding in features and bug fixes to QuickGUI.

Issues that are brought up on the forum are generally solved in short time. The library started in April, so it's really young in comparison to CEGUI. As for RBGUI, the library is a great starting point for a UI solution, but I don't think its maintained by the original author anymore. Not only that, but I have yet to see a unique skin with the library, I have a feeling its not as easy to skin as one would hope. So basically, CEGUI is my only competitor.. although it is a great competitor. Large user base (testers), lots of widgets, and the basics of a layout and skinset editor, make it tough to compare. What QuickGUI offers that CEGUI doesn't is: active development, ease of skinning, ease of use. Granted there are bugs like you say, but I'm usually quick at handling them.

Its true that QuickGUI's more complex widget set needs work, for example, I'm continously working towards a TextArea and MultiColumnList widget, but a lot of core design features keep showing up. I have not created a GUI library before, and as such, I'm always finding a better way to accomplish things.

Another appealing factor of QuickGUI in active development is that I am more capable of adding in features you want, especially if they benefit others.

What is the time frame of your project? I imagine QuickGUI should be getting decently stable within a months time.

DX vs. OpenGL: I haven't ran any performance tests, but I see OpenGL as only a little lower in FPS than DirectX. I ran VTune over the code a little while ago, but didn't find any obvious spots for optimization. I will probably analyze the code at a later date, to see any potential optimizations.

Portability Issues: What platform are you using? There are QuickGUI users on Linux, and some using Code Blocks IDE. Although I'm not familiar with these platforms myself, there are users available to help.

Console: That issue is already fixed in my code, but I'm working on something and can't commit at the moment. Normally I would just fix and commit immediately, but I'm working on some core features related to skinning. (fixes applied during the process, I fix bugs as soon as I can)

Hope that answered some of your questions!

For anybody who is interested, I just looked into CEGUI and RBGUI for ways that QuickGUI could be optimized. From what I see, RBGUI is really well written code, very clean and organized, but there is no effort put into Batching. Basically you iterate through each Widget Container, drawing each Widget as you come to it. In my case, I have Quad containers that sort Quads according to zOrder and texture, and send as many similarly grouped quads at the renderer as possible.

The only main optimization QuickGUI needs is the CEGUI idea of the RenderCache. The idea would be to make the Sheet into one texture, and each Window into it's own texture, and render only a few quads per frame. The problem with this is that its not easy to cache text. I'm not sure the performance hit resulting from rebuilding a cached image for text every time a letter is added or removed.

I don't plan to tackle this anytime soon, I'd rather improve and add to the widget set, and move toward stability. But at least I have an idea as to how QuickGUI could be improved, to increase performance. This is pretty much the only area of QuickGUI that can be optimized for performance, as far as I know. Regarding OpenGL vs DirectX performance, I don't do any special operations that would favor one implementation vs the other, the library uses whatever Ogre provides me. Maybe OpenGL likes lots of small batches sent to the renderer instead of large batches, I don't know.

Great to hear, so many improvements ahead! Keep up!
And my 2 cents on OpenGL vs DirectX - from the tests I did the do more or less the same. Actually OpenGL seems a bit better with loads of tests.
Yeah, and a note - I also did some test to the code via AQtime, and it seems that the greatest performance hit is indeed with the text. Basically, a text like 100-200 characters, fully updated every frame seems to hit performance as badly as 30-40% of the original. Just some info, anyways.

Actually its funny, because in the back of my mind I was thinking about Text, and how it could be optimized. Changing the text means I have to update the entire quad container storing the text, which is not ideal. I need to be able to have each string of text as its own VertexBuffer, so I only update a minimal number of quads.

Now that I think about it, there are some optimizations that can be done with Text, I will add these to the list.

Thanks for the information. I saw you mention AQtime in another thread, and I'm interested in trying it out, when I come around to analyzing the code again. Maybe it will be more helpful than VTune. VTune was pretty cool, but the VS integration sucked, and I couldn't easily navigate through all the function calls. I found myself looking at execution times of stl containers a lot.. iterator access, traversal, etc.. not much I can do there.

Good to hear about the advancements and bugfixes. I think I'm gonna wait until you update your svn repo before I integrate a test GUI into my project because I want to use console to make a basic chatbox as the first GUI test. After that I can do some more tests with Direct3d vs OpenGL and see if theres still a noticeable difference.

Hopefully tomorrow I will have the majority of the day to hammer things out. There is one last important issue with ScrollBars I haven't yet addressed, which is a minimum slider thickness. Since I have *live* scrollBars, where the slider thickness represents the ratio of viewable space to total space, the slider gets more and more thin as you add text to the console. I need to be able to cap the slider from getting too thin, while being able to properly scroll through all the text data. This is scheduled by next release, its a little difficult to implement, since it defies the *live* implementation I have in place.

Just a thought, but why don't you leave it 100% *live*? That would make it more original as well. Plus, I doubt there would be times, when it would get too thin, as after all it is a GUI system, not some encyclopedia

I might take your advice on this, given the small size I had the console at, you'd need around 50 or so lines of text to make the slider tiny. Any normal console would be wider and maybe taller than what I used in the demo. Either way, I could probably push it off for now.

I downloaded quickGUI svn and it is a VAST improvement from the current release. Great work there; I'm starting to implement it into my project now that I've played around with it a little bit. I hope theres more good stuff to come.

Always! But it might not be lightning fast, I mix in features, bug fixes, and requests... its a bit to take in!

my new games is unfolding with QuickGUI,
i love quickGUI because is very very "quick", Instead CEGUI is slow, i don't like