[Scummvm-devel] Re: ScummVM

[Max Horn]

Am 07.03.2005 um 00:31 schrieb Travis Howell:

> In the past (scumm/resource.cpp revision 1.93) you made findResource() 
> and findResourceData() constant in ScummVM, was there any particular 
> requirement for this change and would it be ok to change back ? some 
> of the WizImage functions used by HE games need to alter the data. 
> Check the commented out code in fillWizRect() of scumm/wiz_he.cpp for 
> example, there are several other cases too (Which have not been 
> commited yet).

It would be possible to change it back -- there is no fundamental 
technical issue prompting it to return read-only data.

However, the way those methods are intended, you should never have to 
write to data they return. It's more an API design decision than 
anything else. The only place where the old code (before my change) 
ever needed to write into this data was with the old code used to 
changing Scumm object names -- that code directly hacked the object 
resources, like the original engines did. Well, it was already a bad 
evil hack when they did it back then (and it forced them to re-do the 
name change whenever the room was reloaded, because these changes were 
of course not persistent). I think it's no coincidence that in V6, they 
introduced the object name resource to avoid this hack (and we 
basically use the same technique now to avoid it in V1-V5 games, too).

If you want to write to data returned by findResource() / 
findResourceData(), then if I were you, I'd first question my design 
and wonder: "Why do I have to do this? Do I really need to, or is there 
another way?" Normally, you should only ever have to write to resource 
data you created yourself (using createResource()), in which case you 
already have a writeable pointer to the data anyway...

Of course it's possible that in the HE games, this rule was changed, in 
which case we could adapt. But I'd like to first learn a bit more as to 
why exactly the change is required, i.e. what feat do you need to 
accomplish? Maybe we can think of an alternate solution...



Cheers,

Max