Menu

#692 Flats not rendered correctly with viewfit set to auto

Always occurs!
pending
None
5
2024-02-16
2024-01-15
No

While testing the new UMAPINFO implementation with version 1.48.14, I noticed that Flats are rendered wrong with some of the new viewfit settings.

How to reproduce:
- Set viewfit to "auto" or "fit height".
- Use one of my UMAPINFO test WADs from FR100 and look at one of the teleporters in the first map.
The edges of the red flat on the bottom does not align to the surrounding walls if you look from different angles.

Tested on a Linux/PowerPC machine, but I don't think the big endian byte order is relevant here.

Discussion

  • Wesley Johnson

    Wesley Johnson - 2024-01-15

    There is good reason I put off this kind of thing for so long. It modifies the draw scaling, one of the most touchy areas of the Doom Legacy code.

    Auto responds to your window size, and I cannot guess at that at all.
    "Fit Height" is probably what it is selecting.

    "Fit Height" also is highly dependent upon the window size. It should still draw normally, if you are using a normal Doom window like 800x600. It is the wide windows that are going to cause problems. I tested with Doom2 for days, trying to find all the draw mistakes. I thought I had them all covered by now.

    I am going to need much better info on what wad, what window size you were using.
    (Searched for FR100.wad, then FINALLY realized that it is that Feature-Request 100. I have too many wads, and all the names are weird)
    Any chance you can use a wad I likely can identify easily, like Doom2.
    How to find the exact thing you are seeing.

    In the mean-time, I will try to look for flat drawing errors. I will also try to figure where those UMAPINFO test wads got put, and what they were.

    Big Endian is irrelevant, unless you are see total color hash (AFAIK).

     
  • Wesley Johnson

    Wesley Johnson - 2024-01-15

    Note: If you select Fit Height where the window size does not match normal Doom ratios, it will scale the width to whatever the correct ratio requires.
    The width may be cropped, or it may be drawing past normal boundaries.

    Same for Fit Width, it is the height scaling that is dependent upon the ratio.
    Each of these combinations will have its own separate debugging issues.

    Drawing beyond normal boundaries has special problems of its own. I thought it looked OK, but you need to know that is a unique problem in itself.

     
  • Wesley Johnson

    Wesley Johnson - 2024-01-15

    What I see is that some of the brown edge is cutoff when seeing the teleporter viewed from any distance. When you get up close, it looks normal.
    That could be something like round-off from the scaling conversions.
    It will take a while to track that down.

    My "Auto" looks normal, even when using a wide screen (1280x800).
    Stretch looks normal. Fit_Width looks normal. Only Fit_Height does this.

     
  • Michael Bäuerle

    On my system "Auto" does the same as "Fit_Height" (looks wrong with both).
    I have used 1280x1024 pixels fullscreen, but a test with a 320x200 window shows the same problem.

    The settings "Fit_Width" and "Stretch" do not show this problem.

    The attached archive contains the WAD file and some screenshots (there is also a screenshot from PrBoom+ for comparison).

     
  • Wesley Johnson

    Wesley Johnson - 2024-01-25

    Fixed SVN1667.
    Two ratio scaling variables were getting different values. There were two changes that were trying to do the same thing.
    Replaced aspectf_x uses with projection_y. Removed the var aspectf_x. It will now be consistent.

    I had tested using the 1280x800 screen size, because it looked extreme in width, compared to the other available choices.
    It happens the screen size 1280x800 has the same ratio as the original 320x200, and this hides defects in the ratio and scaling. It is one of the screen sizes where all the viewfit choices appear the same, at least when the code does it correctly.

    Thank you for noticing this.

     
  • Wesley Johnson

    Wesley Johnson - 2024-01-25
    • status: open --> pending
     
  • Wesley Johnson

    Wesley Johnson - 2024-01-25
    • assigned_to: Wesley Johnson
     
  • Michael Bäuerle

    Looks good now.
    Ticket can be closed.

     

Log in to post a comment.