2007-05-30 21:56:52 +00:00
|
|
|
/* ScummVM - Graphic Adventure Engine
|
|
|
|
*
|
|
|
|
* ScummVM is the legal property of its developers, whose names
|
|
|
|
* are too numerous to list here. Please refer to the COPYRIGHT
|
|
|
|
* file distributed with this source distribution.
|
2003-07-28 01:44:38 +00:00
|
|
|
*
|
2007-05-31 20:28:29 +00:00
|
|
|
* Additional copyright for this file:
|
|
|
|
* Copyright (C) 1994-1998 Revolution Software Ltd.
|
|
|
|
*
|
2003-07-28 01:44:38 +00:00
|
|
|
* This program is free software; you can redistribute it and/or
|
|
|
|
* modify it under the terms of the GNU General Public License
|
|
|
|
* as published by the Free Software Foundation; either version 2
|
|
|
|
* of the License, or (at your option) any later version.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
2005-10-18 01:30:26 +00:00
|
|
|
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
|
2003-07-28 01:44:38 +00:00
|
|
|
*/
|
|
|
|
|
2007-09-19 08:40:12 +00:00
|
|
|
|
2003-11-23 13:40:24 +00:00
|
|
|
#include "common/util.h"
|
2008-12-29 11:55:09 +00:00
|
|
|
#include "common/stack.h"
|
2011-04-24 08:34:27 +00:00
|
|
|
#include "common/textconsole.h"
|
2006-02-17 15:07:36 +00:00
|
|
|
|
2003-11-16 14:18:29 +00:00
|
|
|
#include "sword2/sword2.h"
|
2006-02-17 15:07:36 +00:00
|
|
|
#include "sword2/header.h"
|
2005-07-09 13:21:21 +00:00
|
|
|
#include "sword2/defs.h"
|
2003-10-28 19:51:30 +00:00
|
|
|
#include "sword2/interpreter.h"
|
2004-02-05 14:19:07 +00:00
|
|
|
#include "sword2/logic.h"
|
2004-11-14 15:00:01 +00:00
|
|
|
#include "sword2/memory.h"
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
#include "sword2/resman.h"
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-10-04 00:52:27 +00:00
|
|
|
namespace Sword2 {
|
|
|
|
|
2004-03-17 09:03:15 +00:00
|
|
|
#define STACK_SIZE 10
|
|
|
|
|
2003-09-20 12:43:52 +00:00
|
|
|
// The machine code table
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-10-19 14:19:52 +00:00
|
|
|
#ifndef REDUCE_MEMORY_USAGE
|
|
|
|
# define OPCODE(x) { &Logic::x, #x }
|
|
|
|
#else
|
|
|
|
# define OPCODE(x) { &Logic::x, "" }
|
|
|
|
#endif
|
2003-10-18 08:11:50 +00:00
|
|
|
|
2006-09-09 10:29:14 +00:00
|
|
|
void Logic::setupOpcodes() {
|
|
|
|
static const OpcodeEntry opcodes[] = {
|
|
|
|
/* 00 */
|
|
|
|
OPCODE(fnTestFunction),
|
|
|
|
OPCODE(fnTestFlags),
|
|
|
|
OPCODE(fnRegisterStartPoint),
|
|
|
|
OPCODE(fnInitBackground),
|
|
|
|
/* 04 */
|
|
|
|
OPCODE(fnSetSession),
|
|
|
|
OPCODE(fnBackSprite),
|
|
|
|
OPCODE(fnSortSprite),
|
|
|
|
OPCODE(fnForeSprite),
|
|
|
|
/* 08 */
|
|
|
|
OPCODE(fnRegisterMouse),
|
|
|
|
OPCODE(fnAnim),
|
|
|
|
OPCODE(fnRandom),
|
|
|
|
OPCODE(fnPreLoad),
|
|
|
|
/* 0C */
|
|
|
|
OPCODE(fnAddSubject),
|
|
|
|
OPCODE(fnInteract),
|
|
|
|
OPCODE(fnChoose),
|
|
|
|
OPCODE(fnWalk),
|
|
|
|
/* 10 */
|
|
|
|
OPCODE(fnWalkToAnim),
|
|
|
|
OPCODE(fnTurn),
|
|
|
|
OPCODE(fnStandAt),
|
|
|
|
OPCODE(fnStand),
|
|
|
|
/* 14 */
|
|
|
|
OPCODE(fnStandAfterAnim),
|
|
|
|
OPCODE(fnPause),
|
|
|
|
OPCODE(fnMegaTableAnim),
|
|
|
|
OPCODE(fnAddMenuObject),
|
|
|
|
/* 18 */
|
|
|
|
OPCODE(fnStartConversation),
|
|
|
|
OPCODE(fnEndConversation),
|
|
|
|
OPCODE(fnSetFrame),
|
|
|
|
OPCODE(fnRandomPause),
|
|
|
|
/* 1C */
|
|
|
|
OPCODE(fnRegisterFrame),
|
|
|
|
OPCODE(fnNoSprite),
|
|
|
|
OPCODE(fnSendSync),
|
|
|
|
OPCODE(fnUpdatePlayerStats),
|
|
|
|
/* 20 */
|
|
|
|
OPCODE(fnPassGraph),
|
|
|
|
OPCODE(fnInitFloorMouse),
|
|
|
|
OPCODE(fnPassMega),
|
|
|
|
OPCODE(fnFaceXY),
|
|
|
|
/* 24 */
|
|
|
|
OPCODE(fnEndSession),
|
|
|
|
OPCODE(fnNoHuman),
|
|
|
|
OPCODE(fnAddHuman),
|
|
|
|
OPCODE(fnWeWait),
|
|
|
|
/* 28 */
|
|
|
|
OPCODE(fnTheyDoWeWait),
|
|
|
|
OPCODE(fnTheyDo),
|
|
|
|
OPCODE(fnWalkToTalkToMega),
|
|
|
|
OPCODE(fnFadeDown),
|
|
|
|
/* 2C */
|
|
|
|
OPCODE(fnISpeak),
|
|
|
|
OPCODE(fnTotalRestart),
|
|
|
|
OPCODE(fnSetWalkGrid),
|
|
|
|
OPCODE(fnSpeechProcess),
|
|
|
|
/* 30 */
|
|
|
|
OPCODE(fnSetScaling),
|
|
|
|
OPCODE(fnStartEvent),
|
|
|
|
OPCODE(fnCheckEventWaiting),
|
|
|
|
OPCODE(fnRequestSpeech),
|
|
|
|
/* 34 */
|
|
|
|
OPCODE(fnGosub),
|
|
|
|
OPCODE(fnTimedWait),
|
|
|
|
OPCODE(fnPlayFx),
|
|
|
|
OPCODE(fnStopFx),
|
|
|
|
/* 38 */
|
|
|
|
OPCODE(fnPlayMusic),
|
|
|
|
OPCODE(fnStopMusic),
|
|
|
|
OPCODE(fnSetValue),
|
|
|
|
OPCODE(fnNewScript),
|
|
|
|
/* 3C */
|
|
|
|
OPCODE(fnGetSync),
|
|
|
|
OPCODE(fnWaitSync),
|
|
|
|
OPCODE(fnRegisterWalkGrid),
|
|
|
|
OPCODE(fnReverseMegaTableAnim),
|
|
|
|
/* 40 */
|
|
|
|
OPCODE(fnReverseAnim),
|
|
|
|
OPCODE(fnAddToKillList),
|
|
|
|
OPCODE(fnSetStandbyCoords),
|
|
|
|
OPCODE(fnBackPar0Sprite),
|
|
|
|
/* 44 */
|
|
|
|
OPCODE(fnBackPar1Sprite),
|
|
|
|
OPCODE(fnForePar0Sprite),
|
|
|
|
OPCODE(fnForePar1Sprite),
|
|
|
|
OPCODE(fnSetPlayerActionEvent),
|
|
|
|
/* 48 */
|
|
|
|
OPCODE(fnSetScrollCoordinate),
|
|
|
|
OPCODE(fnStandAtAnim),
|
|
|
|
OPCODE(fnSetScrollLeftMouse),
|
|
|
|
OPCODE(fnSetScrollRightMouse),
|
|
|
|
/* 4C */
|
2011-04-14 12:12:27 +00:00
|
|
|
OPCODE(fnColor),
|
2006-09-09 10:29:14 +00:00
|
|
|
OPCODE(fnFlash),
|
|
|
|
OPCODE(fnPreFetch),
|
|
|
|
OPCODE(fnGetPlayerSaveData),
|
|
|
|
/* 50 */
|
|
|
|
OPCODE(fnPassPlayerSaveData),
|
|
|
|
OPCODE(fnSendEvent),
|
|
|
|
OPCODE(fnAddWalkGrid),
|
|
|
|
OPCODE(fnRemoveWalkGrid),
|
|
|
|
/* 54 */
|
|
|
|
OPCODE(fnCheckForEvent),
|
|
|
|
OPCODE(fnPauseForEvent),
|
|
|
|
OPCODE(fnClearEvent),
|
|
|
|
OPCODE(fnFaceMega),
|
|
|
|
/* 58 */
|
|
|
|
OPCODE(fnPlaySequence),
|
|
|
|
OPCODE(fnShadedSprite),
|
|
|
|
OPCODE(fnUnshadedSprite),
|
|
|
|
OPCODE(fnFadeUp),
|
|
|
|
/* 5C */
|
|
|
|
OPCODE(fnDisplayMsg),
|
|
|
|
OPCODE(fnSetObjectHeld),
|
|
|
|
OPCODE(fnAddSequenceText),
|
|
|
|
OPCODE(fnResetGlobals),
|
|
|
|
/* 60 */
|
|
|
|
OPCODE(fnSetPalette),
|
|
|
|
OPCODE(fnRegisterPointerText),
|
|
|
|
OPCODE(fnFetchWait),
|
|
|
|
OPCODE(fnRelease),
|
|
|
|
/* 64 */
|
|
|
|
OPCODE(fnPrepareMusic),
|
|
|
|
OPCODE(fnSoundFetch),
|
|
|
|
OPCODE(fnPrepareMusic), // Again, apparently
|
|
|
|
OPCODE(fnSmackerLeadIn),
|
|
|
|
/* 68 */
|
|
|
|
OPCODE(fnSmackerLeadOut),
|
|
|
|
OPCODE(fnStopAllFx),
|
|
|
|
OPCODE(fnCheckPlayerActivity),
|
|
|
|
OPCODE(fnResetPlayerActivityDelay),
|
|
|
|
/* 6C */
|
|
|
|
OPCODE(fnCheckMusicPlaying),
|
|
|
|
OPCODE(fnPlayCredits),
|
|
|
|
OPCODE(fnSetScrollSpeedNormal),
|
|
|
|
OPCODE(fnSetScrollSpeedSlow),
|
|
|
|
/* 70 */
|
|
|
|
OPCODE(fnRemoveChooser),
|
|
|
|
OPCODE(fnSetFxVolAndPan),
|
|
|
|
OPCODE(fnSetFxVol),
|
|
|
|
OPCODE(fnRestoreGame),
|
|
|
|
/* 74 */
|
|
|
|
OPCODE(fnRefreshInventory),
|
|
|
|
OPCODE(fnChangeShadows)
|
|
|
|
};
|
2006-09-09 10:47:32 +00:00
|
|
|
|
|
|
|
_numOpcodes = ARRAYSIZE(opcodes);
|
2006-09-09 10:29:14 +00:00
|
|
|
_opcodes = opcodes;
|
|
|
|
}
|
2003-12-14 16:33:27 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
int Logic::runResScript(uint32 scriptRes, uint32 offset) {
|
|
|
|
byte *scriptAddr;
|
|
|
|
int result;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
scriptAddr = _vm->_resman->openResource(scriptRes);
|
|
|
|
result = runScript(scriptAddr, scriptAddr, offset);
|
|
|
|
_vm->_resman->closeResource(scriptRes);
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Logic::runResObjScript(uint32 scriptRes, uint32 objRes, uint32 offset) {
|
|
|
|
byte *scriptAddr, *objAddr;
|
|
|
|
int result;
|
|
|
|
|
|
|
|
scriptAddr = _vm->_resman->openResource(scriptRes);
|
|
|
|
objAddr = _vm->_resman->openResource(objRes);
|
|
|
|
result = runScript(scriptAddr, objAddr, offset);
|
|
|
|
_vm->_resman->closeResource(objRes);
|
|
|
|
_vm->_resman->closeResource(scriptRes);
|
|
|
|
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
|
|
|
int Logic::runScript(byte *scriptData, byte *objectData, uint32 offset) {
|
|
|
|
byte pc[4];
|
|
|
|
|
|
|
|
WRITE_LE_UINT32(pc, offset);
|
|
|
|
return runScript2(scriptData, objectData, pc);
|
|
|
|
}
|
|
|
|
|
|
|
|
// This form of the runScript function is only called directly from
|
|
|
|
// the processSession() function, which uses it to update the script PC in the
|
|
|
|
// current object hub. For reasons which I do not understand, I couldn't get it
|
|
|
|
// to work if I called the function first with a dummy offset variable, and
|
|
|
|
// and then updated the object hub myself.
|
|
|
|
|
|
|
|
int Logic::runScript2(byte *scriptData, byte *objectData, byte *offsetPtr) {
|
2010-05-06 19:00:39 +00:00
|
|
|
int i;
|
|
|
|
|
2003-12-14 16:33:27 +00:00
|
|
|
// Interestingly, unlike our BASS engine the stack is a local variable.
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
// I don't know whether or not this is relevant to the working of the
|
|
|
|
// BS2 engine.
|
2003-11-29 17:05:30 +00:00
|
|
|
|
2008-12-29 11:55:09 +00:00
|
|
|
Common::FixedStack<int32, STACK_SIZE> stack;
|
|
|
|
int32 opcodeParams[STACK_SIZE];
|
2003-12-14 16:33:27 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
uint32 offset = READ_LE_UINT32(offsetPtr);
|
|
|
|
|
|
|
|
ResHeader header;
|
|
|
|
|
|
|
|
header.read(scriptData);
|
|
|
|
|
|
|
|
scriptData += ResHeader::size() + ObjectHub::size();
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// The script data format:
|
2003-09-20 12:43:52 +00:00
|
|
|
// int32_TYPE 1 Size of variable space in bytes
|
|
|
|
// ... The variable space
|
|
|
|
// int32_TYPE 1 numberOfScripts
|
|
|
|
// int32_TYPE numberOfScripts The offsets for each script
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2011-05-25 15:17:11 +00:00
|
|
|
// Initialize some stuff
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-14 16:33:27 +00:00
|
|
|
uint32 ip = 0; // Code pointer
|
|
|
|
int scriptNumber;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
|
|
|
// Get the start of variables and start of code
|
2003-09-20 12:43:52 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
byte *localVars = scriptData + 4;
|
|
|
|
byte *code = scriptData + READ_LE_UINT32(scriptData) + 4;
|
2004-04-07 06:57:37 +00:00
|
|
|
uint32 noScripts = READ_LE_UINT32(code);
|
2003-09-20 12:43:52 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
code += 4;
|
2003-12-14 16:33:27 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
byte *offsetTable = code;
|
2003-12-14 16:33:27 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
if (offset < noScripts) {
|
|
|
|
ip = READ_LE_UINT32(offsetTable + offset * 4);
|
|
|
|
scriptNumber = offset;
|
2005-11-13 19:42:54 +00:00
|
|
|
debug(8, "Starting script %d from %d", scriptNumber, ip);
|
2003-09-20 12:43:52 +00:00
|
|
|
} else {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
ip = offset;
|
2003-12-14 16:33:27 +00:00
|
|
|
|
2010-05-06 19:00:39 +00:00
|
|
|
for (i = 1; i < (int)noScripts; i++) {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
if (READ_LE_UINT32(offsetTable + 4 * i) >= ip)
|
2003-12-14 16:33:27 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
scriptNumber = i - 1;
|
2005-11-13 19:42:54 +00:00
|
|
|
debug(8, "Resuming script %d from %d", scriptNumber, ip);
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
|
2005-07-09 13:21:21 +00:00
|
|
|
// There are a couple of known script bugs related to interacting with
|
|
|
|
// certain objects. We try to work around a few of them.
|
2005-06-28 10:25:25 +00:00
|
|
|
|
|
|
|
bool checkMopBug = false;
|
2005-07-09 13:21:21 +00:00
|
|
|
bool checkPyramidBug = false;
|
|
|
|
bool checkElevatorBug = false;
|
2007-12-16 00:41:30 +00:00
|
|
|
bool checkPearlBug = false;
|
2005-06-28 10:25:25 +00:00
|
|
|
|
|
|
|
if (scriptNumber == 2) {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
if (strcmp((char *)header.name, "mop_73") == 0)
|
2005-06-28 10:25:25 +00:00
|
|
|
checkMopBug = true;
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
else if (strcmp((char *)header.name, "titipoco_81") == 0)
|
2005-07-09 13:21:21 +00:00
|
|
|
checkPyramidBug = true;
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
else if (strcmp((char *)header.name, "lift_82") == 0)
|
2005-07-09 13:21:21 +00:00
|
|
|
checkElevatorBug = true;
|
2007-12-16 00:41:30 +00:00
|
|
|
else if (strcmp((char *)header.name, "pearl_31") == 0)
|
|
|
|
checkPearlBug = true;
|
2005-06-28 10:25:25 +00:00
|
|
|
}
|
2003-11-29 17:05:30 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
code += noScripts * 4;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2004-12-27 17:29:07 +00:00
|
|
|
// Code should now be pointing at an identifier and a checksum
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
byte *checksumBlock = code;
|
2003-12-14 16:33:27 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
code += 4 * 3;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-09-20 12:43:52 +00:00
|
|
|
if (READ_LE_UINT32(checksumBlock) != 12345678) {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
error("Invalid script in object %s", header.name);
|
2009-09-24 10:15:50 +00:00
|
|
|
//return 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-09-20 12:43:52 +00:00
|
|
|
|
2004-12-27 17:29:07 +00:00
|
|
|
int32 codeLen = READ_LE_UINT32(checksumBlock + 4);
|
|
|
|
int32 checksum = 0;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2010-05-06 19:00:39 +00:00
|
|
|
for (i = 0; i < codeLen; i++)
|
|
|
|
checksum += (unsigned char)code[i];
|
2003-07-28 01:44:38 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
if (checksum != (int32)READ_LE_UINT32(checksumBlock + 8)) {
|
|
|
|
debug(1, "Checksum error in object %s", header.name);
|
2004-12-27 17:29:07 +00:00
|
|
|
// This could be bad, but there has been a report about someone
|
|
|
|
// who had problems running the German version because of
|
|
|
|
// checksum errors. Could there be a version where checksums
|
|
|
|
// weren't properly calculated?
|
2003-09-20 12:43:52 +00:00
|
|
|
}
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-14 16:33:27 +00:00
|
|
|
bool runningScript = true;
|
|
|
|
|
|
|
|
int parameterReturnedFromMcodeFunction = 0; // Allow scripts to return things
|
|
|
|
int savedStartOfMcode = 0; // For saving start of mcode commands
|
2003-09-20 12:43:52 +00:00
|
|
|
|
|
|
|
while (runningScript) {
|
2003-12-14 16:33:27 +00:00
|
|
|
int32 a, b;
|
|
|
|
int curCommand, parameter, value; // Command and parameter variables
|
|
|
|
int retVal;
|
|
|
|
int caseCount;
|
|
|
|
bool foundCase;
|
2004-04-23 07:02:11 +00:00
|
|
|
byte *ptr;
|
2003-12-14 16:33:27 +00:00
|
|
|
|
2003-09-20 12:43:52 +00:00
|
|
|
curCommand = code[ip++];
|
|
|
|
|
2003-09-21 16:11:26 +00:00
|
|
|
switch (curCommand) {
|
2003-12-14 16:33:27 +00:00
|
|
|
|
|
|
|
// Script-related opcodes
|
|
|
|
|
2003-09-21 16:11:26 +00:00
|
|
|
case CP_END_SCRIPT:
|
|
|
|
// End the script
|
2003-12-14 16:33:27 +00:00
|
|
|
runningScript = false;
|
2003-11-29 17:05:30 +00:00
|
|
|
|
2005-07-09 13:21:21 +00:00
|
|
|
// WORKAROUND: The dreaded pyramid bug makes the torch
|
|
|
|
// untakeable when you speak to Titipoco. This is
|
|
|
|
// because one of the conditions for the torch to be
|
|
|
|
// takeable is that Titipoco isn't doing anything out
|
|
|
|
// of the ordinary. Global variable 913 has to be 0 to
|
|
|
|
// signify that he is in his "idle" state.
|
|
|
|
//
|
|
|
|
// Unfortunately, simply the act of speaking to him
|
|
|
|
// sets variable 913 to 1 (probably to stop him from
|
|
|
|
// turning around every now and then). The script may
|
|
|
|
// then go on to set the variable to different values
|
2011-05-25 14:31:37 +00:00
|
|
|
// to trigger various behaviors in him, but if you
|
2005-07-09 13:21:21 +00:00
|
|
|
// have run out of these cases the script won't ever
|
|
|
|
// set it back to 0 again.
|
|
|
|
//
|
|
|
|
// So if his click hander finishes, and variable 913 is
|
|
|
|
// 1, we set it back to 0 manually.
|
2003-11-29 17:05:30 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
if (checkPyramidBug && readVar(913) == 1) {
|
2005-07-09 13:21:21 +00:00
|
|
|
warning("Working around pyramid bug: Resetting Titipoco's state");
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
writeVar(913, 0);
|
2003-11-29 17:05:30 +00:00
|
|
|
}
|
|
|
|
|
2005-07-09 13:21:21 +00:00
|
|
|
// WORKAROUND: The not-so-known-but-should-be-dreaded
|
|
|
|
// elevator bug.
|
|
|
|
//
|
|
|
|
// The click handler for the top of the elevator only
|
|
|
|
// handles using the elevator, not examining it. When
|
|
|
|
// examining it, the mouse cursor is removed but never
|
|
|
|
// restored.
|
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
if (checkElevatorBug && readVar(RIGHT_BUTTON)) {
|
2005-07-09 13:21:21 +00:00
|
|
|
warning("Working around elevator bug: Restoring mouse pointer");
|
|
|
|
fnAddHuman(NULL);
|
|
|
|
}
|
|
|
|
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_END_SCRIPT");
|
2003-12-14 16:33:27 +00:00
|
|
|
break;
|
|
|
|
case CP_QUIT:
|
|
|
|
// Quit out for a cycle
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
WRITE_LE_UINT32(offsetPtr, ip);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_QUIT");
|
2003-12-14 16:33:27 +00:00
|
|
|
return 0;
|
|
|
|
case CP_TERMINATE:
|
|
|
|
// Quit out immediately without affecting the offset
|
|
|
|
// pointer
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_TERMINATE");
|
2003-12-14 16:33:27 +00:00
|
|
|
return 3;
|
|
|
|
case CP_RESTART_SCRIPT:
|
|
|
|
// Start the script again
|
2004-01-10 21:56:59 +00:00
|
|
|
ip = FROM_LE_32(offsetTable[scriptNumber]);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_RESTART_SCRIPT");
|
2003-12-14 16:33:27 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
// Stack-related opcodes
|
|
|
|
|
|
|
|
case CP_PUSH_INT32:
|
|
|
|
// Push a long word value on to the stack
|
|
|
|
Read32ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
stack.push(parameter);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_PUSH_INT32: %d", parameter);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case CP_PUSH_LOCAL_VAR32:
|
|
|
|
// Push the contents of a local variable
|
|
|
|
Read16ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
stack.push(READ_LE_UINT32(localVars + parameter));
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
debug(9, "CP_PUSH_LOCAL_VAR32: localVars[%d] => %d", parameter / 4, READ_LE_UINT32(localVars + parameter));
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case CP_PUSH_GLOBAL_VAR32:
|
|
|
|
// Push a global variable
|
2004-04-07 06:57:37 +00:00
|
|
|
Read16ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
stack.push(readVar(parameter));
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
debug(9, "CP_PUSH_GLOBAL_VAR32: scriptVars[%d] => %d", parameter, readVar(parameter));
|
2003-12-14 16:33:27 +00:00
|
|
|
break;
|
|
|
|
case CP_PUSH_LOCAL_ADDR:
|
2004-04-07 08:53:24 +00:00
|
|
|
// Push the address of a local variable
|
|
|
|
|
|
|
|
// From what I understand, some scripts store data
|
|
|
|
// (e.g. mouse pointers) in their local variable space
|
|
|
|
// from the very beginning, and use this mechanism to
|
|
|
|
// pass that data to the opcode function. I don't yet
|
|
|
|
// know the conceptual difference between this and the
|
|
|
|
// CP_PUSH_DEREFERENCED_STRUCTURE opcode.
|
|
|
|
|
2003-12-14 16:33:27 +00:00
|
|
|
Read16ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
stack.push(_vm->_memory->encodePtr(localVars + parameter));
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
debug(9, "CP_PUSH_LOCAL_ADDR: &localVars[%d] => %p", parameter / 4, localVars + parameter);
|
2003-12-14 16:33:27 +00:00
|
|
|
break;
|
|
|
|
case CP_PUSH_STRING:
|
|
|
|
// Push the address of a string on to the stack
|
|
|
|
// Get the string size
|
|
|
|
Read8ip(parameter);
|
|
|
|
|
2004-04-07 06:57:37 +00:00
|
|
|
// ip now points to the string
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
ptr = code + ip;
|
2008-12-29 11:55:09 +00:00
|
|
|
stack.push(_vm->_memory->encodePtr(ptr));
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_PUSH_STRING: \"%s\"", ptr);
|
2003-12-14 16:33:27 +00:00
|
|
|
ip += (parameter + 1);
|
|
|
|
break;
|
|
|
|
case CP_PUSH_DEREFERENCED_STRUCTURE:
|
|
|
|
// Push the address of a dereferenced structure
|
|
|
|
Read32ip(parameter);
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
ptr = objectData + 4 + ResHeader::size() + ObjectHub::size() + parameter;
|
2008-12-29 11:55:09 +00:00
|
|
|
stack.push(_vm->_memory->encodePtr(ptr));
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_PUSH_DEREFERENCED_STRUCTURE: %d => %p", parameter, ptr);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case CP_POP_LOCAL_VAR32:
|
|
|
|
// Pop a value into a local word variable
|
|
|
|
Read16ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
value = stack.pop();
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
WRITE_LE_UINT32(localVars + parameter, value);
|
|
|
|
debug(9, "CP_POP_LOCAL_VAR32: localVars[%d] = %d", parameter / 4, value);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case CP_POP_GLOBAL_VAR32:
|
|
|
|
// Pop a global variable
|
2003-09-21 16:11:26 +00:00
|
|
|
Read16ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
value = stack.pop();
|
2005-06-28 10:25:25 +00:00
|
|
|
|
2005-07-09 13:21:21 +00:00
|
|
|
// WORKAROUND for bug #1214168: The not-at-all dreaded
|
|
|
|
// mop bug.
|
|
|
|
//
|
|
|
|
// At the London Docks, global variable 1003 keeps
|
|
|
|
// track of Nico:
|
|
|
|
//
|
|
|
|
// 0: Hiding behind the first crate.
|
|
|
|
// 1: Hiding behind the second crate.
|
|
|
|
// 2: Standing in plain view on the deck.
|
|
|
|
// 3: Hiding on the roof.
|
|
|
|
//
|
|
|
|
// The bug happens when trying to pick up the mop while
|
|
|
|
// hiding on the roof. Nico climbs down, the mop is
|
|
|
|
// picked up, but the variable remains set to 3.
|
|
|
|
// Visually, everything looks ok. But as far as the
|
|
|
|
// scripts are concerned, she's still hiding up on the
|
|
|
|
// roof. This is not fatal, but leads to a number of
|
|
|
|
// glitches until the state is corrected. E.g. trying
|
|
|
|
// to climb back up the ladder will cause Nico to climb
|
|
|
|
// down again.
|
|
|
|
//
|
|
|
|
// Global variable 1017 keeps track of the mop. Setting
|
|
|
|
// it to 2 means that the mop has been picked up. We
|
|
|
|
// use that as the signal that Nico's state needs to be
|
|
|
|
// updated as well.
|
2005-06-28 10:25:25 +00:00
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
if (checkMopBug && parameter == 1017 && readVar(1003) != 2) {
|
2005-07-09 13:21:21 +00:00
|
|
|
warning("Working around mop bug: Setting Nico's state");
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
writeVar(1003, 2);
|
2005-06-28 10:25:25 +00:00
|
|
|
}
|
|
|
|
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
writeVar(parameter, value);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_POP_GLOBAL_VAR32: scriptsVars[%d] = %d", parameter, value);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case CP_ADDNPOP_LOCAL_VAR32:
|
2003-09-21 16:11:26 +00:00
|
|
|
Read16ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
value = READ_LE_UINT32(localVars + parameter) + stack.pop();
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
WRITE_LE_UINT32(localVars + parameter, value);
|
|
|
|
debug(9, "CP_ADDNPOP_LOCAL_VAR32: localVars[%d] => %d", parameter / 4, value);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case CP_SUBNPOP_LOCAL_VAR32:
|
|
|
|
Read16ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
value = READ_LE_UINT32(localVars + parameter) - stack.pop();
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
WRITE_LE_UINT32(localVars + parameter, value);
|
|
|
|
debug(9, "CP_SUBNPOP_LOCAL_VAR32: localVars[%d] => %d", parameter / 4, value);
|
2003-12-14 16:33:27 +00:00
|
|
|
break;
|
|
|
|
case CP_ADDNPOP_GLOBAL_VAR32:
|
|
|
|
// Add and pop a global variable
|
|
|
|
Read16ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
value = readVar(parameter) + stack.pop();
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
writeVar(parameter, value);
|
|
|
|
debug(9, "CP_ADDNPOP_GLOBAL_VAR32: scriptVars[%d] => %d", parameter, value);
|
2003-12-14 16:33:27 +00:00
|
|
|
break;
|
|
|
|
case CP_SUBNPOP_GLOBAL_VAR32:
|
|
|
|
// Sub and pop a global variable
|
|
|
|
Read16ip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
value = readVar(parameter) - stack.pop();
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
writeVar(parameter, value);
|
|
|
|
debug(9, "CP_SUBNPOP_GLOBAL_VAR32: scriptVars[%d] => %d", parameter, value);
|
2003-12-14 16:33:27 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
// Jump opcodes
|
|
|
|
|
|
|
|
case CP_SKIPONTRUE:
|
|
|
|
// Skip if the value on the stack is true
|
|
|
|
Read32ipLeaveip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
value = stack.pop();
|
2004-04-07 06:57:37 +00:00
|
|
|
if (!value) {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
ip += 4;
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_SKIPONTRUE: %d (IS FALSE (NOT SKIPPED))", parameter);
|
|
|
|
} else {
|
2003-12-14 16:33:27 +00:00
|
|
|
ip += parameter;
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_SKIPONTRUE: %d (IS TRUE (SKIPPED))", parameter);
|
|
|
|
}
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case CP_SKIPONFALSE:
|
|
|
|
// Skip if the value on the stack is false
|
|
|
|
Read32ipLeaveip(parameter);
|
2008-12-29 11:55:09 +00:00
|
|
|
value = stack.pop();
|
2004-04-07 06:57:37 +00:00
|
|
|
if (value) {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
ip += 4;
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_SKIPONFALSE: %d (IS TRUE (NOT SKIPPED))", parameter);
|
|
|
|
} else {
|
2003-09-21 16:11:26 +00:00
|
|
|
ip += parameter;
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_SKIPONFALSE: %d (IS FALSE (SKIPPED))", parameter);
|
|
|
|
}
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case CP_SKIPALWAYS:
|
|
|
|
// skip a block
|
|
|
|
Read32ipLeaveip(parameter);
|
|
|
|
ip += parameter;
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_SKIPALWAYS: %d", parameter);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case CP_SWITCH:
|
2003-12-14 16:33:27 +00:00
|
|
|
// switch
|
2008-12-29 11:55:09 +00:00
|
|
|
value = stack.pop();
|
2003-09-21 16:11:26 +00:00
|
|
|
Read32ip(caseCount);
|
|
|
|
|
|
|
|
// Search the cases
|
2003-12-14 16:33:27 +00:00
|
|
|
foundCase = false;
|
2004-04-26 20:28:34 +00:00
|
|
|
for (i = 0; i < caseCount && !foundCase; i++) {
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
if (value == (int32)READ_LE_UINT32(code + ip)) {
|
2003-09-21 16:11:26 +00:00
|
|
|
// We have found the case, so lets
|
|
|
|
// jump to it
|
2003-12-14 16:33:27 +00:00
|
|
|
foundCase = true;
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
ip += READ_LE_UINT32(code + ip + 4);
|
2003-09-21 16:11:26 +00:00
|
|
|
} else
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
ip += 4 * 2;
|
2003-09-21 16:11:26 +00:00
|
|
|
}
|
|
|
|
|
2003-12-14 16:33:27 +00:00
|
|
|
// If we found no matching case then use the default
|
2003-09-21 16:11:26 +00:00
|
|
|
|
|
|
|
if (!foundCase)
|
|
|
|
ip += READ_LE_UINT32(code + ip);
|
|
|
|
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_SWITCH: [SORRY, NO DEBUG INFO]");
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case CP_SAVE_MCODE_START:
|
|
|
|
// Save the start position on an mcode instruction in
|
|
|
|
// case we need to restart it again
|
|
|
|
savedStartOfMcode = ip - 1;
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_SAVE_MCODE_START");
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case CP_CALL_MCODE:
|
|
|
|
// Call an mcode routine
|
2003-09-21 16:11:26 +00:00
|
|
|
Read16ip(parameter);
|
2006-09-09 10:47:32 +00:00
|
|
|
assert(parameter < _numOpcodes);
|
2003-12-14 16:33:27 +00:00
|
|
|
// amount to adjust stack by (no of parameters)
|
|
|
|
Read8ip(value);
|
2006-09-09 10:29:14 +00:00
|
|
|
debug(9, "CP_CALL_MCODE: '%s', %d", _opcodes[parameter].desc, value);
|
2010-05-06 19:00:39 +00:00
|
|
|
|
|
|
|
// The scripts do not always call the mcode command
|
|
|
|
// with as many parameters as it can accept. To keep
|
2011-05-25 15:17:11 +00:00
|
|
|
// things predictable, initialize the remaining
|
2010-05-06 19:00:39 +00:00
|
|
|
// parameters to 0.
|
|
|
|
|
|
|
|
for (i = STACK_SIZE - 1; i >= value; i--) {
|
|
|
|
opcodeParams[i] = 0;
|
|
|
|
}
|
|
|
|
|
2008-12-29 11:55:09 +00:00
|
|
|
while (--value >= 0) {
|
|
|
|
opcodeParams[value] = stack.pop();
|
|
|
|
}
|
2010-05-06 19:00:39 +00:00
|
|
|
|
2008-12-29 11:55:09 +00:00
|
|
|
retVal = (this->*_opcodes[parameter].proc)(opcodeParams);
|
2003-12-14 16:33:27 +00:00
|
|
|
|
|
|
|
switch (retVal & 7) {
|
|
|
|
case IR_STOP:
|
|
|
|
// Quit out for a cycle
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
WRITE_LE_UINT32(offsetPtr, ip);
|
2003-12-14 16:33:27 +00:00
|
|
|
return 0;
|
|
|
|
case IR_CONT:
|
|
|
|
// Continue as normal
|
|
|
|
break;
|
|
|
|
case IR_TERMINATE:
|
2007-12-16 00:41:30 +00:00
|
|
|
if (checkPearlBug && readVar(1290) == 0) {
|
|
|
|
// Pearl's interaction script will wait
|
|
|
|
// until global(1290) is no longer 0
|
|
|
|
// before doing anything. But if the
|
|
|
|
// script was terminated prematurely,
|
|
|
|
// that never happens.
|
|
|
|
warning("Working around Pearl bug: Resetting Pearl's state");
|
|
|
|
writeVar(1290, 1);
|
|
|
|
}
|
2003-12-14 16:33:27 +00:00
|
|
|
// Return without updating the offset
|
|
|
|
return 2;
|
|
|
|
case IR_REPEAT:
|
|
|
|
// Return setting offset to start of this
|
|
|
|
// function call
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
WRITE_LE_UINT32(offsetPtr, savedStartOfMcode);
|
2003-12-14 16:33:27 +00:00
|
|
|
return 0;
|
|
|
|
case IR_GOSUB:
|
|
|
|
// that's really neat
|
Applied my own patch #1341495, in an attempt to fix alignment issues
reported by Crilith.
To elaborate a bit, the engine no longer accesses resource data through
packed structs. Instead it uses memory streams and the READ/WRITE
functions.
If data is mainly read, not written, I have replaced the old struct with a
new one with a read() function to read the whole thing from memory into the
struct's variables, and a write() function to dump the struct's variables
to memory. In fact, most of these write() functions remain unused.
If data is both read and written, I have replaced the struct with a class
with individual get/set functions to replace the old variables. This
manipulates memory directly.
Since I'm fairly sure that these structs are frequently stored as local
variables for a script, all script variables (both local and global) are
stored as little-endian and accessed through the READ/WRITE functions,
rather than being treated as arrays of 32-bit integers.
On a positive note, the functions for doing endian conversion of resources
and save games have been removed, and some general cleanups have been made
to assist in the rewrite.
Initial reports indicate that this patch indeed fixes alignment issues, and
that I have not - surprisingly - broken the game on big-endian platforms.
At least not in any immediately obvious way. And there's still plenty of
time to fix regressions before 0.9.0, too.
svn-id: r19366
2005-10-29 21:24:54 +00:00
|
|
|
WRITE_LE_UINT32(offsetPtr, ip);
|
2003-12-14 16:33:27 +00:00
|
|
|
return 2;
|
|
|
|
default:
|
2006-09-09 10:29:14 +00:00
|
|
|
error("Bad return code (%d) from '%s'", retVal & 7, _opcodes[parameter].desc);
|
2003-12-14 16:33:27 +00:00
|
|
|
}
|
|
|
|
parameterReturnedFromMcodeFunction = retVal >> 3;
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case CP_JUMP_ON_RETURNED:
|
|
|
|
// Jump to a part of the script depending on
|
|
|
|
// the return value from an mcode routine
|
|
|
|
|
|
|
|
// Get the maximum value
|
|
|
|
Read8ip(parameter);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_JUMP_ON_RETURNED: %d => %d",
|
|
|
|
parameterReturnedFromMcodeFunction,
|
|
|
|
READ_LE_UINT32(code + ip + parameterReturnedFromMcodeFunction * 4));
|
2003-12-14 16:33:27 +00:00
|
|
|
ip += READ_LE_UINT32(code + ip + parameterReturnedFromMcodeFunction * 4);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-07-28 01:44:38 +00:00
|
|
|
|
2003-12-14 16:33:27 +00:00
|
|
|
// Operators
|
2003-09-20 12:43:52 +00:00
|
|
|
|
2003-12-14 16:33:27 +00:00
|
|
|
case OP_ISEQUAL:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a == b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_ISEQUAL: RESULT = %d", a == b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case OP_NOTEQUAL:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a != b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_NOTEQUAL: RESULT = %d", a != b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case OP_GTTHAN:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a > b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_GTTHAN: RESULT = %d", a > b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case OP_LSTHAN:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a < b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_LSTHAN: RESULT = %d", a < b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case OP_GTTHANE:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a >= b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_GTTHANE: RESULT = %d", a >= b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case OP_LSTHANE:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a <= b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_LSTHANE: RESULT = %d", a <= b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case OP_PLUS:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a + b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_PLUS: RESULT = %d", a + b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case OP_MINUS:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a - b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_MINUS: RESULT = %d", a - b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case OP_TIMES:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a * b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_TIMES: RESULT = %d", a * b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case OP_DIVIDE:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a / b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_DIVIDE: RESULT = %d", a / b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case OP_ANDAND:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a && b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_ANDAND: RESULT = %d", a && b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
2003-12-14 16:33:27 +00:00
|
|
|
case OP_OROR:
|
2008-12-29 11:55:09 +00:00
|
|
|
b = stack.pop();
|
|
|
|
a = stack.pop();
|
|
|
|
stack.push(a || b);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "OP_OROR: RESULT = %d", a || b);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
|
2003-12-14 16:33:27 +00:00
|
|
|
// Debugging opcodes, I think
|
|
|
|
|
|
|
|
case CP_DEBUGON:
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_DEBUGON");
|
2003-12-14 16:33:27 +00:00
|
|
|
break;
|
|
|
|
case CP_DEBUGOFF:
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_DEBUGOFF");
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
case CP_TEMP_TEXT_PROCESS:
|
|
|
|
Read32ip(parameter);
|
2004-04-07 06:57:37 +00:00
|
|
|
debug(9, "CP_TEMP_TEXT_PROCESS: %d", parameter);
|
2003-09-21 16:11:26 +00:00
|
|
|
break;
|
|
|
|
default:
|
2003-12-14 16:33:27 +00:00
|
|
|
error("Invalid script command %d", curCommand);
|
2009-09-24 17:52:53 +00:00
|
|
|
return 3; // for compilers that don't support NORETURN
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2003-09-20 12:43:52 +00:00
|
|
|
return 1;
|
2003-07-28 01:44:38 +00:00
|
|
|
}
|
2003-10-04 00:52:27 +00:00
|
|
|
|
|
|
|
} // End of namespace Sword2
|