SCI: Add more support for >16-bit SCI3 offsets

Basically just grepped for getOffset calls being assigned to
uint16s and expanded those to uint32 when they looked trivial.

While some of these changes seem superfluous, at least for the
US/English SCI3 games where potentially impacted game scripts are
not large enough to have a problem with 16-bit offsets (e.g. when
feature detecting the sound type), at least some of these changes
are necessary for correct operation of the find_callk debugger
command in SCI3 games. There should not be a reason why any of
these variables need to be kept as uint16, in any case.

1 files changed, 2 insertions, 2 deletions

diff --git a/engines/sci/engine/kscripts.cpp b/engines/sci/engine/kscripts.cpp
index 98c35fcb49..af4b8ff081 100644
--- a/engines/sci/engine/kscripts.cpp
+++ b/engines/sci/engine/kscripts.cpp
@@ -160,7 +160,7 @@ reg_t kClone(EngineState *s, int argc, reg_t *argv) {
 
 	debugC(kDebugLevelMemory, "Attempting to clone from %04x:%04x", PRINT_REG(parentAddr));
 
-	uint16 infoSelector = parentObj->getInfoSelector().getOffset();
+	uint16 infoSelector = parentObj->getInfoSelector().toUint16();
 	cloneObj = s->_segMan->allocateClone(&cloneAddr);
 
 	if (!cloneObj) {
@@ -211,7 +211,7 @@ reg_t kDisposeClone(EngineState *s, int argc, reg_t *argv) {
 	//  At least kq4early relies on this behavior. The scripts clone "Sound", then set bit 1 manually
 	//  and call kDisposeClone later. In that case we may not free it, otherwise we will run into issues
 	//  later, because kIsObject would then return false and Sound object wouldn't get checked.
-	uint16 infoSelector = object->getInfoSelector().getOffset();
+	uint16 infoSelector = object->getInfoSelector().toUint16();
 	if ((infoSelector & 3) == kInfoFlagClone)
 		object->markAsFreed();