negative renderradius disables rendering

According to the wiki actors should be rendered and they were in latest ZDoom devbuilds. But after the refactoring they are not rendered at all. It happened in 2.3 and 2.4 and still happens now.

Negative values disable additional sectors disregarding Radius value! This means that the actor with RenderRadius -1 will only be drawn if the sector under its X/Y coordinates is visible.

It already happened in "- use msecnode_t's for the touching_renderlists instead of std::forward_list."
https://github.com/coelckers/gzdoom/com ... 37e4e6211a

Yeah it's the first commit exhibiting the problem, it didn't happen on "- removed the global 'sector_list' variable."

Man, who wrote that?

i don't understand why anyone would use a negative render radius. It's obviously an invitation to obtain weird undefined behavior. I can't think of a valid use-case for the effect described.

But i think it was the intended effect, to get the old Doom behaviour. Why would a negative value disable rendering? That makes little sense.

The old Doom behavior is to just not provide a RenderRadius.

According to the source, render radius 0 restricts it to the source sector, and -1 removes the actor even from its origin sector's render list. Some actors like invisible bridges use this because they can otherwise put a huge drag on that list's performance.

Sounds like a problem on the Wiki.

For me this was really confusing from the start but that's not what i see here:
viewtopic.php?f=18&t=54718#p964839
As i understand it when it's zero radius was meant to be used the same way to query sectors around the actor.
The 'logic' changed several times too. Well i see that it worked differently before.

I can't really say. It's just what I got from a quick look.

The old code added the thing to its own sector and that part was outside the if (thing->renderradius >= 0) :
https://github.com/coelckers/gzdoom/com ... 2aa14L6675
In the new code to restrict it to the sector of the thing i think i'd need an additional parameter for P_CreateSecNodeList in the else :
https://github.com/coelckers/gzdoom/com ... 57327dR464

I think you're right and the specification changed but the original implementation did not respect it. Seems the wiki it's based on an older logic?
However i don't see how zero renderradius restricts rendering to the source sector. I think that's not the case since in ZDoom 2.4 software it's pretty obvious that "things receive wrong illumination when they are rendered from different sector."

I think the old version it's fixed (zero case). If you think it's correct and there's interest i could make a PR, after all it's not a big deal.

Code:

diff --git a/src/p_local.h b/src/p_local.h
index 098c9c4ff3..2f0a311148 100644
--- a/src/p_local.h
+++ b/src/p_local.h
@@ -397,7 +397,7 @@ nodetype *P_AddSecnode(linktype *s, AActor *thing, nodetype *nextnode, nodetype
 template<class nodetype, class linktype>
 nodetype* P_DelSecnode(nodetype *, nodetype *linktype::*head);
 
-msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector_list, msecnode_t *sector_t::*seclisthead);
+msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector_list, msecnode_t *sector_t::*seclisthead, bool restricted = false);
 double   P_GetMoveFactor(const AActor *mo, double *frictionp);   // phares  3/6/98
 double      P_GetFriction(const AActor *mo, double *frictionfactor);
 
diff --git a/src/p_maputl.cpp b/src/p_maputl.cpp
index 053f44c13a..b191902060 100644
--- a/src/p_maputl.cpp
+++ b/src/p_maputl.cpp
@@ -463,7 +463,10 @@ void AActor::LinkToWorld(FLinkContext *ctx, bool spawningmapthing, sector_t *sec
       // at sector_t->touching_thinglist) are broken. When a node is
       // added, new sector links are created.
       touching_sectorlist = P_CreateSecNodeList(this, radius, ctx != nullptr? ctx->sector_list : nullptr, &sector_t::touching_thinglist);   // Attach to thing
-      if (renderradius >= 0) touching_rendersectors = P_CreateSecNodeList(this, MAX(radius, renderradius), ctx != nullptr ? ctx->render_list : nullptr, &sector_t::touching_renderthings);
+      if (renderradius == 0)
+         touching_rendersectors = P_CreateSecNodeList(this, radius, ctx != nullptr ? ctx->render_list : nullptr, &sector_t::touching_renderthings, true);
+      else if (renderradius > 0)
+         touching_rendersectors = P_CreateSecNodeList(this, MAX(radius, renderradius), ctx != nullptr ? ctx->render_list : nullptr, &sector_t::touching_renderthings);
       else
       {
          touching_rendersectors = nullptr;
diff --git a/src/p_secnodes.cpp b/src/p_secnodes.cpp
index b351f0e580..58b1820fc5 100644
--- a/src/p_secnodes.cpp
+++ b/src/p_secnodes.cpp
@@ -219,7 +219,7 @@ void P_DelSeclist(portnode_t *node, portnode_t *FLinePortal::*sechead)
 //
 //=============================================================================
 
-msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector_list, msecnode_t *sector_t::*seclisthead)
+msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector_list, msecnode_t *sector_t::*seclisthead, bool restricted)
 {
    msecnode_t *node;
 
@@ -239,7 +239,7 @@ msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector
    FBlockLinesIterator it(box);
    line_t *ld;
 
-   while ((ld = it.Next()))
+   while (!restricted && (ld = it.Next()))
    {
       if (!box.inRange(ld) || box.BoxOnLineSide(ld) != -1)
          continue;


I've done a PR but i don't know the performance impact of this thing, at first there were slowdowns but that was the STL version.
https://github.com/coelckers/gzdoom/pull/1506

Please leave this thing alone. I won't change how this works.

That's why i asked, if the performance impact is not big it's not worth changing it. The wiki needs to be updated anyway.
The code is in LZDoom now just in case it enhances performance somehow, seems to work well so far.