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.
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
This ensures that if there is a bug in the drawing code that causes
the row to be unset, it will not result in silently reading garbage
out of random memory.
CID 1354802
The previous implementation did not work properly, assigning the
next insertion index to the oldest object instead of filling empty
cache slots on a cache miss.
In order for scaling ratios to apply equally across objects that
start at different positions on the screen, the pixels that are
read from the source bitmap must all use the same pattern of
division. In other words, cels must follow the same scaling pattern
as if they were drawn starting at an even multiple of the scaling
ratio, even if they were not.
Previously sourcePos was always originating from plain 0, 0
which made some pixels not always getting drawn at the right
spot when uneven scaling was used (for example 5:12).
Seems to fix gabriel knight 1 hires graphic issues
1. Reorder member initialisations to match class member order
2. Use #pragma mark instead of comments for annotating sections
3. Remove useless >=0 checks on unsigned types
Colin Snover
Filippos Karapetis
Martin Kiewitz
Johannes Schickel