[Scummvm-cvs-logs] CVS: scummvm/scumm string.cpp,1.96,1.97

Max Horn max at quendi.de
Tue Apr 8 12:33:06 CEST 2003


Am Dienstag, 08.04.03 um 18:32 Uhr schrieb Jonathan Gray:

>
>
> On Tue, 8 Apr 2003, Max Horn wrote:
>
>>
>> Am Dienstag, 08.04.03 um 01:31 Uhr schrieb Jonathan Gray:
>>
>>> Update of /cvsroot/scummvm/scummvm/scumm
>>> In directory sc8-pr-cvs1:/tmp/cvs-serv10043
>>>
>>> Modified Files:
>>> 	string.cpp
>>> Log Message:
>>> remove old fixme that seemingly isn't needed anymore. note this
>>> triggers an assertion in zak when text is used for some strange
>>> reason, but should make indy3/zak256 strings look normal again
>>>
>>
>> If this triggers an assertion in Zak256, then why did you just remove
>> it ??? Why not keep it, but change the check to be specific for 
>> Zak256 ?
>>
>
> Here's the deal..
> originaly the fonts were the wrong way around for indy3 and zak256
> ie 0 was 1 and 1 was 0. The line I removed was one I added a long time 
> ago
> to make it show the right fonts, said line was a hack.
>
> I noticed indy3 and zak where showing the wrong font so the hack has
> became uneeded. Even if I put a zak specific hack there the text would
> still be the wrong font compared to what it was in the original and
> 0.3.0b.
>
> What I was hoping was that we could get rid of the hack.
>
> If the hack goes back in then the other code that is obviously 
> affecting
> this is going to have to change.
>

The point is: you wrote "this triggers an assertion". So, I read that 
as "before my change Zak worked, albeit with a wrong font, now it 
crashes". If you meant something else, please clarify it, otherwise 
this change is bad, and at least for Zak256 the hack should be readed 
(with an "if (ZAK)" of course, and a FIXME comment), so that Zak256 is 
at least playable...



Max





More information about the Scummvm-git-logs mailing list