| Age | Commit message (Collapse) | Author |
|---|
|
The engine ID identifies which engine should be used to launch the target.
Also remove the 'single ID' system. Different games from engines that used
that system now have different game IDs.
Also-By: Matthew Hoops <clone2727@gmail.com>
|
|
|
|
|
|
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.
|
|
|
|
Previously, a C-style cast was used to convert a
Common::Array<Plugin *>, populated with pointers to StaticPlugin
and DynamicPlugin instances, to a
Common::Array<PluginSubclass<T> *>, but PluginSubclass<T> is a
*sibling* class to StaticPlugin/DynamicPlugin, so this cast was
invalid and the results undefined. The methods for retrieving
subclasses of plugins can't be easily changed to just generate an
array of temporary wrapper objects that expose an identical API
which dereferences to the preferred PluginObject subclass because
pointers to these objects are retained by other parts of ScummVM,
so the wrappers would needed to be persisted or they would need to
just re-expose the underlying Plugin object again. This indicated
that a way to solve this problem is to have the callers receive
Plugin objects and get the PluginObject from the Plugin by
explicitly stating their desired type, in a similar manner to
std::get(std::variant), so that the pattern used by this patch to
solve the problem.
Closes gh-1051.
|
|
After player gets to the castle using a robot, Willie's notes
become red "Windows'" (in DR Russian version) notes. One of the notes
requires patching.
|
|
|
|
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.
|
|
All these fall through were marked as deliberate, so again I've only
changed the comment to silence GCC.
|
|
|
|
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.
|
|
NEVERHOOD: Add earlier English demo of Neverhood
|
|
|
|
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.
|
|
Apparently contains a placeholder song or soundtrack. Download link in the sourceforge issue tracker.
https://sourceforge.net/p/scummvm/bugs/7117/
|
|
The original game would display a message if you tried to load or
delete a game without actually selecting one. At least for now,
let's just avoid crashing.
|
|
Don't crash when clicking a read-only text widget. In the original,
the load game dialog's text widget isn't read-only, but since we
allow multiple games to have the same name it's probably for the
best that we don't quite match the original behavior here.
|
|
It's bugging me, ok?
|
|
|
|
gameid -> gameId
guioptions -> guiOptions
|
|
_singleid -> _singleId
_gameids -> _gameIds
_guioptions -> _guiOptions
|
|
Some backends like GCW0 do no support graphics >320x240 due to
the hardware limitation (downscaling is possible but it will ruin
the pixel hunting which is often part of the gameplay).
Instead of manually updating the list of engines, we now introduce
a new dependency.
I marked all relevant engines, but some, like tinsel, require more
work with putting their relevant high-res games under USE_HIGHRES
define.
|
|
|
|
|
|
|
|
|
|
Some of the resource patches needed to be modified to work with the
latest changes to the DCL decoder
|
|
NEVERHOOD: Possible fix for bad car behaviour
|
|
According to johndoe it's correct to pass the entire coordinate,
rather than just X, to the car in these cases as well. I can't
tell any difference at all in the behavior, but I guess it doesn't
hurt either. After all, we can easily zero the Y coordinate, if we
ever want to.
|
|
This is something I found when trying the savegame from bug #6932,
but I still don't know if it actually is that bug.
From what I understand, there are two different cases in the
moveCarToPoint() method: One where you click on a different
section on a track than you're on, and one where you click on the
same section on the track that you're on.
In the latter case, it sends message 0x2004 to the car, which is
then handled by AsCommonCar::handleMessage(). That one will assume
that the parameter is a point, but this can also be encoded as an
integer with 16 bits for the X coordinate and 16 bits for the Y
coordinate. See MessageParam::asPoint().
If we only pass an X coordinate to the message, the Y coordinate
is assumed to be 0, and we do this in a couple of places. I do not
know the exact implications of that, but in the two cases I've
changed here, it meant that clicking on the track below the car
would still make it go up, because it thought you were travelling
towards the top of the screen.
So I think this is the appropriate fix, but even if it is, I do
not know if it's enough or if it should be changed in other places
as well.
|
|
|
|
|
|
|
|
These have been left behind after the split of the scenes and the scene
sprites. Thanks to fingolfin for pointing out the duplicate defines
|
|
|
|
When the memory puzzle is reset, each revealed tile gets hidden again.
When a lot of tiles were hidden, the multiple clicking sounds would
fill the available sound slots. To avoid this, only a single click is
sounded when losing
|
|
|
|
This fixes bug #6661 NEVERHOOD: Uninitialized variable during car ride.
|
|
|
|
This should hopefully fix the crashes in the Hall of Records as mentioned in bug #6513.
|
|
This clears the radio music variable when leaving the room. I've
discussed with johndoe123 and he says this is what the original
does. (You could also get the same effect by clearing it when
entering the room.)
|
|
|
|
|
|
This is occurring due to duplicate entry ids, which should probably not
be present.
|
|
I hope this will help the memory leak reported as part of bug #6513
but my computer isn't quite up to the task of doing any extensive
Valgrind testing.
|
|
This is the same fix that was applied to getKloggsTextIndex() some
time ago. It restores a missing Willie nonsense letter. While I
haven't actually verified for myself that this letter appears in
the original game, it is referenced in Wikipedia's article about
Absalom.
|
|
The getKloggsTextIndex() function would return 40 twice in a row
when wrapping around. This caused one of Willie's nonsense letters
to appear instead, since they're supposed to trigger when
getTextIndex1() returns the same result more than once.
The same bug also appeared (and has been fixed) in getTextIndex3(),
but there it just caused the same nonsense letter to appear twice.
|
