Messed up visplanes

Take a look, happens after implementing high-res support and changing visplane UInt8s to UInt16s along with dynamically allocating visplane_t::top and visplane_t::bottom if they don't exist. This warping effect occurs when turning, once the player moves ever so slightly on the x or y plane everything is corrected. Any hints?


https://sites.google.com/site/ghostlydeath/badplanes.png?attredirects=0

Damn...I encountered the same exact problem with Mocha Doom :-S

Must check what my notes say, however in general it had to do with unrotated visplanes "bleeding" to the bottom of the screen, but in my case the effect was more on the horizontal axis (you could see vertical zones where the effect occured), while in your case it seems distance-specific. Hold on for more, though.

P.S.: OK, so in Mocha Doom, the "warped floor" bug was caused by not properly computing one of the LUTs used in MapPlane in ExecuteSetViewSize:

(snip)

...

    for (i=0 ; i<viewwidth ; i++)
    {
    // MAES: this spot caused the "warped floor bug", now fixed. Don't forget to compute xtoviewangle[i]!    
    cosadj = Math.abs(finecosine(xtoviewangle[i]));
    MyPlanes.distscale[i] = FixedDiv (FRACUNIT,cosadj);
    }

...

Also, I got a "bleeding floor" bug caused by AddLine not calling ClipPassWallSegment in the case of same-level floors and ceilings with the same texture, due to improper goto elimination.

Is the problem reduced or gone when switching to a lower resolution?

kb1 said:

Is the problem reduced or gone when switching to a lower resolution?

Nope

It looks kind of like what happens when texture coordinates aren't transformed by a perspective matrix in OpenGL/Direct3D, which means it is just being interpolated linearly across vertices in the world.

Are you taking perspective or aspect into consideration?

EDIT: Don't ask me how to do it, though - I just let OpenGL do the work. ;)

In my case it turned out I wasn't computing xtoviewangle[i] at all (and of course any tables that depended on it were also rendered wrong, but any effects were was visible only on the floors).

Mocha Doom supports high resolutions but not -yet- dynamic changing, so I don't know how you implemented (re)computation of that table. In Java it's possible to resize arrays without updating references if they all are inside the same class/superclass.

If you need to pass it somewhere externally however and you reallocate/resize, then all external objects will still be pointing to the old, unresized copy.