Yep. In vulkan quake i dont see an issue with 289. In quakespasm i get the gravity problem or when going up a lift it damage happens to health. 

Boris,

You could try this workflow for your purposes.

The following link details a DOS compilation of super8. I'm not sure how recent it is, however it may support modern map limits and features.

http://www.vogons.org/viewtopic.php?f=24&t=39878

If you don't have a DOS machine, you could try running it from DOSBOX or similar emulator or VM to achieve your desired results.

Good luck! 

I am game to implement this - it shouldn't be much work, and it fits well with the "vid_desktopfullscreen" feature we've had for a while (If you set this to 1, the vid_width/vid_height cvars are ignored when you go fullscreen, it just uses you desktop res.) Another reason to do it is, one of my test machines (Linux) doesn't offer any fullscreen modes besides the native LCD res.

How does this sound, new cvars r_width/r_height, which default to 0 (use window size), but if you set them to something else like 320/240, Quake would render at that given resolution and then get scaled to the window size.

The remaining questions are, if you render to 4:3 but have a 16:9 window, should it be letterboxed or stretched, and should the stretching be always nearest-neighbour or respect gl_texturemode? I am thinking always letterbox rather than stretch if the aspect ratios differ, and always nearest for now? 

Off the top of my head, if I was doing this I'd repurpose the old vid_stretch_by_2 cvar and retain the aspect ratio. 

"The remaining questions are, if you render to 4:3 but have a 16:9 window, should it be letterboxed or stretched"

Imo horizontal letter box is the best option, stretching looks bad. Setting resolution to 320x240 (4:3) and then stretching it to 16:9, defeat the purpose. I guess someone who wants to play in 16:9 in super low resolution will set it to 320:180 anyway. 

would probably be a better resolution. 180 pixels tall is way too low res tbh 

Yeah, I just thrown this as an example.
I think hardware-wise minimum resolution available in modern cards is 640x480, so it will be scaled to closest minimum anyway (or to whatever resolution you have), so you could go with any resolution you like :D 

Something weird I just came across by accident. If you give yourself 99999 (i.e. 5 times "9") health via the console (by typing "give h 99999"), the player's perspective tilts sideways like it does when you die, but you can still keep playing normally.

It doesn't happen when you type 4 x 9 or lower, nor when you type 6 x 9, but it does happen again with 7 x 9 and higher.

Any idea why this happens? Is this a known bug? 

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.