CEGUI with Ogre

Forum for general chit-chat or off-topic discussion.

Moderators: CEGUI MVP, CEGUI Team

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

CEGUI with Ogre

Postby CrazyEddie » Sun Jun 06, 2004 13:12

Hi,

Glad you got it working :)

Compiler option /Zm is the precompiled header memory allocation limit setting (400 will allocate a maximum of 200MB of space), the CEGUI projects are all set-up to not use pre-compiled headers (yet), so this should really have no effect at all. To answer your question, I have never seen any problem like this; when I did the initial project files for MSVC7.0 they all compiled without any problem, though I haven't tried it lately ;)

Thanks for the suggestion about making the Renderer for Ogre (or even the whole system) an Ogre plugin. When the project was originally being discussed over on the Ogre forums, sinbad specifically stated that he would prefer any replacement GUI to not be a plugin, so that's the number one reason that it isn't done that way. :)

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

CEGUI with Ogre

Postby CrazyEddie » Sun Jun 06, 2004 13:32

hehe :o I wondered when this would come up :mrgreen:. I'm going to have to add a setting of some kind to the Ogre GUI Renderer where you can specify which scene manager you want to use, as at the moment it's hard coded to ST_GENERIC. It's on the long list of things to do...

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

CEGUI with Ogre

Postby CrazyEddie » Sun Jun 06, 2004 15:47

Glad you got it working under the other scene managers. A similar modification will be made to the CVS version of the system in a few days or so (may be a little longer).

The point of rendering 3D objects into GUI elements has come up a lot, and is something that will definately be put into the system at some point in time. My current thinking on this (though no decisions have been made at all regarding this) is to render the required geometry to a texture that is the basis for an Imageset. The GUI system can then draw the the texture (the contents of which can change as ofted as required, since the GUI does not care what's actually on there) to the screen as part of some widget.

How to implement this? Well, you can already create an Imageset from a ready made CEGUI::Texture (then you just have to manually define some Images). All you need is to add a method to the Ogre CEGUI::Texture / Renderer specialisations that allows you to pass in a ready made Ogre texture and return a CEGUI::Texture, that should be all that's required (not tested it yet though).

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

CEGUI with Ogre

Postby CrazyEddie » Sun Jun 06, 2004 19:16

It's not my place, nor my wish, to integrate the GUI into Ogre any further than the Admin for that project has requested. As sinbad told you, the GUI is to remain a separate entity - this way when a person develops their application, they choose which graphics engine to use, which GUI library to use, which sound library to use, and so on... In addition to this, although much of the interest in the library is from the Ogre community, the system has to remain pretty much the same to use on any targeted graphics engine / api.

Currently the only thing that i think is dissatisfying with CEGUI is the event handling, i think "the ogre" eventhandling way looks a bit less messy if you ask me.


I do not understand what you mean by '"the ogre" event handling way'. The system was put together without referencing the current Ogre events system at all. My primary goal was to improve on what was in the GUI system in previous versions, which I have done. To have every possible event sent to a central place for collection and processing would not be good in my opinion, the application would get thousands of events that it doesn't care about and would most likely take a performance hit for its trouble. The way the system is now, the application only ever needs to hear about the events it wants to (the whole point of the event subscription system), while the internal system and classes can specialise behaviour as required (the whole point of the on<some event> handler system). For a centralised system I believe you'd end up with a collection of event 'codes' which you switch upon 'Windows style' - personally I have an aversion to huge collections of such codes.

At the present time I am satisfied with the system the way it is. There is still so much work to be done before the initial Mk-2 release, and ripping out the heart of the system at this stage is not a priority :lol:

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

CEGUI with Ogre

Postby CrazyEddie » Sun Jun 06, 2004 20:49

:oops: sorry if it came to sound like a "flame" of the event managing way you have choosen to use.

That's cool. No need to apologise - you can say whatever you want ;)

I just think that when using CEGUI in a target application compared to how ogre works, the eventhandling looks and feels better in ogre.

Prior to writing the GUI Renderer class for Ogre, I had never used Ogre (though I was aware of the project). I do not have any experience using Ogre in an application, so can't compare the two or comment any further on that side of things.

I didnt mean how it was ment to do on the inside of CEGUI, do you have some design notes about your eventsystem ? maybe some UML diagrams or something, It would be great for me to get a larger view on how things work.

I can't design at a computer. All my design stuff is done as scribblings on paper, I did have a diagram of all the classes in the system and how they interact with each other (not much on the input system though), I can't find that stuff at the moment - I may even have binned it all :oops: (it will probably turn up eventually, I hope so because I wanted to use it as the basis for some of the docs :)).

I'll just waffle on for a bit about the internals of the event system instead :lol:...

The system for inputs entering the GUI is basically the same as it was in the older versions (though simplified, the System object can now auto-generate some events itself based on the events it is given - like double clicks are generated from mouse down events). The GUI does no discovery of inputs on its own - all inputs are fed into it. These input events are then forwarded to whichever window (every UI element is a window) has focus (or has captured input) - via an on<some event> handler (such as onMouseMove). Each specialisation of the Window class overrides the on<some event> handlers for the events/inputs it is interested in (and may define other on<some event> handlers which may be further specialised in derived classes. For the input events, any input not handled (signalled by not setting the 'handled' field in the passed EventArgs object to true) is passed back up through the parent window(s) until it is handled or the top of the window heirarchy is reached. An on<some event> handler may also fire an external event which can be subscribed to by interested parties (though presently no 'Input' event ever fires an external event).

The external events and subscription system was partially inspired by the way that .Net and C# handles events, and obviously uses boost::signals internaly to implement the system. The base window class has a large number of external events available (at this stage some are still not wired up yet), and other windows and widgets define new external events as appropriate. Every external event is matched by an on<some event> handler in the class that defines the event, though (as stated above) not every on<some event> handler will have a corresponding external event.

Im going to wrap up a small "OgreRefApp::GuiManager" framework which is able to utilize CEGUI as a guisystem. or any other system out there for that sake, that was what i had in mind when I wrote the last post, i just wanted to hear your oppinion :)


I see - why didn't you say so :P I'd be happy to see what kind of thing you come up with. Don't think that when I say I'm happy with things how they are that I'm not interested to see how others are able to change / use / integrate the system. Or that I'm not open to feedback and suggestions - the system is how it is now because of feedback and suggestions ;)

User avatar
leedgitar
Not too shy to talk
Not too shy to talk
Posts: 29
Joined: Wed Jan 12, 2005 12:06

CEGUI with Ogre

Postby leedgitar » Mon Jun 07, 2004 05:50

I just think that when using CEGUI in a target application compared to how ogre works, the eventhandling looks and feels better in ogre.


You may be the first person to ever feel that way :wink: Note the Ogre team will be promptly removing all interactive widgets from their CVS tree in favor of using this GUI as a 3rd party lib within their demos and such.

Anyway, are you talking about how input events are registered with the system, or how events are handled internally within the widgets, or...? Can you give specific examples of exactly what you are referring to ?

User avatar
nfz
Not too shy to talk
Not too shy to talk
Posts: 27
Joined: Wed Jan 12, 2005 12:06

CEGUI with Ogre

Postby nfz » Mon Jun 07, 2004 20:33

I prefer the use of signal/slot (or multicastor design pattern) as the event mechanism which is why I chose CEGUI as the GUI to use along with Ogre as the renderer. I think once people start using CEGUI a lot more, they will applaud Paul for using the multicastor approach to the event system since it makes things so much easier to set up and is considerably more flexible than Ogre's event system.

User avatar
CrazyEddie
CEGUI Project Lead
Posts: 6760
Joined: Wed Jan 12, 2005 12:06
Location: England
Contact:

CEGUI with Ogre

Postby CrazyEddie » Tue Jun 08, 2004 09:01

The CEGUI Events system - Crazy Eddie's final word...

The thing to realise here is that it's not like I just randomly stuck a pin in a list of event signalling methods and went with it :) As some people reading will already know, the whole GUI system was discussed at length back in February on the Ogre forums, and as a direct result of that discussion the entire GUI system was redesigned from the ground up. Even before this, I had acknowledged that the event system in Mk-1 was possibly the worst invention ever :oops: (so if anybody doesn't like the new approach, they should try using the old one :P) So, I was on the look out for something better, the signals/slots approach was mentioned in the discussion I believe - and this matched closely with my own wishes for this area of the system, so the decision was made. :twisted:

User avatar
mac
Just popping in
Just popping in
Posts: 16
Joined: Wed Jan 12, 2005 12:06

CEGUI with Ogre

Postby mac » Thu Jun 10, 2004 10:58

Sorry to "spoil" you last word...

I just wanted to say that your gui system looks brilliant (features and also internals)!!!

cegui-mk2 is much better than the old implementation from ogre!

Also: You are making big steps forward - so it't no problem when you miss your own deadlines by a few days. Most software projects have a little delay - and many many aren't even finished. :)

Keep on going (at this pace...),
Thank you,
mac


Return to “Offtopic Discussion”

Who is online

Users browsing this forum: No registered users and 1 guest