| Age | Commit message (Collapse) | Author |
|---|
|
game restore
|
|
Convert macros and vars to enums, rename keyboard events in
preparation for adding key up events, clean up unnecessary nested
conditionals, add TODOs for potential future work.
|
|
When in Galaxy Galleria, going into the software store and trying
to shoplift the SQ4 Hintbook will crash the game after you leave
and are electrocuted.
Fixes Trac#10229. Closes gh-1031.
|
|
Trying to find differences in Lighthouse's audio sample playback,
I discovered that SCI3 had its own variant of handling volumes and
sending this volume information back to game scripts. It is not
known if this fixes any sound bug.
|
|
|
|
This subop is used only by RAMA.
The VMD objects in RAMA's game code contain a frame rate field,
which is usually -1, but occasionally is not. In the cases where
it is not -1, it appears to be either set for a video with sound
(so the value doesn't do anything to that video), or it is just
resetting back to the baked-in frame rate of the video file (so
it doesn't need to exist, except to fix videos broken by earlier
played videos with explicit frame rates).
Since this is a global state flag that does not get reset in SSCI,
the ultimate effect of kPlayVMDSetFrameRate in RAMA is that it does
nothing to any of the videos where the explicit frame rate is set,
but it does inadvertently cause *other* videos with no sound and no
explicit frame rate to have a different frame rate depending upon
what was played earlier in the game (and whether or not the engine
was restarted in the meantime).
This bad transferring of frame rates is most noticeable with the
exit-video of the vidmail player, which is played when you back out
after selecting a vidmail. Its nominal framerate is 10fps, but it
will play at whatever frame rate was last set by some other video
that happened to have an explicit frame rate, even if that frame
rate was bogus.
So, just ignore all calls to this subop, as it is fatally buggy.
|
|
Fixes CID 1381416.
|
|
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.
|
|
|
|
|
|
There seems to be no difference between DOS and Windows versions
of the game from what I could see in the game code (it checks
platform but only seems to just set a global which is never used),
and from what I could tell online they are all DOS/Windows hybrids,
so just simplify life and make them all DOS platform versions.
|
|
|
|
Near the end of the game, RAMA will start trying to store some
invalid references. This does not affect the save game negatively
in any way, but it was causing the kernel to assert a signature
failure.
|
|
This is used by RAMA in room 6201, after eating the alien fruit.
|
|
Despite what game script disassembly lead me to believe, the game
seems to create only one auto-save, which ends up being saved as
911.sg (not autorama.sg). This save file is created just before
entering the underground Avian Lair in New York, and seems to be
designed as some emergency backup since entering the Avian Lair is
a one-way trip.
|
|
Used by RAMA, in various places, starting with the refrigerator
at base camp after the cable car at the beginning of the game.
|
|
Which were originally only played, when using the Windows interpreter.
Afaik the DOS interpreter was incapable of playing more than 1
sample at a time, which was probably the reason why Sierra only
added these for the Windows interpreter.
For example a sample is now played, when points are awarded.
Those samples are currently used all the time and will also
enhance the game, when platform DOS is chosen.
In case someone wishes to opt-out of this, we could add a game
specific option.
We do something like this for Space Quest 3 already,
that's why I don't see a reason to add a game option right now.
|
|
In a couple of places, Lighthouse updates the renderer with screen
items for the next room before the room transition video plays.
This is normally fine when using the compositing video renderer
because the videos are drawn into new planes which occlude the
screen items, so the screen items are culled from the draw list
and do not submit their palettes. However, when in HQ video mode,
we currently force the overlay renderer, which was not blocking
screen items before forcing a frameOut, so the screen items'
palettes got submitted prematurely in this case and caused bad
rendering after the video finished playback.
Now, if we are forcing into the overlay code path, we still create
a blank plane behind the overlay before the forced frameOut in
order to correctly occlude screen items and keep them from
participating in rendering before they normally would.
Fixes Trac#10233, Trac#10235.
|
|
for Hk So Good store catalog.
Implements enhancement #10227
|
|
|
|
If this is not done and the file is buffered, it will not show up
in the list of save games, and the new save will fail.
|
|
|
|
Somehow, up until trying to view an encrypted data cube in RAMA,
the missing relocation of locals did not seem to cause any trouble
in any of the other SCI3 games.
|
|
This reverts commit d2dd942ad79df0c4ac9d841fb5b0919d260bb79c.
The Serializable class is an interface class and has only the
empty default copy constructor. There is no reason to call this
explicitly. Whatever is warning about this should be fixed to stop
warning about it, rather than adding such unnecessary calls to the
engine code.
|
|
kArrayCopy would perform an unnecessary memory copy of the source
array, the treatment of the count value as unsigned was clearly
not correct since it was being sign-extended and checked against
-1.
|
|
|
|
|
|
|
|
One of the strings is a static string of the same size as the size
passed to strncmp so there is no point in not just using strcmp.
|
|
|
|
|
|
RAMA has its own custom save game format that game scripts write,
but we still want to be able to use these save game files from the
ScummVM launcher, so the metadata has to be able to be written
separately from the rest of the game saving.
|
|
function
|
|
Preparations for adding support for RAMA's custom save game format.
|
|
|
|
The maxSize given when generating a SegmentRef is supposed to be
the maximum size of raw data that can be held inside the offset-
part of a reg_t, not the entire size including the segment.
This fixes a buffer overflow in "Inside the Chest", which still
does not work, but at least doesn't cause heap overflows anymore
with this change.
|
|
Torin RU map 38140 has an unusual terminator entry; instead of a
normal terminating entry of 11 FFs, its terminating entry is
03 FF FF FF FF C4 36 01 FF FF FF. So, two changes are made:
1. The end-of-map check is now the same as in SSCI1.1+ and only
checks that the final byte of the Audio36 tuple is 0xFF,
instead of the entire tuple;
2. The unneeded entry size heuristic has been turned off for
all SCI32 games.
A quick check of the English versions of LB2CD, EQ1CD, SQ4CD, and
KQ6CD, as well as all English SCI32 games, indicates that this
approach seems to be working correctly.
Fixes Trac#10188.
|
|
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.
|
|
I missed these lines when going through things earlier.
|
|
This fixes a problem in Lighthouse 2.0a where the mini-sub would
fail to start playing the animation of the shipwreck when clicking
on the throttle.
In SSCI, in SCI3 only, r_acc was (inadvertently?) set to the
superclass object ID whenever a super call was made. This happened
because OP_super would call to get the superclass object ID, the
calling conventions of the compiler put this return value into EAX,
and then the PMachine message processing code put whatever was in
EAX into r_acc before each message was processed.
In the game code, there are a sequence of steps that look like
this:
* First, throttle::doVerb is called when throttle is clicked on;
* Which calls getRobot::doit to tell the shipwreck robot to start
playing;
* Which calls wreckBot::init to reset the Robot for the animation;
* Which calls Hiliter::hotVerbs(0) to remove cursor hotspots;
* Which calls Hiliter::dispose to clean up since it is not used;
* Which causes Hiliter::verbList to get set to 0.
* Later, verbList is loaded into r_acc, and it is still 0;
* Then, Hiliter::dispose makes a super call to Obj::dispose;
* Then, Obj::dispose does nothing except call kDisposeClone,
which does not mutate r_acc, so r_acc is still 0 from verbList;
* Then we return back through 5 calls to throttle::doVerb;
* Then throttle::doVerb checks that r_acc is non-zero, and if so,
adds wreckBot to theDoits global, allowing the animation to
occur.
In ScummVM, without setting r_acc in the super call, the non-zero
check failed and the wreckBot didn't get put into theDoits, so the
entire sequence fell apart. In SSCI, the non-zero check happened
to succeed because the Obj::dispose super call put the Obj class
into the accumulator. So now we do that too, and now Lighthouse
2.0a works here.
Earlier versions of SSCI used EAX for other things in between the
OP_super call and the message processing, so would set r_acc from
different data, so this change does not apply to those versions.
|
|
|
|
|
|
|
|
|
|
|
|
This improves the behaviour at the end of PQ4 when navigating the
warehouse with the flashlight by getting rid of mouse events that
may have been queued before the mouse warp to the other side of
the screen is performed. Without this, frequently, those extra
events would then be processed and cause the mouse to jump back to
the opposite side of the screen, triggering another navigation in
the opposite direction.
This patch really only helps when mouse capture is enabled in
ScummVM as well, but it does allow the sequence to be played
pretty much normally in that situation. Additional (pending)
patches to ScummVM itself are needed to move the mouse to the
correct place when mouse capture is off and the system mouse moves
outside of the game window.
Refs Trac#9689.
|
|
|
|
|
|
In the DOS interpreters, this function is a no-op. Lighthouse calls
it regardless of platform, so dummy it out for non-Windows
platforms. This is not known to address any particular issue, and
is really just to eliminate the warning about an unknown
configuration setting when starting Lighthouse in a manner that is
compatible with the original interpreter.
|
|
This wait function is used by kernel calls other than kWait, and
those other functions do not mutate r_acc in SSCI.
|
