CEGUI (Crazy Eddie's GUI) Forums

Hi,

Firstly, a big welcome back to Crazy Eddie. I first used CEGUI a few years ago, and was worried by his absence!

And well done to the rest of the team for keeping the project supported.

So v0.6 eh?

This brings me back sniffing around CEGUI. I have a few questions about current capabilities.

1) Is there DX10 support?
2) Are animated buttons/graphics possible without hacks?
3) Can windows 'transition'? Eg Fade in, Fade out, zoom, collapse, rotate, layer in 3d space, etc
4) Can the functionality of CEGUI be used with my own custom renderer?
5) Any plans to integrate new C++ functionality? Eg boost::bind overloads for events?

Many thanks

Simon

sipickles wrote:Firstly, a big welcome back to Crazy Eddie. I first used CEGUI a few years ago, and was worried by his absence!

Thanks for the welcome

sipickles wrote:1) Is there DX10 support?

This was added in the 0.6.1 release.

sipickles wrote:2) Are animated buttons/graphics possible without hacks?

Depends on your definition of hack, I suppose. There is still not much in the way of what you might call "integrated" animation support.

sipickles wrote:3) Can windows 'transition'? Eg Fade in, Fade out, zoom, collapse, rotate, layer in 3d space, etc

Some windows internally fade themselves, there is currently the concept of a 'Task' which I think is suppose to allow adding such things to any window, though to be honest I've not looked at this too much, and given where it originated from, I don't hold much hope for it's implementation, robustness, or it's chances of remaining within the library.

You may be aware that the rendering layers of CEGUI are currently being rewritten, and some of the effects you mention are definitely things I would like to support. The rendering rewrite is intended for the 0.7.x series of releases, the first of which should be made this year.

sipickles wrote:4) Can the functionality of CEGUI be used with my own custom renderer?

This was always the case.

sipickles wrote:5) Any plans to integrate new C++ functionality? Eg boost::bind overloads for events?

CEGUI used to use boost::bind as parts of its event implementation. Everybody moaned and whined about our use of boost, so eventually this was removed. There are no plans to add it back.

Obviously when evaluating CEGUI's progress, especially during 2007, you need to consider the various events that took place regarding the development team. Effectively, we are 12 months behind where we should be

CE.

CrazyEddie wrote:

sipickles wrote:1) Is there DX10 support?

This was added in the 0.6.1 release.

Great!

CrazyEddie wrote:

sipickles wrote:3) Can windows 'transition'?

You may be aware that the rendering layers of CEGUI are currently being rewritten, and some of the effects you mention are definitely things I would like to support. The rendering rewrite is intended for the 0.7.x series of releases, the first of which should be made this year.

I think this is a must. GUI have taken leaps lately (Think compiz) We need to keep up with that - its just what people expect nowadays. 2d static windows juts don't cut it anymore.

CrazyEddie wrote:

sipickles wrote:5) Any plans to integrate new C++ functionality? Eg boost::bind overloads for events?

CEGUI used to use boost::bind as parts of its event implementation. Everybody moaned and whined about our use of boost, so eventually this was removed. There are no plans to add it back.

Surely, an overloaded option can please both boost users and the luddites (;)).

CrazyEddie wrote:Obviously when evaluating CEGUI's progress, especially during 2007, you need to consider the various events that took place regarding the development team. Effectively, we are 12 months behind where we should be

What project isnt?!

I am glad to hear CEGUI has plans. I think we will implement it for our debug GUI, and hopefully include it in our release versions as more transition functionality arrives.

Thanks for your help.

----- ps any links to wiki or docs on Custom renderers?

sipickles wrote:----- ps any links to wiki or docs on Custom renderers?

For this moment i'm affraight you have to look at existing renderers. We provide an Irrlicht renderer, and the Ogre team provides an Ogre renderer. The source code of these hopefully provide insight on the steps to take with your own renderer.

But i am not the rendering expert!

scriptkid wrote:But i am not the rendering expert!

Hmmm. Neither am I! I wonder where this leaves us?

Do you accept contributions to the source code from non-team members?

sipickles wrote:Do you accept contributions to the source code from non-team members?

We do accept, and would even like to encourage, contributions from non-team members. There are, of course, some things to be kept in mind:

* Obviously you grant us the right to license the contribution under the MIT license using our umbrella copyright notice, although you will, of course, receive credit in any full source files contributed, and also in the AUTHORS file.

* If you're writing something specifically for us, it's probably a good idea to get into a discussion about what you're going to write and how you intend to implement it. There would be nothing worse than spending valuable time writing something to be told that it conflicts with other work or is not suitable due to the implementation.

* If you're submitting patche files, ensure that each patch file is independent and does one thing only. IMO there's nothing worse than a patch that is supposed to perform a certain modification, and then turns out to affect and 'tweak' various other non-related things - patches like that will just end up in the bin

* Contributions should be in the same general style / format and use any coding standards we use. Details of all of this can be found in CE's early test docs for the 0.7.x series, here.

* CrazyEddie is a perfectionist and a hard-arse! Some past contributors have had a rough ride - those who stick at it end up producing really excellent stuff, though

Can't think of anything else at the moment.

CE.

CrazyEddie wrote:

sipickles wrote:2) Are animated buttons/graphics possible without hacks?

Depends on your definition of hack, I suppose. There is still not much in the way of what you might call "integrated" animation support.


CE.

I also like animated windows (motion, fading, sizing, flashing), i've created my own animation layer on top of cegui. I have found that CEGUI made it easy to animate windows, though the animation is not part of cegui itself.

CrazyEddie wrote:

sipickles wrote:5) Any plans to integrate new C++ functionality? Eg boost::bind overloads for events?

CEGUI used to use boost::bind as parts of its event implementation. Everybody moaned and whined about our use of boost, so eventually this was removed. There are no plans to add it back.

CE.

Gee wizz wonder what the state of boost was at the time. I've recently started to use boost and I love what I've seen so far. Currently I use shared pointers, asio (networking recently added to boost), filesystem I/O, and other boost tidbits. I intend to use it more fully as I grow in my development.

What were some of the complaints about boost?

daves wrote:What were some of the complaints about boost?

Many people had inordinate problems compiling the boost dependency - I think this was the number 1 issue. I never understood the issues, generally I never had any real problems with building it.

I think the final motivation for removing the use of boost::signals (and boost::bind beneath it), was due to having boost related items present in the public interface. Basically, having CEGUI depend on parts of boost is one thing, but having user / client code inherit that dependency due to those parts being present in the public interface was/is unacceptable.

Ultimately a replacement was (under my direction) written and contributed by a user - this was in use until the 0.5.0 release at which time I had to rewrite it due to not being able to get permission to re-license the contributed code as MIT (from LGPL).

CE.

CrazyEddie wrote: Basically, having CEGUI depend on parts of boost is one thing, but having user / client code inherit that dependency due to those parts being present in the public interface was/is unacceptable.

Makes sense.