Conversation
|
If we merge this then we should remove all the other scaling code. I was hesitant doing this before because it requires the GUI to be rendered in a separate render pass instead of a sub pass. I assume this is the case here? |
|
Unless I'm misunderstanding something, the GUI is already rendered on a separate render pass. The Screen Effects compute shader runs in the middle (and if using |
|
I'll take a look |
7b55369 to
87b39c2
Compare
|
Still want to merge this btw. Just haven't had time to look at it. I basically want to verify first if it's not better to just realloc the render targets at the smaller size? |
|
IIRC using smaller render targets would require more of them (two are needed to run the screen effects, and if they're smaller a new larger one wold be needed for the UI), and managing that doesn't look like it'd be less complex. Is that just to save some memory? |
|
I just have bad memories from using resolution scaling based on viewports. But I think we don't do any bilinear sampling of render targets (which causes problems at the borders) so it might be fine. |
|
I'm okay with merging this, but I think we should just remove the screen effects path completely with the same PR. |
|
The subgroup stuff too? The screen effects path could be repurposed to do "supersampling downsampling" as it did before. Not sure if many people would want to use that. |
|
I would just kill it. I'm not attached to that code :) |
When
r_simplescaleis set to1, instead of adjusting texture LOD and point sampling in the screen effects shader, adjust the viewport to render a smaller rectangle and then point upscale after screen effects, before the HUD is drawn (like QuakeSpasm does). This gives faster 3D view rendering and supports any scale factor.