[Scummvm-cvs-logs] SF.net SVN: scummvm:[45303] scummvm/trunk/engines/sci/engine/vm.cpp

[fingolfin at users.sourceforge.net]

Revision: 45303
          http://scummvm.svn.sourceforge.net/scummvm/?rev=45303&view=rev
Author:   fingolfin
Date:     2009-10-21 10:00:08 +0000 (Wed, 21 Oct 2009)

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

Modified Paths:
--------------
    scummvm/trunk/engines/sci/engine/vm.cpp

Modified: scummvm/trunk/engines/sci/engine/vm.cpp
===================================================================
--- scummvm/trunk/engines/sci/engine/vm.cpp	2009-10-21 09:59:18 UTC (rev 45302)
+++ scummvm/trunk/engines/sci/engine/vm.cpp	2009-10-21 10:00:08 UTC (rev 45303)
@@ -145,25 +145,28 @@
 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)) {
 
-		// This code is needed to work around a probable script bug, or a 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
-		// original interpreter, the new actor is loaded in the same memory location as the old
-		// one, therefore the client variable in the stopGroop object points to the new actor.
-		// This is probably why the reference of the stopGroop object is never updated (which
-		// is why I mentioned that this is either a script bug or some kind of limitation).
-		// In our implementation, each new object is loaded in a different memory location, and
-		// we can't overwrite the old one. This means that in our implementation, 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)
+		// WORKAROUND: This code is needed to work around a probable script bug, or a
+		// 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 original interpreter, the new actor is loaded in the same memory
+		// location as the old one, therefore the client variable in the stopGroop object
+		// points to the new actor. This is probably why the reference of the stopGroop
+		// object is never updated (which is why I mentioned that this is either a script
+		// bug or some kind of limitation).
+		//
+		// In our implementation, each new object is loaded in a different memory location,
+		// and we can't overwrite the old one. This means that in our implementation,
+		// 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
 			reg_t stopGroopPos = segMan->findObjectByName("stopGroop");
 			if (!stopGroopPos.isNull()) {	// does the game have a stopGroop object?
 				// 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
 				ObjVarRef varp;
 				if (lookup_selector(segMan, stopGroopPos, kernel->_selectorCache.client, &varp, NULL) == kSelectorVariable) {


This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site.