That's just rounding to nearest rather than rounding down.

Yes, but in color calculations, every small inaccuracy amplifies the others. And as mentioned, gamma correction also plays a part and there may be issues with gamma correction.

Anyway, while I was open to explore how to improve the image in GLQuake and trying to figure out what's causing the differences in lighting, you're getting angrier. Better forget this conversation and leave it behind, it's not good to let things become unhealthy. 

Go underwater ;) 

In Mark V change Temp1 to 1024 and restart the map for particles. Its at 0 by default. Mark V is capable of displaying the same AD particle effects as QS. 

the waterwarping is a pretty great
but i'm not a fan of distortions
sorry

https://imgur.com/a/LXc2KYT 

Thanks spy and Redfield, that worked and it looks great now. 

If you let Mark V generate a new config file from scratch and check the gamma, it says that it's set a 0.75 even though 1 is listed as the default. I thought that this was a bit strange and I'm looking for some insight on it.

I also have a slight suspicion that this has an impact on mappers. I've played some maps recently that were incredibly dark at gamma 1 and contrast 1, but they were much more playable at Mark V's default gamma of 0.75. It makes me wonder if people are mostly just testing in Mark V causing their maps to be extremely dark in other source ports that default to 1/1 gamma/contrast. 

GLQuake defaulted it's gamma to 0.7 on non-3DFX hardware. Not sure why MarkV is doing similar but it seems too much of a coincidence. 

Mark V doesn't default gamma 0.75 (gamma 1 is default), but a certain revision did (revision 2? revision 3?) where I was merging with QuakeDroid. Johhny Law noticed different defaults in the Windows version and I corrected.

QuakeDroid defaults gamma 0.75 because gamma 1 is just too dark. 

On my Windows 10 machine, I didn't experience any Poorchop/Johnny Law mouse oddities.

Makes me wonder if maybe I could cause the issue somehow by installing maybe new Direct X drivers? I don't know.

If I can't experience an issue, makes it tough to guess. The mouse was fine for me.

If Mark V 1036 download link doesn't experience the mouse issue on Johnny Law/PoorChop's machine, I would suspect the issue relates to DirectInput which 1.99 switched to.

If that is the case, I could make DirectInput turn on and off and maybe default off. 

make DirectInput turn on and off and maybe default off.

I'm thinking that's probably the best option.

After playing Mark V and setting my sensitivity to an appropriate value to account for dinput, if I then use some other engine or a different version of Mark V, my sensitivity is way too high!

Here's another thought: If dinput is being used, automatically double the sensitivity value (rather, treat the value as doubled). That would probably get rid of the need for the Sensitivity slider to go up much higher to account for dinput being much less sensitive.

And if people wanna be more precise (even with the doubling happening behind the scenes), they can use decimal values, like sensitivity 10.5

But doubling the Sensitivity value for dinput would probably feel very close to the standard Sensitivity value when dinput is not being used. 

Bummer that you couldn't reproduce. I gave Mark V another few tries within the past few weeks and I had the same exact issues that Johnny Law spoke of - sometimes -mouse1 didn't register so I was firing indefinitely. Previously I just thought it was neither +mouse1 nor -mouse1 registering.

I'll spend some time playing around in 1036 to see if it works fine for me. 

I'm about to go camping, but I'll remember to get back to this later. 

Guys take your time, it's the summer. But yeah, if either of you can find out if 1036 does or doesn't have the issue, it can really shed some light on the nature of the issue. 

I've tested long enough by now that I would've noticed if I was still having issues but I haven't had any problems with 1036. I spent a while bunny hopping and playing through maps, and all of my mouse clicks registered just fine.

On a side note, I am getting some pretty terrible performance outside of id1 maps but that's another issue. 

Thanks for info. Helps confirm thoughts on issue. 

May I trouble you to test one more build ...

The 1080 build. download

And tell me if you have the mouse issue with 1080.

The results from 1080 should allow me to conclusively and quickly do a patch fixing exactly the "right" thing. (The alternative is some guesswork and if I am wrong it could take 3 attempts.)

I'd like to resolve the "Poorchop/Johnny Law Windows 10 mouse issue" right the first time. 

I played through some id1 and bunny hopped around for a long time, but I didn't notice any issues with mouse clicks registering. v1080 seems to be working fine here as well. 

Thanks! 

FWIW I just played through Amphitheater Of Abaddon using build 1080 and didn't notice any problems. 

(and that was me) 

Defaults to gamma .75 I can confirm this as I've installed it into new directories 3x this week. I usually reset my config by hand BTW so it's defaulting for sure. 

Heads up that uwjam is performing pretty badly with this mod. Seems the sprites are causing significant framerate issues. I will test some more this evening but wanted to check with anyone else and see if they were experiencing issues.

I just played in QSS and did not experience the showdown. 

I haven't tested uwjam with Mark V but I've played a few other maps that have some frame rate issues despite running perfectly fine in other ports. Not really sure how to troubleshoot something like this though. 

The MarkV D3D9 sprite drawing code is particularly sensitive to high numbers of sprites and will suffer performance problems in those situations.

Basically it looks something like this:

for (int i = 0; i < numsprites; i++)
{
SetState ();
DrawSprite ();
UnSetState ();
}

In order to deal with D3D9's well-known draw call overhead problems, the D3D9 wrapper code attempts to concatenate multiple draw calls with the same state into a single draw call, so that the whole thing can run with fewer draw calls.

The MarkV code (inherited from FitzQuake, in turn inherited from GLQuake) prevents it from being able to do that, because making any state change will break a batch.

Changing it to something like this will help a lot:

SetState ();

for (int i = 0; i < numsprites; i++)
DrawSprite ();

UnSetState ();

By SetState and UnSetState I specifically mean the alpha test state here; the polygon offset state only happens with Hipnotic bullet-hole decals and should be rare enough, whereas texture changes are something that has to happen so that's a state change that you'll just swallow. But this change on it's own should go a long way towards fixing things up.