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). 

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

Seems more like you're trying to retroactively justify incorrect behaviour. That's not going to fly. Again, I'd encourage you to actually go back and run the original software Quake to see exactly what it is you're trying to support. 

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.

For anyone interested in learning more about the reasons behind many of the decisions in the software Quake renderer (and those reasons are often "it had to run in 8mb on a P60") the latter chapters of Michael Abrash's Graphics Programming Black Book are a valuable reference: http://www.drdobbs.com/parallel/graphics-programming-black-book/184404919

Mankrip's statement here is confirmed by chapter 68, the section on mipmapping, by the way. 

Can a charitable gentleman remind me which Quake engines have external file reading/writing ability via QuakeC? 

Makaqu (and therefore Super8) does, IIRC.

Darkplaces and FTEQW certainly does. 

Any idea whether they follow a standard, or just do it in different ways? 

Most engines with QC file access probably uses Frik_File. 

If that's a kind of standard, and QuakeSpasm were to implement it, it would be AWESOME 

Not an engine programmer per say, but was curious if its possible to put in an engine hack which recalculates collisions against regular bsp and treats them as if they were q3 bsp, so that the point, player and shambler hitboxes can be overcome? 

No.
Q2/Q3 BSP does not use the bsp tree for culling, it only uses it to find the nearby brushes.
The information needed just isn't in the file...

With the 'smoothnstuff' branch of ericw's branch of tyrutils, the 'stuff' part that I snuck in includes an -wrbrushes argument to qbsp. This causes the qbsp to insert brush info into the bsp file, this can be used with a supporting engine (read: FTE only for now) for brush collisions in a similar way to q2 or q3 brush collisions.
(you also need to use the matching vis+light tools in order to prevent the extra info getting stripped).
Add -noclip if you want to break every other engine but compile your bsp a bit faster, but without this second arg, the bsp will still work in other engines, just using vanilla-style collisions. 

bsp leaves are convex, in theory the engine could treat each solid leaf as a brush, then use that brush to do the q2/q3 brush expansion logic to handle arbitrary sized boxes.

that's also how collision should be handled on rotating brushmodels. 

in theory, you can do something like that (a little more complex though).
in practise, you lose all clip brushes.

The other option is to use trisoup collision. Again, no clip brushes, so again not a real option (imho). 

ah right, clip brushes. I guess you could pull them out of hull1, but they would only be useful against entitys at least player size (since you can't shrink them, only expand.) 

So far most of the time the standard q1bsp's seem to collide ok on hitboxes < player size and > point , except when you are in tight areas of the bsp, like corners and irregular shaped solid bruses. The 'squarer' the area you are in , the less this seems to be an issue. I also seem to recall that the velocity of the ent effects the collision as well, past a certain value, I dont recall what it was, or if it was movetype related.

So I suppose traceline / tracebox fails when you have a non-standard mins/maxs ent formed and want to check collision on it, though would those not stand a better chance to hit the world than say another ent which is also non standard? I guess world is not considered a point type collision hit when contact is made...world is not point, player or shambler, but it does have a mins and maxs and a size, so I guess collision on it all depends on the brushes? Im not a mapper so I dont get to work with that stuff very often...but I always thought a collision against a bsp brush was calculated on a point size area of the bsp. 

The collision hulls in Quake are based on clipping polygons which are pushed inwards from the visual hull, and the amount pushed is based on the set sizes of the 2 sizes of boxes that Quake supports. That way everything is a point check and cheap.

I think...