CEGUI (Crazy Eddie's GUI) Forums

Hi,

I've been using CEGUI for somewhere between 4 and 6 months now and I thought that I'd just give a bit of feedback. I am using CEGUI for the interface to a series of games related tools (map editor, physics editor) that form a part of a larger "game prototyping" system (aimed at developers, not your average joe).

These are my personal findings and I'm not stating that my opinions are the rule by any means! I'm sure that everyones experiences differ, this is just my 2 pence...

My opinion of CEGUI can be summed up as: Rather heavy weight, many nice features, generally flexible, good for tools but I wouldn't use it in a final "end-product" yet.

Memory: It would be *very* nice if you could initialise the CEGUI library with function pointers to custom malloc and free routines. This means that no dynamic allocations should occur prior to initialisation with the custom mem-routines.

Use of exceptions: Not a good idea if you want to maximise the CEGUI userbase in the games domain. Speed issues exist with some compilers when using various types of exceptions. Makes a mess of integrating CEGUI with a scripting language (see notes regarding LUA binding below).

LUA Binding: A good start but need serious work. The judicious use of exceptions throughout CEGUI causes problems with exceptions thrown due to a LUA function call pushing back up to the native code that executed the LUA script - while this behaviour is occasionally useful I would prefer if LUA could handle the exceptional situation itself sometimes. The only way around this (I can see) is to enclose each lua function binding with try/catch blocks converting specific exceptions into lua errors, others into additional return fields (lua functions can return >1 value) and just rethrowing the rest.
(I'm considering solving this by adding new functionality to the already-custom version of tolua++ I'm using to allow keywords in the package file to specify how the various exceptions should be handled for each function).

CEGUILayoutEditor: Again a good start, but I'll agree with other posters on this forum that I'd rather the base feature set be complete than partial support for the basic features and some advanced fancy features in the future.

Skins\Visual Customisation: Good flexibility, but a mess. Numerous config files specifying this and that and no good management tools for them. The forthcoming imageset editor from martignasse looks nice though!

Custom Renderer: Nice & easy to use - got CEGUI rendering through my custom gfx system in no time.

Logging: Ability to hook the CEGUI logging mechanisms to allow support for custom log-file formats\systems.

I hope that wasn't too negative, as CEGUI has really been useful to me these last few months and I am very grateful for all the hard work that Eddie and everyone else has put into CEGUI!

Please feel free to correct me if any of my issues are already addressed in the current version of CEGUI. I also realise that others have already pointed out some of the issues above!

Thanks,

Mike.

Hi Mike.
Thanx for the feedback, it's valuable and obviously based on real experience using the library

Some of the issues you mention have already been addressed in 0.5 (svn trunk) tho.

Lua: I have added a new modifier to the tolua++ generator, which allows you to control exception handling per function. fx:

This would add a try/catch block inside the binding function and for CEGUI::Exception it returns nil+exception-message. for any other exception (...) it raises a lua error.
It's been added to some methods but more could use it... It will come in time.

Logging: In 0.5 the logger has been abstracted so you can just inherit from CEGUI::Logger and instantiate it before initialising System to use your own derivative.

Memory: I generally think this sounds like a good idea.

Exceptions: To some extent I agree, tho the current approach is consistent. And if it should be changed it should be done globally. IMO. I would (personally) not object to changing it, but it would be huge job :/

Layout editor: yes it's not perfect, but there's alot of demand for it so even tho it might not be what everybody is looking for it's a start and works for some of our users.

Skinning: A little messy? Maybe, tho not IMO. But as you said it's very flexible and the different components are well seperated. Imageset, Looknfeel and Scheme. These three files all serve a specific purpose and together they form a complete skinning system. I'm not sure how we could simplify it. Except for maybe a wrapper with a simpler interface. If you have ideas to how you'd like it improved please ellaborate. But we (the CEGUI team) are very pleased with Falagard. It's certainly better than the old C++ based approach.

I'm not trying to put your points to the ground and would love to see this thread evolve. So... Keep bringing in that feedback

MikeW wrote:My opinion of CEGUI can be summed up as: Rather heavy weight, many nice features, generally flexible, good for tools but I wouldn't use it in a final "end-product" yet.

That view is shared by a lot of people, and that's too bad.
Would be nice if we could define "heavy weight" and put up a list of things which might compell people to use it in final end-products.
Personally, I think CEGUI compares nicely with other GUIs in commercial games.
But the opinions differ.

MikeW wrote:Use of exceptions: Not a good idea if you want to maximise the CEGUI userbase in the games domain. Speed issues exist with some compilers when using various types of exceptions.

Is that because games programmers still insist on living on the edge code-wise?

MikeW wrote:Skins\Visual Customisation: Good flexibility, but a mess. Numerous config files specifying this and that and no good management tools for them.

I agree.
Would be great if management tools arrived which eliminates the need to ever look at them again.

Thanks for the feedback on the feedback!

lindquist: I like what I'm hearing! Your handling of the Lua exception issue is basically the same as what I was planning - an extra tolua++ keyword or two. I was also considering allowing "exception blocks" to be specified in tolua++ packages. These would just be syntactic sugar for specifying the same parameters for a group of functions - may improve readability of the package files.

The logging abstraction is just what I am after...

Also, a point I didn't make before for greater control of memory management is that it is another thing that would make CEGUI more attractive to more games developers I think. Fast & efficient memory management really cannot be overemphasised in my experience.

Exceptions are funny things... From a pure computer science point of view I can see the need for them to exist and from a practical point of view they also serve a purpose. Problem is they come with an added overhead (not as bad as it used to be). Personally, for projects using exception handling, I tend to only use exceptions when a situation occurs that either directly prevents the following code from working properly or when an error occurs that cannot be expressed by the function's return value (but even then I try to avoid them). You'll never please everyone in this area!

I didn't mention that I've used the existing layout editor for all layouts in my current project.

After I wrote my message I started thinking about the skinning system a bit more. I think that now I understand it better and I understand how each file controls one facet of the total information required to put a gui on the screen.

I'm not trying to put your points to the ground and would love to see this thread evolve.

No problem. Without these kind of discussions looking for a middle ground of sorts between everyone's desires development would no doubt end up following some tangent or the other! (As it would with any project without feedback).

jacmoe: Definition of "heavy weight", Hmmm... I guess it is a matter of "imposition": When you use CEGUI what does it impose on you?

Currently, an extra 1.5+ MB to my game distro whether or not I want to just pop up a game title and main menu screen or a much more complex RTS style interface. Also it requires that I use exception handling and that I do not have fine control over the memory allocation issues.

Ideally any library should only impose the bare minimum required to to the task you are asking it to do, not always achievable in the real world but it's good to dream!

Is that because games programmers still insist on living on the edge code-wise? Smile

Lol! Originally it was mainly it is to do with speed issues. I forget all the details now (I investigated the whole exceptions vs performance thing a few years ago now) but they are definitely one of those "religious" issues. I think that nowadays the speed issue is probably becoming less important w.r.t. exceptions, but the problem is also that exceptions can be used in so many different ways and not everyone agrees on the "correct" manner.

Right, I promise to keep all further posts to at least 75% shorter than this one!

Thanks again,

Mike.

Hi,

I was about to send more or less the same post as the OP.
We have been using CEGUI for 4 months now.
We are using it for our next commercial game (so a final "end-product" )
As a game developper I agree with everything that has been said by Mike.
(Except what was related to the lua binding, since we are not using it)

Memory: Ability to customize memory management is really missing.
(We are using custom memory managers here)
As already said, simple function pointers to custom malloc and free routines would be enough though.

Use of exceptions: We are not very happy with that. When possible, we really avoid them all over our codebase.
We also modified the code to replace throw's by a custom macro that allowed more control (for example it breaks into the code before the exception is thrown)
We also found that some usages of exception were abusive (like try/catch around file opening to test existence. Such exceptions are just poluting our debug output).

Logging: Latest (trunk) CEGUI::Logger version seems much better than the one we have here.

CEGUILayoutEditor: We had to take the code and add a lot of features before it became usable for our artists.

Skins\Visual Customisation: Configuration files are ok, except for lookNFeels that appeared to be a bit difficult to use for non-programmers here.

But except from that, the major problem we are facing here is bad performances, especially in two situations:
- Lots of text. Quads rendering takes huge time when we have lots of text on the screen.
- Lists creation. Loading lots of items to populate lists takes a lot of time, even with our custom resource provider that allow item layouts file to be loaded only once for all.
What takes time here is multiple parsing of the layout when cloning would be the appropriate solution (Then registering callbacks for every items also take time of course)
But maybe we missed something here, because populating big lists the way we do it is really unefficient.

Despite all the criticisms (that I hope are constructive) we choosed CEGUI because we think its a very good library that can save us a lot of time.
So to summarize we really hope the next version will not come too late for us (and that upgrading will be easy of course)
We'd be happy to share all the code changes and additions that we did in CEGUI as well as in CEGUILayoutEditor if it is helpfull.

All the code change on the editor or anything else is welcomed. Since we are working on improving the editor at the moment.

Skins\Visual Customization: It's another area which requires a visual editor.

Chocapic wrote:We'd be happy to share all the code changes and additions that we did in CEGUI as well as in CEGUILayoutEditor if it is helpfull.

Yes, that would be great!
I think that the CEGUI project really depends on real-world projects submitting real-world modifications.
This would make CEGUI a much better GUI library.