| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
These are flagged by GCC if -Wswitch-default is enabled.
|
|
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.
|
|
Also-By: Matthew Hoops <clone2727@gmail.com>
|
|
|
|
This commit introduces the following changes:
1. Graphics::loadThumbnail()
Now returns a boolean and takes a new argument skipThumbnail which
defaults to false. In case of true, loadThumbnail() reads past the
thumbnail data in the input stream instead of actually loading the
thumbnail. This simplifies savegame handling where, up until now,
many engines always read the whole savegame metadata (including
the thumbnail) and then threw away the thumbnail when not needed
(which is in almost all cases, the most common exception being
MetaEngine::querySaveMetaInfos() which is responsible for loading
savegame metadata for displaying it in the GUI launcher.
2. readSavegameHeader()
Engines which already implement such a method (name varies) now take
a new argument skipThumbnail (default: true) which is passed
through to loadThumbnail(). This means that the default case for
readSavegameHeader() is now _not_ loading the thumbnail from a
savegame and just reading past it. In those cases, e.g.
querySaveMetaInfos(), where we actually are interested in loading
the thumbnail readSavegameHeader() needs to explicitely be called
with skipThumbnail == false.
Engines whose readSavegameHeader() (name varies) already takes an
argument loadThumbnail have been adapted to have a similar
prototype and semantics.
I.e. readSaveHeader(in, loadThumbnail, header) now is
readSaveHeader(in, header, skipThumbnail).
3. Error handling
Engines which previously did not check the return value of
readSavegameHeader() (name varies) now do so ensuring that possibly
broken savegames (be it a broken thumbnail or something else) don't
make it into the GUI launcher list in the first place.
|
|
|
|
|
|
|
|
|
|
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.
|
|
drascula.dat file version bumped
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Bug #7110 showed a crash here. Even though that was likely a compiler
error, these extra checks shouldn't hurt.
|
|
|
|
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.
|
|
|
|
ALL: Unify messages concerning engine data files
|
|
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.
|
|
This function is called a lot, and having a debug level of 1 made it very
difficult to find any other debug prints.
|
|
|
|
The engine data files should be included in the package, so downloading
may not be the best suggestion. Instead refer to the README.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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
|
