Hi!

Thanks for all the hard work you've put on this great engine. It wasn't until now that I was able to come across a bug that I'd like to report.

Fairly recently I got myself a monitor with a max refresh rate of 165 Hz, so to squeeze out all that juicy smoothness the monitor can offer, I decided to adjust the host_maxfps setting in the config to 200. However, this causes problems that can be seen most notably in elevators: all entities onboard the elevator seem to kind of lag behind.

For example, if I go down an elevator, the elevator goes down smoothly, but I go down in skips, as if I was Wile E. Coyote forgetting that gravity exists for a split second and then I fall on the elevator again only to forget gravity for another instant as soon as I touch the elevator again. And the pattern repeats.

The same happens going upward, with more severe consequences, as I end up slightly inside the elevator, which may sometimes cause the elevator to think that it's squishing me, which causes it to damage me and then reverse back down.

I did some testing, and the only influencing factor seems to be the value of the host_maxfps setting. (Fiddling with the V-sync settings didn't seem to do anything.) The threshold value seems to be about 165, above which the problem starts appearing.

Anybody else have this problem? Sorry, if this has been addressed before. 

In most quake engines and wasn't really designed to go that high. Some engines have uncoupled physics from framerate and work better at higher frames. I believe dark places is one such engine. 

Hi,
I know QS is OpenGL while RPi is GLES, but, really, it would be great to enjoy Quake (or Arcane Dimensions)on a small, silent and low-power-consuming Raspberry Pi 3.
BTW Quakespasm is yet available in Raspbian Jessie repository, but I get a "Couldn't load video device" error when I try to run it in framebuffer mode (CLI).

So really no interest in a Raspberry support? :( 

there's actually a few engines that support gles2 nowadays.
Izhido(was it?) had one for ios, alternatively there's multiple engines that run on android with its gles1/2 limitations, including my own.

If you grab the source for fte, you should be able to use the following command for the original rpi (cross compiles, you might need to fix up some assumed paths inside the makefile):
cd engine && make gl-rel FTE_TARGET=rpi
If they've fixed up their egl support since the original, you can try and be more generic and just use the following:
cd engine && make gl-rel FTE_TARGET=linux32 CFLAGS=-DUSE_EGL
With that generic build line, you can switch between egl vs glx under x11 with setrenderer egl vs gl.
I don't actually have any sort of rpi, so I can't really help much more than that. 

Funny thing I just ran across...

Using the latest 64-bit quakespasm-sdl2.exe, with the latest NVidia drivers, there are certain POV points on the DM3 bridge where sections of the outside pentagram area are being rendered in my view.

Screenshots:

https://www.dropbox.com/s/1b5cb0dbg9t51o6/spasm0000.jpg?dl=0
https://www.dropbox.com/s/nlst7lupknon1ga/spasm0001.jpg?dl=0

and here's my config.cfg and autoexec.cfg:

https://www.dropbox.com/s/wm75461ngtotcv8/config.cfg?dl=0
https://www.dropbox.com/s/6i1jj64oelutyg2/autoexec.cfg?dl=0 

I think it's just r_wateralpha 0.5 in config.cfg + non-watervised bsp (QS has had gl_clear default to 1 for a few versions, so you don't get HOMs anymore, but you get that instead, which is less obvious what's happening).

So it's good that it's not some deeper bug in the renderer, but this is a common enough thing (it's been reported a couple times I think, happens to me fairly regularly) that we should probably do something about it...

IIRC, QS has had r_wateralpha be archived in config.cfg since an early version, and when you combine that with changing gamedirs with "game" you can easily launch something like AD, then change to id1 in the console, exit, and end up having r_wateralpha 0.5 saved in your id1/config.cfg.

There's also the option of having the engine detect watervis, etc. 

Ah hum. Yeah I clean-installed recently and I guess I picked up a default r_wateralpha of 0.5 from either QS or Mark V. Actually it's been so long since I messed with those settings for non-watervised maps I forgot that it even had an effect if r_novis was 0. 

I really wan't to play Arcane Dimensions in low resolution. Unfortunately mark v, which supports resolution scaling, doesn't support AD. The winquake version has problems everywhere and the opengl version can't handle some things like the fog in the necromancers keep. Apart from that performance is also really bad. mh explained how that has to do with mark v being cpu-bound while engines like quakespasm are fillrate-bound, which also means that downscaling would greatly improve performance in quakespasm while having close to no benefit in mark v.

I mainly wan't this feature because of the way it looks (explained in detail in my mark v post here: http://www.celephais.net/board/view_thread.php?id=61375&start=1487 ), but the potential performance boost is also incredibly useful to me as I'm running quake on pretty slow hardware. Quakespasm is already a huge improvement over mark v in AD, but I still get occasional framedrops on 1366x768 (native resolution of my laptop) while 320x200 runs silky smooth. Of course not in fullscreen, but quakespasm will output that resolution in windowed mode if you specify it with -width and -height. That proves to me that the resolution I wan't to play on is at least technically possible in quakespasm, I would just need a feature similar to that in mark v which stretches a borderless window to fit the full screen without interpolation. You can even simulate something like this by using the windows magnifying tool, but it's horribly awkward to set up and doesn't allow you to use the mouse (more on that in my last post in the mark v topic).

So, getting to the point here, I will pay the developer who implements this feature in quakespasm. That's how badly I want this. I absolutely love quake, and the amazing lovecraftian environments in AD make me truly happy to experience, but I can't enjoy them as much on high resolutions as I would otherwise.

If you're one of the developers reading this, name your price for the time it would take you to implement this. I will pay you, given that the price is within reasonable bounds. 

Not sure I'd play on 320x200 but less detailed quake maps definitely look better in lower resolutions IMO. I tried setting QS to a lower res than my laptop screen, but my screen just blurs it and it looks terrible. It would be nice to have the option of playing on lower resolutions but with krisp krunchy krixels 

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.