[Scummvm-devel] Re: [Scummvm-cvs-logs] SF.net SVN: scummvm: [20967] scummvm/trunk/engines/scumm/script_v5.cpp

[Travis Howell]

From: "Max Horn" <max at quendi.de>
> Am 28.02.2006 um 02:14 schrieb kirben at users.sourceforge.net:
>
>> Revision: 20967
>> Author:   kirben
>> Date:     2006-02-27 17:14:02 -0800 (Mon, 27 Feb 2006)
>> ViewCVS:  http://svn.sourceforge.net/scummvm?rev=20967&view=rev
>>
>> Log Message:
>> -----------
>> These zakTowns specific changes aren't explained and don't match 
>> original code. If problems still occur, add bug reports with details.
>
>
> You are right, this could have been documented better, but: Please, 
> folks, use the "blame" feature of subversion next time to find out  who 
> made a given change and why, and then ask those people about it  -- that's 
> often more useful than just removing it, although it means  a little bit 
> more work for you :-).

Actually I did look through the commit logs but as you later noticed, the 
only issue referenced in the logs, had been fixed long ago. Even further 
back an actor number of 0 in o5_actorOps() was just ignored completely.

> So, all SCUMM games have one-based indexing for most stuff, including 
> actors. Still, some old games access actor 0. We have discovered that  at 
> least some of them use this to store "default" values. We still  print out 
> a debug() message when actor 0 is accessed, in fact.
>
> IIRC, some data for actor 0 was accessed in other parts of Zak256,  code 
> that works differently in ScummVM, and for that reason we added  this 
> (entirely ScummVM specific, as you noticed) mapping into that  particular 
> opcode.

The original and enhanced versions of Maniac Mansion and Zak McKracken used 
the talkColor of actor 0, when displaying any printed message from an actor 
 > 127. So basically this it normal for SCUMM 1 - 2 engines.
In the case of the FM Towns versions of Zak McKracken, it is another script 
bug, they failed to update all the scripts correctly. In a couple of 
scripts, the talkColor is still set for actor 0, instead of the string 
color, when printing message for actor > 127. But it makes no visual 
difference either way under ScummVM at the moment.

> Moral of the story: Improving our engine based on disassembly has its 
> advantages (and I am very grateful for cyx, Kirben and anybody else  doing 
> that currently), but we do some things differently on purpose,  and you 
> can't see that by just looking at the disassembly. Which is  why it's 
> important that all WORKAROUNDs etc. get documented properly,  but which 
> also means that one shouldn't always blindly trust the  disassembly :-).

Yes, I try to be careful of ScummVM specific differences, when adding 
corrections from original disassembly of games. The original disassembly is 
often helpful for finding if issues in SCUMM engine are scripts bugs too, as 
it shows places where additional checks or code should usually not be 
required.