| Age | Commit message (Collapse) | Author |
|---|
|
These objects should have been initialized only during the first
pass. Double-initialization does not cause any visible problem
problem during normal operation (mostly it just causes memory
waste by making Object::_baseVars/_baseMethod double up their
data), but could have silently allowed games to receive bogus data
for an out-of-bounds property or method index, instead of raising
an error.
|
|
|
|
When a game deletes a script and then loads the same script again
before it has been fully deallocated,
SegManager::instantiateScript tries to reuse the same script
& locals segments, but it was failing to reuse the old locals
segment because Script::freeScript would unconditionally clear
the old locals SegmentId, which meant the old locals segment would
just leak.
This patch does not fix old save games which may contain orphaned
locals segments, but should prevent the problem from occurring
going forward. (It is possible to clean up these old save games,
but this is not a big leak so it doesn't seem worth the extra
effort to do so.)
|
|
See code comment in Object::init for more details.
Fixes Trac#9780.
|
|
This groundwork enables an object to look up its static name
separately from the normal process that is used to populate
Object::_variables when an object is first constructed.
(The static name property needs to be able to be retrieved from
objects inside of earlier save games whose name properties may
have already been modified at runtime, so the code cannot simply
pluck the value out of Object::_variables when they are first
initialised and then persisted into the save game, as nice and
easy as that would have been.)
This commit also helps to clarify the situation with relocation
tables in SCI1 games that start with a zero entry.
Refs Trac#9780.
|
|
|
|
Script buffer data is modified after a script is loaded by
savegame operations, and, in SCI16, by string operations. Casting
away const to allow these mutations to happen is not a very good
design, so this patch just changes the privately held reference
to data to be mutable. (Public accessors still return immutable
data.)
|
|
|
|
|
|
|
|
Export functions may be relocated above 64k in SCI3, but exports
that do not have an entry in the relocation table must be handled
the same as SCI1.1-2.1.
|
|
|
|
|
|
|
|
Locals offset needs to be set even when the script has no exports.
|
|
The field at +8 is for the MemID associated with a relocation.
|
|
|
|
The previous fix for this bug was incorrect; it only happened
to work because of another bug: the number of exports was being
read incorrectly (reading the byte size of the export block, not
the number of exports), so the validation check for the export
number always passed. Then, the "small" offsets that were seen
were actually either invalid reads into the header of the next
block in the script (KQ4), or reads into the bad first export
table which contained an unfilled offset (Camelot).
Once the incorrect number of exports was fixed, the previous "fix"
broke in KQ4 because the export number validation started to work
correctly and the first export table does not have enough entries
(needs 2, has 1).
This patch fixes the bug by using the last export table in SCI0
scripts instead of the first export table. (This does not affect
most scripts, since only the buggy scripts have more than one
export table.)
Fixes Trac#9731.
|
|
|
|
|
|
|
|
|
|
1. pushi opcode now displays decimal value and selector value (if
one exists) in-line
2. lofsa, lofss, and super opcodes now display resolved
object/class names
3. Opcode arguments are visually aligned
|
|
Exports with a zero offset are supposed to point to the start of
the code block in the script hunk, but they were being ignored.
This may also apply to SCI1.1 games, but until that can be
verified, this fixes the zero-offset in only SCI32 games for now.
|
|
Previously, this was using the offset of the property dict inside the
script. However, this isn't unique. For example, SQ6's DPath and
PolyPath classes both have their property dict at offset 8 of their
respective scripts. This would break Obj::isMemberOf.
Closes #846.
|
|
- Detection works via signatures (couldn't find a better way)
- new kString subcalls were introduced SCI2.1 LATE
- kString now has signatures and is split via subcall table
- kString fix, so that KQ7 doesn't crash, when starting a chapter
- Sci2StringFunctionType removed, because no longer needed
|
|
|
|
|
|
|
|
|
|
|
|
implement string collecting for SCI3
implement object offset collecting for SCI0-SCI2
implement said-str offset collecting for SCI0-SCI1
add new debug command scro / script_objects
add new debug command script_said
string without terminating NUL now a warning
the latter happens in qfg2 for amiga room 84
|
|
fixes string identifying in mac SCI1.1 games
|
|
debug command is called "script_strings" / "scrs"
|
|
this is a script issue and also happens
in Sierra's SCI. Gets solved by script patch.
|
|
|
|
|
|
Gabriel Knight + King's Quest 6 patches now also work for Mac versions of those games
added support for selectors instead of using hardcoded values
|
|
This way the assert is checking that the allocated buffer is large enough
for the memcpy that follows it.
|
|
|
|
This ensures that it won't be confused with a function with the same name
|
|
This is needed for future support of large SCI3 scripts. The program
counter is isolated and does not interfere with other parts of the VM,
plus it does not get stored in saved games, so it's pretty straightforward
to convert
|
|
Also renamed some SCI3 related code to indicate when it's SCI3 specific
|
|
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)
|
|
The caller offset is never actually used inside the function
|
|
|
|
Thanks to DrMcCoy for reporting them
|
|
This reverts commit 577d7e41c9ca2c498dc85e41c373fbdca8d2ed41.
|
|
Merge the init() and load() Script methods and reset the script when
necessary
|
|
These are needed for future handling of large SCI3 script files
|
