| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Drawing the cursor in this mode will result in a read overflow as
it is 8bpp.
|
|
|
|
|
|
|
|
|
|
|
|
Only cursor remains to be updated to go through GfxFrameout, and
then we can let GfxScreen go back to being SCI16-only.
|
|
|
|
|
|
|
|
We originally used hardcoded gameIDs and checked for CD-version.
Now the game option itself is checked for.
When it's available for the currently detected game, the option
is read, otherwise it defaults to false (same behavior as before).
|
|
|
|
|
|
When objects are added to a SegmentObjTable, it may cause the
internal storage for the table to expand and move to a new
region of memory. When this happens, all pointers to objects held
by a SegmentObjTable of the same type would be invalidated, due
to an implementation detail that should not be exposed. To prevent
this, objects are now allocated separately on the heap, so even if
the table's storage moves due to insertions, the objects owned by
the table will not, so references remain valid for the lifetime of
the object.
|
|
Pseudo mouse was functionality in SCI1+ games, that allowed the
user to control the mouse via keyboard cursor keys.
This new class only worked, when a tiny difference inside
the keyboard driver happened on kMapKeyToDir calls. We previously
tried to enable this behavior depending on cursor type, but
this didn't work correctly (Larry 5 for example was not detected
as such, but had PseudoMouse support).
|
|
This happens in e.g. Phant1, when walking from dining, to
reception, to up the stairs.
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
|
|
SCI32: Support Torin's autosave system
|
|
|
|
doCatalog::mode does not exist, the method is actually
doCatalog::changeState
This issue has been in there since the workaround was added
through commit 20b1d80d598e6f741e28c9a85d186e463d111816
|
|
The VMD decoder sends audio directly to the system mixer.
|
|
|
|
|
|
|
|
|
|
When new bitmaps are added and the underlying Common::Array needs
to move to expand, this invalidates all pointers to bitmaps, which
makes it basically impossible to use the bitmap segment since you
never know if a reference is going to be invalidated due to an
array move.
To solve this, BitmapTable is changed to hold pointers to
SciBitmaps that are allocated separately on the heap instead, so
when those bitmaps are looked up, the resulting pointers are valid
for the lifetime of the bitmap, instead of the lifetime of the
Common::Array used internally by BitmapTable.
|
|
|
|
|
|
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.
|
|
|
|
Torin has two sets of saves: autosave.### and torinsg.###, both with
their own slots and .cat file. The autosave system uses autosave.000
and autosave.001. It also checks the presence of autosave.cat to
determine if it should show the chapter selection menu on startup.
|
|
|
|
|
