sciAudio - a new way to put sound in your games!

[gumby]

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.

[Collector]

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.

[Collector]

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?

[gumby]

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

[Collector]

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.

[gumby]

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.
 

[gumby]

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.

[Collector]

That would make sense since with the limitation of the PC speaker.

[gumby]

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.

[gumby]

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)

[Collector]

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.

[gumby]

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

[Collector]

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.

[Collector]

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.

[gumby]

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.