Don't show any warnings if the game was started with --nosound.
If there is no sound device connected only show one warning at startup and no ingame warnings.
My fix may not be the best one, but it works.
Differential D1481
Remove the unneeded sound warnings when no sound Stan on May 2 2018, 8:39 PM. Authored by
Details
Don't show any warnings if the game was started with --nosound. My fix may not be the best one, but it works. Start one game without connected sound device and one game with sound device but with`--nosound`. (Seems only be reproducible on windows)
Diff Detail
Event TimelineComment Actions Successful build - Chance fights ever on the side of the prudent. Link to build: https://jenkins.wildfiregames.com/job/differential/458/display/redirect
Comment Actions I didn't read the SoundManager file yet, but in general not creating a component (or passing a dummy component) if the --nosound argument is passed sounds nicer than creating a soundmanager that is determined to be unused and error out and then trying to catch and hide the result? Comment Actions IIRC the change in GameSetup.cpp makes that no component is created with --nosound. Comment Actions So the question is: How can the code detect a missing soundcard if sound is enabled prior to creating the SoundManager? Comment Actions That doesn't explain the reader how the reader can reproduce the thought. An alternative would also be to not catch this error and have the program exit horribly, but informing the user what to do (configuring some sound device thing), Comment Actions The catch also catches any kind of exception, which raises the question whether we want to catch and silence other errors or rather have people experience the errors and report them.
Comment Actions So what about setting a bool m_correctAlcInit to false when no device is connected and check for that after constructing CSoundManager instead of catching an exception? With my patch an unconnected device throws exactly one warning, but then remains silence (in contrast to the error spam we currently have), which is the behaviour we want. Comment Actions We don't expect the user not to connect a sound device. But we use the exception to handle that unexpected possibility.
The program shouldn't exit, because it's no fatal error. We can't pick an other device, because if the exception is triggered no device at all is connected. Comment Actions
An un-recoverable error in the constructor is _the_ use case for an exception and the above would be a really ugly workaround imo. Two solutions I think:
Comment Actions
If the only case that is dealt with in this diff is a user not having any sound device for real and not some bug or misconfiguration, then the code should expect that. That's very much expected now that we know that users with that configuration exist. throw has the intention of dealing with program errors and program errors should be avoided. (Not so important, still.) It should detect that situation and then notice that it doesn't need a soundmanager and whatever else is involved that --nosound disables (I see some more stuff about that than g_SoundManager, ISoundManager::SetEnabled(false)?). Tried this thing https://code.wildfiregames.com/D1481#68798 ? Comment Actions That! No, the intention of throw is to escape the usual code path in case something unusual happens. (One example from Java: If you try to open a file you don't have the rights to, it throws an exception. It is not necessary a program error, but it is unusual, so an exception gets thrown.)
That means you want to initialize the alcDevice before initializing the soundmanager and then pass that to the constructor of the soundmanager. (Or you would need to init the device twice) That would result in ugly code. Using an exception is just the cleanest way to go.
Comment Actions Did you try to check the specs or just like what you see and end it there?
Comment Actions Seems like I can't reproduce that bug anymore. Comment Actions Successful build - Chance fights ever on the side of the prudent. Linter detected issues: Executing section Source... source/soundmanager/SoundManager.h | 27| #include·"items/ISoundItem.h" | | [MAJOR] CPPCheckBear (syntaxError): | | Code 'classISoundManager{' is invalid C code. Use --std or --language to configure the language. Executing section JS... Executing section cli... Link to build: https://jenkins.wildfiregames.com/job/docker-differential/2826/display/redirect Comment Actions Successful build - Chance fights ever on the side of the prudent. Linter detected issues: Executing section Source... source/soundmanager/SoundManager.h | 27| #include·"items/ISoundItem.h" | | [MAJOR] CPPCheckBear (syntaxError): | | Code 'classISoundManager{' is invalid C code. Use --std or --language to configure the language. Executing section JS... Executing section cli... Link to build: https://jenkins.wildfiregames.com/job/docker-differential/2827/display/redirect |