What are the cvars that can be tweaked to make DarkPlaces look like software Quake? 

type in this -

gl_texturemode gl_nearest 

r_useanotherengine 1 

Doesn't make any engine look like software Quake. Software Quake had mipmaps but gl_texturemode gl_nearest will disable mipmapping. 

software quake didn't have mipmapping. This will remove all texture filtering and make it look oldschool.

Are you trolling? 

Of course software Quake had mipmapping. That was one of the cool features. 

Oh, I see, you're confusing mipmapping with filtering ... no, it didn't have texture filtering. But it DID have mipping. 

If you view a texture in TexMex, it will let you see the 4 mipmap textures it creates.

Any Quake texture wad has 4 levels of detail built into the texture.

WinQuake uses them. GLQuake did not use them and instead generates it's own mipmaps from the texture. 

gl_nearest_mipmap_nearest 

TexMex ---> open a wad --> select a texture and click View ->View Detailed.

The smaller images below the main image are the mipmap level textures. 

I guess I was confusing filtering and mipmapping as the same thing.

Basically I was helping the dude get the pixelly goodness. 

The workings of the software renderer aren't as well known to most as the GL engines.

Mostly because for maybe a decade, the WinQuake style engines were basically abandoned and forgotten.

Mankrip was probably the main person working on them (other than Spike) but MH did 2 big tutorials that really made them better (one was animation frame lerping). 

You guys seem to over-emphasize smaller differences in rendering from GL to Software. I mean, what most people really want, and notice, are the pixeled textures. And that's it. 

Without simulated 8-bit rendering (i.e. every pixel you see on screen is in the quake palette) I'd be reluctant to say it looks anything like software quake. 

The quake palette is not up to the task of rendering most modern maps which have been designed with coloured lighting. They look like garbage in anything but mark_v and quakespasm. 

 

I mean, what most people really want, and notice, are the pixeled textures. And that's it.

overbright lighting is hugely important. glquake doesn't support it, which is why everyone complained about it being "dark", and the idgamma fix which just wrecked the palette instead was ugly and didn't address the real problem.

metlslime began supporting it in fitzquake 0.70 or so. 

There's also R_DrawSurfaceBlock8_mip0, R_DrawSurfaceBlock8_mip1, R_DrawSurfaceBlock8_mip2 and R_DrawSurfaceBlock8_mip3.

nearest_mipmap_nearest looks fine, but nearest_mipmap_linear can look better; it retains the pixel crunchiness but gives a smoother transition between mip levels. Of course that's moving away from how software Quake looked again, but that's no bad thing IMO in cases where software Quake actually did look worse (is anybody really and seriously going to argue that particles that get smaller nearer the viewpoint look better, for another example).

Of course, some people confuse aliasing with detail, which is why some may actually prefer gl_nearest on it's own.

All that aside, the pixel crunchiness of software Quake has other advantages too, aside from just pixel-crunchiness for the sake of pixel-crunchiness. One of them is that the texture art is actually quite finely detailed down to a per-texel level to begin with, with a lot of those details being as small as a single texel. Look at the health pickup box textures, for example. When you blur those with linear filtering all of that fine texture art just turns into a mushy mess. 

The quake palette is not up to the task of rendering most modern maps which have been designed with coloured lighting. They look like garbage in anything but mark_v and quakespasm.

I'm sorry, but Quakespasm doesn't do anything special with either the Quake palette or with textures. It's just an absolutely standard 2x modulate blend using built-in GL functionality. 

(is anybody really and seriously going to argue that particles that get smaller nearer the viewpoint look better

This is one of the things that bothers me with most modern engines that "fix" it... 

(is anybody really and seriously going to argue that particles that get smaller nearer the viewpoint look better

What like e.g. in QuakeSpasm? A particle near the player's face is a quake unit in size I think, but the same particle the other side of the room has to be drawn bigger otherwise it would be completely invisible. 

A particle near the player's face is a quake unit in size I think, but the same particle the other side of the room has to be drawn bigger otherwise it would be completely invisible.

Nope, that's not what I mean at all.

It's evidently been quite a while since people have actually used software Quake, and have forgotten how it really looks... :)

What I mean is that in software Quake particles on the other side of a room start out small enough, but still visible. As they get closer they increase in size normally with perspective. Then once they get so close they start getting smaller again. So a particle that's, say, 10 units from the viewpoint is actually substantially smaller than one that's, say, 100 units from the viewpoint.

That's how software Quake looks and that's what I mean. 

To try to retain the distance cue of particle size without occasionally obscuring the view with a gigantic square of color? Makes sense. 

No. It was due to the particles of the vanilla software renderer being fully broken.

Everything about their maths is fucking wrong. From the top of my head, here's a list:

� They're not scaled to the screen resolution. They were developed for a 320*240 video mode, with a double height version for the obscure 320*480 video mode, and that's it. Their dimensions will always be wrong on any other video mode, including 320*200.

� They were hardcoded for FOV 90, and go wrong on any other FOV. This makes them get actually *smaller* when zoomed in, which is bloody awful.

� Their origin in 3D space is *not* in the center of their square, but in its top-left point. If you freeze them by pulling down the console and then rotate the camera around, their squares will move around their top-left point, instead of staying at the center of their previous 3D space position.

� Their maximum size is 8 pixels, IIRC. Again, the actual screen resolution is ignored, which means that in lower resolutions, they'll be able to get closer to the camera before being clamped. So, this "feature" doesn't make sense at all, it's just some weirdness that people got used to.

I'd actually challenge people to play WinQuake at 320*240 fullscreen for several hours doing everything the vanilla game can do and try to compare it to how the game look & behave on their regular engine & config setups. But I don't want to be that annoying. :P 

The main purpose of the mipmaps in the software renderer is not to make the game prettier, but to conserve surface cache memory, which is used for the lighting.

Since the liquids in the vanilla renderer doesn't use lightmaps, they don't use mipmaps either. And hardware rendering with mipmaps will also mipmap the liquids.

And GL_NEAREST doesn't disable the lightmap filtering, not to mention that hardware rendering doesn't feature the same color banding of Quake's colormap, unless explicitly coded for it (FTE is one of the rare hardware-accelerated engines that does this, but I haven't tested it).