Hmmm.

1. Does the SDL alternate build do this as well? SDL build

This would tell me if it were something about the pure Windows code or the all operating systems code.

2. Also: What do you have mouse1 bound to? Attack? Jump? 

1. Not nearly as often. I was hoping I could say "never", but I do think it missed a couple of mousedowns during a map playthrough. (While in comparison, it would not be unusual for mark_v.exe to miss a mouse event in the course of even an individual fight.)

2. +attack 

One probably-irrelevant difference I noticed: the mark_v.exe FPS display is pegged at 72 (my host_maxfps), while the FPS display in the SDL build wandered between 67 and 70 on the same map. 

Yeah, the probably irrelevant difference is just that. The DX9 is better at hitting exactly the 72 because it is faster.

re: mouse - Looks like more to do with Windows 10. I'm glad you are able to replicate the issue PoorChop experienced, increases odds of conclusively solving it. 

I'm glad too, good to know that I'm not the only one experiencing this. 

For the people who want to test it, here are some of the ID1 maps I've recompiled with lit liquids:
http://www.quaketastic.com/files/misc/litwater_id1mapexamples.7z

I've tried to figure out how to implement lightmapped translucent liquids in mh's GLQuake code, but hardware rendering isn't my thing and I've got no time to learn it. 

If I get time I'll do a 2.0 build. It's not overly difficult, like you indicate, just a matter of knowing what to do. 

So these lit water and things are looking cool. I am also wondering about the possibility to implement sv_protocol 999 support in Mark V.

The map I'm working on needs it, and I get a hard crash with hunc_alloc error similar to TerShib when I try to force it.

Is there a chance to see this happen? I would love to be able to see how the map handles in Mark V. 

Version 2 with translucent water support: http://www.quaketastic.com/files/misc/Q1LitWater_2.zip 

HUGE thanks!

Initially I thought "well, I can just combine the texture & lighting like the translucent mirrors does before blending", but then I found out that GLQuake's mirrors doesn't use lightmaps either. No way for clueless me to hack it in. 

New screenshots 

I have to be quite tiresome about this and confess that I'm still not a fan of the look. To me, the water no longer looks like water - it looks solid instead.

I'd also be of the opinion that light should go through translucent water.

But then, Quake's rendering was never really about being 100% realistic anyway. 

Well, it still looks better in Retroquad, mainly because of soft depth. But I'm confident that mappers will figure out good ways to use it.

And it should certainly be optional. 

cl_autodemo is really invaluable. If you could append the map filename to the file they generate that would be super helpful. Or at least part of the name. Ppl ask me to play their maps often and I use autodemo for this. Would be great to know what map a given demo is for outside of the exe. I am constantly renaming files. 

Redfield -- A large coordinates protocol would be a next year most likely. It wouldn't be sv_protocol 999, which sports lots of brokeness (I should make a video sometime).

Dumptruck - Mark V autodemo was adapted loosely from Qrack autodemo which does exactly that. If I am able to determine the cause of the Poorchop/Johnny Law mouse issue, I would probably throw in a "cl_autodemo 2" that like, Qrack, does exactly what you want. 

play_autos mydemo

To play all of mydemo0, mydemo1, 2, 3, 4 etc. automatically in a row.
And if someone leaves out, mydemo3 for instance, it would just skip to mydemo4.



Protocol 999 opt in cvar pretty please please. With sugar and a cherry on top. I've got a few Orl-size maps I'm working on that have a 99.9% chance of needing 999. 

Yes, would you make that video demonstrating 999's brokenness? Or at least briefly talk about it? Cause I'm curious to know. 

Yes, in time I will make a video.

mh has an expression "once you see something, you can't unsee it".

I think seeing in this case is going to be necessary. 

I'm the original designer.

The core idea is actually quite solid. It's based on 666, but with the addition of a bunch of opt-in features. The client and server negotiate which features to use, and the whole thing can gracefully degrade if a feature is unsupported.

It was always more about higher precision angles and more TE_ effects than big coords, or at least that's how it seems to me thinking back, but big coords was just one of the things it could also support. The important thing though is that it's extensible nature means that you could plug in your own big coords system if you wanted.

Being built on 666 means that it inherits all of an NQ protocol's weaknesses. That's not an attack on 666, it's an observation on NQ protocols in general. There are much better ways of doing all of this stuff; supporting big coords, more precision, more effects AND being more efficient in the data stream. NQ is a bit brute force, which is fine in simpler setups but hits scalability ceilings much faster. 

mh: it was always more about higher precision angles ...

Translated: nice smooth rotating doors and draw bridges.

(like Remake Quake could do -- as opposed to clunky hipnotic doors)

Fitz 666 didn't have enough angle precision resulting in walking on a drawbridge coming down to not feel jerky and the same for getting pushed by an opening door. Also the higher precision angles were used for some rotating effects in QuakeC. 

999 should be used on any map with bsp rotation such as drawbridges, pushable gates (ne_ruins), rotating path changers (like Dismal Oubliette but rotaty), etc.

OR maps as big as Orl's.

Still not sure what the problem with it is. 

It should probably just be renamed to "ORL Protocol." 

Nope. 999 does nothing for hipnotic rotation at all.

If you want to see real rotation, you'll have to play Remake Quake and trigger the draw bridge or find a rotating door.

Must use the Remake Quake engine -- Quakespasm doesn't support true rotation (nor does Mark V, it did briefly once upon a time but it led to the discovery of some oddness with existing Quake maps -- even a couple of stock Quake ones -- and was removed).

Sadly, true rotation sadly interferes some with existing maps where entities or even maps have the angles key set (and they shouldn't be). I think dis_sp3 is an example. 

a lot of games come with two *.exe's
one for windows 32 bits and one for windows 64 bits...quakespasm have quakespasm.exe and quakespasm-sdl2.exe... even quake has two exe's (normal and opengl)

maybe would be cool to have two markv.exe's, one for old maps and one for new maps with true rotation :)

just my two cents :) 

There's something strange I've spotted on your GLQuake code, in R_BuildLightMap.

This is your source:

for (j=0 ; j<smax ; j++)
{
t = *bl++;
t >>= 8;
if (t > 255)
t = 255;
dest[j] = t;
}


But this is the original source:

for (j=0 ; j<smax ; j++)
{
t = *bl++;
t >>= 7;
if (t > 255)
t = 255;
dest[j] = 255-t;
}


What's the reasoning behind that?
(255 - (t >> 7)) == (t >> 8) ?

Oh, wait, I've found it:
"shift the lightmap by 8 (jnstead of by 7) in R_BuildLightmap"
Overbrights, ok.

However, by doing that you lose precision, resulting in more abrupt discrepancies in light values across different surfaces, which is likely another reason why the lightmapped water in your GLQuake engine looks worse than in Retroquad.

Compare these shots:
GLQuake
Retroquad (with soft depth disabled)