When kLightsMode (aka kInterpRGB) is false, "a" is always 0 (vertice data is
not used in caller in corresponding branches), so taking it into account makes
all triangles transparent.
This is not visible in practice, because putPixelTextureMappingPerspective is
only called when (kInterpST || kInterpSTZ) is true, and kInterpRGB is always
true when that's the case. But unifying color processing allows further code
simplification.
This reverts commit b8bddf64da.
Since 9b7548ccf7, alpha test is enabled
when drawing model faces, fixing transparency issues in GRIM which were
corrected by reverted commit.
It is incorrect to test transparency when caller did not enable it.
Also, this change bypasses increments done at the end of
putPixelTextureMappingPerspective, so transparent textures in 16 bits mode
would be stuck on the transparent pixel for the current line's 8-pixel run
in filTriangle, and would ignore z coordinate.
Increment y inside the loop, not outside.
Set y to the topmost vertex y coordinate, which depends on which half of
the triangle is being drawn.
Should have been part of:
commit 3c2689a65f
TINYGL: Optimise scissorPixel.
This does not (should not) fix any visible regression, as pixel scissor is
only (?) used when dirty rectangle mecanism is enabled (and it is disabled).
This method is used to blit large buffers, so a large unrolling is still
beneficial. As it is the second hottest-spot in grim, the frame rate
increase is most significant there (compared to emi).
It is possible to convert calls to memset_{s,l} into call to memset when
all bytes of the depth or color value are the same (which is the likely
case), improving buffer clearing speed.
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.
Vincent Pelletier
Paweł Kołodziejski