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. 

 

Is that sock's unfinished AD map?
Did he finish it? 

Qmaster, yeah it's sock's map, it's not released yet though. The screenshot is in QS_Spike with the r_scale cvar. 

can't wait for sepulcher, that screenshot makes it look badass.

@eric i saw your name in the credits for tfuma, which is actually my favorite of the bunch in ad. it feels way more interactive than the others and is probably the best looking map using the base style ever created. giant robots are also a plus.

how did you and gavin split work on that map? are you responsible for the ambush at bottom of the slime pit? :P 

looking at all these screenshots i'm imagining a alternate past where this shit was all vanilla.