Here is my theory, correct me if I'm wrong:

I think max health you can apply is 32767:
0111 1111 1111 1111

Why not 65534? Because leading bit is reserved for sign, so -32767 is:
1111 1111 1111 1111

Now if you type 99999 you get:
0001 1000 0110 1001 1111

but you can't keep 20 bits so 4 bits got chopped and you end with:
1000 0110 1001 1111

and leading bit is 1 which means you get a negative number of -1695
That's why camera is "broken" and you are still alive(?)

999999 gives:
1111 0100 0010 0011 1111

same story as above, too many bits, so we chop it to:
0100 0010 0011 1111

leading bit is 0 so it's positive, which gives 16959

etc. 

Here is my theory, correct me if I'm wrong:
You're right.

There are two "views" of health in Quake: the value stored on the server and the value stored on the client.

The server is the master whereas the client is just used for determining if the screen tilts, whether the status bar displays, stuff like that.

So each frame the server writes it's current value for health to the client. The server stores health with full 32-bit precision, which is why movement and not actually being dead still works. The client stores it with 32-bit precision. However, and because saving 2 bytes per client was important in 1996 but bites us in the ass today, it writes it as a 16-bit signed short value.

So yes, it's losing significant bits in the transmission from server to client.

All happens in SV_WriteClientdataToMessage and a quick fix might be to bounds-check what's written. 

Yup, as a quick fix this appears to work fine.

I'm not sure of the utility of having values below 0 or above 999 on the client, because the client only needs to know (1) are you dead, so it can tilt the screen, change the sbar, and not draw the viewmodel; and (2) if you're not dead, what your health is to a limit of 3 digits because that's all that the sbar has room to display.

if (ent->v.health < 0)
MSG_WriteShort (msg, 0);
else if (ent->v.health > 999)
MSG_WriteShort (msg, 999);
else MSG_WriteShort (msg, ent->v.health); 

I'm not sure of the utility of having values below 0

Isn't the negative magnitude used for gibbidy giblets? 

ignore me 

ignore me

Have more beer. :)

Even if it was an issue you could bound it to signed 16-bit range instead. 

That's great news!

Concerning the stretch or letterbox question, I think there is a way to get around the issue altogether.

Create a console variable like "vid_scaler" which defaults to 1 and determines by which number your resolution should be divided before scaling. For example, you're running quakespasm in 1920x1080 and set vid_scaler to 4, which results in a new resolution of 480x270. The game renders this resolution and scales it 4 times without interpolation, fitting the screen exactly. Alternatively, you could have also set it to 3 or 2 which would give you 3x-scaled 640x360 or 2x-scaled 960x540.

That is the way mark v does it, and it looks really good. Even if the scaled resolution will always be somewhat higher than 320x240 depending on your native resolution, having no letterboxing more than makes up for it. And you could always create a custom resolution like 1280x960 to get 4x 320x240.

That's how I run mark v on my 1366x768 laptop. Since 1366 cant be properly divided by 3, I created 1344x768 for myself which has small black bars but can be 3x-scaled properly from 448x256.

Most people won't have that problem anyways, and doing it this way would also allow you to customize the chunkiness of the pixels to your personal preference. FifthElephant could play on 640x360, given that he has a 1080p display. 

Clamping health on the server message sounds like a bad idea because it assumes the client will never display values above 999 . Network code should clamp to the protocol maximum, display code should clamp to the display maximum. 

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 :)