PrBoom+ and Slime Trails

[Vordakk]

I have recently begun using the latest version of PrBoom+ to test some maps I'm making. I also played through a number of pwads using PrBoom+, including the entirety of Alien Vendetta. In both instances, I use -complevel 9. What I'm finding is that PrBoom+, at least the way I'm using it, is showing/allowing a lot more slime trails than the ZDoom that I'm accustomed to, both in my own maps and in others' maps. Is this true, or am I just going crazy? And if so, does this then mean that any slime trails present in PrBoom+ -complevel 9 will also pop up if someone plays through one of these levels using a vanilla .exe?

[entryway]

Yeah, slime trails affect vanilla too. Build nodes with zdbsp to reduce them. Use GL renderer to avoid them.

Alien Vendetta is complevel 2 megawad, btw.

[Vordakk]

I appreciate the response, but that doesn't really answer my main question. I've dealt with slime trails before and know what they are. And I already use ZDBSP to build my nodes. I was really wondering if any native ZDoom behaviors are decreasing the amount of slime trails that show up in a given .wad, because I see WAY more of them when I use PrBoom+, both in testing my own wads and in playing wads by other people.

For example, I am working on a map where the play area is surrounded by rocky, earthen walls. These walls are oddly shaped, craggy, and feature jagged edges and angles. I first playtested the level in ZDoom and fixed the few slime trails that occurred(like maybe 3 max). I then playtested that very same level in PrBoom+ and found about 12-15 more slime trails.

[Maes]

There was an entire thread devoted to a similar problem some time ago:

http://www.doomworld.com/vb/source-ports/57748-random-visual-glitch-in-prboom/

It's simply a side effect of the vanilla (and Boom) renderer and map format, and will be present in anything using 16.16 fixed point arithmetic in the renderer and map code. The only way to avoid this is to use ports that have gone to great lengths to fix it with stopgap fixes and opportunistic patching, use floating point accuracy, or hardware rendering. This boils down to ZDoom, Eternity and most GL ports.

Sometimes you can fix it even on "normal" ports with a different node build or post-loading hacks, but not always.

[Graf Zahl]

Maes said:

and will be present in anything using 16.16 fixed point arithmetic in the renderer and map code.

The biggest issue with slime trails still is the vertex coordinate imprecisions by chopping off all fractional bits. Compared to that the inherent issues with using fixed point math are small.

Using a node builder that can store fixed point vertices (ZDBSP) and an engine that can read such a format (PrBoom+, Eternity, ZDoom) should normally be enough to eliminate the vast majority of slimetrails.

And for any hardware rendering engine it's not even an issue because they work differently.

[entryway]

Graf Zahl said:

Using a node builder that can store fixed point vertices (ZDBSP) and an engine that can read such a format (PrBoom+, Eternity, ZDoom) should normally be enough to eliminate the vast majority of slimetrails

Do extended nodes affect compatibility? If they do, is it not really hard to separate dependent code from drawing code? If it is possible and not very hard to implement, then probably there is sense to add an opportunity to save extended node somewhere else in pwad (with different name, etc) to have both classic and extended nodes together in case if classic nodes can be built?

Currently extended nodes are mostly used only for very large maps I think (probably _only_ for sunder.wad), just because it is not possible to create normal nodes for giant levels. Nobody will create extended (incompatible with vanilla and many ports) nodes for vanilla levels just for fun because of slime-trails

[Graf Zahl]

I think for that it might be better to include the node builder in PrBoom and do something like ZDoom and GZDoom do with GL nodes: Maintain 2 sets of nodes, one for gameplay processing and one for rendering.

For any vanilla compatible map the node building is fast enough so that nobody should notice.

[Gez]

How does the textured automap work in PrBoom+? ZDoom needs GL nodes for it to work, and can build them while loading the map; but PrBoom+ does not include a GL node builder, does it?

[entryway]

Gez said:

How does the textured automap work in PrBoom+? ZDoom needs GL nodes for it to work, and can build them while loading the map; but PrBoom+ does not include a GL node builder, does it?

glboom-plus prepares some additional data for textured automap: gld_CarveFlats->gld_FlatConvexCarver. Sometimes it is incorrect, but not fatally. IIRC, all needed code already was present in glboom, but was not used, so I just enabled it. Then glboom-plus calls gld_MapDrawSubsectors in this way:

for (i = 0; i < visible_subsectors_count; i++)
{
  subsector_t *sub = visible_subsectors[i];
  int ssidx = sub - subsectors;
  for (loopnum = 0; loopnum < subsectorloops[ssidx].loopcount; loopnum++)
  {
    GLLoopDef *currentloop = &subsectorloops[ssidx].loops[loopnum];
    glBegin(currentloop->mode); // GL_TRIANGLE_FAN
    for (vertexnum = currentloop->vertexindex;
         vertexnum < (currentloop->vertexindex + currentloop->vertexcount);
         vertexnum++)
    {
      glTexCoord2f(flats_vbo[vertexnum].u + floor_uoffs, flats_vbo[vertexnum].v + floor_voffs);
      glVertex3f(flats_vbo[vertexnum].x, flats_vbo[vertexnum].z, 0);
    }
    glEnd();
  }
}

[Vordakk]

Maes said:

It's simply a side effect of the vanilla (and Boom) renderer and map format, and will be present in anything using 16.16 fixed point arithmetic in the renderer and map code. The only way to avoid this is to use ports that have gone to great lengths to fix it with stopgap fixes and opportunistic patching, use floating point accuracy, or hardware rendering. This boils down to ZDoom, Eternity and most GL ports.

So in other words I wasn't crazy when I saw more slime trails using PrBoom+ than I did using ZDoom. :)

I'm wondering if it's even that big of a deal that I have a few slime trails lingering. I can't imagine most people getting too worked up about it anyways. I'll try to fix the ones I can, but I'm not gonna let it slow me down from now on.