KYRA: More adlib driver code cleanup #2728
Call the opcode functions with a pointer to the parameters instead of data poiner reference and first parameter. The data pointer is updated in AdLibDriver::executePrograms() before calling the opcode function; an opcode can change channel.dataptr if (and only if) it wants to jump (and is responsible not to change it inadvertently).
DeepCode's analysis on #db5d96 found:
I've noticed an inconsistency in the encoding of addresses in the sound programs. There are two diffent encodings: in EoB addresses have an offset of 191, newer games use relative addresses. But the four callbacks with addresses as parameters use different conditions: update_checkRepeat() uses always relative addresses, update_jump() uses Eob style for version < 2, update_jumpToSubroutine() uses EoB style for version < 3, and update_setupSecondaryEffect1() always uses EoB style addresses. I don't know whether this is an inconsistency in the original drivers, a bug, or doesn't matter since the features aren't used by the games where it would make a difference. But unless it needs to be the way it is, the same code should be used everywhere to avoid confusion.
Do you know whether this can/should be changed?
I also considered reordering struct Channel to reduce padding, but didn't. What do you think?
Heya, thanks for your work on this. Please ignore the deepcode and codacy output, unless there is actually something valid in it. No need to make code changes just to silence the tools. The only thing you really want to check is the travis output for clang and gcc (there are no warnings from your code, so all is good).
From first glance I don't see anything I wouldn't be willing to merge. Maybe change the long type to int or int32, since we don't seem to use that type in Kyra, but that's not a real point of critique...
Regarding your question about the offsets: I would like to think that we got it right the way it is, since we went over the original driver disasms often enough. But honestly, I'll just have to take another look to be sure. I'll get back to you when I have your answer.
Changing the channel struct layout isn't really necessary, unless you really want to do it and the code layout doesn't suffer from it.
So, about the offsets: the absolute offsets in the original drivers are inconsistent, as they are not in match with the data provided by the sequencer (except maybe EOB1? - I remember fixing the teleporter sounds in EOB2, but EOB1 might have been correct).
This is what I found in the disasms:
Apparently Westwood changed these offsets to relative over time whenever they spotted a particular bug.
Still, I see no way to fix it, unless it becomes evident that there is actual corresponding data which is also correspondingly fixed.
* Move delete of sound data from AdLibDriver::setSoundData() to CadlPlayer::load() since the latter class owns the data. * Add helpers to reduce code duplication in handling of timer wraparound and _soundData offset checks. * Improve a comment on instruments table. * Reduce nesting level in AdLibDriver::executePrograms(). * Simplify struct clearing (layout independent) in initChannel(). * Change calling convention of opcode callbacks: data pointer is no longer a reference but channel.dataptr is updated before calling; drop last argument with the first data value. These changes have been merged in ScummVM. Link: scummvm/scummvm#2728