separated window resolution and render resolution

[sudge]

It's more like feature request than issue and it is something very common. I can make make the game running e.g. in r_mode 6 which is 1024x768 but I cant resize the windows having the same render resolution, or maybe I dont know the command. I've tried to find something about that without any result. So does it possible to make different window size having the same render resolution? (make the feature like that, if possible)

[ensiform]

Show examples of where it is very common? This seems unheard of to me.

[mrwonko]

So you mean stretch the rendered image to a given size?

[Archangel35757]

I believe he is referring to when you run the game in Non-Full Screen Mode and you have a window you can resize to any size-- but he wants the game's rendered view to remain the fixed render size. So basically he's changing the size of the "blackness" around the rendered game view. The minimum adjustability being equivalent to the rendered game image. Correct @sudge?

[sudge]

@ensiform try to look at the DSfix settings for Dark Souls game, or I believe some id tech engines can do the same; it's only not commonly using, cause in the most of the games it's simply dont needed at all. (if not talking about consoles, upscaling rendered image is often using there) @mrwonko yes @Archangel35757 correct, one point - not adding the "blackness", but stretching the entire rendered image to the window size

[ensiform]

There's no id tech engine that does what you ask. There is cg_viewsize which causes a box to be rendered.

[xycaleth]

What would be the benefit of doing thi, @sudge? I can only imagine that you'd get a blurry game.

[leilei-]

As rude as I may be, I did actually implement something like this in the OA engine called r_virtualMode.... Which itself is a horrible hack of the bloom code, and is unorganized and still called "tvmode" all around the code....but it does "work".

It was a big hack that maintained two different width/heights, it'd become a textured quad that would stretch past and fill the screen or window.

Turning it off meant r_virtualMode -1. 0 would do 320x240, 1 400x300, and so on, following the same list as r_mode. They would all be stretched to the current video mode you're using, but it can NEVER exceed that video mode: It would have to clamp. You can't pull off DSR/VSR doing this.

Personally I don't think it's useful or practical for OpenJK and would just be another complication to deal with for the end user, and those who understand it and use it will be in the low single digits. The reason why I did it is so I could debug my content's visuals in low resolutions without having to squint or change from my desktop's native res :)

And finally computers are ridiculously powerful these days, if JA is slow on your modern computer you could try r_primitives 2.

[sudge]

@xycaleth

I can only imagine that you'd get a blurry game.

To stretch windowed game to a screen height if you have no 1280x1024 resolution available (19" monitor or laptop 13-14-15" screen), but maximum resolution is about 1600x900.

[mrwonko]

So it's just about allowing arbitrary resolutions? That's what r_mode -1 and the customheight/-width are for. Or do you want to force incorrect aspect ratios?

[ensiform]

This requires using framebuffers and extra GL extensions to work. While nice, and there is a working code example for this in another project, I think others have suggested we not add it.

[dionrhys]

I don't see a use case for this either. As @mrwonko pointed out, r_mode -1, r_customWidth 1280, and r_customHeight 720 can set an arbitrary resolution to draw the game at.

[ensiform]

It can only draw to the limits of the monitor though, which using a framebuffer and r_render* is not limited to.

One is also restricted from taking screenshots or /video of the game if the window clips the side of monitor, or game is minimized. (Pixel ownership problem with legacy OpenGL pipeline)