This removes the unnecessary Buffer subclass and stops most places
where the output buffer was being interrogated about dimensions
instead of GfxFrameout.
* Rewrap comments to 80 columns
* Clarify comments where possible
* Use smart pointers where appropriate
* Change view/pic flags detection to always use word-size
(byte-size check for flag 0x80 was a compiler optimisation)
This reverts commit d2dd942ad7.
The Serializable class is an interface class and has only the
empty default copy constructor. There is no reason to call this
explicitly. Whatever is warning about this should be fixed to stop
warning about it, rather than adding such unnecessary calls to the
engine code.
kArrayCopy would perform an unnecessary memory copy of the source
array, the treatment of the count value as unsigned was clearly
not correct since it was being sign-extended and checked against
-1.
The maxSize given when generating a SegmentRef is supposed to be
the maximum size of raw data that can be held inside the offset-
part of a reg_t, not the entire size including the segment.
This fixes a buffer overflow in "Inside the Chest", which still
does not work, but at least doesn't cause heap overflows anymore
with this change.
1. Added a new game option for linear interpolation when scaling
overlay-mode video in ScummVM builds with USE_RGB_COLOR;
2. Implemented SCI2.1-variant of the VMD player renderer (fixes
Trac#9857), which bypasses the engine's normal rendering
pipeline;
3. Improved accuracy of the SCI3-variant of the VMD player by
writing HunkPalettes into the VMD's CelObjMem instead of
submitting palettes directly to GfxPalette32.
The ScummVM implementation of class SciArray::fill() has a bug where it
will overwrite the array[index] with the value count times, rather than
fill the array starting from index count times.
This patch fixes that behavior. This was noticed because the LSL7 dice
game was broken, it was impossible to lose. After this patch the dice
game works as expected.
Closes gh-953.
With this bug, whenever a string was trimmed from the right, the last
character was always cut off, even if it wasn't whitespace. This was
apparent in the RAMA demo, which parses a text file for its scenes,
and each line is trimmed
This bug existed in SSCI and was pulled in carelessly during
initial implementation of SciArray. Closer examination of SCI3
reveals that this only happened to work in SSCI because it would
always allocate on the first resize, and would always allocate 25
extra elements per allocation.
KQ7 1.51 writes int16s from the save game catalogue into a Str
object, then retrieves byte 0 from the string and compares it to
-1. This happens to work out because (1) characters were treated
as signed in SCI2.1early and earlier, and (2) int16s in the save
game catalogue were little-endian.
In SCI2.1mid and later, this trick no longer works because
characters are treated as unsigned and get zero-extended instead.
Fixes Trac#9632.
Memory references and integers in SSCI are both 16-bit numbers,
so game scripts frequently (incorrectly) use an IntArray instead
of an IDArray for holding references. Since references in ScummVM
are 32-bit reg_ts, IntArray entries must be large enough to hold
reg_ts in order to be compatible with game scripts that store
references in integer arrays.
The alternative solution is to find and patch all incorrect use of
IntArray across all games. This is possible, but a bit risky from
a save game stability perspective, since incorrect IntArray usage
is sometimes not apparent until well after the array is
instantiated (like GK1's global interview array).
This change invalidates existing SCI32 save games.
This change invalidates earlier SCI32 save games, which separated
arrays and strings in an incompatible manner. Old save games
contain invalid references to a string segment which no longer
exists, and contain incompatible array structures that lack
critical type information.
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.
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.
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.
No functionality change has been made with this commit. This avoids
setting and getting the reg_t members directly, and is the basis of any
future work on large SCI3 scripts (larger than 64KB)
SCI scripts can contain stale pointers, which are used later on. We now delete
the contents of hunk entries without invalidating the relevant pointers and let
the GC clear the references. Many thanks to waltervn and wjp for all their work
and help on this.
Filippos Karapetis
Eugene Sandulenko
Colin Snover
Hein-Pieter van Braam
D G Turner
Johannes Schickel
Filippos Karapetis
Tarek Soliman
Matthew Hoops
strangerke