So caller does not have to depend on the pixel format used internally to
BlitImage.
Update callers which do request for color keying (GRIM/EMI only).
Also, remove a special-casing of transparent color when converting image
format which sets a color in a packed format independent from actual
destination format.
Also, in GfxTinyGL::createTextObject, prefer changing invisible colorKey
value than actually-visible color.
Scissor operations happen in a 2d rectangle, but it used to take a buffer
offset as a parameter. As a result, it had to divide that value with its
width, which is an expensive operation, which has to be done for each
pixel candidate for display (even before z-buffer comparison when
applicable, in current implementatoin).
But callers actually generate the buffer offset from rectangular
coordinates, so propagate these instead.
This sadly increases API redundancy, but saves a lot of time in a very
frequent occurrence (especially when enabling dirty rect mechanism,
which is not yet enabled by default).
drawLine was broken for dx = 0 lines.
Also, the split between fillLineGeneric and drawLine, along with the many
parameters exchanged (with obscure names with subtle differences), made
the code hard to understand.
This implementation should be easier to check.
There was no visible CPU usage change.
Fixes GRIM's ticket printer, which are composed of a lot of vertical
segments.
Normalising d when light is not in front of surface (nor behind when in
two-sides mode) is not needed as the value will not be used.
The same optimisation is already done when handling specular lights.
Also, remove "if (... > 1E-3)" conditions: as dot-product is not zero,
neither operand is zero, so this test (as a divide-by-zero protection) can
be removed.
Because writePixel may decide to not write anything (alpha test), in which
case no z-buffer write should happen.
Factorises code.
Fixes apparent back-face culling in GRIM behind transparent textures, like
the tube (the 3d-shape Manny takes out, not the flat image in foreground)
in set mo.
In all 4 updateTmp call places, q is not initialised, so there is nothing
of value in the alpha channel (it's 0). So just apply the same rule as for
other color channels.
As per OpenGL specifications, light 0 is the only light with full diffuse and
specular light initial state. This should not affect residualvm as all enabled
light properties are configured.
So that dot-product result (used for attenuation) is between -1 and 1.
This should make no difference for GRIM: as far as I can see, all
direction vectors are already normalized in data files.
As per OpenGL specifications:
The spot direction is transformed by the upper 3x3 of the modelview
matrix when glLight is called, and it is stored in eye coordinates.
Linking TinyGL and OpenGL into the same binary could cause conflicts
because both have a glColor3fv function.
It is currently not used in ResidualVM, so it is safe to change this.
