- Most R_SkinAvailable calls should be returning index into demo.skinlist (same numerical value as when demo was recorded), for demo sync
- A handful of general things permit exception for this
- Expose `replaynumskins` (calculated as `(demo.playback ? demo.numskins : numskins)`) to Lua
- There's *always* more that can be done for this, but this is the minimum spec that can at least be somewhat stable
- Software* + OpenGL support
- *Not supported: R_DrawColumnShadowed_8
- This has something to do with walls and FOF lights.
However, I don't see an easy code solution and I don't
know how to even test this.
- 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.
- V_HUDTRANS does not fade if combined with V_SLIDEIN
(since sliding elements are not supposed to fade).
- If not V_SPLITSCREEN, uses most opaque fade value among
splitscreen players (since Tally will fade back out for
specific players).
- No need to call CV_RegisterVar
- Cvar definitions live in only one file, easier to locate
- Organized into sections -- netvars, cheats, etc.
- Use builder pattern to initialize cvars
- Still need to extern if you want to read the cvar value
More opportunities for early rejection in table-wide searches, in anticipation of future work.
- Many circumstances independently implemented string name comparisons. Most of these have been converted to use R_SkinAvailable, with one exception.
- M_CharacterSelectInit already needs to iterate over the characters, so produce the skin hash independently.
In levels with tens of thousands of precipmobjs, the
overhead of running a thinker for all of them is too much,
no matter how small the thinker is.
ALL thinking is done inside the renderer now, where it can
be limited by distance. Precipmobjs track the last
leveltime they thunk, so interpolated frames don't think
twice.
There can be very many precipmobjs in a sector. During BSP
rendering, for each sector reached by BSP (the entire
visible level at least), all the precipmobjs would be
iterated and their distance from the camera calculated, to
determine whether they are within draw distance.
The issue with the old approach is that there really are
too many precipmobjs in each sector. By iterating the
blockmap within a certain range instead, precipmobjs
out of view are not iterated at all, saving some time.
Caveat: drawdist_precip is no longer respected as an
exact value, since it must round to the precision of the
blockmap.
List of potentially scary changes:
- Removes snext/sprev for precipmobj_t
- Removes preciplist for sector_t
- Adds bnext/bprev for precipmobj_t
- mobj_t and precipmobj_t field offsets are symmetrical
- Modified P_SetPrecipitationThingPosition and P_SetThingPosition
- The syntax in these functions is kind of wacky
This doesn't need to be in a bunch of rendering code, simply only run it in TryRunTics.
Worst case scenario: if this sucks then it means dedicated servers have also sucked the whole time and we should come up with a new solution to fix both of them.
More likely scenario: nothing changes and we now aren't doing networking inside of the renderer.
