The pathfinding debugging code is using Sierra's buggy 8-bit matching
algorithm to find colors for drawing obstacles and path points in most
of the SCI 1.1 games. This usually results all colors being black.
Now we select the good 16-bit algorithm for internal use.
Detect when kPaletteSetIntensity is called from an unthrottled
script loop and only apply speed throttling in that situation.
This fixes several slow fade-in / fade-outs such as KQ6's Sierra
logo and title screen. We've been throttling kPaletteSetIntensity
on every call, even when it was being used once per game cycle
(which our kGameIsRestarting throttling already handles) or within
kWait-throttled loops. In both cases this has added delays on top
of delays and slowed things down even further.
Fixes color 0 in QFG1VGA at night. This is the menu bar background.
QFG1VGA uses a soft black (27,27,27) for color 0 during the day and
regular black (0,0,0) at night. Until recently, ScummVM didn't display
the soft black, because it didn't include color 0 when copying pic
palettes to the system palette. Now that color 0 is included, it's
exposed that PalVary has been excluding colors 0 and 255 when
calculating the new palette, preventing QFG1VGA's soft black from
transitioning to regular black at night.
SSCI includes all entries when calculating the new palette.
In SCI 1.1 most palette operations copy entry 0 to the system palette,
such as when drawing a view. This continues an earlier fix which
included entry 0 when drawing a pic and exposed that this needs to
happen in other places too: 3de471de36
Fixes bug #11544 where a KQ6 RAVE resource ended up with the wrong
color in room 380. System palette entry 0 ended up as [7,7,7] when
the RAVE was drawn instead of black, the expected color, causing the
RAVE palette to merge incorrectly. [7,7,7] comes from pic 380's
palette, after which entry 0 should be set to black when drawing
view 5 and copying its palette, which is what now happens.
When drawing a pic while pal-very isn't active, SSCI 1.1 sets the
first 255 palette colors, as opposed to skipping the first when
normally inserting a palette. Without this, a palette cycle that
includes the first color will permanently alter the system palette,
such as in Hoyle4 when winning the Klondike game with certain
table backgrounds.
Fixes bugs #11164 and #11195
The new approach is to delay kAnimate briefly (with an 68ms timeout)
while there is a zero-tick PalVary running, so that it has time to
trigger.
The previous workaround would immediately process a zero-tick
PalVaryInit/PalVaryReverse. This caused problems in QfG3 (bug #10304)
where it interfered with PalVaryPause.
The previous workaround could also be modified to handle pause/resume,
but this new approach should be closer to SSCI's behaviour, which used a
timer for a zero-tick PalVary too.
This fixes bug #10304, and keeps #5298 fixed too.
Bitmaps in ScrollWindow and Robot code are managed by the kernel
and not by game scripts, although they must be able to be
referenced through a reg_t. To prevent incorrect GC of bitmaps
that are in use but not referenced by any game script, explicit
memory management of hunk entries can be enabled.
This means tick-based times are saved to save games, as in SCI32
engine, instead of seconds, which are not accurate enough. It
also means places in SCI engine that need to access game ticks
should do so through g_sci instead of g_system or g_engine.
This needs to be performed because the screen palette might not change
after the call. Fixes the display of the bat in the character selection
screen in the full version of QFG4
More transparency/color mapping effects are now working (e.g. the
flashlight at the Gedde tomb in GK1, the rays of light at Schloss Ritter
in GK1, the torch in the QFG4 demo and the shadows in QFG4, PQ4 and KQ7)
Fixes some graphics glitches in the QFG4 demo and the menus of QFG4, by
implementing one of the transparency effects used mainly in SCI32.
Many thanks to fuzzie for her debugging info on QFG4 demo and to wjp for
his great help on the dissassembly