The two properties that control pixel packing and the size of the
surface need to be preserved for loadStream() to work correctly.
They are now under complete responsibility of the client.
This decoder needs to keep track of client parameters that control
how the pixels are going to be packaged, so the responsibility for
clearing the state has been moved on the client (using the destroy()
method on ImageDecoder).
As no client uses the IFFDecoder for more than one image at a time,
this change does not require updates to the engines. The only effect
is on Parallaction (BRA-Amiga), which can now control the way pixels
are packaged in mask and path bitmaps.
The default at cursor construction has been set to not visible.
This now requires an explicit call to setVisible(true) to show the
cursor, but a basic test shows that this seems to be OK and engines
which fail to do this would have been intermittently broken before.
This fixes loading of JPEG files which contain RGB color space instead of YUV.
It is a pretty odd extension of JPEG files by Adobe which is indicated by this:
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/JPEG.html#Adobe
To still support Groovie's need for YUV data I added some possibility to
request direct YUV output.
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.
Alyssa Milburn
Matthew Hoops
peres
Willem Jan Palenstijn
D G Turner
RichieSams
Johannes Schickel
Johannes Schickel
Eugene Sandulenko
Torbjörn Andersson
Narek Mailian