Perhaps what you have to say would be more interesting if you provided some specific examples with some specific engine names.

Everyone likes a good rant, but that's muddy as hell with no specifics. 

They should have to debug the maps and OS issues and not have a common source of bugs in the engine, too. This is why quakespasm is favored, even though it is missing the original software engine.

It's not that simple. Quakespasm, FitzQuake and so on are also favored because they operate in 32-bit color. They have 32-bit colored lights, 32-bit colored fog, 32-bit alpha blending, 32-bit color skyboxes and so on.

Software renderers can't compete with that. Even less so if 32-bit color filtering for 8-bit textures is also taken into account. There's no way to make a 24-bit software renderer fast enough to do all those true color effects at a playable speed. No way.

I was happy enough to figure out how to do color-corrected 8-bit alpha blending in real time, because the alternative color system I was developing would be slower and overcomplicated. It's hard to create precomputed 16-bit or 24-bit color transformation tables that fits in the CPU caches and are fast (using a single access for each RGB color instead of doing the R, G & B transformations separately).

The smooth, smooth colors of hardware rendering are something that really sets both worlds apart, even if texture filtering is disabled. Software rendering feels just poor in comparison.

That's why there's no market for it. Texture filtering gets disabled because it distorts the texture resolution, and software rendering is not used because it distorts the texture's colors.

Any software renderer with 8-bit colored lights, 8-bit colored fog, 8-bit alpha blending, 8-bit color skyboxes and so on is doomed to be just a trifle, just a novelty. There's no reason for anyone to put them above what the hardware renderers can do.

All this may sound weird coming from me, but I'm just thinking objectively. 

Looks like QS and MarkV both MAX_STATIC_ENTITIES at 512. Hunk_Allocing the static entities as they arrive sounds like a good solution, as long you can be sure things added to the hunk during CL_ParseServerMessage will stay around until the client is restarted.

We can be absolutely certain this is the case for static entities.

The client-side code (where the Hunk_Alloc would be done) adds efrags as the last part of setting up a static entity, and efrags depend on the world existing. The world is loaded into the hunk. Therefore the hunk must be valid otherwise the world itself wouldn't be valid.

Server-side static entities depend on the progs.dat to have been loaded first, and the progs.dat is also loaded into the hunk. So the same applies - if the hunk were somehow invalid then the progs.dat would also be invalid.

So both client-side and server-side we can conclusively prove that there are absolutely no circumstances in which it's not valid to use the hunk by the time static entities are loaded. 

Quake 1 and its artwork was designed around 8-bit color and the software renderer. By comparison, the opengl renderer has a "washed out" appearance as described earlier by the Winquake community and in a summary of Quake engine differences at Quaddicted. I agree that the opengl engine is superior in maps specifically designed for that engine, however, the remakes of Quake maps (ExMx) look better to me in the software renderer. These maps aren't designed around high resolution skyboxes and transparent textures.

I agree that the software renderer can't compete with the opengl renderer where it performs best. However, the software renderer has its strengths, such as portability (and performance) on non-gl systems, suitability to represent the original artwork and derivatives, (and better compatibility with past mods in the case of Winquake projects).

If there was a Winquake client with Quakespasm like software development practices, then it would be easier for developers to offer secondary compatibility to the software renderer, such as Sock and others have done. 

Maybe someone should code a very conservative WinQuake client that doesn't focus on effects and instead is essentially a WinQuake clone of FitzQuake/Quakespasm.

Would you agree with that statement? 

Fine! Next update I'll change static ents to array of pointers. And in cl_parse.c

Change this to Hunk_Alloc size(entity_y) ent = &cl.static_entities[i];

I guess it's a 2 liner anyway. 

3 liner. I'll have to zero fill the pointer array on CL_NewMap. 

Next update I'll change static ents to array of pointers. And in cl_parse.c

Nope, that's not what we're talking about.

What we're talking about is getting rid of MAX_STATIC_ENTITIES, getting rid of cl_static_entities and getting rid of cl.num_statics - delete them, altogether.

Then the code in cl_parse.c gets rid of this block:

i = cl.num_statics;
if (i >= MAX_STATIC_ENTITIES)
Host_Error ("Too many static entities");
ent = &cl_static_entities[i];
cl.num_statics++;

And replaces it all with this:

ent = Hunk_Alloc (sizeof (entity_t));

The thing is - there is atually no need to track static entities in an array; whether that be an array of entity_t or of entity_t * is irrelevant; it's not needed and can be gotten rid of. 

Beta Windows GL Build - Feb 4 2016

* no limit to static entities
* alpha masked models (0x4000 flag in QME 3.1)
* (with changed source files provided) 

Although obviously I didn't read your post since it was literally 3 seconds before I clicked submit, I did remove the array.

However, I do keep the count for the compatibility warning vs. original Quake. ;-) 

I dunno, wasn't the original Unreal software renderer 32-bit? 24 at least... And it ran pretty well. 

Maybe I'm wrong ... it's too early in the morning. 

I think you're actually making two arguments here, one of which is valid but the other of which is bogus, and unfortunately you're using the valid argument as justification for the bogus one.

The valid argument is that there is a pixel-art aesthetic in Quake, with lots of pixel-level detail in it's textures that the default linear filtering used by GLQuake ruins.

However, that should not be extended to try argue that a lot of the rest of Quake's original grunginess is either deliberate, or finely crafted, or efficiently coded, or whatever.

You see, the evidence is there in the code itself, in comments in the code, in sources like interviews, .plan files, Michael Abrash's Black Book, the Masters of Doom book, and so on. The thing is: id Software were very open about discussing Quake and it's development and none of this is a secret.

Take Quake's colormap for example; you absolutely positively cannot try to argue that it's in any way finely crafted, because it's not, and we have the proof. It's just a brute-force nearest-colour match: https://github.com/id-Software/Quake-Tools/blob/master/qutils/QLUMPY/QUAKEGRB.C#L203

Likewise .MDL files: you cannot claim that the reduction of position vertices to 8-bit is anything other than a crude scale and bias, with type conversion, because once again the evidence is there in the modelgen.c source code.

If you look at the code and other sources you'll see lots of "fixme" comments, you'll see Carmack's "I hate our model format!" remark, and more. It's a matter of public record that Quake's development was one year of experimentation followed by 6 months of an insane rush to get it finished and released. So please don't try to claim that there's much in the way of deliberate craft there.

The majority of modified winquake engines seem to be enthusiast projects to show off the latest visual feature. This is worthwhile for working on experimental features, but much less so for the mappers and gamers.

If you were talking about Quake clients back in 2002 or 2003, you'd be right because that's the way the majority of Quake clients actually were developed back then. I was there, I remember it. Making such a claim about an engine such as Fitzquake, which has an explicit goal of remedying the areas where GLQuake is inferior to software Quake, just shows that you haven't been paying attention. 

I am one of the people who loves the look of software quake, because of the hue shifts in different light levels, which imo gives it a more appealing and painterly look. If this is not intentional, as mh implies, it doesn't matter to me, I still like the way it looks. I also love the way the light is banded and not smooth. It's a proper retro look and has its own charm.

You lose the subtle shift of hues with GL engines, but obviously you get better preservation of the texture art, coloured lighting, fog and all the other cool stuff. 

The UT renderer is 16-bit, IIRC. However, it doesn't feature all the effects of its hardware counterpart, so it still fits my description. Combining all of those different effects together requires a lot of work.

I was going to use a 16-bit indexed color palette, with textures using only 256 colors from that, so most color transformations could be done with a single ( (texel << 16) | pixel) operation. But all tables together would consume lots of memory, and reducing their sizes to fit into the L3 cache would kill the smoothness I was trying to achieve. I even thought of an approach using a special texture format, but that would require creating special tools and extra work steps for the asset creation, not to mention that Quake compatibility would go out of the window. 

Ahh OK ... I love software rendering. It just has a character that hardware doesn't seem to retain. 

mh, thanks for the explanation of safety of Hunk_Alloc'ing static ents, helps me visualize things :) 

A 10 minute experiment on Mark V WinQuake. Some success ... but spans must be clipping each other so incomplete.

WinQuake screenshot:

screenshot 

2nd - 10 minute experiment .. WinQuake alpha masked models. Part 2.

Success!

screenshot

It works! Rather surprised in a way, nothing is ever easy with the internals of the software renderer. But this particular time, not so hard. 

Which method did you use? Doing a whole pass for each surface is easy, but not optimal. 

It was a 2 liner. Here's how it worked:

D_PolysetDrawSpans8

if ((lzi >> 16) >= *lpz)
{
byte bsrc = ((byte *)acolormap)[*lptex + (llight & 0xFF00)];

if (bsrc != 255) { // Baker: masked theory.
*lpdest = bsrc;
*lpz = lzi >> 16;
}
}

I feel like a complete jerk as result. 

Oh, that's a MDL. I thought it was a BSP. 

Awesome! 

wow baker, this is great! thanks for taking a chance on the alpha textures on models! 

Surely it should be "if (*lptex != 255)" - I don't know if palette index 255 can ever come out of the lighting calculation, but that aside, alpha should come from the base texture anyway.