This controls how fetched texels are combined with the color that was
produced by a preceding texture unit or with the vertex color if it is
the first texture unit.
Currently only a small subset of possible combine modes is implemented
as required by glquake.
This is an interesting quirk that occurs due to us using the x87 FPU
when Serenity is compiled for the i386 target. When we calculate our
depth value to be stored in the buffer, it is an 80-bit x87
floating point number, however, when stored into the DepthBuffer,
this is truncated to 32 bits. This 38 bit loss of precision means
that when x87 `FCOMP` is eventually used here the comparison fails.
This could be solved by using a `long double` for the depth buffer,
however this would take up significantly more space and is completely
overkill for a depth buffer. As such, comparing the first 32-bits of
this depth value is "good enough" that if we get a hit on it being
equal, we can pretty much guarantee that it's actually equal.
The previous clipping implementation was problematic especially when
clipping against the near plane. Triangles are now correctly clipped
using homogenous coordinates against all frustum planes.
Texture coordinates and vertex colors are now correctly interpolated.
The earier implementation was just a placeholder.
This extracts the sampler functionality into its own class.
Beginning with OpenGL 3 samplers are actual objects, separate
from textures. It makes sense to do this already as it also
cleans up code organization quite a bit.
The Context and Software Rasterizer now gets the array of texture units
instead of a single texture object. _Technically_, we now support some
primitive form of multi-texturing, though I'm not entirely sure how well
it will work in its current state.
Textures are now initialized with a nullptr upon generation.
They are only actually created once they are bound to a target.
Currently only the GL_TEXTURE_2D target is supported.
The software rasterizer now allows rendering with or without
a bound TEXTURE_2D.
The software rasterizer now samples a texture passed to us from the
GL context. This is currently a bit of a hack, as we should be
scanning from a list of texture units and checking if they are
enabled. For now, this at least gives some visual confirmation
that texturing is working as it should
This implements different blend modes in the SoftwareRasterizer by
first setting up the blend factors then rendering the pixels into a
temporary buffer and finally mixing the contents of the temporary buffer
with the contents of the backbuffer based on the blend factors.
This untangles several concepts in the rasterizer and makes it possible
to toggle different stages on a per-block level rather than having to
check whether the feature is enabled for every pixel.
This makes the software rasterizer use integers for triangle coverage
calculations. The previously used floating point algorithm was not
precise enough in certain situations and showed gaps between triangles.
This is not yet subpixel accurate.
Tests against and writes to the depth buffer when GL_DEPTH_TEST is
enabled via glEnable(). Currently fragment z is always compared against
existing depth with GL_LESS.
This is based mostly on Fabian "ryg" Giesen's 2011 blog series
"A trip through the Graphics Pipeline" and Scratchapixel's
"Rasterization: a Practical Implementation".
The rasterizer processes triangles in grid aligned 16x16 pixel blocks,
calculates barycentric coordinates and edge derivatives and interpolates
bilinearly across each block.
This will theoretically allow for better utilization of modern processor
features such as SMT and SIMD, as opposed to a classic scanline based
triangle rasterizer.
This serves as a starting point to get something on the screen.
In the future we might look into properly pipelining the main loop to
make the rasterizer more flexible, enabling us to enable/disable
certain features at the block rather than the pixel level.
