Two questions!

CaseyB,

First of all, thanks for the wonderful library. I begin integrating your library into my app - migrating from FMOD.

Okay one question which I cant help noticing it.. why is it classes inheriting from Ogre::Singleton need getSingleton() and getSingletonPtr. It is pretty much covered by the Singleton template, so you dont need that. For example:-

/** Returns the Listener singleton object */
static Listener& getSingleton();
/** Returns a pointer to the Listener singleton object */
static Listener* getSingletonPtr();


The lines above are not needed.

Edit: Right after I posted this posting, I notice that the classes inherit from Singleton privately, so this maybe the reason why. I am sure you have reason for this.. so why? I am a curious cat

Secondly, why I didn't you give the option to user to retrieve the sound files using absolute directory (not thru resource manager)? Sometimes, sound file name may be the same but they are not the same. Consider this scenario of when there are 5 vehicles in the games and each of them has engine.wav, brake.wav, skid.wav etc. It is not very clean to actually rename them to be engine_car1.wav, engine_car2.wav etc. It is better to give the user options either to load via Ogre resource manager or direct full path name.

Okay I am done modifying OgreAL a bit so that it solves me the issue (2).

I also remove the exception thrown if SoundManager::getSound is invoked with not-existing sound name (if sound is not succesfully loaded for example). I remove the exception because it really gets in the way of me retrieving the pointer of OgreAL::Sound - this highly depends on the design anyway Maybe you can try to add second parameter in the getSound - if it is set to true, insteaf of throwing exception, it will simply return NULL.

If you need the code, I can paste it here. It is simple anyway.

I ran into that same problem today, but there is a "hasSound" option, so you don't need to modify "getSound".

KungFooMasta

Yes I noticed the hasSound member function, but the code will result in extra lines like below:-

if (smg->hasSound("engine"))
sound = smgr->getSound("engine");
else
sound = 0;

Instead I can just

sound = smgr->getSound("engine");

And just imagine if if I try to load 10 sounds? Parameter flexibility is the key Maybe CaseyB can modify OgreAL so that we can implement functions like below:-

sound = smg->getSound("engine", false); // false means dont throw exception

It is small anyway, but I like to fret on small stuffs

Okay one question which I cant help noticing it.. why is it classes inheriting from Ogre::Singleton need getSingleton() and getSingletonPtr. It is pretty much covered by the Singleton template, so you dont need that. For example:-

/** Returns the Listener singleton object */
static Listener& getSingleton();
/** Returns a pointer to the Listener singleton object */
static Listener* getSingletonPtr();


The lines above are not needed.

I think the answer why you need to reimplement them is documented in the OGRE API itself. For instance, take a look at one of the many many *Manager classes around there (here's one: http://www.ogre3d.org/docs/api/html/cla ... mManagere0)

Why do we do this? Well, it's because the Singleton implementation is in a .h file, which means it gets compiled into anybody who includes it. This is needed for the Singleton template to work, but we actually only want it compiled into the implementation of the class based on the Singleton, not all of them. If we don't change this, we get link errors when trying to use the Singleton-based class from an outside dll.

This method just delegates to the template version anyway, but the implementation stays in this single compilation unit, preventing link errors.

Firstly, sorry for not getting back to you sooner, I was out of town yesterday.

Ok, now for your first question, You are exactly correct! That is why it is implemented that way!

Now for your second question:why I didn't you give the option to user to retrieve the sound files using absolute directory (not thru resource manager)?Honestly, because I never thought about it! What I could do is try to retrieve the file from the filesystem directly and if that fails try the ResourceManager and then if that fails throw the exception. That's a great thought! Thanks!

Thirdly, I took this directly from Ogre and I also like the idea of throwing an exception instead of returning NULL, really this is just personal preference, but it seems cleaner to me. Either way you're going to have to handle the case where the sound file wasn't found so it's either checking the return against NULL or doing a try...catch.

I try to avoid using try.. catch wherever possible. I prefer returning NULL and checking that myself.

I haven't gotten to the point where I use hasSound a lot, I only use it at the menu screens, to check if a background song has been created.

KungFooMasta