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. 

You are right. I only spent a few minutes, tried a quick experiment and it worked. I think the above happens to work because 255 is a fullbright. 

Windows Open GL + WinQuake | Windows Direct X Version

* Alpha masked models support (set .mdl's QME 3.1 0x4000 flag)
* Alpha masked models for WinQuake version too
* No limit static entities
* RCON remote console support (ProQuake compatible) + full NAT fix.
* sv_map_rotation "dm3 dm6 dm4 dm6" --- map rotation via cvar - repeated names fine, it won't get confused.
* May have (all?) obscure mod bug-fixes that NightFright pointed out.
* Install from Quaddicted. Type "install travail" for instance. Type "uninstall travail" to uninstall.
* No dependencies at all. Just single .exe

Source. Maybe next time will update Mac build. 

 

will this play orl's new map set? 

ericw did a very kind thing by making a scrappy custom Quakespasm executable with "protocol 999" support for orl's map so more people might try it.

As I understand it, it isn't true protocol 999 and wouldn't be able to play, for instance, RemakeQuake like the RemakeQuake Engine can screenshot.

So it's not a real protocol -- it's just something kind that ericw did for ORL. 

It's been a while but IIRC protocol 999 was deliberately designed to be modular; if I've got this right, a standard protocol 666 data flow is also a valid protocol 999 data flow with the exception of the protocol version number and an extra int which is used to specify what optional features are used.

Again working from memory, clients and servers then use that extra int to negotiate what set of these optional features they both have in common, and from there features are enabled or disabled.

So in theory even a "scrappy protocol 999" is therefore also a valid protocol 999.

But like I said, this is all from memory. The last released version (which was not supposed to be final) may or may not support all of this, but what I've just described is certainly what the intention was. 

This interests me. It's one of the goals of my protocol experiments.

Got more detailed info on this?