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.
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.
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.
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.
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.
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.
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.
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 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.)
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.
