The win32/win64 bits was used just as an example of games that come with two exe's. I didn't want to imply that it has something to do with true rotation :)

Well, forget my lame example... My point is, why not compile two markV.exe's? One to play old maps and one (with true rotation) to play new maps that can use this feature? =D 

A induces B.

Image ---> video 

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

Believe me, I've rewritten the lightmapping code to use L16, RGB16, RGB32F, RGB10A2 and other formats over the years. I've written GPU lightmap implementations where the 4 styles are combined on the GPU with zero precision loss. I've stored exponential factors in the alpha channel and unpacked them in a shader. I've even done 4x overbrights with standard RGB8 lightmaps, losing 2 bits of precision.

This is not a big deal. For lightmaps the extended range is more important.

I guess a version 3 using L16 lightmaps might be in order to prove this. 

And just in case this needs to be explicitly stated.

The lightmapped water path uses exactly the same code as regular lightmapped surfaces. In GLQuake that's just multiplying 2 numbers, and nobody can claim that one way of multiplying 2 numbers gives a better or different result than another.

Frankly, I'm sick of hearing "Retroquad is better because..." - where can I download Retroquad, run it, study it's code and learn from it? Nowhere. You may as well be talking about touched-up screenshots for all the practical use that is. I've heard the mouth, show me the trousers. 

I was talking with some others about the way that Arcane's particle effects are rendered in different engines. I was wondering if you had any plans to bring Quakespasm's level of detail to the engine. QS doesn't really do a whole lot but there are some extra sprites for models like the flame. Their absence is pretty striking in Mark V. Here's what I mean:

QS:
https://i.imgur.com/5lvrO9y.jpg

Mark V:
https://i.imgur.com/rmgvRMq.jpg

I didn't even think that QS was doing anything in particular regarding Arcane's extra particle effects. I do know that QSS takes it a step further with smoke but I'm not expecting that level of detail in Mark V. I also know it's a pain when users make requests like this but don't get me wrong, I'm not asking for this to be turned into an existing engine. I just like the extra sprites and I was wondering if there were any plans for something like this. 

not sure what you mean, i believe the particles not showing up on mark V - it's on your side

i have no probs here
https://imgur.com/a/YBJ9pFq 

I have a feeling that you're not using a default setup. The flame itself in your photo looks like a sprite or even just a bunch of particles lumped together. In a clean install of Mark V and a fresh install of Arcane 1.7.1 with default settings, flames don't look like that. 

Version 3, with GL_LUMINANCE16 lightmaps; thse are 16-bit lightmaps with 7 more bits of precision than GLQuake without overbrights and 8 more bits than GLQuake with overbrights. I'd encourage anyone who thinks that bits of precision in lightmaps are super-impotrant to run this and see if they actually are. I'd even encourage double-blind tests.

http://www.quaketastic.com/files/misc/Q1LitWater_3.zip 

yeah, the patricles depend on temp1 in AD cfg settings 

it's QMB enabled in my case, you can turn them off 

Quake 2 engine, D3D9, with GPU-animated lightstyles and GPU dynamic lights; renders the lightmaps at the full original precision of the BSP light data lump; unlimited dynamic range for added dynamic lights.

http://www.quaketastic.com/files/misc/Quake2GPULightmaps.zip

It's a long time since I worked on this so I don't know how robust it is, but it should be fine for playing through the original SP missions. 

This was another one that went part of the way but I didn't continue with; no real idea why. It uses real-time lighting derived from the same light equations as are used in the original light.exe, but I never got round to adding shadows. Needs heavy optimization work.

http://www.quaketastic.com/files/misc/Q1RTLights.zip

Its fun to run around the original maps and look at how different the lighting quality is, but I wouldn't play Quake with this. Also, any map compiled with any more modern tool will probably look hellish weird because I don't have support for all of the other options added since light.exe was originally released. 

I was talking with some others about the way that Arcane's particle effects are rendered in different engines.

https://imgur.com/a/3oSpkFn

this pretty much matches the qs screenshot 

not bad

https://imgur.com/IrDhF6Z

https://imgur.com/kFW0TIU

it seems it's a great alternative to KMQ 

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.