Well, I am happy to unpack it.
The only TADS code is the OutputFilter defined in websound/websound.t. Basically all this does is scan output for tags. It rewrites them in an XML compliant way and then uses eventPage.sendEvent to send them to the browser.
On the browser side, I modified main.htm to load the new sound libraries (websound/sound.js and websound/soundmanager2.js). I also modified the main.js script to initialize the sound code (line 27) and to handle tags (line 115). Those were the only real changes needed in the stock code.
However, since main.htm and main.js are part of webui, they are already included as resources in the T3 output. One approach would be to copy the entire webuires folder from the base install into the game directory, and then modify the files locally. This is straightforward but requires all of those files to be distributed instead of just the modified ones. It has the drawback of making the change look much more invasive than it really is.
If you look at the Makefile.t3m, you’ll see that I used a different approach. I included the modified files in a separate directory (websound) and then told the compiler to name them something else when linking them in. This is normal; the unusual part is doing that when there is definitely another resource with that name already in the .t3 file. First the default webuires/main.htm gets added as webuires/main.htm, and then websound/main.htm gets added as webuires/main.htm. The old resource is still there, but it’s inaccessible because another resource took its name.
This seems to do what I want - the first main.htm gets superseded by the next one - but I don’t know if it’s guaranteed to work.
Something similar has to happen with audio files in order to get them to where the browser can find them. Normally if you had a file called res/audio.mp3, you could link it in and all would be well. But with WebUI the files need to be under the webuires structure or the browser can’t access them. So in the makefile, you can say “add this resource but use this path instead of the original one” - that’s what the last line does.
Then in your T3 code you can refer to “res/audio.mp3”, the JS code will look for “/webuires/res/audio.mp3”, and the compiler will make sure that is the resource path.
The idea is that authors can use the same sound tags to support audio in both adv3 and adv3web games. The only thing that has to change is the makefile, but that has to change in any case to include the networking features.
If you open up soundPlay() in sound.js the rest of it should be clear. It’s just straight JS code at that point. Right now it only does stuff with the src and cancel attributes. But you could add any attribute you like and handle it in a similar way. For example:
function soundPlay(tag) {
var cancel = tag.getNamedItem("cancel");
if (cancel) {
soundManager.stopAll();
}
else {
var mp3Src = tag.getNamedItem("src");
var oggSrc = tag.getNamedItem("oggSrc");
// some code that uses both the MP3 and OGG filenames to set up SM2
}
}
Then your T3 game code could send a somewhat nonstandard sound tag that references both files.
<sound src="res/test.mp3" oggSrc="res/test.ogg" />
Whether that works depends entirely on how the soundPlay function handles that combination of attributes.