Broadly equivalent to something that can run Doom 3.

So, my laptop from 2006. cool beans.

Anyway, I was only suggesting it as an optional option, not the default or anything. 

A source port like Fitzquake/QS shouldn't turn into bloatware, IMO. Although forking it may be an option. 

True, but I think anything that moves the visuals closer to the original game is a worthy change. 

I'm entirely uncertain how such added functionality could be called "bloatware". 

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

quakeforge is probably the most overlooked yet impressive engine out there. taniwha put a lot of work into it (and its tools) the last years. 

dwere

So, explain how adding a new shader to bring the hardware rendering more inline with the software rendering is bloat. That's a great goal to shoot for in many people's eyes. 

Emulating software mode using hardware rendering with fancy shader tricks seems like too much hackiness for such a "practical" engine. Even if the hardware requirements will stay the same.

Especially considering that the difference between software and relatively simple hardware rendering is not that big in Quake compared to Doom. You really need shaders to emulate Doom's light diminishing feature, because it can't be properly emulated with regular hardware fog, which affects the picture big time. On the other hand, shoehorning the picture into the palette is a purely cosmetic feature. 

So 2x overbrighting is also "bloatware" to you then. Because that raises the hardware requirements too (either by way of extra functionality via GL_ARB_texture_env_combine or extra GPU muscle by way of multipassing). Likewise fullbright colours. 

Of course not. Those are important features, their absence in GLQuake was a flaw (unless you're aguirRe).

Whether true color rendering is a flaw is highly debatable. 

 

I like the 8-bit look for the same reason people like pixels. Same reason people like model interp turned off. Same reason people don't like coloured lights.

And so on. 

I like colored lights. And I like all other things, except for different reasons. 

Not saying everyone here has those tastes.

I mean, I like fog, which makes me a hypocrite I guess. 

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.