I have played it since I own Quake II in Steam and the update is free.

But, I find nothing impressive. Saw lighting and shadow enhancements, but not much that make the mind go 'wow'.

Unless they completely overhaul the whole engine, textures and models there won't be much change from playing the original Quake II experience.

(For me the difference in Diablo II and the D2 Resurrection is more substantial and noteworthy. But then again, it's not a free update. I bought it but then got a refund after I found out it requires online connection to play the game. And there were connection problems for me.)

Well thats kinda the idea...

If they actually remade stuff, not just small improvements, there would be a topic on vogons "Hurdidur they destroyed my childhood, I need another gpu from ebay"

Malik wrote on 2023-08-13, 10:34:

But, I find nothing impressive. Saw lighting and shadow enhancements, but not much that make the mind go 'wow'.

Have you tried the RTX Quake 2? That one is definitely a bit more visually interesting. Maybe visually "curious" is more appropriate. Surreal.

But I hear you on the been there done that feeling.

swaaye wrote on 2023-08-13, 15:08:

Malik wrote on 2023-08-13, 10:34:

But, I find nothing impressive. Saw lighting and shadow enhancements, but not much that make the mind go 'wow'.

Have you tried the RTX Quake 2? That one is efinitely a bit more visually interesting

Yes, I should try that. Previously I had a Radeon GPU and didn't try it when the update was released. Now I have the Nvidia's card and forgotten about it. Thanks for reminding.

Malik wrote on 2023-08-13, 10:34:

Unless they completely overhaul the whole engine, textures and models there won't be much change from playing the original Quake II experience.

I'd think the game logic running slicker is a larger difference than the slight graphics/renderer makeover. id Tech 2 games tend to have this 10hz rust no one's brave enough to fix in source ports and they went and did something about it.

Other than that, altered maps, a new compass item (to hint you where ala UT3), and new enemy attacks are another major change (and are currently complaint #1) and would be quite misleading if that was written off like there's no difference from beyond the surface level.

"No changes below the surface", lolwut. The biggest under-the-hood change is that other than the core game logic they threw out the old engine entirely and rebuilt the game on theirs ("KEX") (which, incidentally, is proprietary, so we won't be seeing any non-official ports of this to other systems...). Haven't seen anyone actually claim that tho, so whatevs.

The guys at Digital Foundry just released a video where they analyze the Quake 2 remaster in great detail.

The few concerns that I had regarding the dynamic lighting implementation were completely alleviated by watching their analysis. This does indeed appear to be the definitive version of Quake 2, and I'll be checking it out for myself when time permits.

Apparently the new AI is based on the originally intended code that never made it to the final game, so it's not exactly a new invention by Nightdive at least. However, I can see some people not liking it, given it considerably changes enemy behavior.

Yea, a toggle to switch between them would be nice. I didn't see one in DF's video, unless I missed it.

The biggest flaw to me is that the brighter lighting is not normalized. That's the reason there's blotches of yellow piss lighting now. Some maps did have their lighting changed up so direct comparisons can't work (like q2dm1) so some of it is hidden, but not all of it. This also leads to the side effect of rendering that blonde head gib not drenched in red (damn i'm looking dead)

Tell someone at NightDive about R_BuildLightmap!

leileilol wrote on 2023-08-19, 20:46:

The biggest flaw to me is that the brighter lighting is not normalized. That's the reason there's blotches of yellow piss lighting now. Some maps did have their lighting changed up so direct comparisons can't work (like q2dm1) so some of it is hidden, but not all of it. This also leads to the side effect of rendering that blonde head gib not drenched in red (damn i'm looking dead)

Tell someone at NightDive about R_BuildLightmap!

Hey, that does look annoying. Honestly you're the best person for the job; not many know such details. They do have a discord server.

EDIT: I'll make a quick post there, see what they think.

EDIT 2: Got this response:

the blotches of yellow lighting are because of the difference in lighting tools and that some of the sunlights were blown out a […]
Show full quote

the blotches of yellow lighting are because of the difference in lighting tools and that some of the sunlights were blown out
a few maps had sunlight values of like 2500
I'm doing a pass on them, but it's nothing to do with our lightmap code - you can verify with ericw-tools lightpreview
the lightmap is 1:1 with what you see in-game

the colors from the color map go from map to GPU with no modifications, same as vanilla Q2
and the shader sources are in the KPF
so they can validate that we aren't doing anything weird with the lightmap
some maps just got brighter because of the new lighting tools
some definitely accidentally got overblown, like jail3
some have an intentionally bright sun
not all problems need a complex code reason for being there
sometimes it's as simple as "light source too bright"

I don't know what they mean by the head gib we have a new lightgrid which replaces the old "pick lightmap value underneath them" […]
Show full quote

I don't know what they mean by the head gib
we have a new lightgrid which replaces the old "pick lightmap value underneath them" for entity lighting, that's probably what they are seeing
but yes q2dm1's sunlight was overblown. it's not a lightmap issue, if you load the old BSP in Q2R it looks the same as the old one did

Copy code to clipboard

1        int maps;
2
3        for (maps = 0 ; maps < MAXLIGHTMAPS && surf->styles[maps] != 255 ;
4             maps++)
5        {
6            bl = s_blocklights;
7
8            for (i=0 ; i<3 ; i++)
9                scale[i] = gl_modulate->value*r_newrefdef.lightstyles[surf->styles[maps]].rgb[i];
10
11            if ( scale[0] == 1.0F &&
12                 scale[1] == 1.0F &&
13                 scale[2] == 1.0F )
14            {
15                for (i=0 ; i<size ; i++, bl+=3)
16                {
17                    bl[0] = lightmap[i*3+0];
18                    bl[1] = lightmap[i*3+1];
19                    bl[2] = lightmap[i*3+2];
20                }
21            }
22            else
23            {
24                for (i=0 ; i<size ; i++, bl+=3)
25                {
26                    bl[0] = lightmap[i*3+0] * scale[0];
27                    bl[1] = lightmap[i*3+1] * scale[1];
28                    bl[2] = lightmap[i*3+2] * scale[2];
29                }
30            }
31            lightmap += size*3;        // skip to next lightmap
32        }

this is from Q2. Our gl_modulate is implicitly 1
so there's no scaling done at all
there's no normalization of lightmaps in Q2
they just go right from A to B
(and the `m` value for main lightmap is 1.0, so, it's 1.0 * 1.0 * rgb)

Okay I got MSVC6 going to hack about ref_gl again, but I can only test my changes through PCem at the moment (win10 sucks). Strike is a very good piss map.

I've noticed 2023's lighting all have the "gl_modulate 2" appearance which really makes the non-normalized clamping look obvious. There's something else going on if they keep the modulate to 1 and the range is breaking somehow....

I think it'd be better if you directly talked to them to avoid potential misunderstanding.

It's in the quake-general channel.

we don't multiply the lightmaps at all, but it just looks like we do because the maps have overly bright lightmaps

just ask them to look at the raw lightmap data, they'll see it's just too yellow compared to vanilla. strike is one I need to tone the sunlight on

https://i.imgur.com/p6dYn9e.png […]
Show full quote

left is vanilla q2 GL with intensity 2 / gl_modulate 1
the top is the output in lightpreview, which matches this
the bottom is our lightmap, which is way too bright, but is rendered the same as it is in our engine

and if you compare it to the software renderer, the intensity difference on the rocks on the left is the same
so all is as it is. it's just our sunlight is too strong
if we were accidentally gl_modulate 2'ing, then it would look like this:

which, yes, does look like our piss output, but only because we have super strong suns that are basically washing the light out
which we're fixing. nothing is wrong with the code

before/after of me just adjusting sunlight values from 2000 to something sane like 150

leileilol wrote on 2023-08-19, 23:32:

Okay I got MSVC6 going to hack about ref_gl again, but I can only test my changes through PCem at the moment (win10 sucks). Strike is a very good piss map.

I've noticed 2023's lighting all have the "gl_modulate 2" appearance which really makes the non-normalized clamping look obvious. There's something else going on if they keep the modulate to 1 and the range is breaking somehow....

it would be better for you to join the nightdive discord to post there directly

https://discord.com/invite/nightdivestudios

edits to previous posts with collapsed quotes aren't very noticeable.

the issues aren't limited to just sunlight but anything emitting light. The sewer lights in base3 also show a difference (more slight but it's there). Q2's normalization also applies to dynamic lights so hand grenades can't turn a hallway into peppermint lighting and chainguns can't go beyond corn light into piss/white.

the colors from the color map go from map to GPU with no modifications, same as vanilla Q2

Vanilla Quake2 never simply just sent the lightmap to the GPU. Referring to R_BuildLightmap was my point on this. The normalization's the stuff after "if ( monolightmap == '0' )". (the 'else' stuff after that block are for Permedia users and doesn't apply here). Quake2's got a lot of software compensation for 1997 3d hardware which is how there's this rabbithole of fragmented Q2 experiences. (i.e. 3dfx only providing gamma correction normally at 1.7 gaslighting other GPUs as 'too dark', PowerVR and Permedia doing a weird alpha blend lightmap with less saturation, and gl_intensity is 2 to approximate overbright as doing combine or blendfuncs on 16bpp is a visual death wish and color control wasn't standardized across windows video drivers)

so uhh... I feel there should be normalization somewhere, regardless of gl_modulate implications. or maybe not clamping. (I haven't touched any ericw tools)

FWIW Quake 2021 also had lightmap issues (not shifting=old overbrights missing. Brightness slider to bring them back = sky/fullbrights washed out). Was never fixed there even after I aired about it to a nightdive dev, so i'm hoping my post here is in good faith to bring more attention towards the original lighting. A major problem is that these were surprise releases with no teasers for early feedback and there's barely opportunities to mulligan a renderer after it has set loose on multiple platforms.

(If there's ever a Quake3 rerelease to follow, that normalized lightmaps too and q3 looks very ugly with that ripped out, and Q3MAP2 compiles lights much darker by default so that's another problem to look forward to.)

Does values greater than 255 even happen with gl_modulate 1 or does lightmap values stay below 255 in that case? I suspect the latter. (Does q2 even have map lighting overbrights like q1 and q3?)

Most likely the clamping you believe is happening is baked into the lightmaps in the remaster .bsps, and not the engine doing it.

If you stuff the original vanilla .bsps into the remaster quake 2 pak0.pak it looks on par with vanilla q2 ref_gl with gamma 1.0, intensity 2 and gl_modulate 1 (minus textures being washed out because it doesn't do intensity like vanilla's way). I welcome you to challenge this assertion; name the location and bsp.

The conclusion is that the engine is not doing wrong, it is the lightmaps in the remaster .bsps that contain the difference.
Overall the bsps in remaster q2 are much brighter than the bsps in vanilla q2; most likely this is an intentional change in the remaster.
It is agreed by the devs that outdoor areas in the q2 remaster bsp's look like shit and are blown out to mostly uniform lighting. The devs are rebuilding the lightmaps for the next patch to rectify this.

EDIT: I also don't see what you mean with the q1 remaster overbrights. Here is a comparison between Winquake and Q1R looking at the torch bowl on the right of start.bsp from original id1. (brightness '0' in Q1R, and gamma 1.0 in winquake). If brightmaps needed to be * 2, it would become tremendously too bright.

Just to fully prove that here is a notorious overbright map example from kjsp1.bsp...running in Winquake vs Q1R:

I don't know why you have the impression that lightmaps in Q1R are being displayed at half their intended brightness. The kjsp1.bsp example especially would look much different if the engine was treating the lightmaps as you claim.

I think maybe you are being thrown off by all of the id1 maps (and q2 maps) being relit by more modern tools. This means more realistic light bouncing and propagation and so forth. This does mean some areas are darker, but at the same time other areas are also lighter. In my opinion the relit q1 id1 maps are not darker than the original id1 maps; maybe some corners are but overall in my subjective view it is about the same. Q2 remaster's relit maps certainly are much brighter than the originals. And in q2's case the light sources from the sky currently have tremendously too high brightness values which is being addressed.

Regardless of the subjective views, I think I have proven objectively that it is nothing the engine is doing wrong.

At least having a normalized hue could help.

gl_modulate 1 on vanilla q2 will only have dynamic lights exceed the luxels for normalization to happen. But if it's the compiler then that could explain some things as Quake2 isn't made for Quake's lighting range (thus ending up like "gl_modulate 2"). ref_soft does have overbrights (pics/colormap.pcx's first 32 rows are overbright ranges)), however the lightmaps are made from the highest RGB value which doesn't care about preserving luminance, so there's some volume loss there (and very evident in the same piss areas)

The maps provided with the rereleases are the representation of the games and are stuck that way on some platforms, so whatever impressions they give is what comes interpreted. I don't have access to their source code or tools and hadn't attempted to load custom maps in them. The lack of gamma correction already doesn't help.

leileilol wrote on 2023-08-20, 09:35:

I don't have their source code or tools and hadn't attempted to load custom maps in them.

The developers already released the source code for the 2023 Quake 2 remaster.

Should be here: https://github.com/id-Software/quake2-rerelease-dll

Joseph_Joestar wrote on 2023-08-20, 09:39:

The developers already released the source code for the 2023 Quake 2 remaster.

These are only the game modules.

As I explained and demonstrated above, Q2R applies lightmaps as if it were gl_modulate 1.

Meaning that spot in remaster strike.bsp looks like solid color piss because that's what the lightmap in the remaster bsp looks like. No amount of gl_modulate or gamma scaling is going to change anything because that's the source data, a solid color for most of that area. That is why they are giving it and most other outdoor areas another pass for the next patch by adjusting the sunlight strength so that it does not completely saturate the lightmap.

The quote from ND dev in eddman's post here demonstrates this.
Note for instance the shadows on the lower facing cliff on the left.
The remaster's current version (second last pic in that post) simply has no shadows there in the lightmap.
This is not a color conversion issue. It's not colors in the lightmap going higher than the highest RGB value. The lightmap simply doesn't have the shadows to begin with because the sky light source during map building was so bright it lit up all places those shadows would be.
The bottom-most image shows the same area with the sky lightsource toned down. The shadows on the cliff return. These adjustments are what the next patch will bring for most outdoor areas.

Not that anyone cares, but some of my impressions:

Finally a Kex engine release with good texture filtering. Good is a bit of an understatement. This is amazingly temporally stable even when using sharp textures. Unlike Doom 64 and Quake Remastered, I feel zero need to downsample this from 8K.

It's so smooth, everything is. It's not just the new AI that makes this feel like an entirely different game. I'm not sure exactly what's getting interpolated that wasn't before, but it's a much better game for it.

While getting rid of the jittering models is a huge improvement, I don't like the look of the lightning, it's too bright and saturated. Also shadows looked bad and I couldn't turn them off.

I wish there were options for a more authentic Quake 2 experience, but if anyone wants to play Quake 2 for the first time, this is what I'm telling them to go with.

Last time I played Quake 2 was like 6-12 months ago. I think I got lost a lot then, so the new compass option is probably nice. I didn't test the remaster for very long, I died somewhere near the start of the second unit.