After discussion with dreammaster. Apparently the 3DO version uses
a resolution of 640x400 pixels internally, not 320x200. Doubling
the X and Y coordinates from what they were seems to match what I
have seen in YouTube videos of the original game.
Some messages spoken to Watson show up in the journal as if spoken
to the inspector. (And, presumably, the other way around, but I
haven't gotten that far in playing the game yet.)
The computer opponent always aims for the bullseye as long as he
needs more than 50 points. After that, he's supposed to aim for
the closest score to what he needs to win. But this coordinate
was never used, and the computer player would always aim at the
same spot outside of the dart board. This, of course, made it
practically impossible for it to beat you. This commit fixes
that.
I thought at first that this fix wasn't quite right, because the
computer won't always hit the score he aims for even if you remove
the random inaccuracy from its aim. But I think it still hits
near the intended target, so maybe this is good enough?
When capturing Blackwood in The Case of the Serrated Scalpel, the
whole scene seems to be running in slow motion. This simply doubles
the speed for it. It may still be a tad slow, but at least it fits
the music much better I think.
Loading from the GMM during the prolog resulted in the mouse cursor
getting stuck hidden and possibly other game state issues, so best to
disable loading in these cases as already was done for saving.
This fixes bug Trac #10746.
Saving/loading already handles savegame creation/play time, the
information just wasn't displayed until now because the MetaEngine
features weren't being reported as supported which I assume to be
an oversight.
Fixes Trac#10006.
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 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.
Without this change the Apple gcc 4.0 compiler (the last version to
support the MacOS X 10.4 SDK) generate a lot of errors regarding
trying to initialise references to Sherlock::Scalpel::Talk with the
address to a Sherlock::Talk object, or about forward declarations of Sherlock::Scalpel::Talk.
