Well, running this code when there is no sound will cause the game to crash:
AudioChannel *audio = aMusic.Play();
audio.Volume = 70;
And the reason for this is that Play will return null if there is no sound.
I think the approach was (and if not, it should be) that the developer wouldn't have to take care of such issues, this should be handled inside the engine and hide it from the developer.
The audio.Volume = 70 line should simply do nothing in such a scenario IMO.
I somewhat disagree. Returning null is, IMO, a valid representation that the function was not able to successfully execute whilst allowing you to recover from the situation instead of crashing the game immediately, particularly in a scripting environment with no error handling.
I would actually prefer that more items return null to indicate failure as opposed to crashing the game.
It would be better if it returned a dummy channel, as mentioned threads ago.
- Alan
Returning null makes sense if the normal case is for user to want to know if the action worked.
But in this case, in 99% of the cases the users won't want to know, and for the remaining 1% you can add an "IsValid" property to the channel that can be queried.
Most people will not think of checking it for null, and to prove it, even the example in the documentation for changing the volume doesn't check the channel for null...
Quote from: tzachs on Thu 11/11/2010 18:50:23
[...]
AudioChannel *audio = aMusic.Play();
audio.Volume = 70;
[...]
Simplay write something like this.
AudioChannel *audio = aMusic.Play();
if ( audio == null )
{
}
else
{
audio.Volume = 70;
}
or if you like
AudioChannel *audio = aMusic.Play();
if ( audio != null )
{
audio.Volume = 70;
}
Thank you Rulaman, but you kinda missed the point. :P
My point was that most agsers would not think to check the audio for null (or to test the game with no sound), and so most games that use this feature would crash in that scenario.
So while what you said would indeed fix this, it will only be fixed after a player reported the crash, which is not desired, and could be avoided by changing the behaviour of the engine.
I have the tendency to wrap any function I use a lot with my own version.
f.e.g. I like to add optional volume parameter to the play function.
This way, whenever the usage of this function is changed (like in newer versions) or when I discover a behavior I don't like (like the one you just described) I can easily circumvent it inside my code rather than going to the endless places it is used in.
I suggest you to do the same.
I see your point here. Play() can return null for other reasons (eg. if the audio file can't be loaded for some reason), but I actually agree that it should return a dummy channel if you are using No Sound, as you say.
Otherwise, I agree that this could cause a lot of games to crash if run with a No Sound setting.
Quote from: tzachs on Sat 13/11/2010 21:38:16
My point was that most agsers would not think to check the audio for null (or to test the game with no sound), and so most games that use this feature would crash in that scenario.
So while what you said would indeed fix this, it will only be fixed after a player reported the crash, which is not desired, and could be avoided by changing the behaviour of the engine.
I know this is a super old topic but that's what just happened to me, haha, a player just tweeted at me that they're getting exactly the crash described. But at least there's a solution I understand listed here!
I can vouch that as a non-programmer, this never occurred to me to consider, and I never thought to test the game with the audio settings disabled because I assumed the engine would handle this scenario on its own gracefully (my fault for assuming, I know the old saying, so I'm not upset, I'm just adding my two cents)
This problem actually affects even some of the commercial games. The "Resonance" will crash at game start if you run the game with sound disabled in setup.
Since I tend to often play games with sound turned off (in winsetup, if the game does not provide a costume sounds check), this is a "bug" I find often... :(
I'm however baffled to read that this is the "intended" behavior for AGS, rather than just ignore any sound related code... 8-0 Specially when it's not mentioned anywhere (that I know off) in the manual.
I've always assumed that once you turn off sound in winsetup, AGS just ignored any sound related commands... :-[
Well, to be honest, there are two perspectives to look from on this problem.
From the "experienced programmer" (tm) perspective returning null channel when no sound was played is logically correct, because no channel put in use.
From the "regular AGS user" perspective this is a source of multitude of errors and unexpected behavior that would bug you and your players tremendously.
90+% of AGS users are "regular users". The initial aim of AGS project is to let those users make games without much hassle.