Lighting issues

[PowerWyrm]

https://github.com/draconisPW/PWMAngband/issues/113

No idea what to do about this. I've copy-pasted the code from V and I don't understand why lighting was changed. Feels so weird.

I don't see anywhere in the code where LIGHTING_DARK is used. Old dark grids are now "lit". Old grids in los are now "lit". Old lit grids now use "los". What a mess...

This should be clarified I think. If using ASCII, "torch" is the brightest tone. Then "los" and "lit". "Dark" should be removed. When using tilesets, shaded tiles should be remapped: currently "torch" and "los" are mapped to the same tile (brightest), while "lit" is mapped to the intermediate tile and "dark" to the darkest. If we want to stay coherent with ASCII, "torch" should be tile 1, "los" should be tile 2 and "lit" should be tile 3.

[PowerWyrm]

Oh yeah.. and negative light doesn't work (try to summon a spider of Gorgoroth for example). Tiles around the monster are still seen as "lit" when they should probably be dark (cf Sil). Same with scrolls of Darkness: unless you don't resist, they do absolutely nothing.

[Nick]

I'll have to have a look at this.

[Nick]

OK, the principles of lighting are quite simple. The default for a known grid is LIGHTING_LIT, and all variations from that in this code snippet from map_info() in cave-map.c:

	if (g->in_view) {
		g->lighting = LIGHTING_LOS;

		/* Darkness or torchlight */
		if (!square_isglow(cave, grid)) {
			if (player_has(player, PF_UNLIGHT) && !square_islit(cave, grid)) {
				g->lighting = LIGHTING_DARK;
			} else if (OPT(player, view_yellow_light)) {
				g->lighting = LIGHTING_TORCH;
			}
		} else if (square_iswall(cave, grid)) {
			/* Lit walls only show as lit if we are looking from the room
			 * that's lighting them */
			if (!square_islitwall(cave, grid)) {
				if (square_islit(cave, grid)) {
					if (OPT(player, view_yellow_light)) {
						g->lighting = LIGHTING_TORCH;
					} else if (player_has(player, PF_UNLIGHT)) {
						g->lighting = LIGHTING_DARK;
					} else {
						g->lighting = LIGHTING_LOS;
					}
				} else {
					g->lighting = LIGHTING_LIT;
				}
			}
		}

		/* Remember seen feature */
		square_memorize(cave, grid);
	} else if (!square_isknown(cave, grid)) {
		g->f_idx = FEAT_NONE;
	} else if (square_isglow(cave, grid)) {
		g->lighting = LIGHTING_LIT;
	}

So LIGHTING_DARK is used for grids which are darkened, as in the radius of view of players with PF_UNLIGHT (necromancers). LIGHTING_LIT is now badly named; it is used for grids which are not in view, but that the player knows about. LIGHTING_LOS (or LIGHTING_TORCH if the relevant option is set) is used for grids in view for non-necromancers.

Negative light does not hide grids you already know about, although maybe it should darken them (LIGHTING_DARK). Scrolls of Darkness remove light - try reading one in lit room - but again don't make you forget the grids.

[PowerWyrm]

Ok I see. Since PWMAngband didn't port the Necromancer changes about lighting (the class already existed and I felt that the change didn't fit the original class), I don't have the part about PF_UNLIGHT.

What was confusing is that torch + los are mapped to the same tile, so when you use "view_yellow_light" you have yellow + white tiles in ASCII but the same tile with tileset.

What I will do locally:
- change squares that have negative light to LIGHTING_DARK
- change mappings in graf-xxx.prf so torch is mapped to LIGHTING_TORCH (tile 1), los is mapped to LIGHTING_LOS (tile 2) and lit is mapped to LIGHTING_LIT (tile 3); dark will also be mapped to tile 3 (I don't think we need a tile 4 for this)

[Nick]

That makes sense.

[PowerWyrm]

- change squares that have negative light to LIGHTING_DARK

Hmm this doesn't work since squares with negative light are automatically marked as "not seen". I need to do something like "squares that are in LOS with negative light" instead.

By the way:

if (g->in_view) {
		g->lighting = LIGHTING_LOS;

		/* Darkness or torchlight */
		if (!square_isglow(cave, grid)) {
			[COLOR="Red"]if (player_has(player, PF_UNLIGHT) && !square_islit(cave, grid)) {
				g->lighting = LIGHTING_DARK;
			} else[/COLOR] if (OPT(player, view_yellow_light)) {
				g->lighting = LIGHTING_TORCH;
			}
		} else if (square_iswall(cave, grid)) {
			/* Lit walls only show as lit if we are looking from the room
			 * that's lighting them */
			if (!square_islitwall(cave, grid)) {
				[COLOR="red"]if (square_islit(cave, grid))[/COLOR] {
					if (OPT(player, view_yellow_light)) {
						g->lighting = LIGHTING_TORCH;
					} else if (player_has(player, PF_UNLIGHT)) {
						g->lighting = LIGHTING_DARK;
					} else {
						g->lighting = LIGHTING_LOS;
					}
				} [COLOR="red"]else {
					g->lighting = LIGHTING_LIT;
				}[/COLOR]
			}
		}

		/* Remember seen feature */
		square_memorize(cave, grid);
	} else if (!square_isknown(cave, grid)) {
		g->f_idx = FEAT_NONE;
	} [COLOR="red"]else if (square_isglow(cave, grid)) {
		g->lighting = LIGHTING_LIT;
	}[/COLOR]

If g->in_view is true then square_islit is true. So:
- first red block is always false and can be removed
- second red block is always true so the condition can be removed and the else block can be removed
- last red block is dead code since LIGHTING_LIT is the default

[PowerWyrm]

Hmm this doesn't work since squares with negative light are automatically marked as "not seen". I need to do something like "squares that are in LOS with negative light" instead.

This is a pain to implement. Darkened tiles that are in plain sight of the character (aka there is a mob that darkens its surroundings in a room) should be obvious but it's not the case. And they don't update when you get out of LOS. Darkened tiles in a corridor appear dark when they shouldn't. I guess I'll leave those tiles "lit", not worth all the hassle for a few mobs with negative light...

[tangar]

Mobs with negative light's look cool though, gives a fresh feeling to gameplay I've added more negative light to wraiths and some other additional monsters in Tangaria.. There wasn't much stuff in terms of gameplay visualization for a long time in Angband, so it's quite impressing to see. But it's certainly not a critical issue and could be postponed until better times