S86 volume envelope fix

[grgowski]

S2X_S86WSGTrackUpdate calls S2X_S86WSGEnvelopeUpdate before S2X_S86WSGChannelUpdate which causes an issue at the very first track update. I think that the envelope flag is set and no update is being performed resulting in zero volumes. I have looked at the S1 equivalent and saw that S2X_S1WSGEnvelopeUpdate is called within the S2X_S1WSGChannelUpdate which is the proposed fix for the S86 driver. I have checked that solution against the register dumps from Mame and it seems that it fixes the issue but I am not sure if that does not have any other side effects. Can you please have a look and see if that makes sense?

[superctr]

What exactly is the issue that is being caused by the current behavior? Please give me an example. I checked a disassembly from the Thunder Ceptor sound driver, and it updates the envelopes _before_ the sequence update. For reference, the channel update function starts at 0x9bf1, the envelope function starts at 0x9c1c, and sequence function at 0x9dc4. I think I had to change the behavior here (to match the disassembly) due to an edge case in one of the tracks. Alas, I also didn't keep track of which game/song caused this, so I think you'd have to go through every game to find side effects. Perhaps you could put it in S2X_S1WSGChannelStart instead

…

On Sun, Feb 28, 2021 at 10:43 PM grgowski ***@***.***> wrote: S2X_S86WSGTrackUpdate calls S2X_S86WSGEnvelopeUpdate before S2X_S86WSGChannelUpdate which causes an issue at the very first track update. I think that the envelope flag is set and no update is being performed resulting in zero volumes. I have looked at the S1 equivalent and saw that S2X_S1WSGEnvelopeUpdate is called within the S2X_S1WSGChannelUpdate which is the proposed fix for the S86 driver. I have checked that solution against the register dumps from Mame and it seems that it fixes the issue but I am not sure if that does not have any other side effects. Can you please have a look and see if that makes sense? ------------------------------ You can view, comment on, or merge this pull request online at: #13 Commit Summary - S86 volume envelope fix File Changes - *M* src/s2x/wsg.c <https://github.com/superctr/QuattroPlay/pull/13/files#diff-953f57e50cd54021e0417b47686cbca196e2a1b57d24a164fe4e780b02be7bb4> (3) Patch Links: - https://github.com/superctr/QuattroPlay/pull/13.patch - https://github.com/superctr/QuattroPlay/pull/13.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#13>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAI3B4PMJTCY5AG5EN4H4G3TBK2ILANCNFSM4YLPH6YQ> .

[grgowski]

The problem is causing a single frame delay for all volume envelopes starting in frame 0. The first time S2X_S86WSGEnvelopeUpdate is called it does not update volumes because the Env[0].Flag is set. The first time that flag is cleared is in S2X_S86WSGChannelUpdate in the if(!C->WSG.SeqWait) part which comes after the envelope update was called.

If you check volume values for all channels after the first iteration you will see that all of them are zero and in the consecutive frames the envelopes are delayed. Here is a register dump for the first channel in Thunder Ceptor. The corresponding volume envelope is xC and the volume should be set to 8 in the first frame.

frame 0: 0x00 0xE1 0x24 0x00
frame 1: 0x08 0xE1 0x24 0x00  
frame 2: 0x06 0xE1 0x24 0x00 

I also see that it does not make sense to move this envelope update to the wrong place so this PR can be closed. Perhaps a better workaround would be to not set the Flag in S2X_S86WSGChannelStart immediately after the initial volume envelope (from the header) is assigned. Let me know if that makes sense or suggest alternative and I will issue another PR.