This now verifies that width and height are a power of 2. The previous
check was nonsensical, probably because it was written against a spec
with improper text formatting, turning 2^x into 2*x :^)
Prior to version 1.1 OpenGL only allowed the numbers 1,2,3 and 4 to be
used as internal texture formats. Symbolic constants were introduced
first with the EXT_texture extension and then later adopted into the
core profile.
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 sets the length of a row for the image to be transferred. This
value is measured in pixels. When a rectangle with a width less than
this value is transferred the remaining pixels of this row are skipped.
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.
Currently just sets the renderer option for what polygon mode we
want the rasterizer to draw in. GLQuake only uses `GL_FRONT_AND_BACK`
with `GL_FILL` )which implies both back and front facing triangles
are to be filled completely by the rasterizer), so keeping this as
a small stub is perfectly fine for now.
This brings `glGetFloatv` more inline with the other `glGet`
functions. We should prevent crashing in the driver as much as
possible and instead let the application deal with the generated
GL error.
Since we operate in screen space where y points down we need to reverse
what is considered clock wise and what is considered counter clockwise.
The rasterizer always expects triangles with a consistent winding order
thus swap 2 vertices if necessary to reverse the winding before passing
the triangle on to the rasterization stage.
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.
GL_VERSION: The spec mandates the following format: x.y or x.y.z
optionally followed by text separated by space.
GL_EXTENSIONS: Return empty string. We do not support any extensions.
glTexCoord should behave like glColor. It only updates a gl context
variable that contains the current texture coordinates. The vertex is
only actually created once glVertex is called.
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.
AK's version should see better inlining behaviors, than the LibM one.
We avoid mixed usage for now though.
Also clean up some stale math includes and improper floatingpoint usage.
This is a very basic implementation of glGetfloatv. It will only give a
result when used with GL_MODELVIEW_MATRIX. In the future
we can update and extend it's functionality.
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.
