is it still too big with the "scale" slider in the settings menu at the minimum setting?

Lolbiscuits, I didn't know about that setting. Seems to fix the issue, cheers :} 

Seconding what Kinn said. I was imagining it implemented along the scr_scale settings like;

scr_menuscale 3
scr_conscale 1
scr_sbarscale 2
scr_vidscale 4

As it is though, with all the scr_scales at 1, vid_scale 3, and scr_sbaralpha 0.999 running at 1920x1080, it looks wonderfully chunky. I'm loving it.

Another way around the screen engulfing sbar would be allowing scales below 1. So a vid_scale of 4 and a scr_sbarscale of 0.25.

I dunno, you're the one coding. Can I get you a beer? 

That would be cool but will probably be really hard to implement.

I think Quake basically runs at a really low resolution that is just being displayed bigger than it actually is, so it would be impossible to have scr_ scalers below 1 since that would require more pixel density than is available. At 0.25 you would need to display 16 different colors in what as far as quake is concerned is only one pixel.

This kind of feature only works if the 3D world and the ui elements are rendered completely independent from one another, so basically the ui would have to be running at desktop resolution while the 3D world runs at a fraction of it.

Can't guarantee you that's right though, just my understanding of it. 

Yeah, scr_sbarscale below 1 would not really work with the current set-up, as you would get pixellated and unreadable status bar.

Having vid_scale affect the 3d view only (drawing 2d UI after scaling) would be possible, main disadvantage is it requires another framebuffer copy (more VRAM use and fps hit), whereas currently I combine scaling with brightness/contrast at the very end of rendering.

On the other hand I can see how the current implementation is a bit confusing with how scr_vidscale is applied on top of scr_sbarscale/scr_conscale/scr_menuscale.

Not totally sure but maybe I'll experiment with the "draw hud after scaling" variant. That is also how FTE and DarkPlaces do this feature. 

https://drive.google.com/open?id=0BzKtjR7p3BXddUo3TVhPd3U5WVU

depending on your aspect ratio and scaler value the console text gets screwed up in a few places. there is usually either at least one horizontal or vertical line somewhere that is a copy of a line directly next to it. strange double dots also keep appearing in some words when typing in the input bar. i checked to see if this happens with winquake mark v scaling aswell, but it doesn't. maybe this problem is exclusive to hardware scaling?

you'll also notice that the console background image is scaled incorrectly (look at the row of holes near the bottom) since the source image is designed to span the width of 3:2 resolutions and is being upscaled slightly to fit 16:9. well, it's actually 683:384 in my case, which is essentially the poor man's 16:9. it's almost unnoticeable without downscaling, but it looks really jarring compared to everything else in scaled modes.

i tried to get around this by creating 1152x768 as a custom resolution that fits my native y exactly to play in 3:2 with letterboxing, the same trick that worked for me in mark v. doesn't work in quakespasm though, it doesn't seem to care about custom resolutions. they don't just fail to show up in the menu either, entering the mode manually into the console just yields the "that mode is not valid in fullscreen" error, even though the resoluton is recognized by the system.

well, since that solution is stupid anyways i'd like to propose the following:

https://drive.google.com/open?id=0BzKtjR7p3BXdbGk2a1k3ZF9SUGM

scr_conaspect: 0 is scaled to fit the x of your resolution, 1 is a 3:2 overlay independent from it.

is the amazing ericw up for this incredible task? :)

oh yeah and while we're on the topic of ui related stuff, is there a way to get the sbar centered in multiplayer that i'm unaware of? couldn't find the cvar for that, apparently it's exclusive to mark v. i know it's faithful to the original quake but i'd still like it centered. 

depending on your aspect ratio and scaler value the console text gets screwed up in a few places

This happens because the console text is a single texture with each letter packed tightly against it's neighbours.

When rendering the text with linear interpolation a 2x2 block of texels is selected and a weighted average is taken (note: this behaviour is built into the txture sampling hardware); adjacent texels may be sampled, hence you see some "spill-over" from adjacent letters in the console text.

Solutions?

Always render the console text with nearest sampling. This is what the original GLQuake does but I'm not certain how well/nice it would look with various scaling modes.

"Pad" out the console text by adding a minimum 1 texel border to each character (in practice a 4 texel border will exactly double the size of the texture which may be required for old hardware that requires power-of-two dimensions) with repeated texels from the edges of that character so that the 2x2 sampling will work as expected.

Adjust the texture coords for characters slightly so that sampling always occurs from within the exact character we're drawing; this is what GLQuake does with the little status bar icons which it also packs into a single texture.

Unpack the characters to 256 8x8 textures and draw them individually with clamp mode. This might run slow.

Build a 256-slice texture array and draw them with clamp mode using the character number as the array slice. This runs fast but requires OpenGL 3.0 or GL_EXT_texture_array.

Don't scale them at all and accept having to squint to see them at higher resolutions.

Draw the 2D GUI stuff to an offscreen texture at the scaled resolution then stretch it over the scene to full resolution. Will run slightly slower.

Something else I haven't thought of? 

boristhesp1der, for the screenshot with the double lines, can I check your vid_width, vid_height, vid_scale, scr_conscale?

The way I implemented vid_scale, if the window size is not divisible by the value of vid_scale, it will just stretch the framebuffer to fit and I think you may get artifacts like that repeated line, I should double-check that.

- The "leaking" between characters is an old problem with QS's scaling, it would be nice to fix sometime using one of the solutions mh gave.

- multiplayer sbar centering: not possible atm, someone submitted a patch for it a while ago, and adding it as a cvar sounds good.

doesn't work in quakespasm though, it doesn't seem to care about custom resolutions
hm, interesting. The difference between markv and QS is we are using SDL (cross-platform library) whereas MarkV is coded against windows directly.. so maybe SDL is not noticing custom resolutions.

- re: the console background, by "scaled incorrectly", do you mean the aspect ratio isn't preserved? That seems like a bug. I'm not sure about supporting a narrower console as the UI code tends to be pretty complex / fragile and it may be messy to do. 

And scr_conwidth is 0, don't know if that is the default but it doesn't play nice with scaling.

I don't think the aspect ratio is the problem, it's just how the improperly scaled image looks through a rough pixel grid. the x resolution is what matters here, it needs to be either exactly 320 or a whole multiple of it since that is how wide the source file is. that's just the way it has to be when the image is forced to span the width of the screen exactly, other ui elements like menu and sbar are not affected by this problem since they are free from this constraint. 

I haven't tested the latest QS build, but I play with a 1366x768 res too. I seem to remember that earlier in this thread someone pointed out that this exact resolution is difficult to scale. I'll have a look with 'search' function. My english is really bad in the way I start every sentance with I. 

eric is right, that number is not divisible by 3 so scaling by that factor is bound to cause problems. 1344 is though, real bummer with that custom resolution allergy. :/

just checked winquake again, scaling seems to work differently there. check this out:

https://drive.google.com/open?id=0BzKtjR7p3BXdRVpIWXhvTEFkRXc

https://drive.google.com/open?id=0BzKtjR7p3BXdb3VMejhqeXFWQ3M

both are taken from 1366x768. Quakespasm has the framebuffer line while winquake does not, even though both are scaled 3x to very similar size. background is also differently ugly in both versions, interestingly enough.

by the way, I noticed the reduced color palette in software quake actually changes atmosphere in ad pretty drastically, would like to try this in quakespasm. the color depth option is stuck to 24bit though, is it just there for decorative purposes or can you actually change it? :P 

1366 is difficult to scale in this kind of way, yes.

Basically: 1366 / 2 = 683, and 683 is a prime number so nothing else will divide equally into it. 

how about black bars? For true 3:2 or 4:3 those are needed anyways? 

Apparently this is why:

"The basis for this otherwise odd seeming resolution is similar to that of other "wide" standards � the line scan (refresh) rate of the well-established "XGA" standard (1024x768 pixels, 4:3 aspect) extended to give square pixels on the increasingly popular 16:9 widescreen display ratio without having to effect major signalling changes other than a faster pixel clock, or manufacturing changes other than extending panel width by 1/3rd. As 768 does not divide exactly into 9, the aspect ratio is not quite 16:9 � this would require a horizontal width of 1365.33 pixels. However, at only 0.05%, the resulting error is insignificant." -Wikipedia

@brassbite
yeah that's what i was trying to do with custom resolutions, for us those are 1152x768 and 1024x768. the latter is included by default but the other is not. i personally find 960x768 more interesting than 1024x768 though, it is not true 4:3 but is a whole multiple of 320 in width which means the sbar fits the screen exactly with 3x scaling. 

I tried downloading the testbuild for the vidscale feature but the link is broken. error 502 

Did a bit of experimenting..

Yeah, 1366 = (455 * 3) + 1, so with vid_width 1366 and vid_scale 3 you'll get mostly 3 pixel wide columns, but one column 4 pixels wide. For me it's right in the center of the window, and pretty difficult to spot..

However I think I see why the console looks so bad.. it's a case of doing nearest-neighbour scaling twice. The actual size that everything is rendered to is 455 pixels wide, which is a poor fit for a 320 wide console background. Then it's scaled up ~3x to 1366.. so all of the scaling errors are magnified 3x. If you do nearest-neighbour scaling from 320 directly to 1366, the artifacts are much less ugly. So this may be a good argument for changing vid_scaled to affect the 3d view only.. hm.. 

when you look closely there is a hairthin line at the right edge of the screen where the desktop is peeking through. it sorta just pushes the problem away instead of dealing with it.

@brassbite
seems like our displays have digital down syndrome :(
here's the link: https://drive.google.com/open?id=0BzKtjR7p3BXdYk1nQ2hfM2lNOU0

@ericw how are the video modes determined? can you just change what it makes available to you by default in the source code or does it depend entirely on the system it's running on? i agree with brassbite, simply being able to set an aspect ratio to get a resolution based on your native height would be very useful and evade the problem alltogether. 

brassbite: sorry, the link in #2727 is fixed.. my server went down for some reason. When it's official: not sure, I think I might try redoing it to only scale the 3d view, as this will avoid the ugly artifacts on the conback / console text that boris reported.

@boris, regarding color depth, on some systems (usually old hardware / OS'es) Quakespasm will let you select 16-bit color in the video menu. Rendering to the quake palette would have to be coded explicitly, probably as a postprocessing effect. Can't promise it'll happen but I agree it would be a cool option to have aesthetically. 

You are looking for a pixel magnification factor, but are instead inputing a pixel division factor.

Division doesn't naturally lead to an integral scale, and since a screen is 2D it may lead to situations where a number works for width but not for height.

i.e. scr_conscale magnifies the console
i.e. Sounds like you are using vid_scale to divide the resolution rather than magnify the pixels.

scr_conscale 2 in FitzQuake doubles the size
But you have vid_scale half the size.

If I am making any sense.

/Scaling is always enjoyable to work through and satisfying upon completion. If you like math problems. The auto-scaling HUD in D3D/GL uses magnification factor.

Like always, one opinion -- probably wrong.

There are different ways to do scaling, anyway ... heheh ;-) It is more important to enjoy doing it, than which of the various methods you decide to employ. There are lots of scaling methods and no right or wrong ways. 

i don't get it. how is magnifying helping the situation compared to division?

they way i understand it is that we have an image that is 320px wide, and we need to scale it to fit on a screen that is not a whole multiple of 320px in width. no matter whether you divide the resolution by a whole number or magnify the source texture by that number, it should be impossible to have a proper result.

let's take my case as an example, which is having 1366 horizontal pixels available. i created a custom resolution of 1344 to be able to divide by 3, which means i am now rendering 448 pixels that all occupy 3 horizontal pixels on my screen. otherwise i would have 455 x 3 + 1, but that doesn't affect the problem and just complicates the explanation.

now we need to display the console in a way that fills the entire width of my screen with 448 pixels available in that direction. this cannot work because the next whole multiple of 320 is 640, not 448. that means only 448 of 640 pixels can be displayed and 192 can not, resulting in an image where most pixels are being displayed at full size but some are displayed at half size.

do i have an error of thinking in that? if i don't, i can't see why magnifying would help since it is affected by this problem in exactly the same way.

i also tested 1280 which is a whole multiple of 320 in 2x and 4x, and both display the console properly.

@eric

can you take a look at this?
https://drive.google.com/drive/folders/0BzKtjR7p3BXdUG5SclhqaG15b28

i would really like to play with 4x scaling, even though my display technically doesn't meet the requirements for that. the text in the menu gets scrunched up since it's running out of space, but this could be fixed by splitting the menu into two pages. is that something you can change? would be cool to have it automatically detect whether enough space is available and switch to split mode if there isn't, but having a cvar like scr_menusize is also fine.

there is also another problem outside of the menu, the text messages are affected aswell (look at the u and r), even though they have more than enough space available. the text in the map info is being displayed properly, which leads me to believe that fixing it should be possible. right? 

@Baker

i was wrong, apparently there is something else going on. 1280x720 looks almost right, but not quite. the aspect ratio has an effect on how the texture is displayed, it needs to be 16:10 or else it gets stretched vertically even if the horizontal resolution is fine. 1280x720 is so close to 1280x800 that i didn't notice the artifacts at first glance. i don't understand why it's doing this though, the source file is tall enough that stretching shouldn't be necessary.

is it a bug or is this behavior intended? 

I started a rewrite of this yesterday that just scales the 3d view, and it's a lot cleaner as far as the code, and will avoid all of the UI scaling issues (at least, not introduce new ones :). So you'd be able to set "scr_viewscale 4" but "scr_conscale 2", etc. I'll post a build as soon as I fix a few things.

Baker, yeah this has been fun. :) I think I see what you mean, the naming is a bit strange for "vid_scale 2" - it does scale up by 2x, but also shrinks the rendered area by 1/2 at the same time. 

new build to try

Cvar is now "r_scale", and it only scales the 3d view, so you can adjust it independently of the console/menu/sbar scale 

Nice one Eric! :) 

this fixes pretty much everything, i can even play on 1366 instead of 1344 now. you da man! :) 

Thanks for all the feedback & testing