For the record, I'm not saying that 8-bit rendering shouldn't exist, I'm merely expressing my doubts about having this implementation in QS. 

Had an old laptop with EGA(?) video once. Down sampled everything to 256 color fixed palette with dithering. Quake looked like a cross-stitched scene. 

One of the definitions of bloatware is that it has "higher hardware requirements than the previous version whilst making only dubious user-perceptible improvements".

It's the case that a certain amount of what software Quake did can only be accurately replicated using fragment/pixel shaders, and I'm not just talking about 8-bit reduction here.

Water warp, underwater warp and scrolling sky are shader effects. It's true that QS (and by extension Fitz) do reasonably decent approximations, but they remain approximations and come with extra overhead of their own (such as hitting the framebuffer and bandwidth quite heavily, massive vertex counts, etc).

The fact that they're approximations means that glitches are still visible if you know what to look for and where to look. And they're the kind of glitches that, when you see them once, you're just going to keep on seeing them.

Keeping the GL_VERSION at 1.1 works counter to what seems common sense in these cases, because it involves performance and quality tradeoffs elsewhere. Brute-forcing something on the CPU that can be done simply and elegantly on the GPU, particularly on what is nowadays entry-level commodity hardware, is a dead-end.

For a specific example, take the sky code. Have you seen FitzQuake's sky code? Sure, it does an awesome job given what it is, but it's also 1013 lines of crawling horror.

A shader-based approach, bumping the hardware requirement to GL2.0 (i.e entry-level commodity hardware) can be done in maybe 100 lines by comparison. It's simpler, clearer, more robust, easier to extend, has less unwanted side-effects if you go hacking at it (and less interactions with other parts of the code if you go hacking at them), it's higher quality, and guess what - it will also run faster.

The thing is: most players won't even notice the difference. But the difference is there, and just because an improvement isn't user-perceptible (or it's user-perceptibility is borderline) doesn't mean that it's not worth shooting for.

It's also one-tenth the code so it can hardly be classified as "bloated".

Emulating software mode using hardware rendering with fancy shader tricks seems like too much hackiness for such a "practical" engine.

I understand what you're saying here, but the example I've given is just one case where Fitz/QS emulates software Quake (nobody seriously wants GLQuake-style sky back) using hardware rendering but without fancy shader tricks. And the simplicity and practicality that you ascribe to Fitz/QS just isn't there. 

I'm going back to Winquake. 

Oh man, if we could get proper water effects again like in the software renderer that ALONE would be worth the price of admission. 

because my pak is going to be WQ compatible :P 

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.