- Introduces new function K_GetDisplayEXP
- Replaces duplicated code between HUD and tally
- Returns UINT16_MAX in div/0 case for invalid result (resolves#1458)
- Hides EXP HUD/tally if no EXP can be earned
Implemented using libopus for the Opus codec, same as is used in Discord.
This adds the following cvars:
- `voice_chat` On/Off, triggers self-deafen state on server via weaponprefs
- `voice_mode` Activity/PTT
- `voice_selfmute` On/Off, triggers self-mute state on server via weaponprefs
- `voice_inputamp` -30 to 30, scales input by value in decibels
- `voice_activationthreshold` -30 to 0, if any peak in a frame is higher, activates voice
- `voice_loopback` On/Off, plays back local transcoded voice
- `voice_proximity` On/Off, enables proximity effects for server
- `voice_distanceattenuation_distance` distance in fracunits to scale voice volume over
- `voice_distanceattenuation_factor` distance in logarithmic factor to scale voice volume by distance to. e.g. 0.5 for "half as loud" at or above max distance
- `voice_stereopanning_factor` at 1.0, player voices are panned to left or right speaker, scaling to no effect at 0.0
- `voice_concurrentattenuation_factor` the logarithmic factor to attenuate player voices with concurrent speakers
- `voice_concurrentattenuation_min` the minimum concurrent speakers before global concurrent speaker attenuation
- `voice_concurrentattenuation_max` the maximum concurrent speakers for full global concurrent speaker attenuation
- `voice_servermute` whether voice chat is enabled on this server. visible from MS via bitflag
- `voicevolume` local volume of all voice playback
A Voice Options menu is added with a subset of these options, and Server Options has server mute.
This static var requires a 64 megabyte .bss section value which
is allocated on application startup. Depending on the particulars of the
operating system's virtual memory implementation, this may result in
dynamic page allocation for the span, or a full upfront allocation.
Either way, it doesn't need to be like this, we can just dynamically
allocate the buffer instead.
This may save up to 64MiB of runtime memory usage.
Replaces the old freelist solution with the LevelPool, which
dramatically reduces the number of allocations needed for mobj and
precip sector assignment. In measurement, this cuts down the time taken
for spawning precipitation by 50%.
This should substantially reduce the number of malloc/free calls made to
create and destroy mobjs, especially during level load and net
save/load.
memory_resource standard header is not available on the OSX deployment
target we are using, so I had to write my own fixed size pool allocator.
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.
