Is there a way to modify render window size?

Such a way will help in case when you're using Reshade+Depth3D to get side-by-side stereo 3D image. For example, to translate image from PC to use with VR headset (I use phone).

I'll take 1920x1080 resolution for example.

Basically you have 4 main options for side-by-side to consider:

• You will have two images with 960x540 resolution. Bad option - not only resolution is low, but there is large unused space on a screen (it ruins VR experience).
• You can have images of 960x1080 resolution but with wrong AR and stretching. Again, stretching is bad (especially for VR).
• You can have game start in 960x1080 resolution. Its side-by-side images will be 480x1080. AR will be fine while translating to the headset (it stretches everything to 1920x1080 during translation). But again, effective resolution is lost.
• You can set custom resolution to 1920x2160. Then all be ok: resolution is fine, AR is fixed while translation to the phone HMD. But we have whooping 4x times more resolution than we needed (960x1080) to render and you need quite a PC to handle this, and the connection to phone will definitely choke.

There is a description of all this with pictures starting with this post: reshade.me/forum/shader-presentation/212...der?start=1180#24613

What could be the ideal result?

If we could make the game to render in 960x1080, but the render window (in which Reshade magic could happen) to be 1920x1080, then we are all done: we have full picture in 960x1080 per eye with perfect AR, modest 960x1080 for game engine to render and usual 1920x1080 to stream to headset.

The question is:
Does Reshade interact with rendering pipeline on a level that could make it possible? If not, can someone suggest a way to do it in principle?

Technically this can be done, yes. I might implement something like this in the OpenVR branch of ReShade.

crosire wrote: Technically this can be done, yes. I might implement something like this in the OpenVR branch of ReShade.

Great news! I'm volunteering to test Will wait for news from you. (BTW does this forum have notifications at all?)

I do not know much about OpenVR. Will it work if I'm not using nor OpenVR nor SteamVR nor HTC Vive?

Meanwhile I started to investigate problem by myself. I leave some information here in case someone will be interested. It is all on OpenGL example, since my game of interest (Freespace 2) uses it exclusively.

I learned a little OpenGL ( nice tutorial here (link that doesn't look like one) , notice the reshape function ) and have developed a feeling that something can be done with these items:



I spied on calls that the game makes to OpenGL (I use gliIntercept), and started to think, where among those we should meddle:
glViewport(0,0,960,1080)
glOrtho(0.000000,960.000000,1080.000000,0.000000,-1.000000,1.000000)
glTexImage2D(GL_TEXTURE_2D,0,GL_DEPTH_COMPONENT32,960,1080,0,GL_DEPTH_COMPONENT,GL_FLOAT,00000000)

But to my relief (as a person who knew next to nothing about OpenGL) here you are to help

to my understanding, even with auto patch on MVP matrix, manual patch on individual broken shaders (UIs, SFXs) are still required on per game basis. or at least that's what 3dmigoto community have been doing over the years.

I should clarify as to what I am proposing:
The game would continue to render at 1920x1080, but ReShade would render to 3840x1080 and give that result to the OpenVR runtime.
Forcing the game to render at a different resolution isn't as easy, since it would likely come with a lot more ballast as kingeric noted.
Also, this would work exclusively with OpenVR, since I can render to an offscreen texture there and have the runtime use that for the headset instead of the window surface.

Hm.
If the game continues to run in 1920x1080 it is kind of useless to render it in 1920x2160 as it will broke AR?
Unfortunately, OpenVR will not help me (as I can see for now) since it uses headset as second monitor (if I get it right). It is not possible for me - I can only stream to headset (I use IP over USB due to throughput).

If we go the other way - start the game itself in 960x1080 and then use reshade to go 1920x1080?

Mixed up resolution, meant 3840x1080. And sure, if you get the game to run in 960x1080, that's the same principle.

So then this image will be shown on 1920x1080 display of headset, it'll end up 960x540, won't it?

Yes, I could easily run it this way.
So I believe if it will be possible to make this way, it be ok:

Start with 960x1080:

⇩ Reshade to 1920x1080

⇩ Depth3D to SBS = 1920x1080

Again, forum accuses my message to be a spam due to its size But it wasn't even so long.
Here is the second part:

I belive I could make some fake monitor in Windows so off- screen image can be placed there. But I'm not sure will it be possible to stream from the "monitor" directly. Also it could be mess for those who uses real multi-monitor setup (I do).

It is not some exotics: stream to phone headset via network or USB connection is a very widespread configuration, I believe. Since one can much easily afford $20 headset + smartphone than Oculus or HTC Vive.

Can't we just extend viewport in the game window itself, or something like that? Since game was started in 960x1080 and its engine uses those values, there should be no mentioned problems with other shaders, etc?

If you're referring to postprocess emulated 3d, then there's already a shader for that in Reshade.
if you're aiming for legit 3d, you would need another perspective from different angle/offset. ( 2d use single cam, 3d requires dual lens)

What crosire was saying, if I'm getting this right, is having the game still running @1080p with reshade write to 2x1080p buffer and stream to VR gear, so that it doesn't tax that much to have the engine also running @ 2x1080p solely for VR resolution, which would later be compressed into SBS image, wasting all those x2 details and x2 performance cost for nothing.

I don't need postprocessing (at least now). The best shader for VR as I know is Depth3D, and all story started from my usage of it. As I mentioned in the first message, I describe it in full detail here:
reshade.me/forum/shader-presentation/212...der?start=1180#24613
reshade.me/forum/shader-presentation/212...der?start=1200#24614

>doesn't tax that much to have the engine also running @ 2x1080p solely for VR resolution

There is a way already for it, Depth3D does it, and more over, it emulates stereo 3D with pretty much decent quality with little overhead (much less then 2x1080p render would be). But the only problem is that either we loose AR or we loose useful space on a screen, since 16:9 resolution is not suitable to show it SBS on a 16:9 screen. We need 8:9 from the game, which is often possible to have, as in my case.

I don't think you get what I was saying, but whatever.

Alas, it seems so.
The only hope is that crosire will figure out something.

I have some results:
reshade.me/forum/shader-presentation/212...der?start=1220#24868

And I still need some advice. Obviously, I don't know enough of how Reshade works. Tried to read the source but it's too complicated for me.

I place here the answer from Depth3D thread, since it is about more general matters.

kingeric1992 wrote: It is not a universal patch I'm afraid.
in my test engine, I have set the viewport to fit window size by retrieving the buffer size, instead of fixed value, (just for the ability to match in event of window resize), meaning your hacks of forcing window size will not work on similar setup.

window size, backbuffer size, viewport size,
these 3 can be tied together, or individually set.
in your case, backbuffer size is tied to window size, while viewport size is set separately.
in my case, all 3 are tied together.
while in some of the modern games, there's a scaling option to have different backbuffer size to the window.
so it really depends on the game implementation.

openVR only need sbs texture, which doesn't has to be framebuffer, that's how render to x2 texture then sent it to openVR would be so much reliable.

kingeric1992 wrote: It is not a universal patch I'm afraid.

It is very likely. The question is - how universal it can be in the end. I'd try various setups and figure out. Strictly speaking, Depth3D itself is not totally universal (I guess Reshade too?), since it has Games compatibility list, and BlueSkyKnight regularly tweaks settings for various games.

in my test engine, I have set the viewport to fit window size by retrieving the buffer size, instead of fixed value, (just for the ability to match in event of window resize), meaning your hacks of forcing window size will not work on similar setup.

Well, here window resize event doesn't happen, we inject on window create - maybe it will be enough for us to get along? Moreover, all mainstream games that I know, even if they allow windowed mode, make it "NO_RESIZE", so it should not be a problem?

window size, backbuffer size, viewport size,
these 3 can be tied together, or individually set.

I can clearly see your point here. I think that backbuffer is the most elusive for me (as you can see in my previous posts - I only talk about window and viewport). Can you elaborate a little bit more, how is it used, or where can I read about it in detail? Which role does it play with Reshade?

in your case, backbuffer size is tied to window size, while viewport size is set separately.
in my case, all 3 are tied together.
while in some of the modern games, there's a scaling option to have different backbuffer size to the window.
so it really depends on the game implementation.

Again, I think you're absolutely right here. But 3 entities, even with 6 possible connections, are not a gazillion, so I'd try to untangle. Or at least to take a look.
BTW how did you tell that it was a backbuffer resize in my case?

openVR only need sbs texture, which doesn't has to be framebuffer, that's how render to x2 texture then sent it to openVR would be so much reliable.

I guess so. But I feel that openVR is useless in my case, since I don't have nor Oculus nor HTC Vive. And moreover I want this setup to run on Intel HD 4400.
Am I wrong with it?

Games don't render to a window. They render to an offscreen buffer managed by the 3D driver (the backbuffer). The driver then manages flipping that with the onscreen buffer, streching/resizing it and sending it to Windows's DWM (desktop window manager, provided the game runs in windowed mode, otherwise it's scanned out to the monitor directly).

In DirectX the backbuffer is freely sized, it is not tied to the window in any way. The only exception is OpenGL, which indeed sizes the backbuffer to the same resolution. That's why you had some success with your particular game. But keep in mind that most games nowadays don't render to the backbuffer directly, they first render to custom buffers (gbuffer, shadow maps, ...) that are managed entirely by the game and only in the final step copy that image to the backbuffer. It's all about how the game then implements the sizing for those buffers, which can highly differ between engines and may even be fixed in some cases.

To wrap it up, your findings can be useful for a small selection of games: Those running on OpenGL and that are using old rendering methods. It likely won't help with any other application.

That's why this is hard to do and much simpler with OpenVR, where ReShade would be responsible for the buffer size and not the game or the driver.

@ksotar
Let me explain, my viewport is determine by framebuffer size, which is a common implementation for games that enables user to resize window, that is, after window created, framebuffer is created to fit window size, then the framebuffer size is used for viewport size, and after window resize, framebuffer is resized to fit the window, then the subsequently viewport resize.

so, if the window is created with hacked value, the framebuffer and viewport will use hacked value in the case.

I know your game has framebuffer size fit to window because reshade renders to framebuffer, and you can't draw anything if you're out of canvas.
(for example, other overlay such as steam overlay or MSI afterbuner would also show up in corresponding corners to your hacked window )

about swapchain/backbuffer, it is created by API functions, in d3d11, you need to fill out DXGI_SWAP_CHAIN_DESC to create a swapchain, there you need to define your buffer by setting width, height or format of the backbuffer with 0 means auto fit to output window.

after backbuffer is created, viewport is used to decided which part of the backbuffer we want to draw onto. which is how it only filled up half the size of the window in your case. So, if the game have viewport tied to window size, depends on if projection matrix is tied to buffer size, either it will start drawing stuffs in the other side that would normally hidden, or the image will get stretch to entire window.

and there's projection matrix, it could also be set separately, or tied to backbuffer. in 3d modeling application where varying viewport is required, the value is tied to viewport size, as a result, after window resize, more region is reveled instead of stretching.

and there are bunch of implementation with window size dependent resources.
further more, viewport and projection matrix is not uniquely set, while forcing viewport to SBS by condition is possible, matrix patch is much more trickier then that.

overall, window size is only a parameter, which may or may not be used by the engine.

for your purpose, might as well just use a child window and put the sbs texture there.

@crosire opengl gl FBO doesn't have to be the same size as the window I think, or at least there are couples of thread discussing that with a quick google and there's this 2^N texture size thing back in the day.

OpenGL's default framebuffer has the size of the window, at least on Windows where it's controlled by WGL. Any custom FBOs are of course entirely controlled by the application.