[Scummvm-devel] copyRectToScreen clipping

LavosSpawn lavosspawn at scummvm.org
Tue Nov 8 03:31:37 CET 2005


I ran into the same problem with the PS2 port.
I think we should add a warning to the SDL backend when it receives invalid 
arguments and turn that into an assert() when the places where this occurs 
are fixed.
But of course I have no idea how difficult it is to track this problem down 
in the scumm engine, so maybe I'm too optimistic here :)


----- Original Message ----- 
From: "Joost Peters" <joostp at 7fc1.org>
To: "Max Horn" <max at quendi.de>
Cc: <scummvm-devel at lists.sourceforge.net>
Sent: Monday, November 07, 2005 2:12 AM
Subject: Re: [Scummvm-devel] copyRectToScreen clipping


> Hi Max,
>
>> Personally, I'd tend to augment the OSystem API specs to explicitly 
>> state that clipping has to be performed. This way incorrect usage  won't 
>> lead to crashes, ever, even in new engines, or if  copyRectToScreen usage 
>> is changed in an existing engine. I prefer  this defensive style of 
>> coding (and the performance penalty should be  close to zero, compared to 
>> the time the blitting itself takes,  shouldn't it?).
>
> Sure, I agree, they should always be checked by the backend.
> The point up for debate is *how*; i.e whether the backend should 
> gracefully handle such violations by silently adjusting the parameters (as 
> it does now), or should error out with a failed assertion, helping expose 
> such 'bugs' in the engines.
>
> Personally I'm in favour of the last option, simply because of the added 
> 'free' debugging/testing functionality.
>
> Anyone else have an opinion on this? :)
>
>> At the same time, though, I'd still be interested in tracking down  why 
>> FT uses a negative height in copyRectToScreen. Out of curiosity,  can you 
>> tell me which copyRectToScreen invocation is the one leading  to the 
>> crash?
>
> It's the bottom call in ScummEngine::drawStripToScreen (a more complete 
> backtrace attached below[1]).
> Quickly looking at the code tells me it does atleast some checking, but 
> obviously not enough.
>
> To reproduce: use bootparam 360, pick the lock, touch the ladder and hide 
> in the shadow. The resulting cutscene will make these calls after the 
> first line of dialogue ("Remain where you--").
>
>
> Regards,
> Joost
>
>
>
> [1]:
>
> #6  0x0804d608 in OSystem_SDL::copyRectToScreen (this=0x8414f10,
>     src=0x8455e00 '\024' <repeats 21 times>, ",,,c=`\031", '\024' <repeats 
> 20 times>, "\032\032\032\032\032\032*", '\032' <repeats 13 times>, "\036", 
> '\032' <repeats 28 times>, "\031o", '\030' <repeats 16 times>, "mm", 
> '\032' <repeats 36 times>, '\030' <repeats 19 times>, '\024' <repeats 28 
> times>..., pitch=320, x=40, y=246, w=8, h=-46)
>     at backends/sdl/graphics.cpp:801
> #7  0x080d4c9a in Scumm::ScummEngine::drawStripToScreen (this=0x842a618, 
> vs=0x84362fc, x=40, width=8, top=246,
>     bottom=276) at scumm/gfx.cpp:589
> #8  0x080d4d50 in Scumm::ScummEngine::updateDirtyScreen (this=0x842a618, 
> slot=Scumm::kMainVirtScreen)
>     at scumm/gfx.cpp:497
> #9  0x080d6324 in Scumm::ScummEngine::drawDirtyScreenParts 
> (this=0x842a618) at scumm/gfx.cpp:434
> #10 0x080d78db in Scumm::ScummEngine_v6::drawDirtyScreenParts 
> (this=0x842a618) at scumm/gfx.cpp:463
> #11 0x0805c764 in Scumm::ScummEngine::scummLoop (this=0x842a618, delta=6) 
> at scumm/scumm.cpp:2503
> #12 0x0805ca03 in Scumm::ScummEngine::go (this=0x842a618) at 
> scumm/scumm.cpp:2205
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Scummvm-devel mailing list
> Scummvm-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/scummvm-devel
> 





More information about the Scummvm-devel mailing list