| Age | Commit message (Collapse) | Author |
|---|
|
Allows patching a Phantasmagoria 1 script to copy instead of rename.
Although most games can call this through their File:copy script, none
have been discovered yet that do.
|
|
Fixes Phantasmagoria 1 animations not resuming after closing the
control panel during the chapter 7 chase
|
|
Phantasmagoria 1's censorship mode is now supported
Trac #11229
|
|
Prevents Phantasmagoria 1 from crashing while in censored mode.
The "blob" subops pixelate rectangles during playback and are
currently being implemented.
|
|
|
|
The game now starts
|
|
Trac #11174
|
|
Also gate them behind the presence of a 184.VOC resource instead of GID_CATDATE. This should not matter with regards to the remap effects -- the 2015 and 2016 demos had none, and the first that did has an unknown release status. Only the 2017 demo would fall, which would be easily fixed by dropping in a valid 184.VOC patch file.
|
|
|
|
Restarting was only supported in QfG4, GK1 and PQ4. Those three used
makeshift script code. The kernel call was stubbed out in SSCI as
well. Fixes bug #10681.
|
|
|
|
Fixes bug #10699
|
|
|
|
Fixes Trac#10251.
|
|
|
|
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.
|
|
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.
|
|
Used by RAMA, in various places, starting with the refrigerator
at base camp after the cable car at the beginning of the game.
|
|
|
|
|
|
This code is identical to the kArrayGetData implementation.
|
|
The original interpreter allowed most string references to be
null references, in which case it would substitute an empty
string.
|
|
In the original interpreter, is it valid to pass a null reference
to both kArray(GetData) (it just acts as an identity function when
the passed argument is not an object) and to kString functions (it
always dereferences to an empty string).
Fixes Trac#10039.
|
|
kCelLink exists in SSCI since 2.1mid, but it is only known to be
used in Lighthouse, during the weapon creation puzzle near the end
of the game.
|
|
|
|
|
|
Non-use of these kernel calls was assumed by reviewing script
disassembly by SV, but it turns out that SV was not picking up
script patches correctly in SCI3 games, so this data is no longer
considered reliable.
|
|
Fixes Trac#9845.
|
|
Upon investigation of Sound code across SCI32 games, it was
determined that there are actually (at least) 3 different
revisions, not just a single SCI2.1 version. This patch only
changes the parts of Sound code that are relevant to the correct
use of Audio32.
Fixes Trac#9736, Trac#9756, Trac#9767, Trac#9791.
|
|
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.
|
|
Fixes Trac#9763.
|
|
|
|
Used by RAMA, when playing a video at the Hub Camp computer at the
beginning of the game (room 1004).
|
|
|
|
|
|
Fixes text scaling gone mad in Phant2.
|
|
|
|
integration
|
|
|
|
|
|
|
|
Used by Phant2.
|
|
|
|
Also added in depth comments about the currently known variations
Returning the RNG seed is now implemented (although it seems no
games actually use this functionality, it seems to be just script
bugs).
Also remove Torin kRandom workarounds.
|
|
|
|
|
|
Hoyle5 will spin on kGetTime between 15 and 300 ticks in multiple
game scripts in order to delay execution (for example, after
choosing opponents and clicking "okay"). This causes ScummVM to
be unresponsive and wastes CPU time.
This commit patches the spin subroutines to instead call a kernel
function (kWait) that waits without a spin loop. This kernel
function was removed in SCI2, and has been added back in ScummVM
specifically for Hoyle5, so this patch will not work with the
original interpreter.
|
|
|
|
|
|
Since this feature is now implemented, it is not necessary to
describe its intended functionality here.
|
