This may come back in the future to deduplicate some gfx code,
but SCI32 had two different inlined ways of doing coordinate
conversions with different rounding methods, so CoordAdjuster32
didn't get used when the graphics system was rewritten.
At the moment, SCI32 code uses the mulru/mulinc methods from
helper.h for scaling up/down coordinates.
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
kCelInfo subop 4 returns the pixel color at the
passed in x,y coordinates for the passed in view,
loop, cel. Shivers uses this function for the
red door puzzle, room 23601 to determine what
blocks on the puzzle board are already occupied
by pieces.
The return value of GfxView::getCelInfo was used virtually everywhere
without a check for it being non-NULL. Hence instead of returning
NULL when the loop count is zero, it makes more sense to assert out
(instead of a segfault, or worse, random data being used).
svn-id: r50422
This helps to ensure proper data encapsulation.
Also reformatted some overlong comments to 80 chars per line, and
fixed some other code formatting issues.
svn-id: r50421
- Removed the custom types MemoryHandle, LoopNo, CelNo (cause we ended up having code like LoopNo loopNo = ...)
- Improved the sanity checks in frameOut()
svn-id: r47087
Colin Snover
Filippos Karapetis
Johannes Schickel
Heather Douglass
strangerke
Lars Skovlund
Martin Kiewitz
Max Horn