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? 

@spike (and also baker and eric)

yeah you're right, i worded that poorly. i know it was originally designed for 16:10 and also about the dos thing. you can really only play those games at 960x600 if you're bound to a 1366x768 display, everything bigger than that will have inconsistencies of some type or another.

what i meant was that 4:3 is an aspect ratio that was actually a thing in 96 in contrast to 16:9 and is supported in the original winquake options menu. it is something that should work properly since it is not an afterthought like 16:9, even if it doesn't. i don't blame quakespasm for that, but i do think it would be cool if it was the first engine to not have this shortcoming :)

the thing is that displaying the console properly shouldn't be a problem, right? my mockup proves that at least from a non-programming perspective, but is it really that hard to just not have the image aspect "corrected" and leave it at 16:10? all i did was copy the console from a 1280x800 screenshot and overlay it in 1280x720 stopping at the same height, which makes it look way better.

i don't get the part about considering width and height separately being a bad thing and this being a lost cause. why does the height matter here? i can understand stretching the image if the source file isn't tall enough, but it is. it would be a problem if the source was 16:9 and we had to make it fit on 16:10, cause then the height does fall short if you want to display the image fullscreen. the only "problem" i can think of is that a little bit of the top of the image can't be displayed since it will be over the top boundary of the screen, but that is not nearly as much of an eyesore as the distortion. you also don't have to look at the top of the console nearly as often as the bottom. the top not being visible is part of the console anyways as far as im concerned, like a theatre curtain that is falling down and lifting up to different heights.

i agree that this is pretty hardcore perfectionism, all the devs and especially eric (since he's also acting as somewhat of a community manager) have done a fucking fantastic job with quakespasm and it is in a pretty great state as it is. but it's not perfect.

feel free to tell me to stop asking if you don't care about this level of perfectionism. seriously, i can totally understand that. it's your time that is being taken up developing after all, and i really don't want to get on your nerves. i swear i'd code this all myself if i could. i am learning, but it's a slow process for me and i'm and nowhere near the level you guys are at. it would probably take me years to reach it since i just lack the deep insight into quakes and opengls inner workings as of right now. i'm sorry if i'm abusing you to code my ideas, but it's just really great to see the things i've been wishing for actually become real, even if i didn't do the dirty work myself.

for me personally it's just fun and maybe almost therapeutic to get quake into a state where nothing nags you in the back of you head. even if the text and menu scaling thing is far from catastrophic from a sane point of view, having it fixed and being unable to find any visual inconsistencies just makes playing it infinitely more enjoyable to me. and i really do love quake, it's pretty damn important to me as far as games go. i just never get sick of it, especially since i got into arcane dimensions.

regarding the testing, 1280x800 at 4x worked without any problems for me. i think they only scale up to 3.6 or something close to that on 1280x720 as of now. same goes for the menu. would be awesome if you did find a way to fix it, i promise i'll stop asking for any more stuff after this :P 

Here is a $20 CRT they are selling on EBay:

http://www.ebay.com/itm/Dell-Computer-Monitor-CRT-E773c-17-/222512283616

Then you have 4:3 CRT like when Quake came out. 

In the Arcane Dimensions folder, there is conback.lmp which is the console background.

You can open this in the Quake image editor fimg.

https://www.quaddicted.com/files/tools/fimg_v0192.zip

Edit it how you like, then save it. 

i think you might have skipped a few lines if you got the impression i actually want to play on 4:3. don't blame you, its a big wall of text. i'm no good at keeping it short. read #2764 if you want know what i actually wanted.

thanks for the idea with fimg though, i guess that's the manual way to do it. 

I just took some screenshots of extreme resolutions that maybe illustrate the reason behind the current behaviour: (it looks like the conback is just scaled to fit the window width/height exactly, then it's scrolled up).

http://i.imgur.com/k0m2LTk.png
http://i.imgur.com/xiqatwK.png

Also note that when you start a new game the console starts fully closed and then opens all the way up, so it would be weird if it used a different stretch factor when half open. 

yeah i get why it's done this way now, avoids a lot of potential problems. my idea wasn't to change the stretch factor but rather just not stretch anything at all and instead align the texture to fit the bottom of the screen and overshoot it at the top, as if it were dropped down a bit by default. stretching should only occur when it is necessary, which it is only for aspect ratios narrower than 16:10 so you don't end up with a hole dropping down from the top of the screen instead of overshooting it.

that's the way i'm gonna try to code it for myself as soon as i figure out how, but right now i think i'll stick with baker's idea. this change probably doesn't justify the effort on your part and could cause a lot of unexpected problems down the line, and i don't want you to have to deal with that because of me. you've already done a lot :) 

Rainy pixel-vision 

Nice. 

awesome! 

Is that software? Amazing.