3D vision of lower levels with distance fog

[Rewryte]

Summary

Features "3D vision of lower levels with distance fog"

Purpose of change

The current method of drawing lower z-levels removes plenty of visual information that should otherwise be assessible to the player character.

Describe the solution

Draw lower z-levels. Naturally, with the top-down perspective most tilesets use, a major issue would be that there is no way to tell which sprites belong to which z-level. To solve this, t_open_air and other transparent terrain can now be assigned a semi-transparent sprite to create fog or other effects that emulate distance. Tileset does not have a sprite? The fallback graphic for transparent terrain now includes a semi-transparent overlay. (The following picture uses clairvoyance for clarity.)

It adapts its brightness to ambient lighting giving night lights some extra flair.

Number of z-levels displayed is determined by 3D vision settings. Setting vertical view distance to 0 will revert drawing behavior to that prior to this PR.

Describe alternatives you've considered

Testing

• LOS works as expected
• Works with night vision / clairvoyance
• Respects experimental 3d vision settings for spotting creatures
• Mostly works with map memory (There are a few spots on lower z-levels that do not get recalled when they should. More feedback on this would be helpful.)
• Mostly working on isometric tilesets but disabled for now due to some issues with height_3d. Future plan if this gets merged.

Performance test: #65738 (comment)
Modding example: #65738 (comment)

Additional context

This PR modifies tile drawing which indirectly affects the map memory system. I would appreciate it if someone familiar with the memory code could look through this to make sure it wouldn't cause any complications.

The following changes will be made to non-isometric tilesets:

• t_open_air is now used as the fog between z-levels so if it is assigned a blank sprite, it will be unassigned. Having a custom t_open_air is still recommended for a minor performance improvement.
• If tr_ledge is not assigned a sprite, it would be assigned a blank sprite, typically replacing t_open_air. This is to prevent it getting replaced with an opaque placeholder.

[RenechCDDA]

I'm not qualified to comment on the technical implementation, but are you aware of Kevin's previous concerns with similar features? (See: #61074 (comment))

[Rewryte]

@RenechCDDA Can't say that I am. Thanks for bringing this up. I'll look into it when I have the time.

[Qrox]

Kevin's previous concerns with similar features? (See: #61074 (comment))

If I may chime in, curses lacks full color support so the best that can be done on curses is probably to darken the symbols and/or use the . symbol one or two level below, and completely hide anything any further.

I'm not sure about the memory usage though, it could increase a bit due to caching and whatnot now that more sprites are drawn, but it probably would not be very significant because the current implementation, from what I can tell, draws the additional sprites with the existing tile context so at its worst it will be similar to the memory consumption when you zoom out.

@Rewryte My concern would be with the time it takes to redraw though, so it would be nice if you could run the framerate benchmark in the debug menu and post the results before and after this change.

[Rewryte]

Thanks for your reviews @Qrox. It might take me a while to go through them. Still trying to get my compiler to make friends with curses. I did a quick test on private working memory usage:

Before changes: 1189460K
After changes: 1202828K
After changes (custom fog): 1234056K

Tried using the debug benchmark function but performance is capped to my framerate despite using exclusive fullscreen and disabling v-sync on my GPU. Any ideas?

[Qrox]

Perhaps the 3D FOV depth option should mention the new 3D vision in its description. Also I think this might be a great chance to enable 3D FOV by default, since it has been working without noticeable issues for a while and there has been complaints that it isn't enabled by default.

[Rewryte]

Looks like setting 3D FOV as default breaks tests. No error message, just an indefinite freeze. I'll take a look at the tests. Probably will revert the option if it is not something I can fix in quick order.

[bombasticSlacks]

This is looking good to me, does merging this without the tileset changes break the tilesets? Those as I understand it need to be made in the tileset repo / handled with the build scripts for the tilesets.

[Rewryte]

This is looking good to me, does merging this without the tileset changes break the tilesets? Those as I understand it need to be made in the tileset repo / handled with the build scripts for the tilesets.

Nope. They are for most part the same changes so these are just a temporary measure until the script built changes take over.

[Fris0uman]

Would it possible to have other terrain render if the sprite is transparent?

Like here be able to see through t_gutter instead of black?

[Fris0uman]

Never mind, the thing below gutter is a wall anyway

[Qrox]

I think you can use connection groups to match the gutter sprite with the surrounding roof tiles instead. It might be possible to support non-open-air semi-transparent tiles by adding a flag similar to NO_FLOOR, but even then it will only draw the wall sprites below (as you've already mentioned) which might not match the roof sprites.

[Rewryte]

Would it possible to have other terrain render if the sprite is transparent?

Pretty much any terrain that returns false on the dont_draw_lower_floor function can be made transparent. This is mostly the NO_FLOOR flag but adding more should be trivial.