Patches for new SharedPtr in Ghadamon

[Transporter]

As SharedPtr now uses atomics, you now have to explicitly cast to the target data type, for example:

Code: Select all

MaterialPtr matPtr = MaterialManager::getSingleton().create("MyMaterial", "General").staticCast<Material>();

http://www.ogre3d.org/tikiwiki/tiki-ind ... ting_Notes

It's easy to patch files:

Code: Select all

#if (OGRE_VERSION < ((1 << 16) | (9 << 8) | 0))
    Ogre::MaterialPtr mat = Ogre::MaterialManager::getSingleton().create("Testmaterial", "Test");
#else
    Ogre::MaterialPtr mat = Ogre::MaterialManager::getSingleton().create("Testmaterial", "Test").staticCast<Ogre::Material>();
#endif

btogre

btogre.patch

(851 Bytes) Downloaded 200 times

ogreassimp
https://bitbucket.org/jacmoe/ogreassimp ... -sharedptr

MyGUI

MyGUI.patch

(3.45 KiB) Downloaded 216 times

SkyX
https://docs.google.com/file/d/0B_ao-Cm ... sp=sharing or Ogitor

Hydrax
https://docs.google.com/file/d/0B_ao-Cm ... sp=sharing or Ogitor

Ogre-Procedural
http://code.google.com/r/ogretransporte ... 4a533135f3

Ogitor
https://bitbucket.org/jacmoe/ogitor/pul ... e-ghadamon

PagedGeometry
Changed as part of Ogitor.

Caelum
Changed as part of Ogitor.

CEGUI

cegui.patch

(7.09 KiB) Downloaded 210 times

[rndbit]

Err.. Why on earth such redundancy was introduced in the first place?

[drwbns]

New sharedPtr takes up much less memory per use.

[rndbit]

Okay cool, but bear with me here..

Code: Select all

MaterialManager::getSingleton().create("MyMaterial", "General").staticCast<Material>();

What prevents create() returning same thing staticCast() returns? I am sure it is pretty obvious that if we call MaterialManager::create() then we are expecting to get Material, not Texture, not anything else. So what is the point of typing obvious thing when it could be avoided?

[Klaim]

Okay cool, but bear with me here..

Code: Select all

MaterialManager::getSingleton().create("MyMaterial", "General").staticCast<Material>();

What prevents create() returning same thing staticCast() returns? I am sure it is pretty obvious that if we call MaterialManager::create() then we are expecting to get Material, not Texture, not anything else. So what is the point of typing obvious thing when it could be avoided?

I was surprised too but I just reminded that it's because of ResourceManager base class having a virtual create() function. See http://www.ogre3d.org/docs/api/html/cla ... nager.html

However in the provided context it is indeed not that useful. One possible improvements is to add a more specific function in each ResourceManager child which return the specific type, something like:

Code: Select all

MaterialManager::getSingleton().createMaterial("MyMaterial", "General")

I don't know if a refactoring would avoid this kind of problem, but in doubt as there is a GSoC going on about resource management system, I'll point the author to read this.

[Transporter]

It should be possibe to integrate the static cast in create method. Something like this:

Code: Select all

MaterialManager::getSingleton().create<Material>("MyMaterial", "General");

Note: CEGUI will drop Ogre support

[rndbit]

Both solutions do not sound perfect to be honest. They are one bit too redundant, but definitely better than static cast.

What about making ResourceManager::create() non-virtual? As far as i can see there is no real requirement for polymorphism, we are using resource managers directly. So in the end we would keep create() in all classes and yet returning object of correct type without any manual casts or useless typing. Best part is that child resource managers will still be able to utilize ResourceManager::create() if needed so there would be no code duplication either.

[Klaim]

I would have removed the ResourceManager as a base class altogether or made it CRTP, personally, but I see in the Ogre code base that the abstract interface is used in a lot of cases, in particular in mechanisms systems like the background loader (which will be rewritten anyway).

[rndbit]

In that case ResourceManager::create() could be refactored to something like ResourceManager::createInternal() freeing up straightforward non-virtual create() for use by users. Cant wait to see the direction this goes ^_^

[Klaim]

You can already take a look at the plan and status in the GSoC thread: http://www.ogre3d.org/forums/viewtopic.php?f=13&t=77193

[Owen]

As has been discussed, the current state is very much "interim". I drafted the patch for 2.0 and it got pulled into 1.9 because it is a significant memory (and sometimes performance) improvement.

In my working copy the way the resource system works is very different. There should be, by the end of it, convenience functions for most of these use cases.

[Mind Calamity]

Transporter - CEGUI will not be dropping OGRE support anytime soon - look at the last comment by Paul (aka Crazy Eddie).

The patch/pull request wasn't accepted because it broke compatibility with older versions of OGRE, and adding Ogre.h would just increase compile time unnecessarily.

I've made a new patch that doesn't break compatibility and doesn't include Ogre.h, you can find my pull request (not yet reviewed by the CEGUI team) here and my repository with support for OGRE 1.9 here.

[Transporter]

Transporter - CEGUI will not be dropping OGRE support anytime soon - look at the last comment by Paul (aka Crazy Eddie).

I have noticed that Paul makes fun of me.

[Mind Calamity]

Hey guys, since I'm using Gorilla, I updated it and remembered this thread, and thought it might save someone the trouble of adding all those version checks. (Easy, but annoying and boring as hell)
So, here's a patch. If you want, please add it to the original post for better visibility, transporter.

Gorilla.patch

Patch for betajaen's Gorilla.

(6.27 KiB) Downloaded 199 times

[Slicky]

When I am building my app I get the errors from sharedptr but no link to which line is creating the error. I end up searching code for ptr. Is there an easier way to find lines that need to be fixed?

[drwbns]

Look at your output build log in visual studio, the first is the the sharedptr error, a few lines later it says "in file ... line blah blah"

[scrawl]

Hi,
here is my attempt to fix this problem, please let me know if there are any issues with it.

Edit: it got merged, thanks masterfalcon!

[nevarim]

compiling skyx with ogre 1.9 i have this error

Code: Select all

d:\ogre\source\skyx\skyx\include\GPUManager.h(120): error C2039: 'staticCast': not a member of 'Ogre::SharedPtr<T>'

and this i

Code: Select all

#if (OGRE_VERSION < ((1 << 16) | (9 << 8) | 0))
			mSkydomeMaterial = static_cast<Ogre::MaterialPtr>(Ogre::MaterialManager::getSingleton().getByName(getSkydomeMaterialName()));
#else
			mSkydomeMaterial = (Ogre::MaterialManager::getSingleton().getByName(getSkydomeMaterialName())).staticCast<Ogre::Material>();
#endif

s code


anyone known how to resolve?

thanks
Neva

[nevarim]

same for hydrax

[masterfalcon]

It should be noted that this is no longer a requirement, the previous behavior has been restored but with a more efficient backend behind it.

[nevarim]

so i must remove

Code: Select all

.staticCast<Ogre::Material>();

?

[masterfalcon]

Yes, that's correct.

[nevarim]

PagedGeometry
Changed as part of Ogitor.

what's meaning that developing of this plugin is stopped and the only way to follow is implementing ogitor?

[nevarim]

in cloudmanager i have another problem:

Code: Select all

NewCloudLayer->_registerCloudLayer(Ogre::MaterialManager::getSingleton().getByName(mSkyX->getGPUManager()->getSkydomeMaterialName())->getTechnique(0)->createPass());

Source\CloudsManager.cpp(230): error C2039: 'getTechnique': not a member of 'Ogre::Resource'

[scrawl]

This should definitely work. I think you are using an older revision of 1.9.