CEGUI Manager Class

For help with general CEGUI usage:
- Questions about the usage of CEGUI and its features, if not explained in the documentation.
- Problems with the CMAKE configuration or problems occuring during the build process/compilation.
- Errors or unexpected behaviour.

Moderators: CEGUI MVP, CEGUI Team

CrimsonGT
Just popping in
Just popping in
Posts: 7
Joined: Mon Jul 12, 2010 12:30

CEGUI Manager Class

Postby CrimsonGT » Mon Jul 12, 2010 12:42

So I was working on a game to kind of learn Ogre more in depth for quite a while. I recently started rewriting it from scratch to clean it up better, and along with this I decided to switch from Canvas to CEGUI. I managed to get some buttons and what not working, and it was quite a bit easier than I assumed. (Feature filled packages usually have quite a learning curve)

Anyways, I am trying to keep everything wrapped up nice and organized this go around, and I wanted to create a GUI Manager class to kind of handle everything. I am still fairly new, so these might be really stupid questions but here goes...

1) I obviously have state management in my application (login screen state, game state, etc). Im wondering if CEGUI has a feature to destroy all existing GUI elements, or if I should just destroy the CEGUI instance when changing states? The first seems much more efficient (keeping the singleton ptr for CEGUI persistent through the life of the application rather than destroying/recreating it to clean up between state switches. What would the recommendation be for this?

2) Canvas didn't really support loading layouts/schemes/etc from XML/LUA so this is a bit new to me. Is the general approach to just hardcode in the GUI elements that won't be changing, such as the main game screen, and use lua script for the others to make quick modifications? Or when using LUA, do most people just use it for everything instead of breaking it up?

3) This is more of a generic question, but as I mentioned wanting to have a little wrapper for CEGUI just for personal organization and what not, what else besides the basics (init/destroy functions, etc) would possibly be suggested as going in there? I still have some reading to do, especially since everything GUI related is revolving around the Canvas approach.

macpl
Just popping in
Just popping in
Posts: 3
Joined: Fri Jul 09, 2010 22:46

Re: CEGUI Manager Class

Postby macpl » Mon Jul 12, 2010 21:37

1) CEGUI::WindowManager::destroyAllWindows() works well enough for me.

As for the others, probably simply a matter of preference and/or needs. Maybe somebody else will have more to write. ;)

Jamarr
CEGUI MVP
CEGUI MVP
Posts: 812
Joined: Tue Jun 03, 2008 23:59
Location: USA

Re: CEGUI Manager Class

Postby Jamarr » Tue Jul 13, 2010 16:31

CrimsonGT wrote:1) I obviously have state management in my application (login screen state, game state, etc). Im wondering if CEGUI has a feature to destroy all existing GUI elements, or if I should just destroy the CEGUI instance when changing states? The first seems much more efficient (keeping the singleton ptr for CEGUI persistent through the life of the application rather than destroying/recreating it to clean up between state switches. What would the recommendation be for this?


I would not recommend destroying/re-initializing CEGUI; this is the least efficient and most error prone. As mentioned you can use WindowManager::destroyAllWindows() and then re-load/create the windows as needed, but is also inefficient and could be very slow for complex layouts. I would only recommend this if your memory constraints are tight. I believe one of the better methods would be to use multiple GUI sheets. You can attach all layouts associated with each screen to a different gui-sheet, and use an empty gui-sheet for times when you do not need the gui. Then just use CEGUI::WindowManager::setGUISheet to switch between them. This will sacrifice memory for performance, as is nearly always the case.

2) Canvas didn't really support loading layouts/schemes/etc from XML/LUA so this is a bit new to me. Is the general approach to just hardcode in the GUI elements that won't be changing, such as the main game screen, and use lua script for the others to make quick modifications? Or when using LUA, do most people just use it for everything instead of breaking it up?


This is almost too subjective to even comment on. If you want the ability to quickly change your screen/window layouts, I would recommend using the layout xml files as opposed to defining layouts in code; if you prefer reducing load-times, then you may want to define layouts in code. If you want the ability to quickly change/tweak your GUI functionality without having to recompile, then I would go with Lua; if you want easier debugging and less management-overhead exposing functionality to Lua, etc. then code the GUI functionality into your application. Or, mix and match as needed. It really just depends on what you want to do with your GUI.

3) This is more of a generic question, but as I mentioned wanting to have a little wrapper for CEGUI just for personal organization and what not, what else besides the basics (init/destroy functions, etc) would possibly be suggested as going in there? I still have some reading to do, especially since everything GUI related is revolving around the Canvas approach.


Most wrappers probably consists of at least initialization, destruction, and input-injection. Anything else would probably be abstraction.
If somebody helps you by replying to your thread, upvote him/her as a thanks! Make sure to include your CEGUI.log and everything you tried when posting! And remember that we are not magicians!

CrimsonGT
Just popping in
Just popping in
Posts: 7
Joined: Mon Jul 12, 2010 12:30

Re: CEGUI Manager Class

Postby CrimsonGT » Wed Jul 14, 2010 15:47

Thank you so much, this was a huge help. I have never used LUA before, does it increase the memory usage substantially?


Return to “Help”

Who is online

Users browsing this forum: No registered users and 19 guests