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) 

Yeah, that's overbrights. Yeah, it loses 1 bit of precision, but it still has 256 gradations of light - software Quake only had 64.

Rotation: higher precision can't fix Hipnotic rotation, that was born broke (fun fact: the hackiest mod is Nehahra, the second-most hackiest is Hipnotic). I can't recall the exact use case but it would have been something like a drawbridge that had the herky-jerkies with standard 8-bit angles. 

Retroquad uses the full 8 bits of precision, and it also compensates for the loss of precision. It has nothing in common with WinQuake when it comes to shading & texturing.

The fact is that the same light can be raycast to slightly different levels across the edges shared between different surfaces. The less precision is used, the bigger this difference can become. 

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