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

Hrm, well when you think about it, the grenades and rockets traveling are point sized. Theoretically, they ought to collide once in a while if you play deathmatch....or maybe when you are fighting an ogre. Whens the last time you saw that happen? Never. So does / would traceline collide with a point sized ent? Just for fun, one time I gave the missile a.think which set its size randomly between point, and I believe half point. Collisions failed when you hit specific parts of the q1bsp sch as corners or angles mostly, but I was able to see a "point to point" collision of sorts with another missile during some tests in dm with another player. So thats why I said earlier, velocity seems to have a factor. Maybe Im being redundant, but I'm curious if the engines are checking the collision boundaries with velocity factored in, or if they stop the ent each frame for the check? 

point size

What you are saying doesn't make sense, unless you think point size means "1 pixel size", which it doesn't.

Point size is mathematically zero size, i.e. a point. 

AFAIK, bbox <> bbox collision supports arbitrary bbox sizes, unlike bbox <> world. 

bbox<->bsp collisions are aligned to the bbox's min position.
This means changing size_z leaves the monster sitting on the ground still, but changing size_x or size_y can allow the monster to (obviously) move into walls on one side but not the other.
Thus its generally much better to just use fixed x+y mins+maxs values, while z values can be more accurate with much less regard to hulls (note that hexen2 uses mins_z set to 0, because why not).
engines that support rotating bsps do so by rotating the start+end positions of any tracelines/boxes around the bsp object. This has the effect of rotating the bbox too, meaning that the top or bottom surfaces (in a non-rotated position) of the bsp are further away than its side edges, when standing on top of said surfaces after rotation.

bbox<->bbox collisions do support arbitrary sizes, but as the same mins pos affects the bsp collision offset, and the size field affects the hull that is used, you're still limited in terms of bbox sizes.
note that bboxes don't rotate, which generally means that the corners of the bboxes can become excessively obvious with large bbox sizes (side note: doom used cylinders, thus didn't have this issue). 

I just realized you can type in small or big.

Is this a feature for case-sensitive OSs?

In Windows version it does not seem to be a useful feature, because if you happen to use a capital letter
in a console command it says 'unkown command'. 

I posted it in the intended QS thread. 

http://quakeone.com/forums/quake-help/quake-clients/11993-quake-osx.html

"Also, only the software renderer is currently available for video - though, to render frames to the screen, I decided to use the new Metal framework available for both desktop and mobile devices"

Usually someone porting the original Quake to an operating system they like comes up with inventive ways to handle video, sound, input. 

Darkplaces Engine Bug [EDIT]

Posted by Teknoskillz [73.142.34.180] on 2016/02/07 21:51:33
Was not sure if this is ok to start a new thread , so feel free to move it to the right one if Im making a mess here. The last engine related topic I was posting in got moved someplace, I cant find i it now? Anyway , on the chance there may be some experienced people here using DP, and may know whats going on, heres a screenshot of the problem: [ http://imgur.com/jpSHrW0 ]

It happens when you set r_showbboxes to non zero. Its some kind of artifacting / re-replicating going on and its been a while since I first saw it, but I seem to remember I was playing with another graphics related cvar before I set showbboxes again during testing, so I am pretty sure its related to the other cvar, just what one, I cant remember? Any help appreciated. This is the most recent release of DP.