@Raziel:
I can't reproduce that issue. All I'm doing is starting a new game and walking outside, and there is music.
I am getting a checksum error though; is ScummVM sending the sysex data too quickly?
EDIT: Found the cause of the checksum error, will submit a patch.
EDIT2: Patch submitted.
I still can't reproduce Raziel's missing music issue, though.
King's Quest 4 SCI MT-32 problem
Moderator: ScummVM Team
I commented on Hubert's bug report. The things he describes in his last comment all seem normal to me.Sven wrote:I still can't reproduce Raziel's missing music issue, though.
Thanks for finding the checksum bug, it should now be fixed.
Regarding the reverb issue. This is missing functionality and it cannot be resolved with one or two lines of code, so this will take some more time. We will keep you updated.
-
envisaged0ne
- Posts: 159
- Joined: Mon Nov 01, 2010 9:17 am
- Location: United States
There's a problem with the DOS CD version of KQ5 with the latest 54480 revision of ScummVM. When I launch the game, it initializes the MT-32, then I get the hourglass. Then the game crashes with a message stating the program has stopped working. This also happens when trying to use the MT-32 emulator. The game will play ok if I don't try to use any MIDI playback for the music.
No repro on that in 54490.
By the way, reverb handling in 54490 is better, but not correct. For KQ5 it now works right, because it will send reverb config 0 once it encounters the reverb 127 in the first song (is this true for all SCI1 games?)
For SCI0, it will send the default reverb read from the patch, but it does so before reading the reverb configs from the patch, thus sending nonsense to the MT-32.
By the way, reverb handling in 54490 is better, but not correct. For KQ5 it now works right, because it will send reverb config 0 once it encounters the reverb 127 in the first song (is this true for all SCI1 games?)
For SCI0, it will send the default reverb read from the patch, but it does so before reading the reverb configs from the patch, thus sending nonsense to the MT-32.
That has been fixed now, thanks!Sven wrote:No repro on that in 54490.
By the way, reverb handling in 54490 is better, but not correct. For KQ5 it now works right, because it will send reverb config 0 once it encounters the reverb 127 in the first song (is this true for all SCI1 games?)
For SCI0, it will send the default reverb read from the patch, but it does so before reading the reverb configs from the patch, thus sending nonsense to the MT-32.
I did some testing on the latest revision (54495):
Reverb appears to be correct in KQ1SCI, KQ4 and KQ5.
However, it is not correct in Police Quest 2. Running PQ2 in DOSBox, it seems the reverb is initialized to reverb config 0 (00 04 05), but is then immediately changed to reverb config 2 (01 01 07) by the intro song. ScummVM now initializes to reverb 0, but does not send the change to reverb 2.
The song in questin is sound resource sound.001. The byte sequence that triggers the reverb change is at offset 0x69, and it's B1 50 02 00. ScummVM only recognizes sequences starting with BF 50 as a revern change, but it appears that is not correct. ScummVM simply passes the B1 50 02 00 sequence on to the driver, which sends it to the MT-32, which does nothing with it because 0x50 is not a valid control change.
I don't know if this means that all control changes with value 0x50 should be treated as a reverb change, regardless of channel, or if there is some kind of difference between BF and B1.
It should be noted that I noticed that when I skip the introduction and then do something to cause the points fanfare to play, the reverb is first changed back to config 0, and then back to 2 (the points fanfare (sound.006) contains the same B1 50 02 00 sequence). When other music is played (I tried the airport music) the reverb was changed back to 0, even though that song resource doesn't contain any reverb change command (no B1 50 or BF 50 or any 50).
Based on that, I might surmise that B1 50 could mean "change the reverb for this song, but change it back afterwards". But that's just an educated guess, someone more familiar with the inner workings of SCI should look at this.
In any case, B1 50 does mean a reverb change and should not be forwarded to the device, which is what ScummVM does now.
Reverb appears to be correct in KQ1SCI, KQ4 and KQ5.
However, it is not correct in Police Quest 2. Running PQ2 in DOSBox, it seems the reverb is initialized to reverb config 0 (00 04 05), but is then immediately changed to reverb config 2 (01 01 07) by the intro song. ScummVM now initializes to reverb 0, but does not send the change to reverb 2.
The song in questin is sound resource sound.001. The byte sequence that triggers the reverb change is at offset 0x69, and it's B1 50 02 00. ScummVM only recognizes sequences starting with BF 50 as a revern change, but it appears that is not correct. ScummVM simply passes the B1 50 02 00 sequence on to the driver, which sends it to the MT-32, which does nothing with it because 0x50 is not a valid control change.
I don't know if this means that all control changes with value 0x50 should be treated as a reverb change, regardless of channel, or if there is some kind of difference between BF and B1.
It should be noted that I noticed that when I skip the introduction and then do something to cause the points fanfare to play, the reverb is first changed back to config 0, and then back to 2 (the points fanfare (sound.006) contains the same B1 50 02 00 sequence). When other music is played (I tried the airport music) the reverb was changed back to 0, even though that song resource doesn't contain any reverb change command (no B1 50 or BF 50 or any 50).
Based on that, I might surmise that B1 50 could mean "change the reverb for this song, but change it back afterwards". But that's just an educated guess, someone more familiar with the inner workings of SCI should look at this.
In any case, B1 50 does mean a reverb change and should not be forwarded to the device, which is what ScummVM does now.
In SCI0, reverb is always reset before every song.Sven wrote:Based on that, I might surmise that B1 50 could mean "change the reverb for this song, but change it back afterwards". But that's just an educated guess, someone more familiar with the inner workings of SCI should look at this.
I will look into the issue with the channel number. Maybe in SCI1 these are always on channel 15 and in SCI0 they may be anywhere.
We are aware of this. The code is still work-in-progress. I'll let you know when it's ready for testing.Sven wrote:Okay, that's interesting. May I point out that ScummVM currently does not do that? I guess a call to setReverb should be inserted into some place like sendInitCommands after all?waltervn wrote:In SCI0, reverb is always reset before every song.
