| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
There is still a problem where the background is white instead
of black; this is caused by the palette of the video using entry
0 as white. This seems to have worked out OK in SSCI because the
video was not actually played back inside the engine itself, so
didn't interfere with the palette of the engine. ScummVM has no
such separation, so the palette of the video interferes with the
palette of the blank background pic, turning it white.
|
|
|
|
|
|
Revert "SCI32: Fix KQ7 1.51 video background"
This reverts commit c8affb54cca259f37522216bad739be085bf9caa.
Revert "SCI32: Fix crash when kShowMovie is called but the video cannot be found"
This reverts commit 93b06f4a9e08de281ee7eb9c780ceac147c3fb23.
Revert "SCI32: Fix KQ7 1.51 basic video playback"
This reverts commit cdab24aa07c18ad4a25a1659f7fca15cca5e358e.
Revert "SCI32: Additional Video32 documentation"
This reverts commit 4ff0924e57a9bc9101ee0799a967fe3373dd2574.
Revert "SCI32: Implement kShowMovie"
This reverts commit 13297c19298c5ad73c9e996c5c31ca91de124911.
|
|
|
|
|
|
There is still a problem where the background is white instead
of black; this is caused by the palette of the video using entry
0 as white. This seems to have worked out OK in SSCI because the
video was not actually played back inside the engine itself, so
didn't interfere with the palette of the engine. ScummVM has no
such separation, so the palette of the video interferes with the
palette of the blank background pic, turning it white.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
In the original engine this would have simply resulted in no draw,
but ScummVM is more strict about it. It is not 100% clear whether
these are normal and should be allowed or not, so for the moment
we'll emit a warning whenever a zero-dimension show rect is seen.
For now they only seem to be generated by plane transitions, and
these zero-dimension screen items cannot simply be omitted because
the 2.1early transitions code requires a fixed number of screen
items per step.
|
|
This is used by Torin in room 50900.
|
|
This commit implements all of the known plane transitions from
SCI2 through SCI2.1mid games. Because kSetShowStyle is always
called indirectly via the Styler game script, it is difficult to
find all the places where transitions are used. As such,
transitions that appeared to never be used have been added as
stubs which will trigger a game crash with a message to report
what was being done, so any missed transition types can be
identified quickly and then implemented.
|
|
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
1. Use the same throttling speed as normal frameouts. The
old throttling speed seemed a bit too slow.
2. Exit the event loop immediately if the engine is supposed to
quit, instead of forcing the user to wait until the transition
has finished before quitting.
|
|
Some games load palettes that include color 255, but this is
hardcoded to white in SSCI, so just ignore it during merges since
it is ignored when the hardware palette is updated anyway.
|
|
Avoid forcing the screen to refresh after a palette change if the
screen is also about to be drawn to, as the palette change + draw
is intended to be an atomic operation.
|
|
|
|
With the addition of the transparent pic type code, the _type
property would be read uninitialised by setType if _pictureId was
set to kPlanePic.
CID 1357230, 1357231.
|
|
CID 1357229.
|
|
|
|
|
|
Sometimes, games accidentally use palette entries that are not
marked as used and expect them to be a particular colour, like the
Phantasmagoria title screen, or the white palette entry (always
255 in DOS/Win).
|
|
|
|
|
|
Ow. My eyeballs.
|
|
|
|
Controls that manage their own event loops and call frameOut
directly generally need to sleep in order to avoid 100% CPU,
just like the main VM event loop.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The way dimensions of scaled screen items are calculated changed
over the lifetime of SSCI. In early low-resolution and
mixed-resolution games, scaled drawing needed to use at a global
cadence across the entire screen to ensure proper alignment, but
in later games (like Torin), local scaling of individual screen
items seems to be the way scaling is performed.
|
|
It is not clear if this is ever actually used by game scripts,
though.
|
