| Age | Commit message (Collapse) | Author |
|---|
|
This fixes the 3-frame glitch that was also present in the
original game when moving in the chapel from room 6500 to 6400 in
chapter 7.
Fixes Trac#9788.
|
|
This happens e.g. on the About page in LSL7 because of an
interpreter problem where bitmap handles are destroyed and then
reused without a kFrameOut call to remove old screen items from
the visible plane list before a kIsOnMe call that causes the
engine to try to read from reused bitmap handles with different
contents and dimensions.
This replaces bad memory reads on the About page in LSL7 with an
assertion failure, until the problem with the About page can be
properly addressed.
|
|
|
|
PQ4CD and several other games contain a hack in two renderer
methods to avoid rendering invalid screen items with zero or
negative-dimension target rects. This prevents PQ4CD from
crashing during the fifth phase of target practice.
|
|
Used by at least Phantasmagoria 2.
|
|
|
|
transparentColor -> skipColor
displace -> origin
scaledWidth -> xResolution
scaledHeight -> yResolution
|
|
|
|
|
|
|
|
This workaround may be able to be vastly simplified in the future
since, so far, simply returning the number of cels in loop 0 is
enough to make all the scripts with this bug work as expected.
|
|
|
|
This fixes rendering errors in Torin caused by the scaler table
being cut off early when cels larger than the dimensions of the
screen are scaled.
|
|
|
|
|
|
|
|
|
|
Negative cel numbers are exploited by at least the hi-res mode of
PQ4CD.
|
|
Torin renders pics that are wider than 1024px; SCI3 bumps the
maximum line width to 4k.
|
|
|
|
|
|
|
|
|
|
|
|
Ow. My eyeballs.
|
|
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.
|
|
In a few places in the graphics system, fixed low-resolution values
are used instead of the game script resolution.
|
|
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
|
|
CID 1351617, 1351618, 1351619, 1351620, 1351621, 1351622, 1354791.
|
|
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.
|
|
|
|
|
|
|
|
|
|
The priority map is not used at all in SCI32 at the engine level by
design, so all the relevant code that handles picture priority is
pretty much dead
|
|
Still not working
|
|
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.
|
|
This reverts commit d85eb8ded68a20de383d84064aacd1a4c81db4e9.
This patch did not correctly fix the scaler to follow the same
rules as SSCI and only worked on the y-axis.
|
|
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
|
|
|
|
|
|
|
|
|
|
Not all SCI2.1late/SCI3 function signatures are fully known yet,
but all subops are now represented in the kernel tables.
|
|
|
|
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
|
|
This replaces "colour" to "color"
|
|
|
|
|
