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.
All values besides 0 and 1 have been unused for a while. Quite frankly, if the gamestate resend doesn't fix them, a rejoin won't either, so kicking them is just adding extra steps.
- dumpconsistency cvar is always enabled (rather than a define), but is now a cheat.
- It now dumps on resend, instead of on consistency failure kick. (Those don't even happen on too many resyncs anymore, anyways...)
- It now dumps for both the server & the client that is resyncing, so there's gamestates to compare. The two files are given names with metadata so they can be matched up.
It's not great, but it was easy enough to do and more useable than having 0 tools to inspect resync at all.
BEHAVIOR being optional is now handled from our side, because using getModule or loadModule on an invalid file is supposed to be an error condition for the VM.
This isn't an optimization for the mobj pointer list, but it is an
optimization for level interpolators, which previously made N
allocations for N non-mobj thinkers. Now those allocations are amortized
according to std::vector's storage.
This could still be further cleaned up to be more C++-ey.
I do not trust memcpy due to the rendering bug even though it appeared to mostly work, so I did it manually. It's still order of magnitudes faster than reloading the level from scratch.
- Use srb2::MobjList to keep checkpoint objects list
intact after savegame load
- Use std::unordered_map of line tag and vector of line_t
pointers
- Use line tag for the key so multiple checkpoints may
be associated to the same set of lines
Prints a full, ordered table of results, basically equivalent to intermission.
Much closer to the kind of logging one would want for tournament play, rather than the SRB2 leftover this command was holding previously.
The following funcs are now a suite with almost-identical argument lists.
- `map` is for immediately going to a map
- Add `-random`/`-r`
- `queuemap` is for interacting with the live Round Queue
- Add `-random`/`-r`
- Performed server-side
- `-clear` and `-show` now accept partial params `-c` and `-s`
- Fix minor error with 0-argument print's text
- `showmap` is for printing information
- Add arbitrary map name/ID input
- `showmap robo` prints the course `map robo` would resolve to
- Add `-gametype`/`-gt`/`-g`
- For compatibility testing
- Add `-random`/`-r`
- Combine with `-gametype` for extra guarantees
- `randommap` was deprecated
- Will only print replacement instructions of `map -random`, and nothing else
- Lost & Found courses are now part of the intended sequence of `advancemap next`
- Does not include Test Run, that's admin choice only
- Courses with too-small playerLimits will be skipped for both `advancemap random` and `advancemap next`
- ResolvesKartKrew/Kart#1411
Reveals the next Round in the queue via server shout message.
Can be used manually, or with automate commands for tournament rulesets that permit foreknowledge of the next Round without requiring the host to work off memory or document.
It was technically possible for custom clients to spoil future rounds of a tournament queued while they are connected to a server.
Making it a PT direct packet to the servernode both solves this problem AND reduces irrelevant NetXCmd traffic for clients.
- `setscore 0 50` will set the player in slot 0's score to 50 points
- `setscore 0 50 -add` will add 50 points to their score
- `setscore -clear` will clear all players' score, as per the old function
- Command will error if PWR is in use (no roundqueue/`usepwrlv 0`/cheats off in GP)
- The previous cheat `setscore` is renamed to `setroundscore`
