I think the ideal situation is dynamic arrays when possible, with some sanity check hard limit, and also "xxx exceeds standard limit of yyy" messages when "developer 1" is set.

- still runs as well on old computers / vanilla maps as an engine with vanilla limits would
- mappers can check how high over vanilla limits they are.
- eliminates frustration for players running huge maps


In practice there can be challenges doing this for each different limit.

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. 

map viewer

Mark V has a map browser already... maybe it could do with a mod browser. To be honest is it necessary? Most maps come with a readme txt with instructions. 

To be honest is it necessary? Most maps come with a readme txt with instructions

I once tried getting some people at work into Quake. The short answer? Yes. 

Doesn't something like QuakeInjector solve the noob issue? 

I didn't know about that thing. I guess I'm the noob :} 

The original was coded efficiently and there's no reason not continue in the same philosophy.

It actually wasn't. The original was coded for an 8 MB MS-DOS machine with no multitasking and no virtual memory, so (1) it could freely grab all of the memory in a machine without worrying about having to play nice with other programs, and (2) if it ran out of physical memory it would explode.

There's vestiges of this all through the original memory management system. Zone memory is one example; the whole LRU/MRU/flush/evict thing in cache memory is another.

When doing any analysis of Quake's memory subsystem you absolutely have to bear in mind that it was coded for an OS and for constraints that no longer exist.

And of course, with specific reference to static entities (and a few other things), there is always this: https://github.com/id-Software/Quake/blob/master/WinQuake/cl_main.c#L46 

The quake engine was coded for efficiency in the use of memory and stability. For one, the so-called modern engines typically have bugs which are not detectable because of the slack memory handling in a modern OS, whereas the popular DOS extenders were strict. This enables detection of memory related bugs and stable code.

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

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