Implements feature request #15092, bringing the DirectSound driver
as an option for the game.
For now this is toggleable by editing scummvm.ini and adding:
windows_audio_mode=true
Differences between the DOS and Windows audio drivers:
* DOS:
- Apparently uses linear volume curves, as per the AIL/Miles drivers;
- Music can fade in and out;
- Fades sound effects in and out at each scene change;
- Lowers the volume of the music each time a speech line is playing;
* Windows:
- Uses DirectSound with volume tables for game volume -> decibel
volume conversion; the resulting logarithmic curve and slightly
different volume scaling for sound effects ensures audibly
different intensities for some sounds;
- Music can only fade out, not in;
- Does NOT sound effects in and out at each scene change;
- Does NOT lower the volume of the music each time a speech line is playing;
The PSX version doesn't have a credits Smacker video
but has a CREDITS.DAT file containing credits strings which
have to be displayed as a scrolling list of names and roles.
This ensures that when loading a savegame the top menu bar
doesn't enter in its open state by mistake because the mouse
coordinates are wrongly set as (0,0).
This patch is available in every executable after the
original UK one. Its purpose is to turn off scripts which
were causing issues by continuing running past their scope.
The patch, as descripted within the the original source
code, checks if the game is past the Syria section,
and if so it checks if the Market Stall section is still
alive, and if so it closes both the section (45) and
the Mega object for Duane (134), effectively terminating
their scripts.
We are only updating the menu bars when the screen is not fading.
This optimization restores the same code speed as previous
codebase iterations without thread-safeness whenever a menu
is interacted with during a palette fade.
This was deemed necessary by the fact that we have the main thread
and the timer thread which are constantly reaching out to functions which
update the screen in one form or another. By putting locks around calls to
_system->updateScreen() and _system->getPaletteManager()->setPalette()
we should be able to avoid issues like the one described in bug #14638.
I marked all places which seem sensitive enough when the main thread and
the timer are both in full operation. I might dial it back in the future after
we are sure that the original issue is gone.
Pressing SHIFT-M shows a debug mouse cursor, and
pressing CTRL-G shows the walk grid.
Also, moved the showDebugInfo() function to sword1.cpp
because it seemed more appropriate.
You can now pause the game via the 'P' key! Also, using CTRL-T
when ScummVM is in debug mode, toggles some on-screen debug
information which was also available in the original DOS version by
launching the game as "sword rev text". Implementing all of this also
meant that I had to finally implement the FPS counter.
I frankly don't know if the PSX version was supposed to have this, but
it appears to work right out of the box...
This now matches the source code and the executable;
this fixes a lot of inaccuracies, implements the tombstone
"death font", implements the Speed setting.
The askForCd() routine is now more accurate as well.
This flag is removed for a few reasons:
* Engines universally set this flag to true for widths > 320,
which made it redundant everywhere;
* This flag functioned primarily as a "force 1x scaler" flag,
since its behaviour was almost completely undocumented and users
would need to figure out that they'd need an explicit non-default
scaler set to get a scaler to operate at widths > 320;
* (Most importantly) engines should not be in the business of
deciding how the backend may choose to render its virtual screen.
The choice of rendering behaviour belongs to the user, and the
backend, in that order.
A nearby future commit restores the default1x scaler behaviour in
the SDL backend code for the moment, but in the future it is my
hope that there will be a better configuration UI to allow users
to specify how they want scaling to work for high resolutions.
The were defined as uint8 and the code was inconsistent in the
way they were handled, for example setting them to 1 in some
places and to true in others. It was working but relying on implicit
conversions both ways between 1 and true.