Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add viewport based scaling support #619

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

Conversation

temx
Copy link
Collaborator

@temx temx commented Jan 21, 2023

When r_simplescale is set to 1, 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.

@Novum
Copy link
Owner

Novum commented Jan 21, 2023

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?

@temx
Copy link
Collaborator Author

temx commented Jan 21, 2023

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 WATER_WARP it already reads from different coords), and that's where the scaling is done. The only use of subpasses that I can see is GUI -> POST_PROCESS (color correction), but that's after scaling is finished.

@Novum
Copy link
Owner

Novum commented Jan 23, 2023

I'll take a look

@Novum
Copy link
Owner

Novum commented Feb 15, 2023

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?

@temx
Copy link
Collaborator Author

temx commented Feb 15, 2023

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?

@Novum
Copy link
Owner

Novum commented Feb 15, 2023

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.
You can alias the same memory for multiple render target sizes. Just needs a barrier.

@Novum
Copy link
Owner

Novum commented Feb 27, 2023

I'm okay with merging this, but I think we should just remove the screen effects path completely with the same PR.

@temx
Copy link
Collaborator Author

temx commented Feb 27, 2023

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.

@Novum
Copy link
Owner

Novum commented Feb 27, 2023

I would just kill it. I'm not attached to that code :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants