[ scummvm-Patches-1508018 ] SCUMM Adlib SFX guesswork (Indy 3, MonkeyVGA, ...)

[SourceForge.net]

Patches item #1508018, was opened at 2006-06-18 09:45
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418822&aid=1508018&group_id=37116

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Torbjörn Andersson (eriktorbjorn)
Assigned to: Nobody/Anonymous (nobody)
Summary: SCUMM Adlib SFX guesswork (Indy 3, MonkeyVGA, ...)

Initial Comment:
Currently, some of the Adlib sound effects for older
SCUMM games like Indy 3 and the floppy version of
Monkey Island 1 sound pretty strange. Perhaps most
noticeably, the effects for opening and closing doors.
I don't know exactly how this is supposed to work, but
I've looked a bit at it and made some guesses that I'd
like to hear what others have to say about.

First of all, the Adlib sound effects are handled by
ScummEngine::convertADResource() where, apparently, we
convert the resource to the data layout used by newer
SCUMM games. One of the steps of this is to convert
some sort of frequency number ('freq') to a note value
('note'). We can see that in most cases 'freq' will be
a fairly low number, but in some cases it will be a
very high number. Let's assume that these high numbers
represent the wrong sound effects.

Looking at
http://www.gamedev.net/reference/articles/article446.asp
we can see that in Adlib, the note is specified by two
values: A 10-bit "F-number", and a 3-bit octave value.
This seems to correspond fairly closely to what we do
in our code. We can probably assume the standard
12-tone scale, so adding/subtracting 12 would move the
note one octave, and if 'freq' has anything to do with
frequencies then doubling/halving it would move it one
octave.

So if I understand it correctly, we currently do this
to adjust 'freq' to the octave:

freq <<= ((current_instr[ch][1] >> 2) & 7) + 1;

So we add one to the three-bit octave field. Suppose
that the value is supposed to wrap around to 0 after 7.
In that case, it should instead be something like this:

freq <<= (((current_instr[ch][1] >> 2) + 1) & 7);

I've tried this, and it makes the door sound a lot more
reasonable to me. The good thing about it is that for
most cases, this change should make no difference
whatsoever. But I don't know for sure if it's right or
wrong.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=418822&aid=1508018&group_id=37116