Also I agree that scaling only seems to make sense at integer scales so a single cave defaulting to 1 would be simplest for the user. Unless there's a desire to scale different let on each axis. 

Yeah, a single cvar like "vid_scaled" "vid_stretch_by_2" sounds better than what I was proposing 

Hey guys
Apologies if I've missed something - but is it possible to use a PS4 Controller with Quakespasm? I'm using DS4Windows as a wrapper to the xinput. Any known issues?
Using latest version of Quakespasm with the controller .txt addon

Thanks! 

Use quakespasm-sdl2.exe which has xinput support (via SDL2). I have only tested a wired X360 controller and steam controller (in Xinput mode) but both of those worked.
There are some notes on config settings here:
http://quakespasm.sourceforge.net/Quakespasm.html#ss3.2 

Just wanted to say thankyou ericw - I wasn't using the SDL exe. Had a great day playing Quake on the couch! 

All my social events will be quake once 4-player splitscreen with pads is on one of the engines. Currently being dominated by Turok 2's splitscreen right now :P 

 

Some of us have friends in real life and like to play games with said real life friends...

Post with your Nick next time asshat. 

I don't mean to be pushy, but is this still happening? It's been radio silence for quite some time now. 

Sorry for the silence, I coded most of it and got sidetracked. Here is a built to test out:

windows build
source

The cvar I went with is "vid_scale", default 1, set it to 2/3/4 to get 2x/3x/4x scaling.
You have to do a "vid_restart" in the console after changing the scale (this could be improved later to have it live update).

I didn't push this to the main QS codebase yet, wanted to get some feedback / testing first but it seems good to me so far. 

I like this feature... I also turned off basically everything, lerping, shadows etc to get it really old school 

Had a quick look, works well! Screenshots are fubar'd though, looks like it's only screencapping 1/4 of the screen. 

build with fixed screenshots

Glad you like it Fifth - yeah, it seems good on id1 maps with square particles + lerping off. 

now... about that 4-player splitscreen. ;) 

Does this build have spikes weather code included?

I'm really curious as to what "vanilla" quake would have looked like with weather effects. 

Not in this build, the scaling should be straightforward to add to QSS though.

Fifth I know, hopefully at some point (or in MarkV :) 

Seriously thank you so much!

Do you have a paypal link? I'd like to keep my word :) 

http://fte.triptohell.info/quake?+set%20cl_splitscreen%203%20+set%20coop%201 :)


@Shamblernaut, at 320*200 rain-like effects will probably just look like a few sparkles occasionally.
slow moving comparatively large snow-like particles are probably going to be okay though. note that hexen2 had snow effects too. 

I like vid_scale....would it be a daft idea to hack in support to be able to scale the console and HUD differently to the main scene?

I like the chunky piskels but the screen-filling HUD less so.... 

can't get fte to work properly 

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

@boris appreciate it, my email is in my profile. 

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.