[Scummvm-devel] copyRectToScreen clipping
max at quendi.de
Sun Nov 6 10:57:15 CET 2005
Am 06.11.2005 um 17:53 schrieb Joost Peters:
> In the SDL (and most other) backend(s) the x/y/w/h parameters that
> are passed to copyRectToScreen() are clipped.
> Can anyone tell me why this clipping isn't done inside the engine?
> (And maybe additionally assert the values are sane in the backend)
> I'm bringing this up as this seems to be a common pitfall for ports.
> Some scenes in Full Throttle are calling copyRectToScreen with
> negative values, e.g. the gas tower cutscene calls copyRectToScreen
> () with x: 24, y: 246, w: 8, h: -46.
> The OSystem documentation for copyRectToScreen() doesn't say
> anything about performing clipping.
> Obviously, when no clipping is performed this will trash random
> It took me some time to track this down on the PSP, and now it
> seems the DC port suffers from the same problem, see: http://
> So I'm proposing we either do the check somewhere where all
> backends benefit from it (inside the engine?), or atleast update
> the OSystem documentation to mention that clipping of the input
> needs to be done.
either approach is fine by me; but of course you are right, we should
document precisely which one backends have to do.
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,
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?
More information about the Scummvm-devel