When using the original drascula dialog to change volume, this was
not saved to the ConfMan, which means the change was lost when
quitting the engine or when opening the ScummVM options dialog.
Also synchronising the _mixer volumes from ConfMan was resetting
the master volume to the maximum. Since ScummVM doesn't have a
master volume, there is no correct way to get it. But we now try to
guess one from the music and speech volumes.
The bug made it possible to only talk once to the drunkard. Any
further attempt to talk to him did nothing. This led to a dead end
if we did not ask about Von Braun the first time around.
This was a bug in ScummVM. The original game did not have the bug.
Added it into hasFeature() of all engines which returned `true` in
simpleSaveNames() before.
As mentioned in #788, SCI is not always using simple names, so it
doesn't have such feature now.
Engines with "simple" savenames would support "Run in background" in
save/load dialog and gradual save slots unlocking. Other engines
save/load feature would be locked until save sync is over.
The delay occurred when trying to interrupt the animation while at
the start of the first scene with Igor. After the interruption (skipping
the intro, return to launcher or quitting ScummVM) it would continue
to play the animation for a bit longer than necessary.
Recently we started to use this as new semantics, although in the past
we used simly <engine>_H. Now these guard defines are consistent with
rest of the files which are used in the engines.
I don't see any purpose to this delays and they were not present in
the original engine. It works fine without those and the interface
seems more responsive.
This fixes bug #7121 DRASCULA: Delay and freeze when pressing
right mouse click on game
Also move a delay when left clicking to after performing the action.
With the delay between the left click and the action, the mouse
position could have moved when performing the action, resulting
in the wrong action being performed (e.g. activating the wrong verb
or picking the wrong object in the inventory). But removing the
delay altogether causes flickering when picking objects from the
inventory.
The delay, since it updates the mouse position, resulted in a
different verb being selected than the one we clicked on when
moving the mouse quickly after the clic. This was quite confusing
and frustrating. I can't see any reason for this delay and it seems
to work well without it. The initial commit adding it indicates this
was "for better mouse response", but it added a lot of other delays
at the same time, and removing this one doesn't see to impact the
mouse response (on the contrary, we get the new cursor quicker).
The original engine skipped the first 32 and last 32 bytes of the
data when playing a sound. We did not do it in ScummVM which
resulted in noise at the start and/or end of some speech. This
was most noticeable with Spanish speech but also occurred
occasionally with English speech.
This fixes bug #7120 Drascula: Audio noise before every voice in
the game
The visible[1] flag in room 31 (i.e. for the axe) is now reset according
to flags[13] (which indicate if we picked up the axe already or not).
This fixes bug #7118 Drascula: Axe item can be picked up infinite
times
To time animations the original engine uses interrupt to get the
Real Time Clock and divides the number of clock ticks by 0.182.
Since there is approximately 18.2 ticks per second, this means
it uses values in 1/100th of a second. In ScummVM we were using
getMillis() / 20, so the animations was two times slower than in
the original.
This might fix bug #7115 Drascula: FPS are incorrect or some
frames are dropped.
Note that for the walk animation we are still not exactly using the
timing of the original. The original engines keeps each walk frames
for 5.7 times 1/100th of a second (i.e. 17.54 FPS). In ScummVM
getTime returns an integer value and as a result each walk frame is
now kept for 6 times 1/100th of a second (i.e. 16.67 FPS, which i
better than the 8.33 FPS we were getting before this commit).
as our getTime returns integer values and thus we use
frames for 6 of 1/100th of a second while the original is slightly
faster as it kept frames for 5.7 times 1/100th of a second.
When splitting strings into several lines to fit on the screen the
original engine could result in lines with one character beyond
the right edge of the screen, which in practice would be drawn
on the next line on its own, aligned to the left (and not centered).
This commits adds a check to avoid this situation. So although
it now behaves slightly differently than the original engine this
is for the better.
Here we transition from an animation at end of chapter 5 to another
animation at start of chapter 6. Usually the cursor is hidden when
performing the action that triggers the animation. But here there is
no action to trigger it and the cursor is made visible when starting
a new chapter or entering a room (so between the two animations).
So explicitly hide it at the start of this specific animation (and it gets
shown again when we enter room 102 at the end of the animation).
This was a regression from commit fa3d3e3 and this fixes part of
bug #7113 DRASCULA: Serious sprite glitches.
The original uses extraSurface to draw text in draw_abc() in the
Spanish version while other languages use tableSurface. But in
ScummVM this was changed to use tableSurface for all languages.
However this caused an issue in chapter 6 when displaying the
inventory has it is also using tableSurface, as it was for all languages
in the original. While using the same surface works for other
languages, in the Spanish version we get the wrong background in
the inventory.
Rather than revert to using extraSurface for drawing text which is
a big change and impact all the chapters, I have opted to simply
swap the usage of the tableSurface and extraSurface in chapter 6
for the Spanish version compared to the original engine. The
changes therefore only impact chapter 6 and only the Spanish
version. I played the chapter in full to check that it indeed works
without causing adverse effects.
When saving from the pendulum scene the curX and curY values are
negative while the curWidth and curHeight values are unset. This
causes random crashes as we may do an array out of bound access
when enterRoom() is called at the end of the load.
I checked the original and the code in ScummVM and there is no
call to talk_solo in chapter 4, while we indeed need to use the red
color for all calls to talk_solo in chapter 5.
The previous fix only fixed the incomplete state when loading from
the launcher. Now this is fixed when loading from the game as well.
It also fixes loading a savegame from the first stage of the pendulum
scene (when the protagonist is not visible) to any other scene in
chapter 6. The protagonist was not made visible again when loading
the savegame.
Room 102 has two states. The first one has an animation of a
pendulum while the protagonist is chained to a table beneath it.
The second state is after the protagonist free himself. In the second
state the pendulum has stopped. When saving in the first state,
loading the save game did not properly setup the pendulum
animation causing graphic glitches.
This fixes bug #7113 DRASCULA: Serious sprite glitches
There was an unhandled case in chapter 2 when the character is at
the exact Y location and close to the X location to where we asked
him to walk. The code started the walk but without properly setting
the curDirection and trackProtagonist variables. This resulted in the
walk never stopping.
I checked what the original source code is doing for this case and
implemented it in the same way: the character does not start walking.
This fixes bug #7112: DRASCULA: protagonist walking off the screen
The changes in this commit should provide an identical text
placement to the original. In addition to using the original source
code as reference I have checked that is the case by comparing
with DosBox for the intro of the Spanish and English versions as
well as for parts of the game with the English version. I added
comments for the obscure parts (such as the original adding a
space at the end of the last line of text when splitting a string
into several lines, thus impacting how that last line is aligned).
This in particular fixes bug #7111: Incorrect position in texts, not as the
original. However this codes centers the text better than what we see in
DosBox, so the result is not identical.
This change is based on the code before the commit 7cf7f4b
"Rewrote the very confusing centerText() function into something that
makes more sense". The changes in that commit do not all make
sense to me so I reverted the line spacing (to add back 2 pixels between
text lines) and part of the logic to center text. The result looks a lot
closer to the original engine in DosBox, but not identical.
Engines should only have to call one set of functions and not decide between the two. In fact, the 'emulation' API was documented to just call the 'real CD' API.
