SCI: Fix warning, and reformat a multi-line comment

svn-id: r45303
This commit is contained in:
Max Horn 2009-10-21 10:00:08 +00:00
parent 745be029b2
commit 1e8883dccc

View file

@ -145,25 +145,28 @@ static reg_t validate_read_var(reg_t *r, reg_t *stack_base, int type, int max, i
static void validate_write_var(reg_t *r, reg_t *stack_base, int type, int max, int index, int line, reg_t value, SegManager *segMan, Kernel *kernel) { static void validate_write_var(reg_t *r, reg_t *stack_base, int type, int max, int index, int line, reg_t value, SegManager *segMan, Kernel *kernel) {
if (!validate_variable(r, stack_base, type, max, index, line)) { if (!validate_variable(r, stack_base, type, max, index, line)) {
// This code is needed to work around a probable script bug, or a limitation of the // WORKAROUND: This code is needed to work around a probable script bug, or a
// original SCI engine, which can be observed in LSL5. // limitation of the original SCI engine, which can be observed in LSL5.
// In some games, ego walks via the "Grooper" object, in particular its "stopGroop" child. //
// In LSL5, during the game, ego is swapped from Larry to Patti. When this happens in the // In some games, ego walks via the "Grooper" object, in particular its "stopGroop"
// original interpreter, the new actor is loaded in the same memory location as the old // child. In LSL5, during the game, ego is swapped from Larry to Patti. When this
// one, therefore the client variable in the stopGroop object points to the new actor. // happens in the original interpreter, the new actor is loaded in the same memory
// This is probably why the reference of the stopGroop object is never updated (which // location as the old one, therefore the client variable in the stopGroop object
// is why I mentioned that this is either a script bug or some kind of limitation). // points to the new actor. This is probably why the reference of the stopGroop
// In our implementation, each new object is loaded in a different memory location, and // object is never updated (which is why I mentioned that this is either a script
// we can't overwrite the old one. This means that in our implementation, whenever ego is // bug or some kind of limitation).
// changed, we need to update the "client" variable of the stopGroop object, which points //
// to ego, to the new ego object. If this is not done, ego's movement will not be updated // In our implementation, each new object is loaded in a different memory location,
// properly, so the result is unpredictable (for example in LSL5, Patti spins around instead // and we can't overwrite the old one. This means that in our implementation,
// of walking) // whenever ego is changed, we need to update the "client" variable of the
// stopGroop object, which points to ego, to the new ego object. If this is not
// done, ego's movement will not be updated properly, so the result is
// unpredictable (for example in LSL5, Patti spins around instead of walking).
if (index == 0 && type == VAR_GLOBAL) { // global 0 is ego if (index == 0 && type == VAR_GLOBAL) { // global 0 is ego
reg_t stopGroopPos = segMan->findObjectByName("stopGroop"); reg_t stopGroopPos = segMan->findObjectByName("stopGroop");
if (!stopGroopPos.isNull()) { // does the game have a stopGroop object? if (!stopGroopPos.isNull()) { // does the game have a stopGroop object?
// Notify the stopGroop object that Ego changed // Notify the stopGroop object that Ego changed
Object *stopGroopObj = segMan->getObject(stopGroopPos); //Object *stopGroopObj = segMan->getObject(stopGroopPos);
// Find the "client" member variable, and update it // Find the "client" member variable, and update it
ObjVarRef varp; ObjVarRef varp;
if (lookup_selector(segMan, stopGroopPos, kernel->_selectorCache.client, &varp, NULL) == kSelectorVariable) { if (lookup_selector(segMan, stopGroopPos, kernel->_selectorCache.client, &varp, NULL) == kSelectorVariable) {