The full range of light scales per the BSP format can't be represented by standard 2x overbrights. "z" is double-bright, so with 4 lightsyles combined I make that 11 bits per channel, and that's not including dynamics.

I guess that the point is, you're always going to be losing precision. 

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

32-bit vs. 64 bit doesn't have anything to do with rotation. Remake Quake engine with true rotation is a 32-bit.

Half-Life has had true rotation since 1998 and it evident in all aspects of the game.

There really aren't any advantages for 64-bit on Windows that I can name, except 64-bit uses a bit more memory because pointers are twice the size.

The Linux build of Mark V, for instance, has always been 64 bit. 

I guess it wasn't clear that I'm implying that the loss of precision can be compensated for by doing t = (t + (1 << 7)) >> 8. It's exactly the same principle of adding 0.5 to the velocity to fix the gravity issues in low framerates. It's obvious.

Anyway, it may be not enough. Besides this compensation, Retroquad performs color correction, gamma correction, brightness correction and multiple kinds of error diffusion.

Maybe the results will be better when your code gets ported to Mark V or other advanced engines. 

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.