"torch-lit" grids in Vanilla

[backwardsEric]

For the user option in Vanilla to color "torch-lit" grids, is the intent to only do that for grids lit up by the player's light source or for anything that's lit up and doesn't have light coming from the intrinsic glow of a room? From what I see in the code, it looks like the current behavior is the latter.

I'm trying to tweak the lighting model (in cave-view.c) so light/unlight from players, monsters, and bright terrain doesn't propagate through walls without breaking the visuals (in cave-map.c), including the "torch-lit" effect.

[Nick]

It's meant to be only grids lit by the player's light source. I vaguely thought the current behaviour wasn't right the other day, but didn't follow up.

[backwardsEric]

It's meant to be only grids lit by the player's light source. I vaguely thought the current behaviour wasn't right the other day, but didn't follow up.

It looks like the tests for square_isglow() in cave_map.c should use the light level instead since there's now more sources of light than squares marked with SQUARE_GLOW and the player's light source. If that's the case, I'm guessing the seen unlit squares should be marked with LIGHTING_LIT for non-necromancers and LIGHTING_DARK for necromancers. Does that sound right?

LIGHTING_TORCH would be applied to the seen squares in the player's light source radius that have a positive light level. Or should that only be done for grids where the light level matches the output of the player's light source to mimic the old behavior of applying LIGHTING_TORCH when square_isglow() was false?

[Nick]

It looks like the tests for square_isglow() in cave_map.c should use the light level instead since there's now more sources of light than squares marked with SQUARE_GLOW and the player's light source. If that's the case, I'm guessing the seen unlit squares should be marked with LIGHTING_LIT for non-necromancers and LIGHTING_DARK for necromancers. Does that sound right?

LIGHTING_TORCH would be applied to the seen squares in the player's light source radius that have a positive light level. Or should that only be done for grids where the light level matches the output of the player's light source to mimic the old behavior of applying LIGHTING_TORCH when square_isglow() was false?

I think square_isglow() is fine, but there needs to be change in how it is used vs square_islit(). The conditional in map_info() starting with (if g->in_view) I suspect needs to be rethought. I think seen unlit squares need to be LIGHTING_LOS (or LIGHTING_DARK if they're in a necro's dark radius). Then seen lit squares are LIGHTING_LIT, and lit squares in the player's light radius are LIGHTING_TORCH - I think that fits the new lighting scheme better than the old !square_isglow() behaviour.

[backwardsEric]

I think square_isglow() is fine, but there needs to be change in how it is used vs square_islit(). The conditional in map_info() starting with (if g->in_view) I suspect needs to be rethought. I think seen unlit squares need to be LIGHTING_LOS (or LIGHTING_DARK if they're in a necro's dark radius). Then seen lit squares are LIGHTING_LIT, and lit squares in the player's light radius are LIGHTING_TORCH - I think that fits the new lighting scheme better than the old !square_isglow() behaviour.

From grid_get_attr() in ui-map.c, LIGHTING_LOS can be a lighter color than LIGHTING_LIT so wouldn't interchanging LIGHTING_LOS and LIGHTING_LIT in your formulation be more intuitive visually?

[Nick]

From grid_get_attr() in ui-map.c, LIGHTING_LOS can be a lighter color than LIGHTING_LIT so wouldn't interchanging LIGHTING_LOS and LIGHTING_LIT in your formulation be more intuitive visually?

Or maybe LIGHTING_LIT should instead be lighter coloured than LIGHTING_LOS, which has the same effect. This stuff always confuses me, so take your best stab at it