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

Max Horn max at quendi.de
Tue Feb 28 00:41:07 CET 2006


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 :-).

In this particular case, it took me five minutes to do so, by first  
surfing to <https://svn.sourceforge.net/viewcvs.cgi/scummvm/scummvm/ 
trunk/engines/scumm/script_v5.cpp?view=log>, then to <https:// 
svn.sourceforge.net/viewcvs.cgi/scummvm/scummvm/trunk/engines/scumm/ 
script_v5.cpp?annotate=20795>, then to <https://svn.sourceforge.net/ 
viewcvs.cgi/scummvm/scummvm/trunk/engines/scumm/script_v5.cpp? 
view=diff&r1=9649&r2=9650>

And then looking at the commit message for revision 9650 to find out  
who did the change and why... eriktorbjorn in this case.


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.

Maybe it is obsolete now, maybe not -- but by removing the whole  
comment, you are deleting our reference to the problem completely.  
Until we are sure it causes no regressions, I would recommend that we  
at least leave a note in place saying that sometimes actor 0 is used  
there and that we need to verify whether that causes any issues.


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 :-).


Cheers,
Max
(who always preferred the eyeball & think RE strategy over  
disassembling anyway, partially due to the lack of a disassembler,  
partially due to the increased challenge *g*).





More information about the Scummvm-devel mailing list