KYRA: More adlib driver code cleanup #2728
Conversation
Free the sound data in SoundPC_v1::internalLoadFile() since it's owned by this class instead of in the driver's setSoundData() method.
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:
Top issues
|
|
Additional note/question: 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? |
|
DeepCode seems to be deeply confused. The description of the issue is nonsense. Maybe it doesn't like line 755? |
|
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. |
|
Thank you for taking the time to check the situation in the disasms. Well, since the code can't be made more consistent, I won't change it, of course. |
|
Is this ready to be merged? I have done a few quick tests with the relevant games. Seems like everything still works... ;-) |
|
Yes, I think it's ready. |
* 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
Again some improvements to the code that shouldn't change behaviour in any way.
If you don't like that I'm changing the way the callback functions work, you may drop the last commit, but I think it's cleaner like that.