Yeah, getting a virus warning from that. From the zip as well. Wonder why that is exactly. I reckon it is some funky code which gets picked up by heuristics? 

How hard would it be to get temporal dithering, similar to that of Inside, into a quake engine?

The banding that the fog generates, esp in dark areas is pretty harsh. With good temporal dithering, that is limited to the fogged areas, things would look a lot nicer. Obvs this is not important as it is not a gameplay thing at all, but it would be neat. 

Also, thanks Kinn for the hud linkage :) 

The main roadblock for Quakespasm is the renderer is not fully converted to shaders; mdl and lightmapped faces are, but water, sprites, sky and anything else are still using fixed-function OpenGL.

Dumping some links on dithering I found:
http://loopit.dk/banding_in_games.pdf
https://www.shadertoy.com/view/MslGR8 

Ah, I see.

Here's a good talk about what they did in Inside here.

https://www.youtube.com/watch?v=RdN06E6Xn9E

I also think they gave away the plugin, or whatever they wrote for Unity to do this stuff for free. Not that that would help a lot with QS. 

 

On any hardware from the past 15 or so years, fixed function OpenGL no longer exists: it's emulated with shaders in the driver.

Maybe "fixed function is faster" was true in the GeForce FX era, but time and technology have both seriously moved on since then. 

Aside from being unable to get an accurate weapon view like winquake/mark_v I think the features here are almost perfect.

r_scale, cl_sidespeed etc fix any minor gripes I've had.

Any ideas if this will be fixed outside of scr_ofsz -2 would be good. 

What about r_viewmodel_quake regarding the weapon position. Setting that to 1 does the job pretty good I think.

I personally really would like the oldschool underwater effect in QS, but yeah, shaders, etc.

That and a way to actually have accurate colormap lighting rendition, because a lot of older levels do look a lot better with the harsher lighting, imo at least. 

Yep r_viewmodel_quake should do the trick.

btw check out the >60Hz monitor support in QSS if you haven't http://triptohell.info/moodles/qss/ - host_maxfps 0 means unlimited, and it keeps physics running at 72fps.

btw thanks for that video ptoing, when I get back into engine coding I'd like to do more with shaders, and the temporal dithering sounds like a cool project. 

Cool :D Would love to see how that looks if properly implemented. I think it would be very nice :) 

ptoing, if Vulkan is an option for you vkQuake solves the banding issues by using 10 bit frame buffer precision. 

Please note that this bug occured in my IRC fork of 0.93.0

I just got a: "TexMgr_ReloadImage: Invalid source for player_0"

Error occurred in the middle of a game whilst quickloading and quicksaving a lot, also while recording demos.

This bug caused the save file list to disappear, it also caused loading saves from disk to fail.

video of failure: https://www.twitch.tv/videos/280904822 

Just tried vkQuake. That indeed solves most of the banding issues. Also like that it has classic water. Thanks for this tip :) 

scratch that last bug report. It occurred again last night without the "TexMgr_ReloadImage: Invalid source for player_0" message. I'm inclined to believe that the bug I'm facing caused that error rather than being caused by it.

either way, with my shoddy coding it could be anything XD 

I have a feature request. The following binding doesn't work properly in Quakespasm while it does work in a few other source ports like Qrack:

alias +movejump "+jump;+moveup;"
alias -movejump "-jump;-moveup;"
bind space +movejump

Jump works just fine but when underwater, the player moves up as if holding the jump key rather than the move up key. It makes swimming up slower than it should be. 

In Qrack or Mark V, type pq_moveup 1 and you don't need any of that.

Feature originated in original ProQuake and spread to about every engine both of the Quake and Quakeworld variety including FuhQuake/ezQuake/FTE/FodQuake (in QW engines and JoeQuake the cvar is called "cl_smartjump" instead). 

Thanks Baker. It turns out that pq_moveup is 1 by default in Qrack, which would explain why the binding seemed to be working when it was really just the cvar. However, setting it to 1 in Mark V causes weird issues - it will stay locked swimming up when I press jump until I press the moveup key. Even pressing movedown won't cancel swimming up and staying at the surface. 

Is there any way to get the classic software "wavey" water warp when underwater? I don't remember in which engine, but I seem to remember some of them did this. Maybe I am wrong though.

Another thing is, when reloading a game of the same level it restarts the music track, this is probably correct "vanilla" behavior, but is there a way around this? Maybe some CVAR that controls this behavior so there's an option not to restart music track.

And some maps have no music track info or have it set to "0" which results in no music playing. Maybe introduce a CVAR for random music track start (and/or override the map setting)?

Would be so nice

Then again simpler workaround would be having a Quake OST playlist on shuffle in some media player in the background. 

FTE does (r_waterwarp 1).
DirectQ does, if I remember right.
And I think vkQuake does too, but it might just be surfaces.
(don't expect them to have the same scale as the software-rendered engines - higher resolutions result in far too many repeats in the vanilla software renderer) 

has water warp as well. 

bugs
-
>sometimes the player can get stuck going down/up ramps/angled brushes, touching obtuse (convex) corners. See the images for examples
https://ibb.co/mm18p8
https://ibb.co/jVdop8
>sometimes monsters teleport-in without particle effects

suggestions
-
>increase the limit of the number of particles. Sometimes, particles vanish from launched rockets during very chaotic battles 

sometimes monsters teleport-in without particle effects
i guess it's a 'spawn silent'/no gfx mode

increase the limit of the number of particles.
there's a command line option -particles 

Getting stuck on those corners is not an engine bug. It's an issue in the map, or the compilers to be precise, and occurs during the QBSP stage.

Particles can be increased manually using the commandline option like спы says. 

Its an engine bug in SV_RecursiveHullCheck.
FTE+DP+ezQuake all have fixed(and more efficient) versions, and porting FTE's over to QSS fixes the issue for me.
However there's a potential risk for things to fall out of one of the thousands of possible maps out there. Its probably not a huge risk, but its still there, hence why I was too paranoid to make that change.
Paranoia is a really bad thing. :(