Each of the material faces is copied member by member then the copied
material state is passed by `const&` to another function, then
destroyed.
This is changed to simply passing the material state directly without
copying.
There is a loop over the lights in which each light state is copied
member by member then the copied light state is passed by `const&` to
another function, then destroyed.
This is changed to simply passing the light state directly without
copying.
Previously we only had a single current texture coordinate, set by
the glTexCoord family of functions. Since we now can have multiple
texture coordinates we track a vector of current texture coordinates
and set the requested one in glMultiTexCoord(). glTexCoord() Always sets
the first texture coordinate.
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.
LibGL will now generate the GL extension string in the constructor and
refer to it later on when the string is queried via glGetString().
Currently we only check whether the device supports non-power-of-two
textures and add GL_ARB_texture_non_power_of_two to the supported
extensions in that case.
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.
Required by Xash3D for the r_showtextures command, where it shows every
allocated texture on screen.
Description of glIsTexture from the spec:
"glIsTexture returns GL_TRUE if texture is currently the name of a
texture. If texture is zero, or is a non-zero value that is not
currently the name of a texture, or if an error occurs, glIsTexture
returns GL_FALSE.
A name returned by glGenTextures, but not yet associated with a texture
by calling glBindTexture, is not the name of a texture."
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glIsTexture.xhtml
Required by Xash3D, which forgoes glGenTexture and implements its own
texture generator. It expects glBindTexture to pick up on this though.
The strategy here is to keep texture_object null if we don't find the
texture in the allocation textures map, as it will then both generate
and set the texture in the allocated textures map using the texture
name passed to us, then bind it.
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.
Allow `Matrix::inverse()` to return an error and deal with those in
LibGL. Also use this opportunity to more efficiently calculate the
transpose of the model view matrix for the normal transformation.
Context parameters are LibGL's way of centrally defining all parameters
that can be retrieved through `glGetBoolean*`, `glGetInteger*`, etc.
The spec describes that capabilities such as `GL_LIGHTING` can also be
retrieved through these methods, but it should not be possible to
retrieve random boolean parameters through `glIsEnabled`. For example,
`GL_UNPACK_LSB_FIRST` can only be retrieved through `glGet*`.
This moves reading of capabilities to `::get_context_parameter` and
implements its use in `::gl_is_enabled`.
Texture coordinate generation is the concept of automatically
generating vertex texture coordinates instead of using the provided
coordinates (i.e. `glTexCoord`).
This commit implements support for:
* The `GL_TEXTURE_GEN_Q/R/S/T` capabilities
* The `GL_OBJECT_LINEAR`, `GL_EYE_LINEAR`, `GL_SPHERE_MAP`,
`GL_REFLECTION_MAP` and `GL_NORMAL_MAP` modes
* Object and eye plane coefficients (write-only at the moment)
This changeset allows Tux Racer to render its terrain :^)
This follows the OpenGL 1.5 spec much more closely. We need to store
the eye coordinates especially, since they are used in texture
coordinate generation and fog fragment depth calculation.
