When I change the display mode in-game, AudioSystem throws an exception whenever I try to set volume or any other property after the display mode change. This is of course because reinit() in StandardGame does this:
if (AudioSystem.isCreated()) {
AudioSystem.getSystem().cleanup();
}
(...)
if ((settings.isMusic()) || (settings.isSFX())) {
initSound();
}
If I comment that out I can change display mode while the sounds and music are still running just fine, and also I have no problem setting volume.
So that leads to this question: Is there a reason for the above code except that the settings might have changed? In other words, is it safe to keep AudioSystem running through a display mode change?
Yes, it is safe to keep the sound running, but reinit() takes for granted that EVERYTHING should be re-initiatlized. Perhaps it should be split out into additional methods and reinit() would simply invoke them all?
As far as the exception that is occurring hopefully Renanse can help since I haven't really done anything with the new sound system yet.
Are you setting properties on existing soundtracks? DF's cleanup destroys and recreates the sound system, which would mean any existing tracks are now invalid.
Yes, I'm sorry for being unclear. I am not wondering about the exception since as you are saying it is thrown because of invalid tracks/source identifiers.
I just wanted to know if it is safe to keep sound running during a display mode change. And darkfrog says it is, so I'm happy about that
It would be good to have them separated. I am using recreateGraphicalContext(). It would be good if that method didn't also reinit the audio system.
I've added a reinitAudio() and reinitVideo() that are both invoked from reinit(). I've also made these methods public so they can be invoked from the outside. This will go in my next check-in.
for better code homogeneity shouldn't reInitAudio & reInitVideo be done in the update queue instead of having only the "recreategraphicalcontext"->reinitAudio&video like this ?
Ownership of problems is great when the owners have the time to do all the work. Since jME is a community driven project we thankfully can rely on patches from the community. You see that as a problem?
Ownership of problems is great when the owners have the time to do all the work. Since jME is a community driven project we thankfully can rely on patches from the community. You see that as a problem?
Just think its funny that everytime you check in code there are bugs - and your usual quote is "please feel free to post a patch". Professional pride .....
Just think its funny that everytime you check in code there are bugs - and your usual quote is "please feel free to post a patch". Professional pride .....
Every time I check in code there are bugs? Perhaps I should refrain from checking in code then if my code is so buggy...good point. ;)
I will point out though that this is not so much a bug as an enhancement even if you are being a jerk. :-p
I think it's nice - Darkfrog will jump right in and help out, and facilitate patching. I remember he put in a patch of mine a while ago, although I could do some refreshing of it now. Maybe theprism is joking around, maybe not…but…I guess everyone likes to give you crap
No worries, I just find it interesting that someone is complaining about not supporting my code when I haven't touched anything in jME for probably a year…