- New in GCC 15: std::vector subscript operator asserts if
out of range (even past-end)
- Solution: use pointer arithmetic where a past-end
iterator is needed
This way when you pop a render pass, it will restore the previous
renderpass state if there was one. Allows for rendering code to enter
and leave the default render pass without interfering with other drawing
code.
The pipeline abstraction mimicked Vulkan and d3d12 explicit pipeline state objects
but, like GraphicsContext, was ill-considered for the kinds of drawing
behavior SRB2 uses. Rather than push this complexity into the drawing
code, it will instead be the responsibility of the backend to manage
explicit pipeline objects if necessary.
Now, drawing code must create a Program instance, bind it, and set the
rasterizer state to do the equivalent. Uniform, sampler, and vertex
attribute bindings are significantly simpler to set up now.
While this has an analog in Vulkan, it is trivial to manage vkRenderPass
on the backend side. We are already having to dynamically manage GL FBOs
for binding framebuffers for drawing in begin_render_pass, so I see
little reason to keep this object around.
This was already slated to be removed; the old PassManager was a failed
attempt to centralize and pipeline all graphics logic for a frame. Let's
remove it as a step towards simplifying some of this code.
I've come to the conclusion that some aspects of RHI are overengineered
to suit a future where we would theoretically support Vulkan with
minimal implementation effort. In an effort of architectural astronaut
engineering this has had the consequence of making much of the code
interacting with RHI significantly more complex.
The GraphicsContext was originally an opaque object to wrap and
contextualize operations that would eventually be inserted into a Vulkan
CommandBuffer for dispatch. In practice, for the GL backend, this does
nothing but introduce another pointer to pass around across all RHI
code, when it had already been previously accepted that the idea of
recording multiple GraphicsContexts at the same time was infeasible.
Thus, I'm choosing to excise GraphicsContext entirely. This doesn't do
much except remove passing around the context object. This is one of
many changes I would like to make that would simplify RHI-related code
and defer the complexity to the hypothetical future. Vulkan can come at
a later date, and we can solve the problems of Vulkan then. Right now, I
am actually more concerned for supporting a d3d9 renderer to shore up
that Intel 945GM laptop GPU support gap we currently have.
Takes two screenshots for a list of maps that have an "Alternate View Point" thing with tag 0 -- one intended for level select pictures and another for Discord Rich Presence. If no view point exists, the map is skipped.
OpenGL does not have renderbuffers until OpenGL 3.0 (contrast to
GLES which has them starting with 2.0). In order to allow people
with older GPUs to play the game for now (until ANGLE+GLES), I am
removing the use of renderbuffers in the game code. They aren't
needed because nothing actually needs a depth or stencil test yet.
Once HWR2 gets rolling, I'll add these back.
FixesKartKrew/RingRacers#1
Some incorrect arithmetic (applying padding to each pixel instead
of each _row_ of pixels) caused the pixel data to be interpreted
incorrectly. This was both in the GL2 RHI driver for read_pixels
and in the ScreenCapture module.
FixesKartKrew/RingRacers#41
- This code uploads encoremap to the GPU as a texture.
- It assumes encoremap is 256 * 32 bytes, but in reality
encoremap is only 256 bytes.
- The textures go completely unused, so I simply
commented out the code altogether.
