For some reason, loadData hardcodes a pixel format.
At least avoid duplicating it in Line constructor.
Likewise, avoid duplicating access to framebuffer's pixel format when
constructing a Line from another.
Also, avoid over-allocating Line, as its size argument is counted in pixel,
not in bytes.
I based ARGB scaling on ST scaling without giving it enough thought.
It accidentally uncovered an older bug in glopClear, which made me recheck
these formulas.
ST scaling maps [0.0, 1.0] to [0x01.0000, 0xff.0000], meaning the first and
last texture rows and columns are never shown.
Treating s and t as proportions of ST_MAX fixes this by mapping to
[0x00.0000, 0xff.fffc] (last two fractional bits being off-precision, as
there are only 14 bits), covering the whole available range.
These shifts are now handled in zline (only user of this macri),
consistently with ztriangle.
I have removed this macro from my working copy, but I missed the breakage
while resolving the conflict.
Before this change vertex data (post-shading) was limited to 6 (green) or
5 (all others) bits of precision.
Interpolation happened with 8-bits precision, so the visual effect is
minor: about 4 off at vertices.
As in ztriangle, vertex color must be shifted from internal 16-bits
fixed-point format to 8-bits colors.
To do so, define values similar to the ones describing for ST fixed-point
format.
Also, use these in tglClear instead of hard-coded multiplicands, as is
done in tglColor4f and gl_transform_to_viewport.
Also, make tglClear take into account requested clear depth.
Replace local implementation by always setting GLVertex zp property.
Replace pointInsideVolume by clip_code, allowing to properly handle
polygons whose vertices are all off-screen but still have a part visible.
Also, replace 2-pixels offset with a more accurate bounding box
computation.
As per Common::Rect data model, right and bottom border are excluded, so:
- Make FrameBuffer::scissorPixel reject bottom & right borders.
- Update bounding rectangle definition for dirty rectangle operations
ClearBufferDrawCall::getDirtyRegion is already correct.
- zblit was almost following, except for an off-by-one mistake.
It is common that the same number of calls are done in the same order, so
do not stop comparing after the first divergence. This saves a significant
number of dirty rectangle in crowded scenes, like sets cn and bi where a few
calls may differ in the middle of call sequence, but later calls would stay
the same.
As a consequence, move current-frame-has-fewer-calls handling to its own
loop.
Also, factorise and extend code appending dirty rectangles.
Also, skip conseutive identical rectangles.
When dirty rectangles are enabled, fixes drawing outside (below) set scissor
rectangle.
y and pp1 must stay consistent for scissor testing to be relevant. y is
already incremented along with pp1, and pp1 does not get re-assigned on
part == 2, so do not set y either.
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.
Vincent Pelletier
Paweł Kołodziejski