viti95 / FastDoom

Doom port for DOS, optimized to be as fast as possible!
512 stars 33 forks source link

Avoid visplane overflow with little cost #108

Open RamonUnch opened 1 year ago

RamonUnch commented 1 year ago

I was playing around in some slightly limit removing wads and I saw that the check for visible plane overflow was removed in fastdoom. In any cases with vanilla the behavior is annoying because you get a crash as soon as there are more than MAXVISPLANES. There is an easy fix which is to add a simple check at the begining of R_FindPlane:

visplane_t *R_FindPlane(fixed_t height, int picnum, int lightlevel)
{
    visplane_t *check;
    lastvisplane = min(lastvisplane, visplanes + MAXVISPLANES-1);

the min function being branchless the cost is quite small, around 0.1% on demo1 and demo4 -nosound with DOSBox 386@33000 cycles. I could not measure any impact on demo3 nor demo2. I guess there are too few visplanes for any effect. The benefit is that you just get visual glitches when the map goes over-detailed instead of a crash. This makes more wads playable. I am not sure this should be included in FastDoom but given you raised the sprite limit, I thought you might be interested.

viti95 commented 1 year ago

Maybe it's better to make the visplanes unlimited, I already did a fully working implementation (there is a branch) for it. I remember it was minimally slower, and the main benefit is that it used less memory in general. Don't remember exactly why I didn't merged it at the end.

RamonUnch commented 1 year ago

Unlimited would be even better indeed! especially if performance hit is minimal. Being able to use less memory on vanilla levels is also a plus.