Formerly, the behavior between when a drawable area was specified and when not
was different in a sense which is not expected. For example, when an empty
textDrawableArea was passed and the text could be drawn outside the 'area'
specified. While when a textDrawableArea covering the whole screen was passed
the text was clipped inside 'area'. Now, the code does follow the latter logic
in both cases.
I am not sure whether this will cause any issues, but a quick check of the
launcher and options menu didn't reveal anything...
This removes the two additional copy steps for rendering when a drawable text
area is specified. Instead it uses Surface::getSubArea to draw directly onto
_activeSurface.
This won't actually make any difference, since the fall through
would do nothing and then reach the break in the default case. But
I think it's less error-prone this way if the code is ever modified.
Formerly values in the gradient and blending code overflowed and thus caused
incorrect colors. Now there's some special case for 32bpp modes, which needs
slightly more operations but assures a correct output.
Formerly we assumed that the newly created surface has the same pitch as the
source surface. This is a assumption that might be invalid (for example in
case of the Surface returned by OSystem::lockScreen.)
Instead of a fixed 1/2 or 1/4 scaling we do a two step scaling now:
1) Scale image to width < 160*2 && height < [100,120]*2 with 1/4 or 1/2
nearest-neighbor.
2) Use a bilinear scaler to scale aspect preserving to 160x[100,120]
This fixes bug #3614568 "GRAPHICS: Odd thumbnail sizes crash".
This fixes future issues like bug #3614654:
"ALL: ScummVM 1.5.0 can't read newer saved games".
There are a few behavior changes introduced with this commit:
- checkThumbnailHeader will now also report the presence of
unsupported/broken (but skippable) headers.
- skipThumbnail will also try to skip the data for broken/unsupported
thumbnail data.
- loadThumbnail will skip over broken/unsupported thumbnail data but still
return 0 in this case.
Using plain "inline" instead of "FORCEINLINE" allows the compiler to continue
even when it fails to inline crossBlitLogic/crossBlitLogic3BppSource. The
impact of other systems now not inlining the functions anymore is hopefully
small enough to not cause any problems.
