Yeah - I saw that vkquake does it. It sounds like it is doable in OpenGL 1.4+ with GL_GENERATE_MIPMAP, and is done in by the GPU (if it was done on the CPU it would kill performance because the warp textures are updated every frame):
https://www.khronos.org/opengl/wiki/Common_Mistakes#Automatic_mipmap_generation

The other thing I was going to investigate was doing the warp in a fragment shader, but need to investigate whether it's faster even on lower end hardware, and if it can be made to look identical to the current warp. 

hmm odd i thought even glQuake mipmapped all textures including
water and sky textures? 

Warp in a fragment shader is faster, even on lower end hardware, and can be made look identical.

Visually it can even be superior, because normally with mipped warps the texture can shift between different miplevels as it warps, even if nothing else changes. But by taking the screen space derivatives of the unwarped texcoords and using a tex2DGrad (or equivalent) lookup, you get to avoid that and get a nice solid warping image. 

cool, thanks for the tip on tex2DGrad, will look into that.

I dug out a quick hack of RMQEngine's warp code to GLSL that I was experimenting with a year or so ago.

Snapping the texture coordinates to the nearest 1/512 (fitzquake renders the warp image into a 512x512 texture by default) seems to approximate the look of fitzquake's warp very closely:

vec2 texc_input = gl_TexCoord[0].xy;
texc_input = floor((texc_input * 512.0) + vec2(0.5, 0.5)) / 512.0;
rest of the shader

screenshots:
fitzquake render-to-texture warp
the above shader
above shader with the rounding-to-nearest-1/512 commented out

The timing is slightly off between the fitz and shader versions but they look pretty close to me otherwise, so this looks promising. 

Version 0.93.0 of QuakeSpasm is released.

http://quakespasm.sourceforge.net/download.htm
http://sourceforge.net/projects/quakespasm/files/

Changes since the previous version:
https://sf.net/p/quakespasm/news/2017/11/quakespasm-0930/ 

Also maybe it's a good time to mention that a lot of links on the QS page are broken, like the id software link on the "Being" page and most of the links on "Other Worlds" (just link them to Quaddicted, Kell's page has been moved here). 

Well hey, that's a neat early-morning surprise. Might've noticed a minor mistake in the patch notes, though:
Revert "always run" changes from 0.85.9 and move the QuakeSpasm
customizations to a new "cl_alwaysrun" cvar: Set to 1 in order to
scale forward/side/up speed by "cl_movespeedkey" (usually 2), and
to make "speedkey" act as "slowkey".
So far as I can tell, cl_sidespeed isn't actually affected by any of the settings and remains at 350 (the Quake default) regardless of Always Run setting, while _forwardspeed and _backspeed work as intended (400 for Vanilla, 200 for Off, 200 [* cl_movespeedkey 2 to equal 400] for Quakespasm). 'Walking' also only affects forward and back speeds, not side speeds, the same as the old behavior. 

Is the quakespasm.pak file up to date from the sourceforge link ?

The version that comes with the link above has date

2 march 2016 00h00,

while the version I already have (from somewhere I don't remember) has date

27 june 2017 21h46.

So what is happening with this file ? 

Yes, it is. 

I tried QS 0.93.0, and there's no rain effect in Sepulcher. I understand that the Spike effects aren't included in that version of QS, but why?

If it's because some people don't like to see "modernized" effects into Quake, why not a "Spike FX" button in the graphics menu ? 

I believe that this was already answered up-thread? 

the patch notes are correct, the reason it doesn't look that way is quake's default cl_sidespeed is already running (350), so increasing it further with the new cl_alwaysrun cvar (or shift key) doesn't make you go faster sideways. It does affect the angle you move when holding forward+left or forward+right.

Barnak: the newer quakespasm.pak is from the admod fork, it has the mod menu graphics. I probably should have renamed admod's pak file so they didn't conflict, but it doesn't matter, the contents are the same besides the mod menu graphics. 

So if I understand clearly what you said, it doesn't matter which version of the Quakespasm.pak file I use? Is that right? 

hmm i got a crash to desktop when doing a rimedemo demo2
will try a debug build later to find the error.
all i did before the timedemo was change my game dir
so it might be a cfg conflict somewhere

loaded qs
game custom
timedemo demo2
crash 

thanks for the report. I cam't reproduce with "game quoth", so maybe be QS crashes on something in your "custom" dir. 

I'm experiencing a very strange behaviour of the mouse. There is a kind of a lag between the movement of the mouse and what I can see on the screen.

I’ve this problem only with the Mac OSX universal app and NOT with Mac OSX (SDL2 version).

Can you image any possible cause?

Thanks 

I noticed input lag on some sourceports if I had vsync enabled, though it's never been an issue in Quakespasm. 

I think I can reproduce that, at least, for a few seconds after entering fullscreen mode the mouse seems especially laggy (macOS 10.13 / SDL1.2 build).

Use the SDL2 version. I'm not sure specifically what is happening here, but SDL1.2 has a hacky way of doing mouse input where it's constantly teleporting the mouse (afaik). This happened to break on the latest Windows 10 update so I'm not surprised there are macOS issues too. The SDL developers officially say 1.2 is abandoned, although they still apply patches now and then, but there supposedly won't be any more releases. 

I'm wondering about the lack of support for the nice Spike effects. I think they're working great and add alot to the atmosphere in Quake (I'm NOT asking for other "modern" graphics and high res textures stuff).

Should I conclude that all Spike effects are abandoned in QS? 

I believe the "Spiked" build was standalone for a reason, same goes for the admod build. I'm not sure how Eric and co feel about this, but IMO FitzQuake/QuakeSpasm was always about staying faithful to vanilla as much as possible. I'd wager a guess and say that it's more about historical preservation and accepting Quake as is than trying to remake it. Adding new gfx is a slippery slope. First you add some optional particles, then you add bloom and HDR, then some fancy shadows, and before you know it you've got a huge codebase with many issues out of your control. And besides, why reinvent the wheel when users interested in extra gfx can always use FTE or DarkPlaces which have more focus on this. 

This is somewhat of a TB issue rather than a QS issue but... SDL2 versions of the engine simply don't work if you launch them through the TB2 compiler dialog. You get game sound, no window appears and no icon on the taskbar.

Does anyone have a workaround? I'm still using SDL1.2 for the time being but the mouse input bug is pretty awful, even if it is a major step up from "not even displaying anything at all".

I might try raising an issue on the TB github if no one has any ideas. 

my first attempts are failing to reproduce this.
TB2.0.0RC4, QS 0.93.0. Latest windows 10 (fall creators update).

I'm not setting any commandline flags in TB's launch dialog. Tried with both vid_fullscreen 0 and 1 in my config.cfg.
My QS is installed directly in my quake directory, not using -basedir.
Anything that might be different from your configuration? 

https://i.imgur.com/f0hSVBj.png That's how I run the engine. If I don't use the -basedir option it complains that my game is unregistered (my .maps directory is the basedir).

Something interesting that I've noted is that when I run the SDL1.2 version, it spawns as its own application under Task Manager. If I run the SDL2 version, it's spawned underneath the TB application, right next to... a lot of instances of qbsp.exe, actually: https://i.imgur.com/2xOE02r.png

I think TB2 might sometimes have trouble cleaning up after itself...

Do you think reworking my compilation recipe to change my working directory away from the map's directory would be a good idea? It's a lot of work, sadly :( 

I can reproduce it now - the key is launching the engine through the "Run Tool" feature in TB.

If I launch it through TB's "Launch Engine" feature, it works normally. So that might be the workaround to look at; in the "Launch Engine" dialog it says you can use variables to refer to the map name.

Still weird that SDL1.2 works when launched via "run tool" and SDL2 fails, I will look into why that is the case. 

TB fails to close the compilers if you dont hit stop before exiting.