The order that volume resources are loaded subtly affects engine
behavior when they contain different versions of the same resource.
This order has been the file enumeration order from the operating
system, causing inconsistent behavior between environments and even
between two different directories of identical files.
The resource validation fails big time because no file Data9 exists.
It's expected as its in Data9.bin instead. Since we check resource fork
explicitly in the case of resource-fork resources this check is redundant
- Common: add wordWrap function to ustr.cpp
- Bladerunner: Explicitly state we have a U32String in subs (same as Subtitles::loadOuttakeSubsText)
- Don't use translations for engine specific "put strings", because they might not support.
- SCI: Use const references for showScummVMDialog
- SCUMM:
-- Don't use translation in md5 warning. left comments with the translated version.
-- Remove some redundant headers in help.cpp
-- Don't use translation in handleSaveload when printing to console
-- Also, display success transaction correctly via u32::format
- TESTBED: Use fake constructor when setting label of button
- SKY: Correctly use translation when using SaveStateDescription
- ULTIMA: Don't use translations when display_string
- ENGINES:
-- GenerateUnknownGameReport correctly, with proper translations.
-- There was an error, where a function had been declared twice, in a header file. Correct this.
After the initial changes just to scummvm/gui for u32, this commit includes the whole project
- Widget creations now always have u32 descriptions, labels, or tooltips
- Message dialogs make use of default arguments instead of providing the same argument explicitly
- encode String::format properly before passing on as argument where necessary
- Modify hugo utils (yesNoBox and notify box) to use u32
- Also provide fake constructors for the above which redirect to the u32 constructor
- Convert all keymap descriptions to u32 across all engines
- showConfirmationDialog in mohawk now uses u32
- showScummVMDialog also uses u32
- Scumm engine has dialogs now which use u32
- General fixes and wrapping convertToU32String for setLabels and related functions
- Add a fake constructor to MesssageDialog which redirects to the u32 constructor
The resource patcher can be used to patch non-script resources
like views, maps, sounds, etc. It is more primitive than the script
patcher in that it does not use signatures for safe and automatic
patch relocation, but it does at least allow existing resources to
be grown if needed.
Refs Trac#9788. Refs Trac#9690.
Ignores a detected volume version of SCI3 when the map version is less
than SCI2, as that indicates detectVolVersion's heuristics failed.
SQ1VGA Russian has volume files with a few junk bytes in between
resource entries, which causes detectVolVersion to return SCI3
instead of the expected result of Invalid and then use the
correctly detected map version. The detection algorithm tries each
version until it finds one that fits, and the SCI3 pattern happens
to fit because it's necessarily the most permissive due to the
wCompression bytes containing meaningless values.
Fixes bug #10156
Adds a new workaround system for known broken messages and their
corresponding audio and sync resources. This replaces all special
cases in c++ and several script patches with data structures and
generic handling.
Common message bugs:
- Wrong tuple requested by game script
- Wrong tuple in message resource
- Wrong message text that exists in another record
- Missing message text
- Audio or sync resource with different tuple than message
Since Datafiles says to rename any RESOURCE.SFX to RESSFX.00n,
and there is only a RESOURCE.SFX on CD 1, don't confuse users by
failing to use RESSFX.001 for CD2 and CD3.
This code is currently untestable and is almost certainly at least
partly based on guesswork & not actual reverse-engineering (as was
the case for all other pre-2015 SCI32 code), so future developers
interested in adding SCI32 Mac support should use it only as an
intermediate reference rather than as known good code.
The original installer copied RESOURCE.SFX to the hard drive so
there was only one RESOURCE.SFX on CD 1. Instead of requiring
users to create duplicates, just use the single RESOURCE.SFX if it
exists.
There is no practical risk now since the enum and array sizes are
the same, but there is no reason to rely on a separate data
structure to avoid potential out-of-bounds index use here instead
of just checking the array size directly, which is always safe.
Lighthouse audio.225 in RESSCI.002 (US English 1.0C) triggers this
condition; the audio resource says its data is one byte larger
than the recorded size in the volume. In this case, just use the
smaller of the two values for the size, to avoid overreads.
It turns out that GOG.com version of Phantasmagoria needs the
37.MAP patch file because for some reason the 37.MAP in RESSCI.000
is empty (36 bytes, versus the correct file which is ~1kB).
Fortunately, this file is the same across all CDs in the original
US release, so hopefully unblocking this patch will not cause any
problems for any of the CD releases either.
Fixes Trac#10161.
If a user fails to rename audio files in the required manner when
copying them, detecting multi-disc audio by looking for a renamed
audio file does not work very well. Looking at RESSCI.00n is a
better choice, though this is not completely valid since e.g.
Rama 1.0 US has only one RESOURCE.SFX volume which its installer
copies to the hard drive, so a little more work will need to be
done in the future to find and fix these kinds of edge cases.
Refs Trac#9976.
For the moment, only warn about bad resources when a game is
actually starting, since unknown but valid resources being
detected by the fallback detector currently also trigger the
warning.
The stream returned by a call to ResourceManager::getVolumeFile
either MUST (when returning an I/O stream from a Common::FSNode)
or must NOT (when returning a Common::File *) be deleted by the
caller, depending upon some internal implementation details of
ResourceSource that should never have been exposed to callers.
FSNode streams that should have been deleted were not being
deleted all the time, which leaked and eventually caused ScummVM
to run out of FDs.
This commit improves this situation by shielding callers from
these internal details by centralizing the destruction logic in
one place, so FSNode read streams stop being leaked and callers
no longer need to know stuff about the internals of the
ResourceSource they are trying to read in order to avoid leaking
or breaking the volume file cache.
Fixes Trac#9782.
sluicebox
Cameron Cawley
wonst719
Vladimir Serbinenko
aryanrawlani28
Bastien Bouclet
Filippos Karapetis
Zvika
Colin Snover
D G Turner
Dan Church