@qbism:
Regarding 8-bit gl shaders, try quakeforge's gles renderer which uses the colourmap and everything. 

Fitzquake renders in OpenGL, so I doubt that it would be considered true to the original aesthetic by Doom community's standarts.

There are plenty of different Doom source ports out there. Most of them have increased limits, a lot of them have at least some additional modding capabilities, and it's not uncommon for them to preserve the software renderer. 

Well tickle my ptarmigan - that's the first I've heard of quakeforge, and that looks awesome. Ok, we need that in quakespasm. 

Doing it requires bumping the hardware requirements to something that supports fragment shaders and dependent texture reads, with good performance. Broadly equivalent to something that can run Doom 3.

Since this is something that the Quake community as a whole seems incredibly reluctant to accept, it's unlikely to happen in an engine like QS. 

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.