visedicts list bug

[mh]

So far as I can tell almost every Q1 engine suffers from this.

First of all the visedicts list is initialized and built from client-side entities in CL_RelinkEntities.
Then CL_UpdateTEnts adds to it.

So far so good.

Now, R_RenderView is called, and via that call (through R_RenderScene/R_DrawWorld/R_RecursiveWorldNode/R_StoreEfrags) more static entities may be appended to it.

The problem is with code that may call R_RenderView multiple times; because the visedicts list is not re-initialized between calls the same set of static entities may be repeatedly appended to the list. timerefresh is a good example and demonstrates that this is a real bug that actually happens, not something theoretical. By the time a timerefresh completes you'll be drawing up to 128 copies of each torch in the current PVS. Trace through the code and you'll see cl_numvisedicts repeatedly going up and up.

[taniwha]

Hmm, though I've modified QF's visedict code quite a bit, I need to check this one because all I really did was to stuff everything into the bsp tree and then queue up the entities as each node is visited when drawing the world.

[taniwha]

Ok, it turns out I fixed this in QF when I made the renderer support unlimited visedicts. The support is via a linked list and entities getting added to the list more than once would cause a loop and thus hang the renderer, so I was forced to move the clearing of visedicts into the renderer (note that the var to look for in qf is r_ent_queue rather than visedicts).

This fix won't be simple to port to other engines because QF uses efrags for all entities. Static entities are "link" and forget, but normal entities, especially beams, took some work to get right.

[qbism]