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. 

Is there a way to get multiple transparencies to overlap properly? If I have 3 transparent brushes overlapped, the engine treats them as see through. Maybe there is a bug when the alpha sum is greater than 1.0? Using water alpha of 0.4 and *glass textures. 

is there a cvar for it? 

for a quick fix, "scr_ofsz -2" (haven't done proper testing to pick this but it seems close-ish)

We really should add a proper toggle.. I can't stand the SSG hiding completely behind the status bar. 

Is there any way of having QS having strafe work more like Mark_V and Winquake?

Currently the strafe value feels far too jerky. It's easy to tell the difference between QS and Mark_V/Winquake by holding forward and then hitting strafe left/right.
QS seems to allow too much travel sideways when going diagonal. 

Proper depth peeling in quake is rare. I hope that it becomes less rare in the future :( 

Has Quakespasm got original Quake movement, or has Mark V got the 'real' movement? Or none of them? 

afaik the only thing QS changed is it made "always run" equivalent to holding the run key, whereas in winquake, "always run" is slightly different (I think?)

Fifth, did you have "always run" on when comparing QS/MarkV/Winquake? were you holding shift/run? 

I made a slight change to this in my source, allowing the player to bind capslock to commands (in this case +speed).

That way if +speed behaves differently to "always run", any differences can be mitigated by using capslock.

(of course the frustrating thing with this is the console is case sensitive for most commands) 

I use always run.

The QS implementation is basically like holding shift to run. You are correct, using always run is a different feeling to holding shift (even in Winquake).

Not sure if this is a bug. It would be nice to have an option to have this operate more like Winquake. 

It would be nice to have an option to have this operate more like Winquake.

Put
cl_forwardspeed 400
cl_backspeed 400
... in autoexec.cfg. 

I'm playing through on NM and my realm progress isn't saving, using latest version of Quakespasm. Is this a known bug? 

Hi Quakespasmers. I stopped by here because someone mentioned a "Beef Thread." I didn't know there was a "Beef Thread!" So I decided to go look for it, but I stopped in here too.

I see FifthElephant is asking about the "Always Run" thing being different. I actually made a post about this on my FvF forum which goes into detail describing WHY it is that way, so I thought I would post a link here for those who are interested (especially for FifthElephant, because he is my BESTEST buddy! >:D Hi FifthElephant!)

http://www.fvfonline.com/forum/viewtopic.php?f=12&t=3776 

After playing Quake for 20 years I am used to the default behaviour. Maybe it isn't in the design goal of the engine and an option wont be included.
I find strafe jumping harder in Quakespasm as the movement is too sudden and jerky. 

I think I may have suggested in the Mark V thread that "Always Run" could be made to have 3 different settings in the menu: OFF, ON, and ALL.

ON would be the standard old setting that doesn't affect side speed, for people who have just gotten used to that.

ALL would be doubling the movement in all directions, including the side speed.

Unfortunately, Mark V changed it so that "Always Run" is ON by default, using the old method that doesn't affect side speed....

I dislike that settings, but could always just ignore it -- I prefer to be able to sidestep really FAST to dodge those rockets. But changing the default so that it's ON is just awful; now I have to make extra settings just to get back to normal. (Yeah, I've complained about this in the Mark V thread already, heh.)

But perhaps Quakespasm would be interested in my idea of 3 different settings for the menu option, for people who prefer it the old way. More user control is usually a good thing, even though I really, really like the way Qspasm has implemented "Always Run," with the full speed in all directions, and having the +speed key still be useful to toggle you to a slower pace. 

What is it with Quakespasm that makes it draw certain brush models regardless of their actual visibility - always and on the other side of the map, even from the outside. Unnecessary triple digit epoly boost.

What's going on and how can I work around the system? Check detail1.jpg from my post in the Tyrutils_ericw thread as an example: the square things in the bottom right corner. Originally, there were some columns in the back of the map as well, but I had returned them to world geometry already. 

Sounds like it's just the "brush model in too many leafs" fix.

Note that because QS uses VBO drawing and draw call batching poly counts aren't as relevant. 

that's the "flicker fix" we implemented. QS's MAX_ENT_LEAFS is 32, so I think the way it works is if an entity bbox spans more than 32 leafs, the server will make it always visible rather than potentially flicker.

Workarounds would be simplifying world geometry where the bmodel is or shrinking the bmodel. 

 

When this problem really came forward in community consciousness (http://forums.insideqc.com/viewtopic.php?p=26885#p26885) I had just recently fixed it by dynamically recalculating visibility for each client, for each entity, each frame. That was effective (it wouldn't have pulled large bmodels into the PVS all the time) but caused hugely excessive CPU load.

It turns out that in this case just drawing it anyway is a more efficient approach, at least for hardware-accelerated engines (the point I made above about r_speeds counts not being so relevant to a properly-optimized renderer can't be overstated enough).