| Age | Commit message (Collapse) | Author |
|---|
|
This groundwork enables an object to look up its static name
separately from the normal process that is used to populate
Object::_variables when an object is first constructed.
(The static name property needs to be able to be retrieved from
objects inside of earlier save games whose name properties may
have already been modified at runtime, so the code cannot simply
pluck the value out of Object::_variables when they are first
initialised and then persisted into the save game, as nice and
easy as that would have been.)
This commit also helps to clarify the situation with relocation
tables in SCI1 games that start with a zero entry.
Refs Trac#9780.
|
|
While extremely rare (only Rama script 64948 seems to have this
profile), it *is* possible for an object to have zero properties
(and thus, zero property offsets).
|
|
|
|
|
|
This ensures that all object name reading code works the same and
is in one place in the codebase.
|
|
ObjMap owns Objects, so every time this map gets copied instead of
referenced, it creates a copy of every single object in the
associated script. This is expensive, and it breaks things like
the `Object::syncBaseObject` call in savegame.cpp, which hasn't
actually been doing anything since
58190c36b4cc84b3200239211d91b0291301db56 because it has been
operating on copies.
|
|
Basically just grepped for getOffset calls being assigned to
uint16s and expanded those to uint32 when they looked trivial.
While some of these changes seem superfluous, at least for the
US/English SCI3 games where potentially impacted game scripts are
not large enough to have a problem with 16-bit offsets (e.g. when
feature detecting the sound type), at least some of these changes
are necessary for correct operation of the find_callk debugger
command in SCI3 games. There should not be a reason why any of
these variables need to be kept as uint16, in any case.
|
|
Fixes Trac#9795.
|
|
Type mismatch is triggered on THEGUIDE.DOS and THEGUIDE.WIN from
at least Phant1 French 1.100.000.
|
|
This fixes a crash in the debugger when disassembling the class opcode
with a class from a script that hasn't yet been loaded.
|
|
Audio played was "Tickets, only", subtitle shows "Tickets, please".
Also remove forcing myDialog for KQ6Print::say (which was added,
while fixing this script patch).
see a46f3c162581740a3cad27e1168164ca91beb9c9
Forcing myDialog causes issues during game over screen (bug #9771).
Bug is solved by this, but script patch isn't perfect right now.
|
|
This fixes bug 9786. Thanks to m_kiewitz for verifying with disasm.
|
|
|
|
The vocab file for this game does not seem to be valid (other
utilities like SV cannot parse it either), and this game does not
seem to need the parser, so just exit early like the SCI1 branch
when unexpectedly running out of bytes in the vocab file.
Fixes Trac#9765.
|
|
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.
|
|
Save game metadata validity checks in SCI32 should all exist within
kCheckSaveGame32 since this allows most games to recover
successfully from an attempt to load an invalid save game. If
gamestate_restore fails, the game will usually crash because the
engine is left in an inconsistent state (game scripts have cleaned
up objects in preparation for a game load that is no longer
happening).
|
|
This "fix" is more of a hack, in the interest of making the game
completable. The root cause is a combination of two problems in
the game scripts:
1. Blink::init expects to receive either 0 or 2 arguments, but
it assumes that if it received *any* arguments, it must have
received 2 arguments. This assumption is wrong, though,
because--
2. soTorinWhoAreYou::changeState(0) calls
poPecandEyes::setCycle(Blink) without including a second
argument (the blink speed).
This ends up with the second parameter being some garbage, and
that garbage gets sent to kRandom which then complains about
receiving garbage.
The correct fix for this would be to fix soTorinWhoAreYou (in
script 51400) to pass a second argument to setCycle, but there are
not enough obvious spare bytes for a quick and easy patch, so this
workaround will have to do for now.
Fixes Trac#9779.
|
|
Refs Trac#9764.
|
|
Refs Trac#9776.
|
|
|
|
|
|
The runtime code for this had previously relied on hot patching
volume file offsets at the moment that a resource was loaded,
instead of correcting file offsets when reading audio maps. The
code added for sanity checking audio volumes started to report
warnings because the offsets being received were for the original
uncompressed audio volume, which (naturally) is larger than the
compressed audio volume.
This commit also deduplicates code between addResource and
updateResource, and tweaks a validation-related error message for
improved clarity.
Fixes Trac#9764.
|
|
|
|
While earlier commits had fixed handling of audio resources in
audio bundles to match SSCI, audio *patches* in SCI16 were still
being treated like standard resource patches. They are now
special-cased in the resource manager, just like SCI32.
Incidentally, while fixing the problem with audio patches, I also
noticed that the patch resource fixes for SQ5/German were very
similar to the special-case operations for resources in SCI32,
though using an odd heuristic. After investigating, it appears
that Sierra SCI1.1 works mostly like SCI32, and not like what
was there from SCI View. So, the old special-case code is deleted
and the special-case code for SCI32 has been expanded to cover
SCI1.1. (SSCI prior to 1.1 do not appear to do this
special-casing.)
Fixes Trac#9773.
|
|
Fixes Trac#9763.
|
|
|
|
|
|
The Lighthouse glider demo comes with a file named SDirectX.dll
which was failing to match the case-sensitive suffix search for
.DLL.
|
|
1. The chunk number was hard-coded to zero and inaccessible.
2. Running ResourceManager::getVolumeFile for a chunk resource
would always return nullptr instead of a stream of the chunk,
which made it impossible to generically validate that resources
being added were within bounds of the container file (or, in
this case, container chunk).
|
|
|
|
Simple assertions in the resource manager are not sufficient to
track down resource corruption issues, and some error conditions
that were being checked already were either ignored or only raised
as warnings that casual users would be unlikely to see.
Ideally, error handling in ResourceManager would be improved to
the point where errors would correctly propagate out of it (so the
warning dialogue could be displayed from outside), but right now
error codes are dropped all over the place, and it would take more
effort to fix that without much benefit for the current situation.
If/until someone has the energy to fix that, the warning dialogue
is simply shown from ResourceManager::scanNewSources.
Refs Trac#9764.
|
|
Fixes Trac#9759.
|
|
|
|
(The DOS version was already listed.)
|
|
In SSCI, mouse events are received through a hardware interrupt
and the cursor is drawn directly to the graphics card by the
interrupt handler. This allows game scripts to omit calls to
kFrameOut without stopping the mouse cursor from being redrawn
in response to mouse movement.
ScummVM, in contrast, needs to poll for events and submit screen
updates explicitly from the main thread. Submitting screen updates
may block on vsync, which means that this call should really only
be made once per frame, just after the game has finished updating
its back buffer. The closest signal in SCI32 for having completed
drawing a frame is the kFrameOut call, so this is where the
update is submitted (by calling OSystem::updateScreen).
The problem with the approach in ScummVM is that, even though the
mouse position is being updated (by calls to kGetEvent) and drawn
to the backend's back buffer (by GfxCursor32::drawToHardware),
OSystem::updateScreen is never called during game loops that omit
calls to kFrameOut.
This commit introduces a workaround that looks at the number of
times kGetEvent is called between calls to kFrameOut. If the
number of kGetEvent calls is higher than usual (where "usual"
seems to be 0 or 1), we assume that the game is running one of
these tight event loops, and kGetEvent starts calling
OSystem::updateScreen until the next kFrameOut call. We also
then start throttling the calls to kGetEvent to keep CPU usage
down. This fixes at least two such known loops:
1. When interacting with the menu bar at the top of the screen
in LSL6hires;
2. When restoring a game in Phant2 and sitting on the "click mouse"
screen.
A similar workaround may also be needed for kGetTime, though loops
around kGetTime should preferably be replaced using a script patch
to call kWait instead.
|
|
This may be masking another bug, but at least what happens in
Phant1 is that the mouse does not get redrawn after being moved
programmatically to the fast-forward button when deviceMoved
returns early.
|
|
|
|
Videos in GK2 use this flag (e.g. the chapter 6 intro).
Now that GfxPalette32::updateHardware no longer calls
OSystem::updateScreen (only GfxFrameout::frameOut does this now),
every time a palette swap occurs during playback, there is a frame
of blackness that should not exist. This is because the order of
operation is:
1. Send black palette
2. Call frameOut (which updates the screen)
3. Send new, correct palette
4. No frameOut (so the screen is not updated with the correct
palette)
OSystem::updateScreen cannot be called multiple times for the same
frame due to vsync, but also, there does not appear to be any
reason to send a black palette, since it seems to be intended to
avoid temporarily rendering video frames with the wrong palette on
a hardware device that cannot guarantee simultaneous application
of a new palette and new pixel data. ScummVM does not have such
a problem, so this feature appears to be unnecessary for us.
For the moment, this 'feature' remains hidden behind an ifdef,
instead of being removed entirely, to avoid potential confusion
when comparing VMD code from SSCI.
|
|
More than one call to OSystem::updateScreen per frame on systems
with vsync ruins performance because the call is blocked until
the next vsync interval.
This also fixes bad rendering performance with the OpenGL backend.
|
|
|
|
|
|
|
|
This fixes the the SCI32 incarnation of Trac#5343
(defect#3061964): Savegames with no name can't be restored
|
|
The approach to video benchmarking used by SCI engine does not
translate very well to modern video devices -- it will either be
so slow that the games think the system is not capable of showing
normal visual effects, or so fast that the benchmarks overflow
their counters. So, game scripts that perform video benchmarking
are now patched to unconditionally return the highest speed value.
A pleasant but subtle side-effect of this change is that the extra
time sitting at a blank screen before the start of a game (while
benchmarks ran) is now gone.
Fixes Trac#9741.
|
|
|
|
Fixes Trac#9739.
|
|
|
|
Also add a bit of info to the German detection entry of
Phantasmagoria 2. Also add URL to censorship information on our wiki.
|
|
|
