Resource Provider

[_mental_]

Yeah I knew about the DataContainer memory leak already, I was more after a general review to see if this is what you envisioned. Good point about the exception memory leak in DefaultResourceProvider::loadRawDataContainer though as I overlooked that.

[_mental_]

I've uploaded a new version to the patch tracker which should fix those memory leaks.

[CrazyEddie]

...I was more after a general review to see if this is what you envisioned.

Aha In that case, yes, this is the kind of thing I had in mind when the idea was first discussed

I've uploaded a new version to the patch tracker which should fix those memory leaks.

Yep, everything looks fine now. Thanks

[_mental_]

Ok I went ahead and committed this initial version + the Linux build for it.

[CrazyEddie]

Right okay. I have now updated the MSVC builds to include the new files.

[_mental_]

Ok I'm ready to commit the rest of the resource provider changes, but wanted to check something first. With the current system you have to instanciate the appropriate resource provider singleton yourself before you start loading resources. This probably isn't ideal, but it does allow the end user to create their own resource providers if they really want to without the need to use the one that the renderer they are using has instanciated.

One thing that I've just thought of is modifying System to take a ResourceProvider pointer in it's constructor. If this wasn't supplied then System would use the appropriate one supplied by the renderer object.

Another option is just limiting the end user to use the resource provider.

Any thoughts?

[CrazyEddie]

I think the best approach would be to pass a ResourceProvider* in the constructor for System. This would be in keeping with the way the other modules that the user creates are passed in (Renderer and ScriptingModule).

CE.

[_mental_]

I'll make the appropriate mods. This also means I can do away with the resource provider singleton which is a good thing

[CrazyEddie]

Ok. Cool

[_mental_]

Ahh thats much better. The ResourceProvider is no longer a singleton. Now if you want to get the resource provider you can do System::getSingleton().getResourceProvider().

I've also re-factored System a little so that it can take a ResourceProvider object as a constructor argument (as mentioned before). If one isn't supplied, Renderer::createResourceProvider() (or the overridden version i.e. OgreRenderer::createResourceProvider()) will be called to create the appropriate ResourceProvider object. This way none of the existing renderers need to be modified to use the new resource provider.

I'll do some more tests and probably check the code in tomorrow.

[CrazyEddie]

Sounds great.

The virtual Renderer::createResourceProvider() method will be a nice touch, since it will allow (per-renderer) default replacements of the actual default ResourceProvider in a totally transparent way; the user will not need to worry about such things unless they need something custom built. Very cool

CE.

[_mental_]

I checked in the modifications above. I also checked in the code to link up the resource loading with the classes that consume the data. So as of now CEGUI loads all external files (except the texture stuff) via the resource provider. Hopefully I haven't missed any

The next thing is to modify the texture loading in the OGRE renderer to use the OgreResourceProvider rather than its current method.

[edit]
I just thought of something... my latest check in will cause problems with anyone who uses CEGUI and OGRE. The reason is that all CEGUI related files (scheme, imageset, xsd etc) will be loaded through OGRE rather than from the local directory. All of these types of files will have to be moved into a directory that is in the users resource.cfg

Fortunately it takes 24+ hours for anon CVS to catch up with the developer CVS

CE, any chance you could post a sticky about that? I'll post something over on the OGRE forums.
[/edit]

[CrazyEddie]

Okay cool. I'll have a good look at this later

I've posted a sticky in the Help forum, and I'll also post an item on the front page.

CE.

[Spoke]

Hi guys!

While testing this new functionality I notice that XERCES is again a dependencie for the client code.

Any plan no removing it?

[CrazyEddie]

Hi guys!

While testing this new functionality I notice that XERCES is again a dependencie for the client code.

Hmmm. I never really though of that Is it a major issue? I remember you did all the work before to factor out that dependency

Any plan no removing it?

It's complicated by the fact that the resource provider system is making use of templates; which is good because it enables everything to be done in a type safe manner. Removal of the dependancy is possible, though at the moment the only way I see of doing it would leave the system in a less robust state

CE.