| Age | Commit message (Collapse) | Author |
|---|
|
This was particularly an issue when the game had been saved in
chapter 1 as in this case the load would happen too early and
the game would crash. In other cases it was working but was
not optimal (the gane loop was run once before it succeeded
to load the game).
This fixes bug #10959.
|
|
I don't see the point and reallocating and freeing the same surfaces
for each chaper, so now they are only allocated once and freed once
at the end.
|
|
|
|
|
|
This reverts commit bf69b25e33189581848412e77624865aa55ba234.
The original game had slight differences between the code for each
chapter. Part of these changes was to simplify the code and unify
some of these differences, particularly in the checks for clickable
areas, where the code is using Common::Rects with contains() now.
I have play tested the whole game with these changes, there are no
visible regressions, and the game is still completable. Thus, I'm
restoring the changes to the engine.
|
|
This reverts
1f1d8607 DRASCULA: Merge the floor coordinates into _walkRect
1e1b6f7c DRASCULA: Rename gotoObject() to walkToPoint() and simplify it
2bf05c2a DRASCULA: Clean up room variables, and simplify some related checks
Reverting due to unanswered questions about why the changes in behaviour
in 2bf05c2a746065f373ac136c994714dae376cdbc are correct.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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 engine data files should be included in the package, so downloading
may not be the best suggestion. Instead refer to the README.
|
|
|
|
|
|
|
|
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).
|
|
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.
|
|
version
This simplifies the code and bring it closer to the original source code.
This should help if we need to debug issues in the future.
|
|
|
|
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.
|
|
This code was committed by mistake in the previous commit.
|
|
|
|
|
|
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
|
|
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.
|
|
|
|
This code was used until commit aaf8b58 that reworked the detection
to support French and German versions.
|
|
The music add-on packs we provide have the audio files in an "audio"
folder, but without clear indication that its contents should be
copied inside the game data folder. Since this can lead to confusion
from users, we just add support for this case
|
|
|
|
This now opens correctly on CTRL-d keystroke.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This removes the superfluous talkHeight, talkWidth and timeDiff
variables. It also changes _loadedDifferentChapter to be a boolean
|
|
|
|
|
|
This cleans up the save/load code and resolves multiple issues with the
original save/load screen.
Save game timestamps and thumbnails are now implemented, together with
the ability to load a game from the launcher.
F7 is now mapped to the ScummVM load dialog, and F10 to the save dialog
(if the user has selected to use the ScummVM save screen).
|
|
This allows quitting ScummVM in only a minimal time when a converstion is
running instead of waiting for it to finish. It is still not instant but much
better.
|
|
|
|
Safer and less portability issues.
|
