New wiki article: Advanced Ogre Framework

A place for users of OGRE to discuss ideas and experiences of utilitising OGRE in their games / demos / applications.
Post Reply
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

New wiki article: Advanced Ogre Framework

Post by spacegaier »

Hello together!

I finally made it: The new Advanced Ogre Framework is finished and up in the wiki :D .

As its predecessor (the Basic Ogre Framework), it is meant as an entry point application showing some of the most commonly used and needed features in an Ogre application such as:
  • Standard Ogre initialization
  • Game State System
  • Graphical User Interface (SDKTrays)
  • Different input modes (game mode / settings mode)
  • DotScene loading
  • Manual material manipulation
Wiki URL: AdvancedOgreFramework

Mercurial Repostiroy URL: BitBucket AdvancedOgreFramework Repository
Note: There are separate branches for the different Ogre versions.

As with the first version, I am now asking for feedback: From the experts concerning style and correctness and from the others feedback regarding features and understandability.

As long as there is no "go" from some Ogre experts, usage is at your own risk, but since everything works (at least for me), there should not be that much problems with it.

For those who want to know how this thing evolved, have a look at the feature discussion thread I opened some time ago, to ask what would be wished for this application. Most things were realized, but if you feel like something is really missing, go ahead and tell me. I will then either put it in (or more likely since it is already quite big), make an extra article for that.

Perhaps I will also change the wiki page a bit, by e.g. making several smaller pages out of this big one (third biggest page on the wiki ;) ). Not totally sure about it though yet, so I'm also hoping for feedback on these kind of things.

That's about it for the beginning. Now I hope that you like it and I am looking forward to get feedback and things to change :D

Cheers
spacegaier
AdvancedOgreFramework_Game.jpg
Update 2013/02/10:
  • ported to Ogre 1.9 (v1.8 version remains as branch)
Update 2011/07/18:
  • all platforms now use Ogre::WindowEventUtilities::messagePump()
Update 2011/03/29:
  • m_pTrayMgr was missing a null initialization in the class constructor, resulting in a possible RT error when leaving the application at the renderer selection screen
Update 2011/02/10:
  • added some Linux specific code bits
  • fixed null pointer exception with m_pCurrentObject
  • when being in a question dialog you cannot press escape anymore to prevent the application from funny behavior
  • corrected pauseAppState()
Update 2010/10/22:
  • removed memory leak caused by m_pTrayMgr
  • removed memory leak caused by pDotSceneLoader
Update 2010/10/21:
  • changed the AppStateMananger destructor to properly delete all its managed states
Update 2010/10/08:
I finally updated the framework to work with Ogre 1.7 and OgreBites::SDKTrayManager as GUI.
  • one more app state added (pause mode)
  • chat mode replaced by a settings mode
  • switched to RapidXML DotSceneLoader
Last edited by spacegaier on Fri Oct 22, 2010 10:00 am, edited 6 times in total.
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
User avatar
boyamer
Orc
Posts: 459
Joined: Sat Jan 24, 2009 11:16 am
Location: Italy
x 6

Re: New wiki article: Advanced Ogre Framework

Post by boyamer »

Thank you very much,nice work.you've done well job.

:)
mikos
Gnoblar
Posts: 14
Joined: Wed Aug 12, 2009 3:42 pm

Re: New wiki article: Advanced Ogre Framework

Post by mikos »

Thanks for working on this =)

However I cannot get this to compile on Mac OS X Leopard on XCode 3.1. In AdvancedOgreFramework.cpp on this line:

Code: Select all

template<> OgreFramework* Ogre::Singleton<class OgreFramework>::ms_Singleton = 0;
I get this error:

error: 'OgreFramework' is not a template type

Anyone know how to resolve this?
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: New wiki article: Advanced Ogre Framework

Post by spacegaier »

Yes, it should be:

Code: Select all

template<> OgreFramework* Ogre::Singleton<OgreFramework>::ms_Singleton = 0;
We had the same problem with the BasicOgreFramework, but I forgot to change this here as well. Is done now (in the next minutes).

EDIT: Changed now in both frameworks (new versions are uploaded).
Last edited by spacegaier on Sun Aug 16, 2009 10:29 am, edited 1 time in total.
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
jonnys
Halfling
Posts: 77
Joined: Thu Mar 27, 2008 7:40 pm

Re: New wiki article: Advanced Ogre Framework

Post by jonnys »

spacegaier wrote:Yes, it should be:

Code: Select all

template<> OgreFramework* Ogre::Singleton<class OgreFramework>::ms_Singleton = 0;
We had the same problem with the BasicOgreFramework, but I forgot to change this here as well. Is done now (in the next minutes).

EDIT: Changed now in both frameworks (new versions are uploaded).
spacegaier, I think you mean

Code: Select all

template<> OgreFramework* Ogre::Singleton<OgreFramework>::ms_Singleton = 0;
jonnys
Halfling
Posts: 77
Joined: Thu Mar 27, 2008 7:40 pm

Re: New wiki article: Advanced Ogre Framework

Post by jonnys »

Great work spacegaier, Was looking forward to the official release. :)

Is it compatible with Ogre 1.7 (Cthugha)?

Because when I compiled it against the latest HEAD SVN build it gives some boost error at this line:

Code: Select all

m_pOgreHeadMat = m_pOgreHeadEntity->getSubEntity(1)->getMaterial();
I'll post more info when I get time, but meanwhile can some one look into this.
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: New wiki article: Advanced Ogre Framework

Post by spacegaier »

Yes, I mean the version without the "class" keyword in.

Considering 1.7: No idea. Never used 1.7 so far. I think you had the same issue with the BasicOgreFramework. Perhaps it would be best to open a whole new thread for this, as this is not a problem directly related my work (I hope and guess).

EDITR: Okay, wasn't n the BasicOgreFramework-Thread, but we somewhere already talked about that...
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
mikos
Gnoblar
Posts: 14
Joined: Wed Aug 12, 2009 3:42 pm

Re: New wiki article: Advanced Ogre Framework

Post by mikos »

Thanks spacegaier & jonnys =) It now compiles but crashes at runtime on this line:

Code: Select all

OgreFramework::getSingletonPtr()->initOgre("AdvancedOgreFramework", 0, 0);
XCode tells me:

GDB: Program received signal: 'EXC_BAD_ACCESS'
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: New wiki article: Advanced Ogre Framework

Post by spacegaier »

Strange, works all fine here on MS Vista...

Try putting the following line the before the crash line and check whether test is null.

Code: Select all

OgreFramework* test = new OgreFramework();
If it's not, then add another line:

Code: Select all

test = OgreFramework::getSingletonPtr();
Is test then null?
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
mikos
Gnoblar
Posts: 14
Joined: Wed Aug 12, 2009 3:42 pm

Re: New wiki article: Advanced Ogre Framework

Post by mikos »

Thanks for your reply, spacegaier. I tried what you suggested and test wasn't null in either of the cases :?
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: New wiki article: Advanced Ogre Framework

Post by spacegaier »

Okay, I guess that would mean that the OgreFramework instace creation and singlelton stuff seems to work as a proper OgreFramework pointer is given back by getSingletonPtr().

The only thing I can think of is that there is a problem with giving the two nulls as the second and third parameter. Therefore you could testwise create two dummy listeners and pass them to the function to see if this changes anthing.

PS: You are sure that it does not crash somewhere IN initOgre()?
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
mikos
Gnoblar
Posts: 14
Joined: Wed Aug 12, 2009 3:42 pm

Re: New wiki article: Advanced Ogre Framework

Post by mikos »

Apologies, I've drilled down a bit more and it appears to be crashing on this line:

Code: Select all

CEGUI::WindowManager::getSingleton().loadWindowLayout((CEGUI::utf8*)"AdvancedOgreFramework.layout");
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: New wiki article: Advanced Ogre Framework

Post by spacegaier »

Okay. thenm I guess that for some reason the AdvancedOgreFramework.layout file cannot be found. Did you delete it (or even the whole GUI folder)?
Also check the CEGUI.log.

Did you check that all the CEGUI pointers are valid?
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
Goilveig
Kobold
Posts: 35
Joined: Sun Jun 28, 2009 4:25 am

Re: New wiki article: Advanced Ogre Framework

Post by Goilveig »

My only major critique (and this is a critique of the Game State Manager articles too) is that the state manager provides no parameter passing on entering a new state.

Why might you need this? For example, maybe your game has 100 levels (maybe you don't even know at compile time how many levels there will be!) and your MainMenu state needs to tell the GameState which level to load. It doesn't really make any sense to have separate states for separate levels, assuming they all use the same rules, as generally the only parameter that's going to change is the name of the file to load.

My suggested change would be to make changeAppState(), pushAppState() and enter() to all take an Ogre::Any as a parameter (if you really wanted to get fancy you could pass a property set of something like std::map<Ogre::String, Ogre::Any> but that may be overkill unless your application really needs that much information passing and you don't want to just pass a custom struct).

There's also a potential memory leak. If ManageAppState(statename, state) throws -- for example, if std::vector<>::push_back() throws a std::bad_alloc, state is leaked. Simplest solution is to put a try/catch(...) around everything in ManageAppState and make it delete state; if there is an exception caught (and of course then it should re-throw an Ogre::Exception).
jonnys
Halfling
Posts: 77
Joined: Thu Mar 27, 2008 7:40 pm

Re: New wiki article: Advanced Ogre Framework

Post by jonnys »

Goilveig wrote: There's also a potential memory leak. If ManageAppState(statename, state) throws -- for example, if std::vector<>::push_back() throws a std::bad_alloc, state is leaked. Simplest solution is to put a try/catch(...) around everything in ManageAppState and make it delete state; if there is an exception caught (and of course then it should re-throw an Ogre::Exception).
I wonder if that's why sometimes it crashes randomly... :( :?:
mikos
Gnoblar
Posts: 14
Joined: Wed Aug 12, 2009 3:42 pm

Re: New wiki article: Advanced Ogre Framework

Post by mikos »

spacegaier: I copied over the 'media' directory from the rar file. But you're right, it cannot find the layout file

Code: Select all

17/08/2009 14:22:34 (Error)	WindowManager::loadWindowLayout - loading of layout from file 'AdvancedOgreFramework.layout' failed.
I'll have a play around and let you know if I can fix it.
Goilveig
Kobold
Posts: 35
Joined: Sun Jun 28, 2009 4:25 am

Re: New wiki article: Advanced Ogre Framework

Post by Goilveig »

jonnys wrote:I wonder if that's why sometimes it crashes randomly... :( :?:
I'd highly doubt you'd get a std::bad_alloc there. You have a vector of pointers, so pretty much the only possible error is if you don't have sufficient memory to allocate a new vector of the larger size. It's certainly possible, but I'd think it would be very, very unlikely unless you were managing an absurd number of gamestates, or if you were really, REALLY pushing the capacity of the virtual address space that your operating system allows (for example, in Windows 32 with default settings, one process can only effectively allocate 2 GB of memory, regardless of physical RAM in the system).

So while it's a possible memory leak -- and all possible leaks should be fixed -- it's very unlikely to actually occur.
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: New wiki article: Advanced Ogre Framework

Post by spacegaier »

Will try the memory try/catch at home.

Concerning the parameter passing: I think that doesn't need to be in here. That is already somewhat application specific and everybody able to understand the code I posted should be able to design such a parameter passing thing as needed by them and I want to keep the framework as small as possible. However, I'm thinking of creating a "Further coding" section in my wiki article where I could put such hints on how to extend the framework.

Thank you very much for this feedback!!!
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
jsirwin
Gnoblar
Posts: 3
Joined: Sat Feb 28, 2009 10:13 pm

Re: New wiki article: Advanced Ogre Framework

Post by jsirwin »

Thanks for documenting your framework, it's allowed me to reflect on how poorly my current one was.

It appears that this framework is geared towards initiali(z|s)ing all states up front, and then swapping between them by name. This is useful for small projects, or demos, but I don't see much value in a "string based" and "put everything on the stack" approach in a large project that has many states. There are likely even situations where states will never be used, so loading them all into memory up front is without much merit. I do, however, understand the value in having the most common states pre-loaded in order to prevent from having to do so in real-time.

I guess what I'm getting at is this: What are some suggestions for dealing with states that shouldn't be loaded on startup? And how to better improve upon this string based selection approach?

My gut tells me to build a manager for loading/unloading states by specific methods, instead of by a string. The manager would have a method for each state, and during the call it could first check if the state is already on the stack before creating. It's really nothing more than a wrapper on top of this framework, but it would allow any state to be called from any other state- without having to deal with a bunch of includes and/or remembering each state's string name.

My gut is also pretty weak at C++ though, since I've been living in the .NET world for the past 6 years. What does YOUR gut tell you to tell me? :-)

Also, if I'm missing something, feel free to let me know... Maybe I got this all wrong...
jsirwin
Gnoblar
Posts: 3
Joined: Sat Feb 28, 2009 10:13 pm

Re: New wiki article: Advanced Ogre Framework

Post by jsirwin »

Also, if I'm missing something, feel free to let me know
I'll go ahead all let myself know: I was missing something. :oops:

At least in terms of multiple state processing.

After going through this design more thoroughly, I realise now that Push will actually allow for multiple states to be active at the same time, although not running. Some minor tweaks to allow states to run in parallel were easy to apply. Eventually I plan to do a more sophisticated grouping technique- so that states can be grouped to run in parallel, and groups can be grouped, etc... This would allow the most flexibility, I believe.

I just thought I'd chime back in, and admit I was wrong that the design didn't support such behavior. Even though a minor tweak was needed, it's "smallness" is attributed to the design already in place.
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: New wiki article: Advanced Ogre Framework

Post by spacegaier »

@mikos: Were you able to solve it?

@jonnys: Same for you. Is the crash solved?
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: New wiki article: Advanced Ogre Framework

Post by spacegaier »

@Goilveig: Did you think of something like this?

Code: Select all

void AppStateManager::manageAppState(Ogre::String stateName, AppState* state)
{
	try
	{
		state_info new_state_info;
		new_state_info.name = stateName;
		new_state_info.state = state;
		m_States.push_back(new_state_info);		
	}
	catch(std::exception& e)
	{
		delete state;
		throw Ogre::Exception(Ogre::Exception::ERR_INTERNAL_ERROR, "Error while trying to manage a new AppState", "AppStateManager.cpp (39)");
	}
}
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
Zephon
Gnoblar
Posts: 13
Joined: Thu Sep 29, 2005 10:29 am

Re: New wiki article: Advanced Ogre Framework

Post by Zephon »

Hi
Really nice work. While going through it some questions came to my mind.
I don't want to bug you and some of them might sound retarded but i really want to know about a few of your design decisions.

- Why use a custom built update method instead of making OgreFramework a FrameListener and passing frame events
to the active state ?

- Why load all gui layouts in advance ?

- What is the use of making an abstract class AppStateListener ? I guess there will be only one AppStateManager
during execution time. Since OgreFramework has to exist in the same time span and it is a singleton, why not make
it a fsm for AppStates ? This would also have the benefit of moving the update method there so it would not
be necessary to dereference OgreFramework singleton multiple times per frame.

- What is the benefit of using a macro for state creation instead of making the states singletons like in this article.
Or is there a reason to have multiple instances of an application state on the stack ? If so why not make a AppState factory ?

- What is the reason for creating scenemanagers and cameras on AppState creation rather than keeping a single one
in the OgreFramework, or even making a camera class ?

Thx in andvance.
User avatar
spacegaier
OGRE Team Member
OGRE Team Member
Posts: 4304
Joined: Mon Feb 04, 2008 2:02 pm
Location: Germany
x 135
Contact:

Re: New wiki article: Advanced Ogre Framework

Post by spacegaier »

Zephon wrote: - Why use a custom built update method instead of making OgreFramework a FrameListener and passing frame events
to the active state ?
FrameListeners are generally considered not the best style. They are suitable for many things (especially tutorials), but an own update() function offers way more flexibility.
Zephon wrote: - Why load all gui layouts in advance ?
You are right. Would probably make more sense to do this in the state class. Will change that.
Zephon wrote: - What is the use of making an abstract class AppStateListener ? I guess there will be only one AppStateManager
during execution time. Since OgreFramework has to exist in the same time span and it is a singleton, why not make
it a fsm for AppStates ? This would also have the benefit of moving the update method there so it would not
be necessary to dereference OgreFramework singleton multiple times per frame.
Will have to think about that. Just took that over from the wiki article the state system is based on.
Zephon wrote: - What is the benefit of using a macro for state creation instead of making the states singletons like in this article.
Or is there a reason to have multiple instances of an application state on the stack ? If so why not make a AppState factory ?
Same as above.
Zephon wrote: - What is the reason for creating scenemanagers and cameras on AppState creation rather than keeping a single one
in the OgreFramework, or even making a camera class ?
For easier switching between the states (SceneManager does not have to be refilled on every change). Why should I make a camera class for this?
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
Zephon
Gnoblar
Posts: 13
Joined: Thu Sep 29, 2005 10:29 am

Re: New wiki article: Advanced Ogre Framework

Post by Zephon »

spacegaier wrote: For easier switching between the states (SceneManager does not have to be refilled on every change). Why should I make a camera class for this?
Ok i see. My thought was that the the control/movement code for the camera could be put together in a single class instead of spreading it out on several states. I guess this is more a matter of convenience. And with states having their own scene managers i think this could mess up the start up sequence of states. Might not be worth the trouble.
Post Reply