Water effects are likewise easy and fast with shaders, but they do need the dFdx/dFdy instructions for the best quality, which means GLSL 1.10 or higher is required. This equates to the second generation of GL 2.0 class hardware, because while the first generation will support these instructions (which it has to by spec), it will quite likely software-emulate them.

The reason why it needs these is because the warped texture coords will cause a shifting between miplevels as the texture warps. It looks really ugly when nothing else is moving and you see a teleport shifting back and forth between higher and lower miplevels in patches and over time. (This is another glitch that you normally don't notice but once you become aware of it - mighty fuck...)

By taking the derivatives for the base (unwarped) texcoords, then doing the warp, and finally plugging the warped texcoords plus the unwarped derivatives into texture2DGrad you get a solid image with no miplevel shifting coming out. 

MH, thanks, that's interesting.

Would people use underwater warp in QS if I added it? I think it would be fairly easy... I recently put in render-to-texture gamma correction with a glsl shader (so we don't need to use SDL's gamma functions, which don't work for a lot of people, mess up the whole monitor, etc.); the water warp code should be pretty similar to that.

regarding software lighting emulation in QS, personally i'm not that motivated to work on it. If it can be done without actually uploading 8-bit textures and doing lookups for lighting in the colormap, but just sampling the lightmap and then rounding the value, it's probably not too bad (add another world drawing function that uses glsl, and modify the existing glsl mdl code to support that). 

What I said above applies to water surfaces, not underwater.

For underwater I've found that perturbing the texcoords by a noise texture that's scrolled by time gives a more pleasing result than a sine wave warp.

The fun part is dealing with edge clamping where the 3D view meets the status bar or the fill texture.

Underwater can also be more reasonably emulated on the CPU using a grid and warping per-vertex, similar to what stock Fitz uses for it's r_oldwater 0. That practically is underwater warp already. 

I'm pretty certain you can emulate the 8 bit look by taking a 24 bit color grading look-up texture, converting it to Quake's 8bit pallete and back again. Should be a pure post process approach. I know it's in Sikkmod and Unvanquished (and virtually every AA engine). Don't know about hardware requirements... 

I'm in the purist camp that plays with GL_NEAREST but even I could do without palettized lighting - too many cases where tasteful colored lighting could really go to shit in a hurry - but if it's a mode that can be toggled or it goes into its own fork, it would be great that it exists.

Getting waterwarp back and such would be hot, but the point about hardware requirement creep is an important one. I'd hope that if waterwarp makes fire shoot out of my laptop, I could turn just waterwarp off and the rest of the engine would still hum along with its present low requirements. The reason that I hope that is that adding GLSL based fancies kind of opens the floodgates for finding better ways to do everything else in GLSL also and suddenly Quakespasm is a GLSL engine. 

It cuts both ways because so-called "GLSL based fancies" can actually be significantly more efficient than brute-forcing something in software.

So in other words, using GLSL for water and sky surfaces will run faster and put less strain on both your GPU and your CPU. So by bumping the hardware requirement a little, the engine can be made more efficient all-round.

Regarding underwater warp, I'd propose that 3 options would be acceptable: off, low-quality (the current effect) and high-quality (a GLSL-based effect). Something like that should suit everybody's requirements. 

 

I think we're on the same page.. QS 0.90 will use some newer GL features than Fitz if they're available on your hardware (world/bmodels stored in a VBO, non-power-of-two textures, and the next release will be able to use GLSL for .mdl rendering.) However, these are all optional - there's a command line flag to disable each extension if needed, and I tried to keep the implementations isolated from the original code. The hardware requirements won't be going up. 

supports NPOT textures already. I know, I begged for it to be added. :P 

not original fitz.

Also, personally I dont see any issue with what mh is suggesting at all. If there is an engine that does bump up hardware requirements that everyone already has but it is more efficient, what is wrong with it being available as a choice? 

10-bits= 1024 color palette. More subtlety to fog and colored lighting while still blending consistently with the 8-bit textures. Possible in gl 2.0?
Engoo does an elegant job of this in 8-bit. The lighting must be designed with the palette colors in-mind for best effect. 10-bits is more flexible. 

For me it's an "all or nothing" thing - i.e. it's only worth doing if the exercise is to emulate software quake's visuals exactly, right down to all the nuances - otherwise stick with true colour and reap the benefits of coloured lighting, fog and whatnot. 

It's worth reminding people that Bengt Jardrup has a version of WinQuake that does nothing fancy beyond raising a ton of map limits.

I remember playing Tronyn's Arcanum episode with it, and the experience was nothing short of...religious.

I don't think that engine has been updated since 2007 though, so I don't know how it would handle many of today's maps - certainly wouldn't load bsp2. 

Would it be feasible to combine bsp2 support with real software renderer? What about framerate on giant maps? 

I'm with Kinn.

Well, mostly ... I mean, I'd be willing to accept colored lights and fog and all that as long as that, too, conformed to the Quake palette at all times.

Might be an interesting look! 

 

I wasn't even drunk. 

 

Well, the framerate in RRP is bad. But it's kinda predictable. What I really don't like is how the engine distorts everything in 4:3 modes.

Not everyone has a widescreen display. Some people have widescreen displays that can show a 4:3 picture without stretching it to fill the screen.

=> It would be nice to have the ability to control aspect ratio correction in the options. 

I have a similar 4:3 situation on an old laptop. Set vid_nativeaspect 1.333 in the console. By default super8 will guess aspect based on the highest available resolution.

Rolling with 8-bit purism theme, the only legitimate framerate comparison is with Quakeforge and GLSL simulated 8-bit. How's that compare on same machine? 

Biggest boost to framerate would be fog 0 in console. But it will never reach Quakespasm fps. (Well, maybe on fast CPU with lousy GPU.) Among all bigmap-capable engines QS is the fastest I've seen.

I usually set cl_maxfps to 24. In SW mode it doesn't feel as choppy as one might think. Hardcore is 12 or maybe 10. Might have been thrilled to get 12 fps in '96. 

I don't know if it's the same issue, but just realized my fov compensation is slightly off-center. The effect is that the view and the vwep are not rotating on the same axis. Fixable. 

Yah, what you said sounds like the culprit. Here is the porblem as I see it:

Look left: http://i.imgur.com/U4aX3sR.png

Look right: http://i.imgur.com/CnvoYH4.png 

>> Pentium 3 laptop?

No, but I often use 640x480 to improve performance, because it's the smallest resolution available to me.

Thanks, "vid_nativeaspect 1.333" helped, although 2D is still distorted. That was my main gripe, really, because unfiltered artwork looks very ugly when stretched by the wrong amount.

>> The effect is that the view and the vwep are not rotating on the same axis.

TBH, it's the case even with the vanilla engine, although it's not nearly as noticeable. 

Thanks for the pics. Bob settings move the model but scr_ofsx, y, and z move player POV. Hadn't thought about that before.

aspect: It might be possible to affect 2D graphics by the override as well. Will look into it.