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.
* LibGL now supports the `GL_NORMALIZE` capability
* LibSoftGPU transforms and normalizes the vertices' normals
Normals are heavily used in texture coordinate generation, to be
implemented in a future commit.
The `GL_LINEAR` param was erroneously not picked up on. Also implement
support for `GL_FOG_START` and `GL_FOG_END`, and make sure that the
`gl_fog*` family of functions are optionally registered with the active
list.
These stubs are largely implemented the same: their API is exposed, but
they print to the debug console and sometimes `TODO()`. These changes
allow GLU and Tux Racer to build.
Methods stubbed:
* `glTexImage1D`
* `glTexImage3D`
* `glTexCoord2d(v)`
* `glNormalPointer`
* `glTexGen(d|f|i)`
* `glTexGenfv`
Previously, if the client supplied `GL_STENCIL_BUFFER_BIT`, `glClear`
would return an error. Since it is a valid parameter, we now continue
and report that this parameter is unimplemented instead.
This adds a method `info()` to SoftGPU that returns the name of the
hardware vendor and device name, as well as the number of texture untis.
LibGL uses the returned texture unit count to initialize its internal
texture unit array.
Replaces the GLenum used in RasterizerConfig to select the draw buffer
with a simple boolean that disabled color output when the draw buffer
is set to GL_NONE on the OpenGL side.
