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.
Remap would crash SCI2.1early games with 19 remap slots, and
did not actually work in most cases in SCI2.1mid+ games.
The SCI16 implementation was moved to its own separate file but
was otherwise touched as little as possible, so may still have
similar problems to the SCI32 code.
1. Split SCI16 and SCI32 code into separate files
2. Use -32 prefixes for SCI32 code and no prefix for SCI16 code,
where possible, to match other existing code
3. Avoid accidental corruption of values from the VM that may be
valid when signed or larger than 8 bits
4. Added documentation
5. Add missing remap CelObj calls
6. Inline where possible in performance-critical code paths
7. Fix bad `matchColor` function, and move it from GfxPalette to
GfxRemap32 since it is only used by GfxRemap32
8. Fix bad capitalisation in getCycleMap
9. Remove unnecessary initialisation of SingleRemaps
10. Update architecture to more closely mirror how SSCI worked
11. Clarify the purpose of each type of remap type (and
associated variable names)
12. Split large `apply` function into smaller units
13. Fix buffer overrun when loading a SCI2.1early game with remap
14. Remove use of `#define` constants
15. Warn instead of crashing with an error on invalid input (to
match SSCI more closely)
16. Change the collision avoidance mechanism between the RemapType
enum and remap kernel functions
17. Add save/load function
Most of the time, we get a bitmap to draw on it. Exposing a buffer
avoids consumers having to create their own all the time, and
encourages use of common drawing code exposed by the buffer.
This kernel call seems only to be used by KQ7 1.51 (which was
Windows-only) to send warnings to the user.
It was easy enough to do a basic implementation in the ScummVM
GUI rather than just make it an empty call, so now it is a thing.
Most SCI32 games draw a "fred" object to the screen when the game
first starts to benchmark video performance. When framerate
throttling is enabled (which fixes many/most timing-related bugs
and reduces system load caused by unnecessary graphics updates),
the game's performance check will think that video card is slow,
causing some "high-performance" game features to be disabled.
To avoid this, we simply disable throttling during benchmarking by
detecting the "fred" object.
The implementation was not correctly rounding the scaled position
with mulru, leading to occasionally incorrect hit detection at
the boundaries of boxes.
This implementation is not 100% engine accurate, but it is
more accurate than what was there, and hopefully the differences
between this and the engine code are merely cosmetic.
The known (intentional) differences are:
1. Uses ScummVM rects inside the engine code, converting to/from
SCI rects on the kernel edges and when scaling
2. Fewer side effects when performing operations that *should*
have been pure from the start (like text dimension calculation).
Still not side-effect-free, but at least things like colours
and alignment do not need to be reset every time a measurement
is taken, unlike in the actual engine.
Editor controls and some other kBitmap code are temporarily
disabled as a result of changes to GfxText32 until they can be
updated to be engine-accurate.
Now that the renderer is loading resources without spinning CPU time
on decompression every frame, it becomes apparent that kFrameOut is
spammed constantly by the interpreter and needs to be throttled to
ensure that transitions and fades work properly.
Colin Snover
Willem Jan PalenstijnandColin Snover
Ori Avtalion
Filippos Karapetis
Martin Kiewitz