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? 

scrappy = perfectly adequete.

possible host_errors is better than unconditional host_errors, imho.
partial is better than none.

unless baker wishes to propose a different solution for large maps or jerky rotations? :P 

// protocol flags
#define PRFL_SHORTANGLE (1 << 1)
#define PRFL_FLOATANGLE (1 << 2)
#define PRFL_24BITCOORD (1 << 3)
#define PRFL_FLOATCOORD (1 << 4)
#define PRFL_EDICTSCALE (1 << 5)
#define PRFL_ALPHASANITY (1 << 6) // cleanup insanity with alpha
#define PRFL_INT32COORD (1 << 7)
#define PRFL_MOREFLAGS (1 << 31) // to do - support this...

if its protocol 999, then read a 32bit integer interpreted as the above flags. those flags define how it differs from 666.
If there's a bit set that you don't understand, error out or something.

there is no handshake/negotiation in rmqe, the server dictates and clients are expected to fall in line.

rmqe uses PRFL_INT32COORD| PRFL_SHORTANGLE| PRFL_EDICTSCALE
qs-oms3 uses PRFL_INT32COORD| PRFL_SHORTANGLE
fte uses PRFL_FLOATCOORD| PRFL_SHORTANGLE (which matches dpp5+ and fte clients, as well as avoids extra inprecision...).

ericw missed te 255 apparently (but so does fte, so whatever).
He also missed U_SCALE (which might come back to bite him with illegible server messages on rmqe servers).
QS should probably also warn if any protocol flags are set that his client doesn't support, again to avoid any bewildering illegible server messages.

personally I'd recommend against having the client distinguish between 666 and 999 other than to parse the flags. its simpler to treat them identically except with 666 having flags 0, but that's just my opinion because I hate lots of OR expressions all over the place. 

Obviously I want smooth rotation. Would ideas behind this protocol permit the following to evolve in it:

1) Prediction
2) Baseline compression/ack frames.
3) EF_FOLLOW, EF_NODRAW and other flags like DarkPlaces, view weapons
4) Possibly connectionless connections.
5) Team scores in multiplayer? 

"alpha insanity" -- that appears several times in the RMQ engine source code. Could you explain what that means? Is that how .alpha in FitzQuake 0.85 if 0 for a new entity should actually be --- I think 255 is full alpha, but I haven't looked. 

It's slightly, and amusingly, ironic that one aspect of Quake that RMQ very successfully recreated was the somewhat fucked-up development.

personally I'd recommend against having the client distinguish between 666 and 999 other than to parse the flags. its simpler to treat them identically except with 666 having flags 0, but that's just my opinion because I hate lots of OR expressions all over the place.

I'd agree with this recommendation; I can't remember what way I did it originally, but like I said - the intention was for 999 to be identical to 666 but for the flags, so this approach would work and be cleanest.

Got more detailed info on this?

There's not really much more to say aside from what Spike and myself have said. Protocol 999 was designed in a rush to meet a very specific requirement (a large map going beyond regular bounds) and was left unfinished. Despite that the intention was for it to be easily adoptable and extensible, so bit of forethought was put into how to achieve that. Hence the fact that you'll see that there's a "moreflags" bit already reserved, which signals to send another int (and IIRC the intention was also that bit 31 of this other int would in turn signify even more flags, and so on, so it should in theory be infinitely extensible).

"alpha insanity" -- that appears several times in the RMQ engine source code. Could you explain what that means?

I think this is in reference to the FitzQuake standard of having an alpha of 0 signifying full opaque. I understand why this was done (so a memset-0 would set a good default) but I remember being annoyed by it at the time. Probably unnecessarily annoyed too, I must add: juggling multiple things, 75% of which aren't even working and all of which are needed now for content does tend to stress one out a little. 

Kinn managed to get me excited about alpha textures on .mdl --- resulting in a couple of updates. I couldn't resist!

I guess I'll be meditating on the protocol 999 thing. My destination of choice is full, no compromises coop support in a way that would meet Spike's approval.

If protocol 999 is a pitstop on that road or not, I still can't tell although perhaps Spike can tell me.

re: the alpha insanity, I hear you ;-)

(I think I'll use the Pitfall logo for this post, I don't think I ever used that one before ... heh) 

in fitzquake, 0 means wateralpha for turb surfaces. other values ignore wateralpha entirely, thus it does make a distinction between 0 and 255.

the problem with extending protocol 999 is a case of who defines the flags.
my own extensions have a chained style, ultimately terminating in the protocol version that they're meant to be extending.
note that fte also has a handshake mechanism (but falls back to stuffcmds for nq).
see also: PEXT2_REPLACEMENTDELTAS|PEXT2_PREDINFO|PEXT2_VOICECHAT, if you're bored.
my personal fear is that everyone defines their own extensions and then I end up feeling like I have to implement 5 different variations of the same extension, each with a different svc or different order of flags etc. each subtly different that I can't share code despite them all fundamentally doing the same damn thing.
unfortunately there is no real authority when it comes to extensions. 

in fitzquake, 0 means wateralpha for turb surfaces. other values ignore wateralpha entirely, thus it does make a distinction between 0 and 255.

I was thinking more in terms of entity alpha and FitzQuake's ENTALPHA_* macros, with the memset-0 happening in ED_ClearEdict. 

My most ideal thing would be split-screen support with controller support. No idea how that would work but I would be overjoyed with that. 

baker, I don't really do approval, ever...
not sure why you're looking at me specifically about coop.

all I can really say is that coop without some easy way to punch holes through NATs is somewhat futile nowadays, from a usability perspective.
my xmpp thing used an XMPP server for ICE stuff, but needing people to create accounts etc is a significant issue, and even using existing acounts like gmail addresses is filled with far too many nightmares.
I keep meaning to use an irc server or something for it, but I can never find the motivation to try.
You could also run your own specialised server for it, but gah, infrastructure.