If the volume is set too high the OpenAL backend preamplification leads
to overdriven sound samples. It's not quite understandable to me why
that only happen on platforms other than Linux (maybe a bug in OpenAL?)
and there's not much we can do against it besides reducing the volume.
As the side note: Simmilar behavior can be seen at least in ioQ3 and
dhewm3...
This cvar is a last resort if all other measures to prevent overdriven
preamplifation fail. Setting it to lower value than 1.0 limits the
overall dynamic range, so sound quality is lost. This is especially
hearable when low volume samples are encountered, like the shotgun
combined with the silencer.
The client uses float values between 0.0 and 1.0 to represent the volume
of sound samples. This is the range required by OpenAL. But the generic
part of the sound system multiplied the raw float value with 374 and
clamped it to a full integer. That worked by luck withth the OpenAL
backend but broke at least the silencer powerup. Solve this problem by
adding a new field "float oal_vol" to the channel_t struct and use it to
pass the raw float value to OpenAL.
This fixes issue #18
Since OpenAL 1.15 AL_GAIN has much more weight than before. That leeds
to overdriven effect samples unless the volume control is set to a very
low level. With this change volume can be set to a high level without
distorting. But there's one problem. A division by 2 is to low to rule
distortion out and by 3 the game is a little bit quieter than before. A
value of 2.5 would be optimal but is not applicable since the volume is
represented by an integer. I've choosen 3 to be aon the save side.
As a side note: This problem was very less worse on Linux than on
Windows and FreeBSD. Maybe Linux guys need to pump there volume up
to compensate this work-around.
For ia64 it's necessary to define int as long long instead of long int. I know
this for a fact because pointers that were encoded as long int in my LLVM and
CLIPS bridge would fail horribly when passed out of clips back into LLVM. long
long fixed it.
If "horplus" is set, the "fov" cvar is interpreted as the horizontal FOV
in a 4:3 screen, and is adapted automatically to the current screen
aspect ratio accordingly. If not set, use the old Vert- approach.
In addition, "horplus" can also be set from the video menu by selecting
the "Auto" option for aspect ratio, which also resets the FOV value to the
standard 90 degrees.
Finally, add a 5:4 aspect ratio (1280x1024) and correct the 16:9 angle
slightly.
These are the code changes and Makefile changes necessary to build and
run Yamagi Quake II on Max OS X. OS X 10.6 or higher is required, older
version may work but we cannot guarantee it. The documentation will be
added in another commit. This patch was contributed by W. Beser, I made
only some small cosmetical changes.
