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.
