These issues were identified by the STACK tool.
By default, the C++ new operator will throw an exception on allocation
failure, rather than returning a null pointer.
The result is that testing the returned pointer for null is redundant
and _may_ be removed by the compiler. This is thus optimization
unstable and may result in incorrect behaviour at runtime.
However, we do not use exceptions as they are not supported by all
compilers and may be disabled.
To make this stable without removing the null check, you could qualify
the new operator call with std::nothrow to indicate that this should
return a null, rather than throwing an exception.
However, using (std::nothrow) was not desirable due to the Symbian
toolchain lacking a <new> header.
A global solution to this was also not easy by redefining "new" as "new
(std::nothrow)" due to custom constructors in NDS toolchain and various
common classes.
Also, this would then need explicit checks for OOM adding to all new
usages as per C malloc which is untidy.
For now to remove this optimisation unstable code is best as it is
likely to not be present anyway, and OOM will cause a system library
exception instead, even without exceptions enabled in the application
code.
The original alpha computation formula had a problem: If something was
drawn on top of a pixel that was already fully opaque, there would be
an overflow in the computed alpha, and the destination alpha would be
truncated to 0 (fully transparent).
In commit 264ba4a9 this formula was replaced with another one, which
did not have overflows but also was not correct.
This commits introduces a new formula, where the rounding errors have
been turned in another direction; drawing a fully opaque pixel on top
of a transparent one would result in a pixel which is almost, but not
fully, opaque. However, this is no problem in practice, since drawing
fully opaque pixels can be achieved with much less code as a special
case, so add that (also improves rendering speed).
The old computation had rounding issues, causing alpha to leak into
the red (usually) component. There's a much easier way to compute it
that does not lead to such problems: What should really happen is that
the two top bits of the A component should be set to 1 (thus adding
75% alpha). So compute it that way for speed and precision.
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.
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.
It gains 35% on the first function of the profiling on Indy IV
It is now nearly memory-bound (~10%) so it might not be needed to schedule the code better than this
This matches the documentation, information from the PNG bug tracker and the
behavior of example decoders off the net. It fixes warnings thrown from the PNG
decoder
This allows any 2Bpp/4Bpp Surfaces to be written via saveThumbnail
and loadThumbnail now. It furthermore will preserve the loaded Surface
in loadThumbnail.
All uses of the old target scale API actually wanted to disallow scaling of
the mouse cursor. This commit adapts our API to this and thus simplifies
backend implementations.
Some backends, most notable the Wii and Android, did some implementation of
the cursor target scale, which I didn't adapt yet. I added a TODO for the
porters there.
The BMP decoder getPalette function definition is now identical to
the other image format decoders subclassed from ImageDecoder.
This also fixes a overloaded virtual warning reported by salty-horse.
The stroke effect isn't properly implemented yet since it isn't used
in the modern theme.
There are slight bleeding colours around the corners of the
tab_background when its corners overlap with the corners of the
underlying dialog. These are hard to avoid because the underlying dialog
destroys the background that we should be blending these corners with.
This fixes bleeding of colours between different regions.
It also turns 'bevel' into an option that turns the stroke into a bevel,
and implements antialiased gradient-fills.
find -name '*.h' -or -name '*.cpp' | xargs sed -r -i 's@\(([A-Za-z0-9]+)\*\)@(\1 *)@g'
This seems to have caught some params as well which is not undesirable IMO.
It also caught some strings containing this which is undesirable so I
excluded them manually. (engines/sci/engine/kernel_tables.h)
On some systems, passing signed chars to macros like isspace() etc. lead
to a runtime error. Hence, mark these macros as forbidden by default,
and introduce otherwise equivalent alternatives for them.
The charsets used by the translations now need to have a "$(name).cp" file,
which contains an charset index => unicode mapping. Otherwise
create_translations will fail.
This adapts the related graphics code, which is the generic Font API and the
TTF font implementation.
It furthermore adapts the GUI to properly take care of kerning in text input
widgets.
Now we set the default localized font to the "text_default" font of the
currently active theme and default to the big GUI font in case none is
specified properly.
This fixes the crash, but the Midi Gain slider (and probably any other
slider bar in modern theme) still distorts the left corner shape when
the slider thumb is at very small values...
