The `ClipPlane` enum is being looped over at run-time performing
run-time dispatch to determine the comparison operation in
`point_within_clip_plane`.
Change this `for` loop to be linear code which dispatches using a
template parameter. This allows for the `point_within_clip_plane`
function to do compile-time dispatch.
Note: This linear code can become a compile-time loop when static
reflection lands in C++2[y|z] allowing looping over the reflected
`enum class`.
The clipping logic is not DRY (Don't Repeat Yourself). The same logic
is repeated in multiple parts of an `if-else` statement. This can be
simplified to contain fewer branches and eliminate the redundant code.
Much of the `Clipper` class can be made free functions and their scope
limited.
The purpose of this is to prepare the interface for a change to more
compile-time dispatch.
Clearing the `m_alpha_blend_factors` is performed manually and in
separate steps. This is error prone for future developers. The
behavior is to reset the entire `struct` to the same state as default
initialization, so this simplifies it to do just that.
Problem:
- The statistics overlay period is hardcoded to 500 ms. This time is
very short and can result in the values being very "jumpy".
Solution:
- Increasing this value can result in more steady values which is
useful when trying to evaluate the performance impact of a change. A
new config value is offered in `Config.h` to let the developer
change to any value desired.
OpenGL mandates at least 2 texture units when multitexturing is
supported. This keeps our vertices lean and gives a nice speed
improvement in glquake. Until we support shaders this should be enough.
We now have one set of texture coordinates per texture unit.
Texture coordinate generation and texture coordinate assignment is
currently only stubbed. This will be rectified in another commit.
This function is used quite a bit during the lighting calculations, so
it's a bit cleaner having it in a centralized spot instead of just
arbitrarily calling `dot()` with numerous `FloatVector3` conversions.
This implements an 8-bit front stencil buffer. Stencil operations are
SIMD optimized. LibGL changes include:
* New `glStencilMask` and `glStencilMaskSeparate` functions
* New context parameter `GL_STENCIL_CLEAR_VALUE`
Implements support for `glRasterPos` and updating the raster position's
window coordinates through `glBitmap`. The input for `glRasterPos` is
an object position that needs to go through the same vertex
transformations as our regular triangles.
When `GL_COLOR_MATERIAL` is enabled, specific material parameters can
be overwritten by the current color per-vertex during the lighting
calculations. Which parameter is controlled by `glColorMaterial`.
Also move the lighting calculations _before_ clipping, because the spec
says so. As a result, we interpolate the resulting vertex color instead
of the input color.
If there's less than 3 vertices, we cannot do triangle strip otherwise
we will go out-of-bounds of the vertices vector.
Required for Half-Life, which sometimes submits 0 vertices for triangle
strip when drawing the electric disks around the pillars in Xen.
This was currently only set in the OpenGL context, as the previous
architecture did all of the transformation in LibGL before passing the
transformed triangles onto the rasterizer. As this has now changed, and
we require the vertex data to be in eye-space before we can apply
lighting, we need to pass this flag along as well via the GPU options.
Most of the T&L stuff is, like on an actual GPU, now done inside of
LibSoftGPU. As such, it no longer makes sense to have specific values
like the scene ambient color inside of LibGL as part of the GL context.
These have now been moved into LibSoftGPU and use the same pattern as
the render options to set/get.
These two functions have been turned from stubs into actually doing
something. They now set the correspondingmaterial data member based on
the value passed into the `pname`argument.
Co-authored-by: Stephan Unverwerth <s.unverwerth@serenityos.org>
This implements the `glLightf{v}` family of functions used to set
lighting parameters per light in the GL. It also fixes an incorrect
prototype for the user exposed version of `glLightf{v}` in which
`params` was not marked as `const`.
This is required to allow lighting to work properly in the GL. We
currently have the maximum number of lights in the software GL context
set to 8, as this is the minimum that OpenGL mandates according to the
spec.
Previously, we were expecting triangles and quads to consist of
complete sets of vertices. However, a more common behavior is to ignore
all vertices that do not make up a full primitive. For example, OpenGL
specifies for `GL_QUADS`:
"The total number of vertices between Begin and End is 4n + k, where
0 ≤ k ≤ 3; if k is not zero, the final k vertices are ignored."
This changes the behavior of `Device::draw_primitives()` to both return
early if no full set of vertices was provided, and to ignore any
additional vertices that are not part of a full set.
The name `scissor_box_to_window_coordinates` was wildy inaccurate since
we are actually transforming window coordinates into whatever the
coordinate space of the backing bitmap is.
This adds a half pixel offset to the edge value calculation in order to
sample the triangle at pixel centers. This is in line with actual OpenGL
rasterization rules and generates correctly interpolated vertex
attributes including texture coordinates.
With the RASTERIZER_BLOCK_SIZE gone we can now render to any size, even
odd ones. We have to be careful to not generate out of bounds accesses
when calculating the render target and depth buffer pointers. Thus we
check the coverage mask and generate nullptrs for pixels that will not
be updated. This also masks out pixels that would touch the triangle but
are outside the render target/scissor rect bounds.
Since the alpha blend configuration should not change between most calls
of draw_primitives it makes no sense to reinitialize the blend factors
for every rasterized triangle.
The alpha blend factors are now set up whenever the device config
changes. The blend factors are stored in struct AlphaBlendFactors.
This adds member functions Device::rasterize_triangle() and
Device::shade_fragments(). They were free standing functions/lambdas
previously which led to a lot of parameters being passed around.
This adds a counter to the debug overlay that displays the average
percentage of SIMD lane utilization.
This number represents the number of pixels that were output for each
quad. A utilization of 100% means that all 4 SIMD lanes were used and
no pixels were masked out before being written to the color buffer.
