Having numerous problems with CEGUI/Ogre

[Revol]

Hey everybody. I'm trying to use the latest CEGUI from SVN with the latest OGRE with everything statically linked, but I'm getting some errors I can't get past.

Code: Select all

1>------ Build started: Project: CEGUIBase, Configuration: Debug_Static Win32 ------
1>Compiling...
1>CEGUIScheme.cpp
1>c:\dev\dependencies\cegui\cegui\src\ceguischeme.cpp(334) : error C3861: 'getWindowRendererModule': identifier not found
1>Build log was saved at "file://c:\dev\dependencies\bin\Debug\BuildLog.htm"
1>CEGUIBase - 1 error(s), 0 warning(s)
2>------ Build started: Project: client, Configuration: Debug Win32 ------
2>Compiling...
2>render.cpp
2>c:\dev\clientsrc\render.cpp(68) : error C2248: 'CEGUI::OgreRenderer::OgreRenderer' : cannot access protected member declared in class 'CEGUI::OgreRenderer'
2>        c:\dev\dependencies\cegui\cegui\include\renderermodules\ogre\ceguiogrerenderer.h(217) : see declaration of 'CEGUI::OgreRenderer::OgreRenderer'
2>        c:\dev\dependencies\cegui\cegui\include\renderermodules\ogre\ceguiogrerenderer.h(72) : see declaration of 'CEGUI::OgreRenderer'
2>Build log was saved at "file://c:\dev\client\Debug\BuildLog.htm"
2>client - 1 error(s), 0 warning(s)
========== Build: 0 succeeded, 2 failed, 19 up-to-date, 0 skipped ==========


Can anybody help out?

[CrazyEddie]

Hi, and thanks for testing out the latest SVN

I had not tested the static build so far, so I guess I should not be surprised you've found issue(s) there. The one flagged up in the build message is a missing extern declaration of a 'getWindowRendererModule' function for the static build. I will affect fixes later today so that the static config will at least build cleanly.

The second error; the one for the build for your app, is due to changes we are making to the way you create those initial objects. You no longer use the c++ new operator to create the renderer objects, but rather use one of the static 'create' members of the OgreRenderer class:

Code: Select all

OgreRenderer& OgreRenderer::create();
OgreRenderer& OgreRenderer::create(Ogre::RenderTarget& target);

Currently the CEGUI::System can still be created by the new operator, though this will change before the final 0.7.0 release. The main reason for these changes is because it means the object creation happens in the CEGUI modules, which is better for us from a memory allocation point of view, it also allows us more freedom to more freely change object sizes on point releases while maintaining binary compatibility.

Another change you need to be aware of as an Ogre user, is that CEGUI::ResourceProvider objects are no longer created automatically by the renderer module. I'm sure we can all agree that data loading has little to do with rendering imagery. So while the old arrangement was convenient, it was not logical from a design standpoint, hence the change. This means that to continue to use the Ogre based resource system (as I'm sure you will) you now need to either explicitly create an instance of the CEGUI::OgreResourceProvider and pass it to the system constructor, or use one of the premade 'bootstrap' ogre-specific convenience functions that create the resource provicer and CEGUI system for you too:

Code: Select all

OgreRenderer& OgreRenderer::bootstrapSystem();
OgreRenderer& OgreRenderer::bootstrapSystem(Ogre::RenderTarget& target);

These functions will create and initialise the following objects for you:
- CEGUI::OgreRenderer
- CEGUI::OgreResourceProvider
- CEGUI::System

Info about other breaking changes and issues can be found here: Changes and Porting Tips for 0.7.0 (all subject to further change, of course ).

Hope this helps

[CrazyEddie]

I committed some fixes yesterday evening, and now building the trunk under the static configuration succeeds (tested with MSVC++ 9); I'm not saying there are not, or will not be, other issues, but it does at least build

CE.

[kingIZZZY]

This means that to continue to use the Ogre based resource system (as I'm sure you will) you now need to either explicitly create an instance of the CEGUI::OgreResourceProvider and pass it to the system constructor,

I must be a noob or something, but i seem to have read something to the opposite effect in the docs tutorial:

For users of the Ogre3D library - or users with other custom resource providers not derived from DefaultResourceProvider - you should not follow the parts of this tutorial that deal with defining resouce groups and their directories (you should especially ignore any example code that casts to DefaultResouceProvider)...

Some clarification would be greatly appreciated.

[CrazyEddie]

Hi,

I don't see the conflict here (u NOOB! j/k). Unless you mean that the tutorial kind of implies that the custom resource provider for Ogre is always used, whereas the earlier posting here (correctly) says that you have to - one way or another - explicitly ask for it?

If that is what you mean, I will amend the tutorial to try an make it clearer... Perhaps:

For users of the Ogre3D library who are using the Ogre3D specific ResourceProvider (either because you explicitly created such an object and passed it to the System::create function, or because used one of the helper 'bootstrapSystem' functions) - or for users with other custom resource providers not derived from DefaultResourceProvider - you should not follow the parts of this tutorial that deal with defining resouce groups and their directories (you should especially ignore any example code that casts to DefaultResouceProvider).

(bolded for purposes of highlighting here)

CE.

[kingIZZZY]

May I suggest a tiny bit more noob-friendly rephrase;

"For users of the Ogre3D library, you should ....<fill in details about createOgreResourceProvider etc, these details in your above post arent mentioned anywhere in the tutorials>.... and then skip the parts about ....."

[CrazyEddie]

Well, first this is covered in the first tutorial:

Ogre3D and Irrlicht 'bootstrapSystem' functions
This section describes the Ogre3D and Irrlicht specific 'bootstrap' helper functions. Unless you're using one of these engines, you can probably skip to Conclusion.

The Ogre3D and Irrlicht engines each have their own intergrated file loading and image parsing functionality which CEGUI can seamlessly make use of via custom implementations of the CEGUI::ResourceProvider and CEGUI::ImageCodec interfaces. In order to make use of these implementations, the user would typically be required to create instances of these objects and pass them, along with the CEGUI::Renderer, to the System::create function. Since this over-complicates system construction for even the most simplest of uses, the renderer for each of these engines provides one or more bootstrapSystem functions that creates all those supporting objects automatically (there are also destroySystem functions for cleaning up afterwards).

When using the boostrapSystem functions, starting up CEGUI is as simple as a single function call:
Ogre3D

Code: Select all

// Bootstrap CEGUI::System with an OgreRenderer object that uses the
// default Ogre rendering window as the default output surface, an Ogre based
// ResourceProvider, and an Ogre based ImageCodec.
CEGUI::OgreRenderer& myRenderer =
    CEGUI::OgreRenderer::bootstrapSystem();

Irrlicht

Code: Select all

// Bootstrap CEGUI::System with an IrrlichtRenderer object, an Irrlicht based
// ResourceProvider, and an Irrlicht based ImageCodec.
CEGUI::IrrlichtRenderer& myRenderer =
    CEGUI::IrrlichtRenderer::bootstrapSystem( myIrrlichtDevice );

The issue with adding another explanation at that point is that the particular section is titled DefaultResourceProvider Explained, so mentioning that this may not apply to Ogre should be sufficient. While obviously the tutorials are supposed to introduce people to the various concepts, what we need to avoid is going off describing every possibility and all the combinations of options, because the tutorials could quicly become muddled and end up confusing more than teaching (there's nothing worse than reading a tutorial and having your eyes glaze over when the author starts rambing!).

I'll think some more about it and perahps see if there's an overall better way of covering these important points

CE.