Wii U Render: viewport size gets "locked" following first draw

ds-sloth commented 4 months ago

Bug Report

What's the issue you encountered?

This is a third issue we encountered recently as we test our Wii U port of TheXTech and prepare for our next stable release. (https://github.com/TheXTech/TheXTech/issues/770)

When the first draw of the frame is in a viewport smaller than the render target texture, subsequently resetting the viewport to the texture's original size will not allow drawing to function as usual. Instead, the viewport will remain limited to its original size.

We worked around the issue by adding a single-pixel RenderRect draw in a target-sized viewport before rendering begins.

How can the issue be reproduced?

I haven't tested this, but I imagine that it will be reproducible as follows:

Set render target to a texture (say, 256x256)
Set viewport to {64, 64, 128, 128}
Draw a red rectangle at {0, 0, 128, 128} to fill the viewport
Reset viewport
Draw a blue rectangle at {0, 0, 256, 256} to fill the viewport

The expected behavior in this case would be for the render target to be entirely blue. However, I strongly suspect that the render target will be blue only in the top-left quadrant, and red on the rest of the {64, 64, 128, 128} viewport, and black for the remainder of the image.

Environment?

I'm using Fedora, and this also affects our CI builds which pull from the devkitPro Docker image. I really don't think that the environment is related.

Additional context?

Thanks for your time and hard work on the library!

ds-sloth commented 4 months ago

As a side note: we also tested your changes from tonight (f322632c91acbf197da3d757de6ccb5fe501f39e, 6669ebbb340f4f1b8512b3006f603f60041498f8) and found that they fixed an additional issue that came up as we were doing further testing on hardware. I'm looking forward to them making it into the devkitPro repositories.

ds-sloth commented 4 months ago

As a further update: I believe that those changes in fact resolved this issue. At the very least, now that we are using a build incorporating those changes, the workarounds I made for this issue are no longer necessary.

GaryOderNichts commented 4 months ago

Glad to hear that those commits resolved the issue.

ds-sloth commented 4 months ago

We updated our CI to build directly from [edit: a fork tracking] your main branch so this issue won't affect us directly anymore. Thank you!

I'll leave it up to you whether to leave the issue open until the changes make it to the devkitPro repo.

devkitPro / SDL