Community
SCI Programming => SCI Development Tools => Topic started by: gumby on October 20, 2012, 02:35:21 PM
-
sciAudio is here! Check out the "LockerGnome Quest Redux" demo game to see it in action!
-------------------------------
Features
-------------------------------
- Playback of WAV and MP3 files
- Unlimited number of sounds playing simultaneously
- Fade in/out, looping and volume control
- Classification of sounds for playback management
- Multiple commands may be issued simultaneously to the 'controller' file
- Multiple controller files to avoid resource contention
- Runs hidden in background & will terminate itself shortly upon game close
- Calls to sciAudio are performed very similarly to the built-in SCI sound calls
- Poor man's encryption (MP3's only) - simply rename your .MP3 to be .sciAudio
- Log file for troubleshooting sound playback ('sciAudio.log' located in same directory as sciAudio.exe)
-------------------------------
Limitations
-------------------------------
Works only in Windows (requires .NET framework)
-------------------------------
Setup
-------------------------------
1) Place the 2 nAudio DLLs & executable into a subfolder within your game named 'sciAudio'
2) Create subfolders within sciAudio for your playback files. Something like this
<gamedir>\sciAudio\effects
<gamedir>\sciAudio\music
3) Include the sciAudio.sc script & 'use' it in any script you wish to have sciAudio playback in
-------------------------------
Available commands
-------------------------------
command <playback command>
play
Begins playback of a sound
stop
Stops playback of a sound
change
Changes playback of a sound. Used primarily for volume & loop control, very limited usefulness.
playx (play exclusively based on sound class)
This behaves just like the 'play' command, but will stop any currently playing sounds with
the same sound class as the specified class.
fileName
Filename to playback, including the path.
soundClass
Sound class to assign this sound. This is simply a string to assign to the playback
for the purpose of potentially changing or terminating all sounds with the same
sound class at a later time.
For example, you might have several sound effects playing simultaneously in a room.
Upon leaving the room, you want to stop all the sound effects. To to this you would
issue a stop <soundclass> command, which would stop all currently playing sounds with
the specified sound class.
If no sound class is specified, a default sound class of "noClass" will be used
volume
Playback volume of sample. Default is 100 (100% volume of sample). Range: 0 to ~300?
fadeInMillisecs
Number of milliseconds to fade in the sample
fadeOutMillisecs
Number of milliseconds to fade out a sample. Can be issued with a play or stop command
loopFadeInMillisecs
Number of milliseconds to fade in a sample between loops.
loopFadeOutMillisecs
Number of milliseconds to fade out a sample between loops.
loopCount
Number of times to loop the sample. Default is 0, -1 is infinite
conductorFile
'Conductor' file name used to place commands into. This is how commands are passed between
the SCI virtual machine & the sciAudio application. The sciAudio application constantly polls all
conductor files, looking for changes & executes them. These files must have extension of .con.
The default value for this parameter is command.con.
Utilization of this parameter is useful in the event you have many near-simultaneous playback
commands issued from within your game. Multiple different conductor files can mitigate the
issue of potential file contention of just using a single file. Most game developers will
probably not need to use this option.
playXFadeOutMillisecs
Only used for the 'playx' command. Upon terminating any currently playing sounds for a
sound class, this value will be used for the fade out.
-------------------------------
Examples
-------------------------------
(use "sciAudio")
(local
snd
)
(instance aud of sciAudio
(properties)
(method (init)
(super:init())
)
)
...
= snd aud
// basic playback
(send snd:
command("play")
fileName("effects\\score.sciAudio") // important: note the two backslashes in path name!
volume("35")
loopCount("0")
fadeInMillisecs("3000") // fade in beginning by 3 secs
fadeOutMillisecs("2000") // fade out ending by 2 secs
init()
)
// looping playback example
(send snd:
command("play")
fileName("effects\\loopedSound.sciAudio")
volume("100")
loopFadeInMillisecs("2000")
loopFadeOutMillisecs("2000")
loopCount("-1") // loop forever
init()
)
// stop with 5 second fade out
(send snd:
command("stop")
fileName("music\\introMusic.sciAudio")
fadeOutMillisecs("5000")
loopCount("0")
init()
)
// change currently playing volume for a sound class
(send snd:
command("change")
soundClass("myMusicSoundClass")
volume("50") // set playback to 50% volume
init()
)
// stop looping a particular sound file
(send snd:
command("change")
soundClass("music\\introMusic.sciAudio")
loopCount("0") // stop looping
init()
)
// exclusive playback (starts new playback of sound
// & stops any already playing sounds (with fadeout) for same soundClass
(send snd:
command("playx")
soundClass("narration")
conductorFile("speech\\narrate.con")
fileName("speech\\newNarration.sciAudio")
playXFadeOutMillisecs("1500") // will fade currently playing "narration" sound class sounds
volume("200")
init()
)
-------------------------------
Notes
-------------------------------
If you decide to re-use the same sound instance for multiple sounds, it's up to you
to reset any previously specified properties, otherwise they will be carried over
into the next command
Use the sciAudio.log file (located in the same directory as executable) for troubleshooting sound playback.
-
This is very welcome news! I've been having problems with sound before. This may be the solution. I'm gonna go check it out in locker gnome.
Thanks!
WOW! I downloaded it and it sounds sweet. I thought it would clash with the art style, but it works really well!
I've tinkered around abit, but I cannot seem to get the script to work. Best I could figure, I copied the sciAudio script from lockerGnome into my game, but when I try to (use "sciaudio") I get a compile error.
-
Doan, what error do you get? Is it maybe a problem with the script number? You should be able to include the script just like any other, nothing special there. You probably need to include the script in the game.ini.
-
it says: "unable to open file:sciaudio.sco for reading!
Please forgive my ignorance (I'm not a programmer), but what do you mean by include the script in the game.ini?
-
Ah, I see the problem. Open the sciAudio.sc script and compile it - this is probably sufficient. That error is indicating that the sciAudio script hasn't been compiled yet.
I'm not sure if the game.ini file is an issue or not. However, the game.ini file is a text file in your game directory that maps every script number to a script name. The script number that I used for the sciAudio script in LockerGnome is 973. If it's not already there, put this line in your game.ini:
n973=sciAudio
That'll allow the compiler to resolve the (use "sciAudio") directive (I think!).
If you don't want to go through all this hassle, just create a new script in SCI Companion/Studio name it 'sciAudio', and then copy/paste the contents of my sciAudio.sc script into it.
-
I went into the game.ini and changed the name to sciAudio, but when I went back to SciStudio, the script became a closed file.
EDIT - Nevermind, I just went into the source folder and changed the file names from the room number to the script name. Everything compiled. Now I will try to see if I can get the audio to work
-
A closed file? I don't understand. Were you able to compile the sciAudio script?
EDIT: Just saw your edit, sweet! Let me know if it works for you.
-
I have everything compiled and good to go, but when I call for the music to play, there is only silence. I am wondering if I have not set up my subfolders correctly? You wrote:
2) Create subfolders within sciAudio for your playback files. Something like this
<gamedir>/sciAudio/effects
<gamedir>/sciAudio/music
Where do I write this?
-
You should be able to use the Locker Gnome Quest folder structure as a guide:
LockerGnomeRedux\src
LockerGnomeRedux\sciAudio\effects
LockerGnomeRedux\sciAudio\music
And of course I just realized that some of my examples are inconsistent with regard to folder structure (I'll update them now). If you are using my sciAudio script, all paths are relative to the sciAudio subfolder. So make calls like this:
// basic playback
(send snd:
command("play")
fileName("effects\\score.sciAudio") // note the two backslashes!
volume("35")
loopCount("0")
fadeInMillisecs("3000") // fade in beginning by 3 secs
fadeOutMillisecs("2000") // fade out ending by 2 secs
init()
)
This will play the <gamedir>\sciAudio\effects\score.sciAudio file (in lockergnome's case LockerGnomeRedux\sciAudio\effects\score.sciAudio).
Important note: Be sure to use two backslashes in path names!
I also forgot to mention that there is log file created in the sciAudio directory called 'sciAudio.log' to assist you with troubleshooting your playback. I've updated the documentation & original post.
-
I think I found why I am experiencing the problem I am. Whenever I run dosbox for my game I type in mount d d:/game and then I type in sciv.exe.
With GnomeQuestRedux, there is a shortcut button that runs it in dosbox without having to do all the typing. When I load GQR this way, the music and sound work, but when I run they game by typing in sciv.exe the sound isn't there.
So I guess my next question is, how do I create the shortcut like you have done for GQR?
-
I would recommend using Collectors customized DosBox installer for sciAudio that is included in the Locker Gnome Redux demo game (DBRunSetup-sciAudio.exe). Put it in your game directory & run it - then just use the newly created RUN.EXE to launch your game.
-
Great! It all seems to be in working order now! Thanks for troubleshooting with me :)
-
Awesome, glad its working for you! Looking forward to seeing what you put together.
-
I think I found why I am experiencing the problem I am. Whenever I run dosbox for my game I type in mount d d:/game and then I type in sciv.exe.
With GnomeQuestRedux, there is a shortcut button that runs it in dosbox without having to do all the typing. When I load GQR this way, the music and sound work, but when I run they game by typing in sciv.exe the sound isn't there.
So I guess my next question is, how do I create the shortcut like you have done for GQR?
If you drop "DOSBoxRunSetup.exe" (or "DBRunSetup-sciAudio.exe" for use with an sciAudio game) in the template folder of Studio/Companion and edit the template game's game.ini's Executable line from:
Executable=SCIV.EXEto
Executable=DOSBoxRunSetup.exe
it will copy the setup to every newly created game. The first time that you click the Run button in Studio or Companion the setup will automatically run and then start you game in DOSBox. Every time you click the Run button thereafter, the game will automatically start in DOSBox. No manual mounting or configuration needed. There are two versions of the App. The original an one modified for sciAudio. If you want to use sciAudio in a game that you are developing, you need to either rename "DBRunSetup-sciAudio.exe" to "DOSBoxRunSetup.exe" or edit the new game's game.ini from
Executable=DOSBoxRunSetup.exe
to
Executable=DBRunSetup-sciAudio.exe
-
New problems ;)
I can only seem to get the sounds you included in GnomeQuestRedux to play. I have changed midi and wav files to mp3 (via itunes), put the mp3s in the correct folder, changed the extension to .sciAudio but no sound.
You mentioned that it could play WAV or MP3, but how do I convert these files to sciAudio files? Thanks
-
The audio files are simply renamed to the .sciAudio extension. Look inside the ".con" files to see if it is calling the right name of the audio files. If you do not have a naming mismatch, perhaps iTunes is converting to some odd proprietary version of MP3. Try using Lame to convert to MP3. Munt (included with the SCI Sound Utilities) can convert MIDI to WAV.
-
Sounds like you are doing everything correctly to me Doan. It does sound like iTunes is creating incompatible files.
You are right, you just rename the file extention to .sciAudio. Note that this only works with MP3s. If you want to use WAVs, you'll need to keep them with the .WAV extension. It should also work with .MP3 file extensions too. I just checked the code again to make sure. Oh, and I just found out that AIFF files will work too (though I haven't tested them) - but need to remain with AIFF as the extension.
I'd recommend downloading a new MP3s off the internet & seeing if those work okay for you, at least to eliminate iTunes as being the culprit.
Oh, yeah and check the sciAudio.log file & verify that you can see it at least attempting to play the file. If you'd like, I can take a look at it if you post it here.
-
I could add LAME to the Sound Utilities while incorporating sciAudio it, as well. I am not sure that a MIDI to WAV function is really that needed as MIDI can just be added by converting it to a SOUND resource via Soundbox.
-
I haven't tinkered in a little bit, because I have been very busy. I do want to thank both of you for troubleshooting with me on this.
Also, I wanted to convert the midi's and use sciAudio for them because I've been getting some weird audio problems using the sound resources and I thought this may allow me to bypass them.
-
I wanted to convert the midi's and use sciAudio for them because I've been getting some weird audio problems using the sound resources and I thought this may allow me to bypass them.
Have you been selecting tracks in Soundbox to be used with your selected driver? You should not use Roland without having Roland music that you are using, otherwise the SOUND resource will sound weird, especially without a real MT-32 or at least Munt. BTW, Munt is included with the Sound Utilities, but you still need to track down the ROMs.
-
I feel pretty stupid now! I just got a few minutes to tinker around some more and I just entered things in wrong. I kept compiling with the .sciAudio extension for mp3 and wav files. When I simply compiled the script as .mp3 and .wav instead of .sciAudio, everything worked perfectly.
Sometimes you just gotta be humble and admit to being an idiot ;D Thanks for the awesome new program and all the help you have given me in making it work!
-
We are all allowed the occasional brain fart.
-
That's awesome Doan! I'm glad it's working for you now. Are you updating one of your previously released games with audio, or is this a new endeavor?
-
Not updating and not something new, but still tinkering around on Betrayed Alliance from 2007 or 2008. It's been so long I can't even remember when I started working on it!
-
Finally getting a chance to play with this. Pretty cool indeed. I am going to have to step the game up just to match the music. I have pulled out Adobe auditions and did some pretty heavy cutting and pasting, but here is the source of my first in game mp3, VG intro song (http://youtu.be/sx5Llsu9qms?t=24s) and it's working.
I am thinking about generating a small mp3 of silence, and then when the player quits the game, making a call to stop the other music and play it instead. It would eliminate the music playing on after the window has closed, or it would at least give that illusion. Granted this would only work for proper exits and not force closes, but that's still something. Any body have any other thoughts on this one, it really bugs me when the music plays on after the game has closed. I realize the cause, the mp3 playing program doesn't know yet that the game is closed, just trying to think of ways to fake it.
Collector, what is the easiest way to turn the automatic backups off on this Run.exe. Was there a checkbox that I missed or something. For now I have just gone ahead and changed the executable name in the game.ini file to use the dosbox batch file. That works around the run.exe and still seems to pump out the mp3 sounds just fine.
-
Yeah, I guess I didn't put create a command to 'stop all currently playing files' - an equivalent to the 'playx' command, something like 'stopx'.
Cloudee, your proposed workaround should work just fine, good idea.
-
The RUN with backup was just an experiment. I wrote it as an answer to prevent the corruption on run, but that does not seem to be a problem with DOSBox. The current version does not make backups. You must have an older version. The attached version does not backup. I could do a version that can optionally backup, if anyone wants.
-
Collector, where can I find the dosbox for sciaudio installer with the non backup version of run.
Also, how hard would it be to tweak the configure file before it comes out of the installer so that the aspect ratio is right.
It's not that hard to edit it manually, but when someone else downloads the game and installs it, it would be nice if they didn't have to go in and change the config file to get it to come out looking the way I drew it.
For example, here is a screenshot with the proper resolution vs straight out of installer...
(http://s27.postimg.org/fqr2hscv7/vg1.jpg) vs (http://s27.postimg.org/6189yz5lv/vg2.jpg)
Here is what I would like the conf file to generate which gives the proper resolution:
[sdl]
output= overlay
fullresolution= 0x0
windowresolution= normal
fullscreen= false
autolock= false
[dosbox]
machine= svga_s3
captures= .
[render]
aspect= false
scaler= normal1x
[cpu]
core= normal
cycles= 10000
[autoexec]
cls
@ECHO OFF
mount c .
c:
cd \
SCIV.EXE
exit
-
Did you look on the Wiki? I don't remember what is on there. If not, I'll have to look around for the full package. If I can't find it, I'll have to rebuild it.
Actually, SCI was designed to have a 4:3 aspect ratio. The reason that on modern monitors the image looks stretched is because the shape of the pixels of a modern monitor are shorter than they were in the old DOS days. This has added scan lines to the monitor, which gives greater resolution. This change occurred with the introduction of VESA/SVGA. However, it made the old games with the same number of scan lines designed for the old monitors unnaturally stretched since the lines are thinner. That is the reason that aspect correction was added to DOSBox.
As to fan games, what aspect is correct, of course will be what ever the graphics were designed for. But the designer should remember that on most monitors that when using full screen, DOSBox will stretch it to 4:3 anyway. Some monitors/graphics card drivers will allow the user to stretch the screen to fill, but not all and most users will not want to bother to set it for individual games. I would have to rewrite the config tool to add aspect correction selection. The one for the run tool is essentially the same one that I had already written for my SCI0 installers for official games.
On a side note, I noticed that you have "scaler= normal1x", which is an invalid entry. That will give you normal2x since DOSBox ignores invalid entries and fall back on its defaults. If you really want to have 1:1 scaling use "scaler= none", but true 300x220 and 300/200 will look like thumbnails these days.
-
Yeah, I have noticed that the normal1x didn't actually accomplish 1 to 1. But since everything seemed to work, I never went back and changed it.
I may just go ahead and write my own little installer. Not one that does everything that yours does, but one that just rewrites or generates the conf file, and the batch file to point to dosbox.
Then instead of cleaning up the dosbox from my game before release, just include the new installer to write the settings that I am forcing upon them.
-
Give me a little time and I'll try to get around to a new version. One other thing, your "captures= ." could cause issues on machines with UAC turned on. This is why the default is in %LocalAppData%\DOSBox. If the game is in a system folder in %ProgramFiles% with UAC on, all of the captures will end up in the VirtualStore. For my own use I have the captures set to the game's folder, too. Sort of makes sense for developers to keep all material for a project together. I could add a method to see if a a game's path includes a system folder or if UAC is turned on and adjust the generated conf entry accordingly.
It might make sense to have two versions. One for game development and one for distribution. It was originally designed to work with Studio's and Companion's run command for development. The needs for game distribution are a bit different. Gumby and I had been working on something that addresses the needs for both as part of a larger project, but that project has been placed indefinitely on the back burner for various reasons.
If I am going to do a rewrite of the run tool, are there any features anyone desires? Any thoughts or ideas are welcome.
-
Ok, Gumby are you ready for this...
How difficult would it be to base the volume, not only off of the volume passed in the mp3's init statement, but to also incorporate the games current volume setting into that as well. Such that an in game volume of 15 would play the sound at 100% of the volume set in the init statement. So if init is set to 50% and gVolume is set to 15 then the sound would play at 50%. Likewise, lowering gVolume to say 10 via the menubar would then force the same mp3 to play at the same level as if I had entered 33% instead of 50% (.67 * 50) and lowering it to 5 would play the sound at 16% (.33 * 50).
As well, F2, or toggle sound. Any thoughts on how we could go about giving a user the ability to mute or unmute. Even moreso, while a sound is playing.
*Edit
Actually it appears as though the current in-game volume controls do not actually work. It took me a bit of testing to come to this conclusion but now I am pretty sure of it. In both the pnc template and the parser template, changing the volume has no effect on the games actual volume. Add this code to the init section of any room to see for yourself
FormatPrint("volume: %d %d" sndVOLUME gVolume)
Then simply go in the room, exit it and change the volume via menubar and then reenter room. I can't get either of the values to change and they should be changing as the volume is changed... which tells me the volume isn't changing.
Also, closely tied into that I tried to do some basic manipulating of the volume variable in the sciAudio script by adding this to the top of the if <> volume -111 snippet, for testing I figured just using a switch statement would be the easiest to see a result.
(if(<> volume -111)
(switch(sndVOLUME)
(case 0 = volume 0)
(case 8 = volume (/ 3 volume)) // until we fix the volume control issue noted above... this is the only case triggered.
(case 10 = volume (* (/ 3 volume) 2))
(case 15 = volume (* 1 volume))
)
...
Unfortunately, the value passed to the command.con didn't come out looking very pretty.
soundClass noSoundClass
volume u????˦amp;??^]übr /> loopFadeInMillisecs 0000
** Edit 2
Ok I am no closer to any kind of solution, but assuming that someone figures out how to fix the in-game volume control, this line in the sciaudio script I believe makes sense logically, unfortunately it is still no closer to working as this time it sends an empty result to the con file which quickly kills the player.
//StrCat(@msgBuf (/ (* gVolume volume) 15))
-
I had this thought at one point as well regarding integrating the volume controls into sciAudio. I'll take a look at implementing this functionality.
I do remember doing a lot of testing around the playback levels. I think it works like a percentage, so it's perfectly legitimate to pass in a value like 500, which should play the sound at 500% normal volume. As I recall, a value of 100 is 100%, so play it at the MP3 normal volume.
-
It would be good to have the sound mute on game close, even if the user simply clicked the close window button rather than quitting the game. I have heard complaints from people about the audio not terminating with the game.
-
Yeah that's bugged me too when the music keeps playing for 20 to 30 seconds after the DosBox window is closed. I should just more aggressively check to see if the game is running, maybe every 5 seconds or so.
-
Or do a task kill from the run utility. I could have it wait for the DOSBox process to exit, then kill the sciAudio process. Not sure if there was some way to pass something on to sciAudio to exit more gracefully? Perhaps have it write to the conductor file to issue an exit command?
-
We can certainly cause the music to stop if the game is exited 'correctly' (i.e. from the 'Quit' command within the interpreter and wiring in a call to issue a stop command to sciAudio) but I quite frequently kill off DosBox with the 'X'. So within sciAudio, I have it polling the running tasks maybe once a minute within Windows and if I can't find either 'RUN.EXE', 'DOSBOX.EXE' or 'SCIV.EXE' running, I then kill off the audio playback. My thought was to just poll more frequently and hopefully that would take care of the issue.
I think also adding in a task kill within the RUN utility would be good too, I'm all for it.
-
We should probably try to cover all of the bases. More frequent polling and having the run utility issue a mute all and possibly a task kill. A mute all would avoid the possibility of killing the wrong instance of sciAudio, in case a user might have two going at the same time for some reason. Otherwise I would have to not only check for the process name, but also to see what the parent process is.
It has been a while, but I believe I had a separate run for the sciAudio, so it would certainly be possible. Cloudee also mentioned a couple of things in another thread that would require a rewrite of the run utility I am going to be redoing it in C#, which will give me a great deal more flexibility. I guess it is time to do a proper implementation.
-
I thought that I would try to get started this weekend. The approach that I was going to take was to make the run tool remain running in the background to wait for the DOSBox process to end, then issue a command via the COMMAND.CON file to cause sciAudio to mute all. Then it occurred to me that it might be better if sciAudio simply had an exit command that the run tool could write to the COMMAND.CON.
-
OK, the new run tool is now adds:
(sciAudio
exit
)
to the end of the COMMAND.CON file when DOSBox is closed by the window exit button. If sciAudio changed to close when the game is normally exited AND accepts the above code to exit, it should take care of the trailing audio on exit. The game exit could close sciAudio with the same command.
What I am thinking is to have two different config tools. One for the developer and one for distribution of the game. The development one will have a few extra options that can be set, such as backup, being able to run a debug version of DOSBox, etc.
-
Yes, I can make those modifications to sciAudio. Not sure when, but I'll get to it.
-
Here is the beginning of the new config tool for the developers. Two tabs. Any suggestions for additional features? I still have to decide how I am going to pass information between the run utility and the config utility since they are stand alone apps. It would work out great if I could force them to use the same .NET config XML settings file.
-
small window resolution 640x400 ;)
-
Already done. Those label are dynamic. If you deselect aspect correction, the labels will reflect it.
Just spent the day adding in a CTRL+Click on each control that will open a browser that load the DOSBox Wiki entry for that setting for more info. That was a lot f busy work that got old very fast. I still need to track down the right URL to add for each control.
-
The new run is mostly finished. I am waiting to know exactly what to hook into sciAudio. I managed to get the two apps to share the same XML config file, so setting from the config tool can be used but the run tool. So now, if you set it to not backup the game's resources on run from the config tool, the run tool will not.
On another note, while testing switching of sciAudio and the backup feature, I had started 120 Below from the new run, but closed the window before clicking past the first credit screen. sciAudio crashed before it had played the first sound. I have attached the crash logs, but I suspect that if it is changed to exit properly on DOSBox close, it would prevent the crash. The run did write to the COMMAND.CON, so could it be a sharing violation?
-
Could be a sharing violation, this could be tested by using an alternate conductor file to issue the command from the RUN application to eliminate that possibility.
Your suggestion in your previous post of issuing an 'exit' command to sciAudio is just fine with me, let's go with that. I just need to find the time to work on this stuff.
-
I could simply disable the writing to the con file altogether to see if the premature exit trips up sciAudio. Of course if it is a sharing violation, we would have to work out another way to handle it.
-
Just tested. Commenting out the part that writes to the con file does not cause sciAudio to crash, but does when it writes to it. Looks like some kind of sharing issue. I really do not see why, since it is being written by and external program anyway, i.e. the SCI engine. Without looking through the source, does sciAudio ever write to the con file?
-
I don't think so, it's a 'one way' street. Only the sci game should be writing to the con file like you said.
I'm now out of action for the next day or so. In ER, apparently it's time for my appendix to be removed :(
-
I hope everything goes smoothly for you. While I have never had to have mine out, my brother and a couple of friends have had to go through it. It didn't lay them out for too long.
I was doing a "using StreamWriter", which was locking the file. The violation was from sciAudio trying to read a locked file. I am now just creating a new instance of StreamWriter, which allows me to manually close the file. Still it would probably be best to add a try/catch on the read in sciAudio.
I have also temporarily added a kill process. at least until sciAudio can be updated with a close command. It will indiscriminately cause all processes named sciAudio to close. It may be a rare situation that someone would have more than one instance running at any given point, but I don't think that it is an ideal way to handle it.
-
Ok fellahs, I've got an itch to get a new version of sciAudio released.
I've fixed the issue with the game exiting and the music continuing to play. My initial implementation was a really bad hack where it just periodically polls the running processes, looking for RUN, DOSBox or ntvdm running. I scrapped that and just attached to the running process and blocked the main thread waiting for it to complete. Much, much simpler and more intellegent way of doing it. Now the sound is killed immediately when the game exits.
Before I throw this out there I'm going to look into the in-game volume controls & see if I can get them first working, then wired into sciAudio.
EDIT: I've also changed sciAudio to allow multiple instances running. As a result, I had to make the 'process attaching' smarter. Now it only looks for processes (RUN, DOSBox, ntvdm) that have started in the past 5 seconds, and in the event of multiple ones found (I don't think this'll ever happen, but!) it grabs the process that most recently started. The result, I can play x different games with sciAudio at the same time - overkill I'm sure :). I tested it by simultaneously running 120 below & a beta copy of VG. Upon killing one, the correct instance of sciAudio was killed and the music stopped while the other game continued to work as expected with sciAudio.
-
I figured out the problem with the in-game volume controls - there is no problem, just a limitation of the default sound driver (STD.DRV). Apparently when using this driver you have no control over the volume. I switched my test game over to the GM.DRV and I now have volume-control goodness.
-
That would make sense since with the limitation of the PC speaker.
-
Just spent the last 3 hours beating up on the sciAudio.sc script. I managed to get the script size down from 3.07K to 1.06K. The only major caveat is that I shrank the total possible command size from 1000 characters down to 250. It should be enough, but in the event it isn't the developer will need to increase the size of the msgBuf array.
I ended up implementing a bunch of constants & putting nearly all the strings into a text resource.
-
sciAudio v1.1 is here.
-------
Changes
-------
- Fixed occassional crashing of sciAudio when multiple sounds are attempted to be played at the same time
- Modified sciAudio to immediately close when game is closed
- In-Game volume controls now supported, both volume change levels and on/off toggling
- Decreased sciAudio script size from 3.07K to 1.18K
---------------
Important Notes
---------------
- There are several new files/updates necessary to allow sciAudio to function properly:
- sciAudio.sh - contains constants referenced within sciAudio.sc
- TEXT.100 (or whatever text res number you wish to use) - contains static strings that are written out to the COMMAND.CON file
- menubar.sc - modified to include calls to sciAudio for the volume controls (including on/off functionality)
-
I haven't looked at the source yet, but how did you determine when the game closes? Watching the SCIV.EXE process won't work if it gets named something else. Did you add a command that is issued by the game to close? I guess I'll have to update the run utility.
-
When the application starts, it looks for a RUN, DosBox or ntvdm process that was launched within the past 5 seconds. It then blocks the main thread until the process exits, at which point it exits. This approach was possible because the app eventing works off of monitoring changes in the COMMAND.CON file which isn't on the main thread.
Yeah, if you wouldn't mind updating the RUN utility that would be great :)
-
One problem with it looking for "Run" is that it is the one file that a developer would want to rename to match his game. Perhaps use its PID instead of the name? I guess that you included the NTVDM for anyone on x86 trying to run it directly. They would have to edit or make the batch file themselves instead of using the run utility. Still it is a good idea to cover all of the bases. Identifying processes.
Edit: I just looked through the new version and saw that you did add an exit command, too. The new run waits for process exit then issues an 'exit' command to the con file. I'll have to test it still to see if file locking will cause problems.
-
It does not seem to be accepting the exit command. This is not a problem in most cases, but if you exit the game without exiting DOSBox the audio still continues.
-
I'll check out the 'exit' command; forgot I put that in :). I see what you are getting at with closing the game without closing DosBox. If I wire the sciAudio 'exit' command with the 'Quit' command for the game in the menubar.sc that should take care of it. Good catch.
I also see opportunity for one more additional feature. Pausing the game should ideally pause the audio as well. Not sure if I can pause the audio playback, but I'll take a look.
-
By the way, sciAudio is still having occasional problems where it'll either fail to play a sound or fail to exit when the game closes. I think the failure to play is caused by not being able to write to the conductor file.
-
Are you closing the file after every write? Could it be an issue with UAC? What if the file was written in the temp dir? Another possibility, is the file getting locked by any other process?
-
Yeah, it could be any of those. I haven't had a chance to troubleshoot very much yet, been just 'go-go-go' with getting Soulshade Asylum completed.
-
I also see opportunity for one more additional feature. Pausing the game should ideally pause the audio as well. Not sure if I can pause the audio playback, but I'll take a look.
Have you had a chance to ponder this pause idea yet. I have found a use for it.
Now that I now had to add cue points to a midi track and actually code against them I can sync the music to the action in the game. However when a print dialog appears on the screen, the midi track is paused however the sciaudio is not. Thereby throwing off the synchronization.
-
For this other little project I was working on
http://sciprogramming.com/community/index.php?topic=1618.msg9332#msg9332
I thought about how to implement audio, and I was going to offer support for sciAudio (e.g. just make it work automatically, because why not? I could do so by intercepting file system calls and seeing if it's writing to the conductor file, etc....).
But looking at what it takes to set up sciAudio and how it works, it seems like it could be simpler. It looks like most of the functionality could be abstracted away in the Sound class itself, and you wouldn't need to special case "sci audio" sounds. Your wav/mp3 files (it looks like they need to be renamed to .sciaudio, but I'm not sure why that decision was made) could just be numbered (or prefixed with a number) and plopped in the main game folder. e.g. 104_GunShot.wav. Then when you play sound 104, it would check to see if there is a file corresponding to that number, and send the info over to sciaudio instead of calling the DoSound kernel. Or rather, calls to DoSound could be replaced with calls to DoSoundCustom, which either forwards to DoSound or sciAudio. Basically, it would mean supporting all the DoSound functionality and forwarding to sci audio instead.
Of course, there are some features like fadein/fadeout times that the Sound class doesn't support (though it could be extended to do so).
Anyway, I just thought of this as I was looking how to support sciAudio - and instead I realized it would be much easier to just support wav files in the DoSound kernel - it's a little more seamless to write scripts against (and it's basically what Sierra did when they started supporting digital audio). And then I thought why couldn't sciAudio do the same? But I haven't used it, so maybe I'm overlooking something? If Gumby pops in again, maybe he could comment? Or maybe someone wants to take this up on their own? It might only require changes to the sci scripts.
-
Basically HD texture packs then, but for sound resources. Implementation-wise, that is.
-
Anyway, I just thought of this as I was looking how to support sciAudio - and instead I realized it would be much easier to just support wav files in the DoSound kernel - it's a little more seamless to write scripts against (and it's basically what Sierra did when they started supporting digital audio). And then I thought why couldn't sciAudio do the same? But I haven't used it, so maybe I'm overlooking something? If Gumby pops in again, maybe he could comment? Or maybe someone wants to take this up on their own? It might only require changes to the sci scripts.
If I understand correctly, your question is can we integrate the calls to sciAudio into the Sound class and removing the need for a separate script file (sciAudio.sc)? I think that should be possible.
-
Correct. I think it could all be hidden inside the Sound class (or possibly even in a wrapper around DoSound kernel, although that might be more complicated), and then be seamless to integrate - people could just switch over their sounds one by one by removing the midi resource, and adding a mp3/wav file that somehow uses that same number.
Slight downside of course is that you're referencing a number from script instead of a meaningful name - but having it work just like digital audio works in SCI1.1 seems like it could be a good thing.
-
Of course now that we have SCI1.1 how much will people need or want to use sciAudio? It was a great thing when we were limited to SCI0 and people were struggling with Soundbox and the limitations of what small wav samples could be embedded in a sound resource. And it does not take ScummVM into account.
If we do expand support for it, would it change the usage of the conductor files? How would it affect the termination of sciAudio on exit as there has been a problem with continuing after the game has exited. I did an inelegant solution with the DOSBox launcher for sciAudio to kill the process on DOSBox exit. This was also inexact as I had no easy way to distinguish between two instances of DOSBox running at the same time.
-
Kinda makes me feel like hacking ScummVM.
Kinda.
Just a little.
-
Bored again?
-
Hacking ScummVM for what? It already supports sciAudio. Nothing would change.
If we do expand support for it, would it change the usage of the conductor files? How would it affect the termination of sciAudio on exit as there has been a problem with continuing after the game has exited. I did an inelegant solution with the DOSBox launcher for sciAudio to kill the process on DOSBox exit. This was also inexact as I had no easy way to distinguish between two instances of DOSBox running at the same time.
Nothing would change with the conductor files.
-
Hacking ScummVM not to use sciAudio or anything, but to intercept DoSound calls and play an external track where available. So if you do (gMusic number: 4 play:), and there's a track-4.ogg or whatever, it'll play that instead of sound resource 4. No sciAudio.
And yes I'm bored, but not (that) suicidal.
-
Ah, makes sense. It's probably not *that* difficult, given that it already has logic to do the exact same thing for Sierra's digital audio resources.
-
Also some of the SVM supported games that people did "enhanced" digital sound tracks to replace the original internal MIDI.
-
Hacking ScummVM for what? It already supports sciAudio. Nothing would change.
Huh? Since when?
Also some of the SVM supported games that people did "enhanced" digital sound tracks to replace the original internal MIDI.
Ugghhh.....don't remind me.
-
Since a while. Supposedly it can handle conductor files but I never got it to work.
(I might misremember, it's 2:57 AM.)
-
I've never actually tested it, I just saw logic in the source code that handles sciAudio.
-
All I remember was asking them to support it and not getting an answer. I guess they just did it quietly...?
-
Apparently support was added 2 years ago (https://github.com/scummvm/scummvm/commit/6a519f7f40bbbb2e8887e69cef1ecd2b029d7490).
On an unrelated note - I lately contributed a ScummVM patch (https://github.com/scummvm/scummvm/commit/aaf8cbca0049aa9161e507a22724a56e19009695) to fix a bug in QfG3 which prevented getting full score. If you're a QfG3 fan you might find it interesting.
-
Troflip, I'm working on reworking sciAudio script to be integrated into the Sound class. I've hooked into the existing commands (play, stop) and check to see if SOUND.XXX file exists (renamed from .mp3) in the sciAudio directory and if so, it'll fire up the sciAudio logic.
End result is what you were referring to, just simply drop in the sciAudio assets & replacement mp3 files and the existing commands to play sounds should 'just work' and sciAudio will handle the playback.
-
Very cool! Glad it worked out :D
-
In trying to track down why Doan's installer broke the sciAudio I found an issue with the program. At first I thought it was a bug in the Publisher plugin, but it turned out that by changing the name of the launcher from 'RUN' to the game's name was causing sciAudio to prematurely exit, so no sound. I have been mulling over solutions, but some of them seem more like workarounds or hacks.
It seems like the best way would be to get sciAudio to look for the launcher regardless of the file name. Easy enough to change the sciAudio source to look for a different specific name than RUN, but that would require the user to edit and then recompile the program. I would rather not have to have the user to install VS if they do not already have installed. Perhaps have it look for an INI file with the game's launcher?
Any other ideas?
-
Yes, in order to not have sciAudio become a zombie task upon game exit, there is a thread that is periodically looking for a known application running (RUN or SCIV?), if it doesn't find it running it kills itself.
An INI or config file makes sense. I'm kicking myself for not considering that, I think it's hard-coded in the application itself.
-
Yes, in order to not have sciAudio become a zombie task upon game exit, there is a thread that is periodically looking for a known application running (RUN or SCIV?), if it doesn't find it running it kills itself.
An INI or config file makes sense. I'm kicking myself for not considering that, I think it's hard-coded in the application itself.
How do you think I should proceed at this point?
EDIT:
Yup, after installing, if I change the name of the executable "Betrayed Alliance" to "RUN" sciAudio works.
-
I'm looking into making the changes now. Would it work/make sense to put another section in the game.ini file for this? Input welcome.
-
Changed my mind, I'll have read it's own sciAudio.ini file in the same directory as the executable. Keeps things clean/unpolluted.
-
New version attached here and also put all this code into a git repo, apparently it wasn't before: https://bitbucket.org/nellisjp/sciaudio/
Now there is an sciAudio.ini file (needs to be in the sciAudio subdirectory of your game) that is read in and used for monitoring a list of (5) possible applications to monitor to determine when to kill sciAudio. It's a bit hacky, and 5 applications might be overkill but it gives a little flexibility and is backward-compatible with the previous versions which monitored either 'RUN', 'DosBox' or 'ntvdm'. I also improved the logging around all of this so it's a bit easier to troubleshoot.
Here's what the included INI file looks like, modify it to suit your needs:
[sciAudio]
GameExecutableName1=RUN
GameExecutableName2=DOSBox
GameExecutableName3=ntvdm
GameExecutableName4=
GameExecutableName5=
-
New version attached here and also put all this code into a git repo, apparently it wasn't before: https://bitbucket.org/nellisjp/sciaudio/
Now there is an sciAudio.ini file (needs to be in the sciAudio subdirectory of your game) that is read in and used for monitoring a list of (5) possible applications to monitor to determine when to kill sciAudio. It's a bit hacky, and 5 applications might be overkill but it gives a little flexibility and is backward-compatible with the previous versions which monitored either 'RUN', 'DosBox' or 'ntvdm'. I also improved the logging around all of this so it's a bit easier to troubleshoot.
Here's what the included INI file looks like, modify it to suit your needs:
[sciAudio]
GameExecutableName1=RUN
GameExecutableName2=DOSBox
GameExecutableName3=ntvdm
GameExecutableName4=
GameExecutableName5=
Fast work! Thanks for the update!
-
Yes, in order to not have sciAudio become a zombie task upon game exit, there is a thread that is periodically looking for a known application running (RUN or SCIV?), if it doesn't find it running it kills itself.
An INI or config file makes sense. I'm kicking myself for not considering that, I think it's hard-coded in the application itself.
I remember when this first came up and the solution. I was looking through the code earlier to refresh my memory of the fix.
Agree that its own ini is best. The game.ini is more for Companion and may not necessarily be distributed with the game unless it includes the source. If the user selects the sciAudio template I can have Publisher make the entry in the new ini. Don't think that Companion should be changed to accommodate this. Not sure how many new sciAudio games we will get with SCI1.1 being available unless someone really wants the SCI0 graphics.
Doan, give me a little time and I will make adjustments to Publisher to add the EXE name to the sciAudio ini.
-
Sure, no problem! Thank you both for all the help!
-
Finally got some time to look at this. I noticed that your git repo does not include the updated code.
-
Gumby, there still seems like there is a problem. Sometimes it will launch with sound and other times it does not. In all cases DOSBox and the launcher are loaded, but sciAudio closes so fast that it never shows in the task manager. Perhaps adding some sort of delay before it starts monitoring processes?
-
No problem, see attached. I added a 5 second wait before monitoring any running processes, that should do it.
-
That seems to fix it. Could you update the sciAudio page on the Wiki?
-
Wiki is now updated.
-
Updated Publisher has been uploaded to the Wiki. It may be a while before I have time to update the repo.
-
Updated Publisher has been uploaded to the Wiki. It may be a while before I have time to update the repo.
So with the update SCIAudio and Installer am I good to proceed with a patch (especially now that the save bug is fixed!) or do I need to wait for the repo? I'm not exactly sure what that is.
-
Only the source on git has not yet been updated. The prebuilt binary on the Wiki has been. Grab the latest from the Wiki and replace the old one in the Companion plugin directory. Replace the old sciAudio in the game with Gumby's new build. Load the game in Companion and start Publisher from Companion and republish.
-
Only the source on git has not yet been updated. The prebuilt binary on the Wiki has been. Grab the latest from the Wiki and replace the old one in the Companion plugin directory. Replace the old sciAudio in the game with Gumby's new build. Load the game in Companion and start Publisher from Companion and republish.
Alright. I redownloaded the installer and sciaudio, but now I'm hitting a problem I've not seen before. The NSIS publisher is not allowing me to compile?
Edit...I bet I know what's wrong. I probably forgot to delete some stuff from earlier. Will trouble shoot.
Edit again. Hmmm. Same problem. Not sure what's going on
-
I'll have a day off in a couple of days or so when I can take a look.
-
I'll have a day off in a couple of days or so when I can take a look.
Take as much time as you need...I just hope it's not me being dumb!
-
No, it was not you. It was from fixing a bug that turned up in Win10 where the program would close shortly after a timer for button management started. This did not happen in Win7. I did a quick fix to avoid using the timer, but it does not allow the compile buttons to re-enable. Looks like I need to redo the whole button management from scratch.
-
No, it was not you. It was from fixing a bug that turned up in Win10 where the program would close shortly after a timer for button management started. This did not happen in Win7. I did a quick fix to avoid using the timer, but it does not allow the compile buttons to re-enable. Looks like I need to redo the whole button management from scratch.
That doesn't sound fun. Sorry to hear it ☹️
-
I think that I have everything fixed. Grab the new version from the Wiki. Try it and play with it. Kick the tires and see if you can break it and let me know.
Besides code cleanup I also added a few extra tweaks. The project properties tab will now autopopulate if launched from Companion with a game loaded in it. any of these fields can be changed before generating/regenerating script. If including source files the script will now ignore any "*.bak" files. These can manually be readded to the script if desired.
-
Collector, I downloaded the most recent version (1.3). I'm getting unusual behavior and cannot get the program to publish. Sometimes It will produce a script, but have the same problem where the compile button is unavailable. Other times it simply won't produce a script at all regardless of if I press publish or not. One time it gave me a script AND allowed me to compile, but it said there was an error. When I tried comment out the error line (just to see what happened), it wouldn't compile at all anymore...
I think I followed all the directions properly.
-
Did you start with Publisher or Publish?
* Completely delete the old Publisher and unpack the new version in Companion's plugin folder.
* Start Companion, load your game and click the plugins menu and select "NSIS Publisher". It should open to the game's properties tab with most of the fields filled.
* Complete any missing fields and/or make any corrections. Click the "Publish" button above the fields. It should generate the NSI script and the compile buttons should be enabled.
-
Did you start with Publisher or Publish?
* Completely delete the old Publisher and unpack the new version in Companion's plugin folder.
* Start Companion, load your game and click the plugins menu and select "NSIS Publisher". It should open to the game's properties tab with most of the fields filled.
* Complete any missing fields and/or make any corrections. Click the "Publish" button above the fields. It should generate the NSI script and the compile buttons should be enabled.
I followed these steps and am getting the same problem. The Publish button currently doesn't seem to be doing anything.
I tried other fan SCI games as well and am getting the same issue.
-
I'll take another look, but it is working for me.
-
I'll take another look, but it is working for me.
Hmm...well that's good! I wonder what's going on on my end? I will keep tinkering. I think I'll start from scratch with everything. Companion, the Installer, and NSIS
Damn! I just downloaded/reinstalled new versions of Companion, the Publisher, and NSIS, merged the foldres and am getting the same result...very frustrating!
I cannot seem to get it to produce a script at all, for any game I put in, whether I press "publish" in companion or "NSIS publisher." All the project properties are auto-filled just as you said, but when I click "publish" nothing seems to happen. If I click the NSI script editor tab, there is just a blank page.
-
OK, it was a silly little error from a quick cleanup just before the final build. Go grab it now.
-
OK, it was a silly little error from a quick cleanup just before the final build. Go grab it now.
Glad to hear it! I will give it a shot soon.
Ok! Things are working, which is good. I'm getting an invalid path error around line 56. I don't have much time to troubleshoot (Wife's bday and all) but hopefully tonight I will give it more attention.
Thanks for updating this Collector!
Edit 1: Got it to publish Quest for the Cheat, but still struggling with Betrayed...will keep at it.
-
Got it to publish Betrayed as well, but had to comment out line 56
!insertmacro MUI_PAGE_LICENSE "${PROJECT_PATH}\Publish_Include\LICENSE.TXTIf I leave that in, I get:
Compiling Script...
Processing config: C:\Program Files (x86)\NSIS\nsisconf.nsh
Processing script file: "D:\Ba1_1\Betrayed Alliance Playtest Version\Betrayed Alliance Copy\Setup Script.nsi" (ACP)
LicenseData: open failed "D:\Ba1_1\Betrayed Alliance Playtest Version\Betrayed Alliance Copy\Publish_Include\LICENSE.TXT"
Usage: LicenseData local_file_that_has_license_text | license_lang_string
Error in macro MUI_PAGEDECLARATION_LICENSE on macroline 17
Error in macro MUI_PAGE_LICENSE on macroline 6
Error in script "D:\Ba1_1\Betrayed Alliance Playtest Version\Betrayed Alliance Copy\Setup Script.nsi" on line 56 -- aborting creation processAm I just missing some file that I should have?
-
@Gumby
I finally got everything installing and working properly with music! I'm ecstatic!
There is one weird thing going on with SCI audio (I think). I don't mess with the volume or allow player input to change it, but sometimes the audio seems to play louder than other times. I'll open the program and the title theme will play either loud or softly. Then when the next song starts, sometimes it's loud and sometimes it's soft. There doesn't appear to be any rhyme or reason. I'm not too concerned about it, I think somehow the volume is bouncing between 70 and 100...I just don't know how or why.
Any thoughts?
-
It's just not finding your "LICENSE.TXT" in the "Publish_Include" folder. Drop it in that folder or change the path in the script to match. You can comment the line out as you did if you do not want to use a license.
-
There is one weird thing going on with SCI audio (I think). I don't mess with the volume or allow player input to change it, but sometimes the audio seems to play louder than other times. I'll open the program and the title theme will play either loud or softly. Then when the next song starts, sometimes it's loud and sometimes it's soft. There doesn't appear to be any rhyme or reason. I'm not too concerned about it, I think somehow the volume is bouncing between 70 and 100...I just don't know how or why.
Any thoughts?
Offhand I don't know why that would happen. Are you including a volume command on playback? If so, maybe the adjustment of the volume is failing sometimes. Can you post the command you are issuing along with the output from the sciAudio.log file?
-
Offhand I don't know why that would happen. Are you including a volume command on playback? If so, maybe the adjustment of the volume is failing sometimes. Can you post the command you are issuing along with the output from the sciAudio.log file?
First instance of music code:
= snd aud (send snd:
command("playx")
fileName("music\\profilegames.mp3")
volume("70")
loopCount("0")
init()
)Next:
= snd aud (send snd:
command("playx")
fileName("music\\titlescreen.mp3")
volume("70")
loopCount("0")
init()
)Third - this one gets loud every time I've tried now (about 10 times) more often than others.
= snd aud (send snd:
command("playx")
fileName("music\\intro.mp3")
volume("70")
loopCount("0")
init()
)Then a little different:
= snd aud (send snd:
command("stop")
fileName("music\\intro.mp3")
fadeOutMillisecs("4000")
loopCount("0")
init()
)followed by:
= snd aud (send snd:
command("playx")
fileName("music\\wizardsroom.mp3")
volume("70")
loopCount("-1")
init()
)There is also a room with has a musical score and if you come and go (restarting the music) once in a while it gets loud. It's call is the same as the others:
= snd aud (send snd:
command("playx")
fileName("music\\overworld.mp3")
volume("70")
loopCount("0")
init()
)
As for the log, I'm not quite sure where to locate it. Is this what you mean?
Disposing of file stream
Beginning playback for: music\titlescreen.mp3
sample volume is: 70
Reading INI file: D:\BA1_1\Betrayed Alliance Playtest version\Betrayed Alliance\sciAudio\sciAudio.ini
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Monitoring application: DOSBox. sciAudio application will run until DOSBox exits.
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
attr.command = play
Sample Volume = 70
Stopping playback for sound class: nosoundclass
Stopping playback & disposing
Disposing of file stream
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Beginning playback for: music\intro.mp3
sample volume is: 70
Starting fade out of 4000 milliseconds
Stopping playback & disposing
Disposing of file stream
attr.command = play
Sample Volume = 70
Sound class isn't currently playing, cannot stop: nosoundclass
Fail: WaveOutEvent device was not closed
Fail: WaveOutEvent device was not closed
Beginning playback for: music\wizardsroom.mp3
sample volume is: 70
Monitored application not found running, or the 'exit' command was issued. Exiting application.
-
I played with the volume on the one that is always LOUD, and even when I put it down to 15, it still is louder than the other songs. It does vanish as you go down, though. 0 is inaudible and 1 is very soft.
Edit: that room is not always loud! If I wait a bit longer on the previous room, the volume will be "normal". So there's something to do with timing?
-
Yeah, that's the log that I was referring to. I wonder if the volume setting is carrying over from the previously played sound. Maybe the fade settings on the previous sound?
EDIT: But it doesn't look like you are fading from the titlescreen sound to the into. Hrm.
-
Hi.
I admit that I haven't read the thread...
However, according to its title, it might be a good place to share that sluicebox, ScummVM's main SCI dev, has added support to SciAudio:
[scummvm:master] 5 new commits
ee553af SCI: Re-add Betrayed Alliance 1.2 detection entry - sluicebox
b9f9733 SCI: Add fan game Soulshade Asylum detection entry - sluicebox
843dd30 SCI: Add support for fan library sciAudio 1.1 - sluicebox
4b5260f SCI: Fix volume slider bug in fan games - sluicebox
f1d4ff6 SCI: Fix boundary checks when drawing font chars - sluicebox
Including a fix to volume issue, that might be related to the last posts here.