More Infos about Beta-1 Please

[zola]

Hi CE

Cool to see that the beta branch is now merged back with the CVS Head.

Could You tell us more about the beta-1?
Besides the API that changed a bit, what are the major new things?
How does the speed compare to the old CVS Head?
Are there any goodies in the beta You especially like?

Make some consumer advertising

Cheers
Tom

[CrazyEddie]

Well, to be honest, there's not much to tell. It was all really a huge clean-up job to lay some better foundations for what's still to come. And lets not forget that the beta is not technically released, I've just done most of what I'll be doing to the core system until it is released; which means almost no more new features will be added for the time being, although bugs will obviously be fixed as they show themselves.

Most of the changes made are in one way or another related to the API modifications. The goal, as stated above, was really to tidy some things up, make many parts of the system more consistant, and try to give the application writer more power and control over what can be done with the events system.

There are also some changes in there that attempt to allow different platforms to run off the same set of data files. I've also started using the new file naming convention agreed with _mental_ a while back.

With regards to speed; I'll say it has the potential to be faster. That's an odd answer I know, so I'll maybe explain that a little. There was a rather large amount of time being spent messing around manipulating colours, this is why the the colour class was introduced. This itself does not really help matters much, to get any benefit some adjustments are required to the renderers. The only renderer so adjusted at the moment is the OgreRenderer, and you definately should see some difference there. The other renderers will be updated in due course. There are various other performance related things just over the horizon too, though I'n not sayingmuch more on that subject just now...

I wouldn't say there's anything in particular that I consider a 'killer' feature right now. I'll just say that I'm now much more satisfied that the system is at a point where future development can continue without the need to break peoples code every couple of days.

So, possibly not the enthusiastic reply you were expecting, eh?

CE.

[CrazyEddie]

I couldn't register, it said "Invalid nickname", so I'll post anonymous.

Delete the sourceforge cookie 'username' and the registration will work. It's a known issue.

- I think you forgot to add CEGUIConfig.h to include/Makefile.am

Yes, I think you're right

- There are some inline methods in CEGUIcolour.cpp which never make it to libCEGUIBase.so . I guess it's because they're never referenced. I compiled it with "gcc version 3.4.1 (Mandrakelinux 10.1 3.4.1-4mdk)". When compiling an ogre app against the lib you'll get errors. Those methods are:

Code: Select all

colour::setAlpha(float alpha)
colour::operator=(ulong val)
colour::operator+(const colour& val) const
colour::operator-(const colour& val) const
colour::operator*(const float val) const


I removed "inline" from them, and then it worked.

Okay, I'll look into fixing this on Saturday morning

One thing that's confusing when using Ogre renderer is that image files are accessed through the Ogre resource manager, while fonts are accessed from the applications current dir.

Yes, this is just the nature of things at the moment. There is work being done on a resource provider for the system.

CE.

[Injector]

I hope this won't be considered as thread hijacking, but I thought it would be better than starting a new thread (since my question plays well with the subject line )

Just out of curiousity:
What were the reasons to implement the event system anew and going away from boost::signal/bind?
Are there any advantages besides the removed dependency?

Injector

[CrazyEddie]

Just out of curiousity:
What were the reasons to implement the event system anew and going away from boost::signal/bind?
Are there any advantages besides the removed dependency?

Well, the number one reason was to remove the boost dependancy. There have simply been so many issues related to the usage of boost it's not even funny.

The main thing I didn't like about boost::signals, was that it meant that not only was CEGui tied to using boost, but also, every application that used CEGui also needed to have boost available; so it wouldn't be possible to package up a pre-compiled CEGui and just use it SDK style, you'd also need to have boost downloaded and compiled as well [1] (which many people do not want, do not like, or are unable to get it to work properly).

Don't get me wrong, I still like boost; regex and the lightweight timer libs are still used within the system itself. But to quote Sinbad...

I admire Boost a lot, but when it goes wrong it's like a box of rabid squirrels; there is just no way you wanna put your head in there.

The solution we have now is quite a bit simpler than boost::signals, so is easier to trace through when things go wrong. I also feel that the new solution offers more control for me, and as such would make extension and/or improvement much easier; previously any such changes may have needed to go through some kind of proxy layer, though now any modifications can be made directly. These are really just side effects though, it was all about dumping boost::signals



[1] boost::timer is still exposed in the public headers, this will be changing. By the time there is an actual 'release' made, boost will only be required to compile CEGui itself.

[sazzer]

One huge advantage from not using boost::bind for the events is that you can *possibly* use CEGUI/OGRE from managed code now.

A while back I was doing some mucking around at using Ogre/CEGUI ni Managed C++, and everything worked fine except for the event handling in CEGUI - it would always throw a hissy fit when an exception was called. The reason is that the managed function pointers are different from the normal ones... I've not tried the new code so it might still have the exact same problem, but it's possible that it doesn't, and if it does it's probably easier to get working now
--
Graham

[CrazyEddie]

One huge advantage from not using boost::bind for the events is that you can *possibly* use CEGUI/OGRE from managed code now.

This sounds interesting, let us know how that goes if you try again I'm not surprised boost::signals caused issues there; it's a complex piece of code, and in many ways far more complex than what was needed for this system. With any good fortune, this new system will npt cause any one any issues, and we're all happy.

CE.

[gcarlton]

In many ways, boost is far more complex than what would ever be required.

Any word on what the hand-rolled version will look like?

[CrazyEddie]

In many ways, boost is far more complex than what would ever be required.

Hehe, very true.

Any word on what the hand-rolled version will look like?

The new code is in CVS now. Look at the files CEGUIEvent.h, CEGUIEvent.cpp, CEGUIRefPtr.h, and CEGUIRefPtr.cpp. The good news is that 99.9% of code will work without needing any changes at all. The only changes that may be needed is if you were previously using the returned Event::Connection object to control the connection; though this went against the advice in the docs anyway, since the interface for that was undocumented.

One of the other main things that you'll notice is that the system now takes about 4 minutes to compile as opposed to 20 minutes.

CE.

[CrazyEddie]

Does this mean I get rid of the bind-includes in my project as well?
And if yes, how?

You can, but you don't have to. The new means of binding a member function to an event is as follows:

Code: Select all

Event::Subscriber(<method here>, <ptr to object with method>);

so as an actual example of how to bind to EventClicked:

Code: Select all

myButton->subscribeEvent(PushButton::EventClicked, Event::Subscriber(&MyHandlerClass::buttonClickHandler, this));

where 'this' is an instance of the class MyHandlerClass.

This is very similar to the original boost:bind code (in fact you just change boost::bind to Event::Subscriber and lose the _1 parameter).

Hope this helps.

PS: I really miss your waffle thread...

I don't have a lot to waffle about these days, I'm mostly doing bug fixes, and also trying to work on a 'Getting Started with CEGUI' guide book.

CE.

[gcarlton]

After a week writing docs, I got back to coding today with an upgrade to NET 2003 and latest from cegui cvs.

Happily, everything worked fine, pretty much straight up. One change I had to make was a functor listener, since its operator() wasn't const. Not sure why that used to work under boost, looks like they may have duplicated code to support both const/non-const versions.

If so, it seems neater just to have one interface, as you have done it.

Also, I found cvs has every cpp/h change I had made to cegui, so I've got the proper unsullied code again as cvs intended.

[mac]

@CrazyEddie: Thanks for the info! Can't wait to read your book...