Is there any way to 'fake' software sprite clipping with hardware rendering?

[Captain Keen]

I often play with software rendering simply because I don't like the significantly clipped sprites in low ceiling areas with hardware rendering.

 

Is there any way to design enemies sprites that don't clip in hardware and act like the software ones? I know it would have to be some clever workaround, as I believe software sprites are stored like wall textures, where the engine draws vertical columns of texturing (since it's all fake 3D). Is it absolutely impossible to replicate that in a true 3D engine?

 

Also: does seeing half of a Revenant or Cyberdemon in a hallway break player immersion for anyone else, or is that just me?

[Edward850]

Yes. In fact Strife Veteran Edition and Doom64 (including the remaster) already do this.
Strife's method is described here: https://doom64ex.wordpress.com/2014/12/24/sprite-clipping-in-strife-veteran-edition-explained/

Doom64's is actually a natural implementation, no hardware tricks. Or rather it's not an "implementation" at all, there's just no z buffer so sprites have nothing to clip against, and instead uses wall segs to clip the sprites during the mask draw phase exactly how the Carmack (software) renderer works. As wall segs are only for walls (well duh), no floor clipping occurs.

Edited January 30, 2022 by Edward850

[Captain Keen]

@Edward850 Amazing, thank you! I wasn't aware of either of these techniques, and the results look very convincing. I'll try to check these out myself asap.

 

Do you think it's possible for a port in widespread use like GZDoom or Boom to have an option to implement a solution like this, for players who want to choose it?

[Gez]

Problem with the SVE approach is that it's resource-intensive, so it's generally a bad idea for a limit-removing port where you can have thousands of sprites to display at once (hello nuts.wad). It would be possible, technically, but not desirable.

 

Problem with the Doom 64 approach is that by imitating the way the software renderer works, it is likely subjected to the same limitations as the software renderer. Notably I don't think this approach would work when changing the view pitch (looking up or down, in other words).

[Graf Zahl]

This approach also won't work with 3D floors. If it was that easy it'd have been added many years ago.

[Edward850]

50 minutes ago, Gez said:

Problem with the SVE approach is that it's resource-intensive, so it's generally a bad idea for a limit-removing port where you can have thousands of sprites to display at once (hello nuts.wad). It would be possible, technically, but not desirable.

I wouldn't be so sure, this has seemingly no impact on performance at all on the Switch with SVE, even while still running OpenGL 1.5.

There will of course be a performance impact, it adds additional overdraw, but given that GPUs are rather underutilized in Doom ports already it may well be the case that there's already plenty of headroom to support it.

 

The only real issue is for some reason, no one has attempted to try it in something not SVE.

Edited January 30, 2022 by Edward850

[Captain Keen]

Ok, thanks for the replies. So I guess the TL;DR version: it is possible, but not without consequences.

[Edward850]

4 minutes ago, Captain Keen said:

Ok, thanks for the replies. So I guess the TL;DR version: it is possible, but not without consequences.

I'm not so sure at this present time. The Doom64 method, certainly. But the SVE method with FBOs remains untested in a wider scale. The supposed consequences are just pure speculation.

There's also other potential options, SVE used FBOs as a shaderless implementation, there's other ways to consider now with modern graphics APIs and shader models.

Edited January 30, 2022 by Edward850