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 

I'm assuming you figured out everything ;-)

And it sounds like you got the reward of the "Aha!" moment. 

Use metlslime's oldwater method or what mh does for GL waterwarp

1. Calculate magnification factor + virtual resolution
2. glViewport 0,0,virtual screen width, height
3. eglCopyTexSubImage2D to capture that area
4. Maybe glClear the texture buffer if you aren't drawing full-screen, although there are ways to avoid this step entirely.
5. glViewport 0,0,real screen width, height
6. Render the texture captured but now to the full screen

Now draw the 2D like normal. No shaders. Maybe 10 lines of code. 

I think that's close to what I ended up with, here is the full patch:

https://github.com/ericwa/Quakespasm/compare/master...vidscale?expand=1

No shaders, I think it only needs GL1.1. 

i understand if im getting on your nerves with my questions and requests, and i sure as hell don't have the same technical knowledge like you two. but i do care about this stuff a lot and would greatly appreciate if you at least explain to me we where i'm wrong. seriously, i have huge respect for what you're both doing and try to learn from talking to you.

if you don't like the pitch about splitting the menu into two pages that's ok, i have a better idea anyways. the reason behind it was to allow for proper ui scaling for aspect ratios wider than 16:10, but there is something less invasive that can be done to display at least 16:9 properly.

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

as of now the text messages and menu are not being scaled all the way to 4x in 16:9, even if the cvars accept that input. the console background also gets screwed up but that has to do with something else.

i made some mockups showing how it should look using 1280x800 as a reference. for the text message you can see that there is more than enough space availabe, but the way it is being scaled is governed by some rules that should not apply when scaling to this extent. seems to me like there is an invisible frame around it that is not wide enough to fit the message at 4x, so the scaling is reduced to a number between 3 and 4.

the sbar is not affected by this rule, which means the text in the tab view is scaled properly, giving you a direct comparison in image 1.

the same thing is happening with the menu, only difference being that there is much less space availabe. as you can see it's still enough space to fit everything important on screen however if you were able to remove the frame restriction. proabably a good idea to change viewsize to 120 when entering the menu so the bottom of the options is more readable.

the console image probem is slightly different, i think it is just being scaled according to aspect ratio when it shouldn't be, causing it to be stretched vertically. this is even worse at 4:3, where it defintely shouldn't happen since quake was designed for that aspect. 

quake's minimum resolution is 320*200, so 16:10, not 4:3
(320*240 won't fit inside a single dos segment, and is NOT a standard VGA resolution, you need SVGA for it, on the other hand 320*200 is _the_ VGA 256-colour mode)
the conback.lmp is 320*200 as a result of this.

I don't know of ANY quake engine that preserves the conback aspect correctly - not even software rendering will. the only real way to do it is via letterboxing, and even then replacementtextures will generally expect some other aspect (like 4:3).

really, perfectionism here is a lost cause. you'll either need to pad (with more rendering/drawfills, or with letterboxing), or use funny sized pixels. just make sure you never consider ONLY the height nor ONLY the width. 

no worries, it's great to have your feedback.
I did see #2754 but I wasn't sure how much of that was caused by the first "vid_scale" implementation.

For the text messages (centerprints like the "Arcane dimensions 1.5 update" one), the thing to remember is they can get quite long, like in this discussion a while ago about dealing with a long episode end message (from "Rapture"): http://celephais.net/board/view_thread.php?id=60831&start=847&end=857

I think you're right that there is an invisible frame around centerprints; since QS always uses the same scale factor regardless of the message length.

Anyway I'll need to do some testing to give a proper reply. so just to double check, I should test 1280x800 with all of the scale factors set to 4x?