| Age | Commit message (Collapse) | Author |
|---|
|
This matches the C++11 std::vector method of the same name, and
replaces usage of taking the address of the first element of an
array by &array[0] or &array.front() or &*array.begin(). The data
method is better than these usages because it can be used even
when the array is empty.
|
|
These are additions to match C++11 std::vector common init
patterns, to make Common::Array cover more common use cases where
C-style arrays are currently used (and should not be).
|
|
|
|
|
|
Fixes Trac#10251.
|
|
Obviously, games other than RAMA need to have sound effects
volumes.
|
|
|
|
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.
|
|
|
|
|
|
|
|
|
|
In SCI3, Sierra removed the ability of the main renderer to
automatically scale CelObjs with different source resolutions.
Instead, in SCI3, all CelObjs are treated as having the same
resolution as the screen (i.e. 640x480).
In all SCI3 games other than RAMA, keeping the code paths for
resolution-dependent scaling is not a problem because all the
assets and game code are correctly designed to use the same
640x480 resolution throughout. RAMA, on the other hand, was
written with the text subsystem set to a resolution of 630x450
(Phant1's screen resolution), and in SSCI, resolution-dependent
scaling code was not removed from the *text* subsystem. As a
result, RAMA's game scripts rely on the slightly larger scaled
dimensions coming out of the text system when determining the size
of screen items for rendering, and then also rely on the main
renderer ignoring the 630x450 resolution baked into the bitmaps
generated by the text subsystem when drawing them to the screen.
|
|
|
|
|
|
|
|
|
|
Was a game bug, finally fixed.
This was a combined effort of wjp and myself. Thanks to wjp.
We both don't own QfG2 1.000 atm, so we could not try it for that
version.
|
|
|
|
|
|
|
|
This file normally stores brightness, music volume, and most
recently used save game directory. Since we store the music volume
ourselves and don't use the save game directory, the only
potentially useful information is the brightness level, and that
is fine to just restore from the save games.
|
|
|
|
|
|
Fixes Trac#10245.
|
|
|
|
|
|
Basic keyup event support appears to have been added in the SCI1.1
IBM keyboard driver, and more robust support was provided in SCI32
which actually gets used by at least Lighthouse. This patch adds
support for keyup events in SCI1.1+.
Fixes Trac#10242.
|
|
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.
|
|
|
|
|
