BGM Queue

[Jesuszilla]

Currently, the only way to do something akin to 3rd Strike's round changing music is to use a combination of BGMVar and ModifyBGM. A much better solution (more similar to what Capcom originally did) would be to make a BGM queue so that the next proper track(s) can be queued up for future playback.

This would require some restructuring of the BGM, but I think it could be a worthwhile feature for full games in particular, or perhaps even enable Xbox-style "playlist" playback eventually?

Not a very high priority for me but I'd like to at least document this for later.

[Jesuszilla]

I've given a little more thought to this and I'm wondering if I should solely do it just for this engine, or if I should perhaps add the queue functionality it to beep but as far as this engine is concerned:

New SCTRLs: QueueSND and QueueBGM, which would take the same parameters as PlaySND and PlayBGM, which would behave similarly, except they'd queue up sounds to play in succession on the respective channel (or BGM) with the following additional parameters:

• queuePos - Queue position. Always clamped to the range of [0,QueueLength]. Defaults to QueueLength if not specified.
• afterLoopCount - The number of loops of the currently playing BGM or snd after which to start playing the new BGM or sound. Defaults to 0 (after the current loop) if not specified.

QueueSND and QueueBGM both would enqueue sounds (or BGM) for immediate playback after position >= loopend in either case.

I'd also propose the following BGMVar attributes: BGMVar(NumLoopsElapsed) and BGMVar(QueueLength). The former would return the number of loops elapsed so far (we should keep track of this so that the afterLoopCount parameter can properly account for future loops regardless of how many loops have passed). The latter would simply return the length of the current BGM Queue.

Perhaps we should also introduce SndChVar as well which would take 2 args, e.g. SndChVar(0, IsPlaying), SndChVar(0, QueueLength), SndChVar(0, VolumeScale), SndChVar(0, FreqMul), ...

[potsmugen]

Regarding queuing, when you have to add so many parameters to such a new Sctrl, isn't the BGMVar+PlayBGM combo still more flexible/simple? I've never tried anything of the sort but can't you do like:

if $nextbgmcondition && BGMVar(name) = "current.mp3" && BGMVar(position) = 9999 {
	PlayBGM{name: "next.mp3"
}

As for the sound trigger, that has been a long time coming. I would personally take a more verbose name over abbreviations, like SndChannelVar or even omit the channel with SoundVar.

[Jesuszilla]

Thought about this a little more after implementing SoundVar, but the reason for a queue over doing this in ZSS is because ZSS only updates at 60FPS, much slower than sound processes.