CEGUI (Crazy Eddie's GUI) Forums

Hello everyone

First of all I had to say that CEGUI it's an awesome library for handling GUI. For that reason my team and I start to used for our game for a class project.

We are using SDL, OpenGL for the project.

At this point where already develop the main menu and all the handling with mouse and keyboard, but we encounter a problem which we have no idea how to solve this.

The idea is that the player starts in the main menu, so in this point all the resources for CEGUI are loaded and the system it's initialized, something like this:



This method init it's called every time that the main menu starts, that's the reason why the bootstrapSystem it's located there. But becaue of that we need to destroy the CEGUI system everytime this class is destroyed, or in other words, everytime the game changes of state. So we write in the destructor this:




So having this system, we execute the game and starts in the main menu perfectly, we enter the game, and the we decide to return to the main menu and crash in this point.



So we have no idea what happens. At next I leave you the source code of the two functions that help us initialize CEGUI and create the GUI and our log.



And The Log:



Thanks beforehand for the help.

Bootstrapping CEGUI and destroying it over and over again is definitely wrong (tm). Only bootstrap once and destroy when your game exits. Destroy the widget hierarchies if you need to.

However what you are doing should work, I guess it could be related to runtime dll conflict or something like that. CEGUI is definitely not tested for this I think.

Thanks for the reply.

I already changed that, boostrapping only occurs once, when the game starts, so it's best if I leave the system till the game exits?

I try that, but when I try to reload the resources for a second time I encounter that this line crashes, give an access violation:



Even if in the destructor of my class I call these:



What problem could exists related to runtime DLL?

I'm not going to say that there is a correct / incorrect way to use CEGUI, since given enough scenarios, you'll find a valid use for all approaches, however, the 'usual' way would be:

• bootstrap system
• load shared resources (mostly everything except layouts) & set defaults.
• drop into main loop / switch to main 'run' state / whatever
• destroy system

So, basically, for the majority of uses, we advocate loading schemes and other resources once (if for no other reason, it leaves less things to go wrong later). This said, destroying the schemes and reloading should work ok. Since it doesn't, please post a CEGUI.log from a run where you use that approach, and also a callstack with debugging symbols from the point of the access violation.

CE.

Thanks for the reply.

So in my SMainMenu destructor I put the next lines:



And I erased the line for destroying the system.

Here is the callstack for this access violation.



And here is the log using that approach:

Right now I do not have any explanation. Obviously it's dying when (re)loading a font. Is it the same location reported in the exception (0xFEEEFEEE)?

Can you confirm you're not doing anything that touches CEGUI in different threads?

CE

Yes, it is the same location reported in that exception.

Right now, our game only uses one thread, so CEGUI doesn't have that problem.

Hi,

I was about to type one reply saying I could not explain this, then I suddenly realised that I am a complete idiot. The cause of the issue has been staring me in the face the whole time.

Basically, I believe it's because you do this:


What is happening here is that the ImagesetManager::destroyAll call is destroying all Imagesets - including those in use by Font objects that still exist. This causes the exception when SchemeManager::destroyAll attempts to destroy the Font objects, as they subsequently attempt to destroy the Imagesets that they own (which no longer exist). Or in short, Fonts keep a dangling pointer to the deleted Imageset.

Normally you do not need to call both of these functions in that way, since destroying all schemes will also destroy any imagesets loaded as part of those schemes. Though if you have manually loaded or created imagesets, clearly you want to destroy those too, so the solution is to call the SchemeManager::destroyAll prior to destroying imagesets (or fonts).

So:


Sorry I did not spot this earlier

CE.

Thanks for the reply.

I already do that, change the order of destruction and keeps telling me the same, the log goes till the font.

Could be because of the custom cursor image?, when SchemeManager destroy's that object, dissapear from memory, but Imageset will deleted this one too?, this doesn't cause a exception too?

Thanks.

It could be the cursor, sure - especially if the backtrace contains CEGUI::Image or CEGUI::Imageset.

CE.

I try with the custom cursor but seems to crash as shows the log, the font it's the problem like you said before, but I can't figure out how to fix this.

I'm at a loss as to why you would get that issue. In my previous test I was able to destroy and recreate things successfully.

The only way I could help now would be to see a minimal example that exhibits the issue (where minimal means preferably without any additional libraries and non-CEGUI code). If you can provide that so that I can reproduce the issue, hopefully the solution will become apparent.

CE.

Hello, I will try to give you a version with non extra libraries but it's kind complicated because we currently use SDL, boost, FMOD.