Without knowing the specific issues which prevented you from building the program, it's difficult to assist.

See "4.5.3 Configuration Domains" in the CS manual for details.

http://www.crystalspace3d.org/docs/online/manual/

What does the actual build command look like? It is not clear from your post if you are even linking against the CEgui library.

If you're on Windows, you should use the cal3d which comes bundled with cs-win32libs. Of course, choose the correct version of cs-win32libs (depending upon whether you are using CS 0.98 or CS 0.99).

What do you mean by "app"? Do you mean that the window has no title?

Code:

inline csRef<iGraphics3D> GetGraphics3d(){return g2d;}
inline csRef<iGraphics2D> GetGraphics2d(){return g3d;}

Look more closely at your code. You transposed the 2's and 3's.

The code should read:

Code:

inline csRef<iGraphics3D> GetGraphics3d(){return g3d;}
inline csRef<iGraphics2D> GetGraphics2d(){return g2d;}

By "doesn't work", you mean what exactly?

Your HandleEvent() function is at fault. If you look at the documentation for this function in csBaseEventHandler, it will tell you that you must call the superclass implementation if you didn't handle the event yourself. It should be written like this:

Code:

bool GameManager::HandleEvent(iEvent& ev)
{
  return csBaseEventHandler::HandleEvent(ev);
}

Better yet, you should just get rid of this function entirely from your code. Again, the documentation will tell you that you almost never have to implement this function in csBaseEventHandler-based classes.

Are you sure that compilation actually froze on that file? How long did you wait? There are a few files in the project which particularly tax gcc (especially in optimize mode) because they instantiate a tremendous number of templates and/or expand a lot of macros into a significant amount of code. For these files, you must exercise some patience.

Try the CVS version of CS. There was some bug fixed recently where the engine was not correctly responding to canvas resizing events.

The --verbose=scf command-line switch will tell you precisely which directories SCF searches for plugins, as well as the actual plugins which it found. Make sure that you completely removed the 0.98 version of CS before using the CVS version. (This is especially important if you 'installed' the 0.98 version.)

Does the .dll for the CS plugin actually exist? Try running CS programs with --verbose=scf to see where SCF is searching for plugins and which ones it finds.

This probably means that CS's CEGUI plugin did not build or did not build successfully.

This appears to be a bug in CS where it is allocating the string in one heap and then attempting to destroy it in a different heap. We normally work around this issue via reference counting and virtual object destructor. I submitted this on the CS bug tracker:

https://sourceforge.net/tracker/index.php?func=detail&aid=1388079&group_id=649&atid=100649

Is the build system even linking the CEGUI library into that application?