Backbuffer resolution scale filter

Started by
5 comments, last by Juliean 8 years, 9 months ago

Hello,

I've got a "simple" problem with my 2D renderer. The game has an internal fixed resolution of 640x480. Now when played in fullscreen, I want the game to look blocky, so in windowed fullscreen (just a windowed application streched to fit the monitor), I have the window/backbuffer in monitor size and just stretch the rendered game image over the screen with point filtering. However in real fullscreen with a 640x480 backbuffer on a say 1920x1080 monitor, the automatic stretching performed by the GPU appears very blurry, like a linear filter at least. Is there any way to configure that, so that it uses a point filter for upscaling the frontbuffer before displaying, so that I can keep the blocky look of the game? I want to support "real" fullscreen for performance reasons, and also want to support a "native" 640x480 solution in fullscreen if possible, also due to performance and due to screenshots otherwise being extremely huge... I've already looked at the DXGI/Device initialization parameters but couldn't find any... does anyone know a possibility to change this behaviour or am I stuck with having to always use screen-sized backbuffer with manual rendering the games final scene view?

Advertisement
Anything that happens after rendering to the backbuffer is out of your control. In fact you don't even know if it's the GPU that's upscaling to native resolution or the monitor itself (typically this is an option in the driver control panel).

If you want to maintain the "blocky" look, then I would suggest that you just always go to fullscreen at the monitor's native resolution. Typically this is the highest resolution mode given by IDXGIOutput::GetDisplayModeList, but you can also ask the output for the current desktop resolution using IDXGIOutput::GetDesc.


Anything that happens after rendering to the backbuffer is out of your control. In fact you don't even know if it's the GPU that's upscaling to native resolution or the monitor itself (typically this is an option in the driver control panel).

Thanks for confirmation! I see, this shouldn't be too hard to restructure properly really, since I am already using the "default" resolution like you suggested in case the user settings are empty. Just have to reconfigure the "resolution" settings of the 2D renderer to only apply to the render targets etc...

This still leaves me with the screenshot-issue though. Thinking about it, aside from me having the game output a screenshot on "print", I just figured it probably shouldn't be hard to put image data into the clipboard whenever print is called, overwriting the default, oversized image being taken then. Well thanks again for giving me some input that put me on the right track.

Is there a reason why you cannot render to a texture and then render the result to a fullscreen quad? Use a sampler state that uses nearest filtering rather than linear.


Is there a reason why you cannot render to a texture and then render the result to a fullscreen quad? Use a sampler state that uses nearest filtering rather than linear.

I'm already doing that, apologies if I failed at making that clear.

The main reasons why I wanted to have "real" fullscreen are:

- Performance. The extra pass rendering to a larger-than-has-to-be backbuffer takes up some additional frame time. This is nowhere near a problem for 2D, but I kind of wanted to be the process of fullscreen/windowed to be unified for the engine, which I can't really do that way.

- Screenshots. Having a backbuffer at Full HD while rendering a 640x480 scene to it, will make screenshots be way larger than they need to. I now have a built-in screenshot function, so I quess I have only learn how to write to the windows clipboard, and overwrite the regular screenshot being taken when pressing the snapshot-key.

All in all, I am OK with the way I'm doing it (which is the same as you suggested), just asking since if there was a better way around it, I'd have taken it (also I only figured a solution for the screenshot-problem after I posted this thread, so yeah)...

Why would you use the clipboard for screenshots anyway? Having to tab out every time you take a screenshot (unless you plan to overwrite the previous one) is horrible. Just save the render texture to a file like every game does.


Why would you use the clipboard for screenshots anyway? Having to tab out every time you take a screenshot (unless you plan to overwrite the previous one) is horrible. Just save the render texture to a file like every game does.

I've just implemented it, yep, its clearly the better. Though I've got a few issues with the snapshop-key myself (which I'll probably adress in another article though). IDK though, not every game does it as far as I'm concerned (not saying they shouldn't, but I'm not really common to that from all that I've played). I only really recall WoW that does it in a transparent way (so the user notices it). Regardless, I just want to make sure that in any way there is not a huge-ass stretched image in the users clipboard, in case they eigther don't notice that they a screenshot is being taken or are common to manually saving it (hitting alt+tag, windows, paint, ctrl+v and ctrl+s is something that you get conditioned to very soon if you do it regularely).

This topic is closed to new replies.

Advertisement