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.
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.
This fixes a bug with avrecorder capturing a mostly white
frame at the beginning of a wipe. This was because
wipe_capture_start_rendering depends on basic_rendering
and a wipe could occur before any 2d elements are batched
for the current frame, thus producing a white frame when
basic_rendering is passed. It only lasted for one frame
because the PREVIOUS frame is used for the wipe itself.
This is also why the white frame was not visible
on screen.
- Drawn over the top of basically everything when enabled.
- Update song credit on
- Menu music update (can sometimes clear it)
- Intermission begin
- Vote begin
- Return to title (by clearing it)
