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.
The compiler is just not smart enough to see that program flow is completely under order, so make sure every variable is initialised
(also change some variable types here and there)
A number of people have said they have sensory issues caused by the
ripple effects from water and heat. This turns off those effects
when reducevfx is on.
It may be a better idea for this to be a separate option, but it's
a starting point we can build upon later.
We don't typically use offsets for font graphics anyway.
But I had to add offsets to the console font specifically,
because the console doesn't render text with the normal
drawing functions.
- Bits 5 and 6 define the button state
- 0xB0 - unpressed (neutral state)
- 0xA0 - animating between pressed and unpressed
- 0X90 - pressed down
- Bits 1 - 4 define the button type
- 0x00 - up
- 0x01 - down
- 0x02 - right
- 0x03 - left
- 0x07 - R shoulder
- 0x08 - L shoulder
- 0x09 - start
- 0x0A - A
- 0x0B - B
- 0x0C - C
- 0x0D - X
- 0x0E - Y
- 0x0F - Z
- Button offsets and dimensions tweaked to my own taste
Makes the drawer more complicated, but the benefit for most circumstances is significant.
In non-splitscreen contexts, pushes V_SLIDEIN|V_SNAPTOBOTTOM HUD elements upwards when the Dialogue is open.
- Avoid iterating displayplayers to find view number and
prefer R_GetViewNumber.
- Iterate over all matching displayplayers if necessary,
instead of stopping at the first match.