lighting: fix long-standing issue with invisible objects

[rouming]

This PR fixes an issue with visibility, where objects in a straight line of sight parallel to the X or Y coordinate lines become invisible. The #6641 is a perfect illustration of the bug.

What's worse, the objects are invisible to the observer (player) regardless of the distance to that objects. The main requirement of a bug reproduction is line of sight parallel to the X or Y coordinate lines.

The actual bug lies in the visibility checks of diagonally adjacent tiles of a point, hit by the cast ray. We've cast an approximated ray on an integer 2D grid, so we need to check if a ray can pass through the diagonally adjacent tiles. For example, consider this case:

       #?
      ↗ #
    x

The ray is cast from the observer 'x', and reaches the '?', but diagonally adjacent tiles '#' do not pass the light, so the '?' should not be visible for the 2D observer.

The trick is to perform two additional visibility checks for the diagonally adjacent tiles, but only for the rays that are not parallel to the X or Y coordinate lines. Parallel rays, which have a 0 in one of their coordinate components, do not require any additional adjacent visibility checks, and the tile, hit by the ray, is always considered visible.

For the rays that parallel to the X or Y coordinate lines, the adjacent visibility check always degenerated to the actual ray point visibility check, which is considered invisible if it does not allow light to pass through, and this is the actual bug.

To fix the issue, ensure the tile is always considered visible if the ray that hits it is parallel to the X or Y coordinate lines.

To better demonstrate the problem, here's a straightforward simulation written in Python:

https://gist.github.com/rouming/25c555720f93735442c2053426e73bf5

The code simulates lighting from the DevilitionX implementation, by placing the observer 'x' in the center of the grid. The observer is surrounded by walls and 5 random obstacles. Tiles, marked as '.' are visible tiles, depict, how rays spread around the observer. The first matrix output shows the bug: no walls and obstacles are visible in the line of sight parallel to the X and Y coordinate lines.

             invisible wall is a bug
                  V
    # # # # #   #   # # # # # # #     
  # . . . . .     . . . . . . . . #   
  # . . . . .     . . . . . . . . #   
  # . . . . . .   . . . . . . . .     
  # . . . . . . # . . . . . . .       
  # . . . . . . . . . . . . # . . #   
  # . . . . . . . . . . . . . . . #   
  # . . . . . . . . . . . . . . .     
    . . . . . . . x . .             < invisible obstacle is a bug        
  # . . . . . . . . . . . . . . .     
  # . . . . . . # . . . . . . . . #   
  # . . . . .   . . . . . . . . . #   
  # . . . .     . . . . . . . . . #   
  # . . .       . . . . . . . . . #   
  # . . .       . . . . . . . . . #   
  # . .         . . . . . . # . . #   
    #         # #   # # # #     #
                  ^
            invisible wall is a bug

In contrast, the second matrix output (with the fix applied) does not exhibit this problem. Also, note the box corners are not visible due to the adjacent visibility checks, which are functioning correctly.

    # # # # #   # # # # # # # # #     
  # . . . . .     . . . . . . . . #   
  # . . . . .     . . . . . . . . #   
  # . . . . . .   . . . . . . . .     
  # . . . . . . # . . . . . . .       
  # . . . . . . . . . . . . # . . #   
  # . . . . . . . . . . . . . . . #   
  # . . . . . . . . . . . . . . .     
  # . . . . . . . x . . #             
  # . . . . . . . . . . . . . . .     
  # . . . . . . # . . . . . . . . #   
  # . . . . .   . . . . . . . . . #   
  # . . . .     . . . . . . . . . #   
  # . . .       . . . . . . . . . #   
  # . . .       . . . . . . . . . #   
  # . .         . . . . . . # . . #   
    #         # # # # # # #     #     

[AJenbo]

Nice, this always bugged me.

[AJenbo]

This may need a new time demo to be recorded to it to pass the tests.

[rouming]

@AJenbo pushed the change related to the clang-format output, please take a look.

This may need a new time demo to be recorded to it to pass the tests.

I'm not familiar with the development process here, not sure is clear to me what has to be done exactly.

[AJenbo]

One of the test is an input recording that plays the two first levels in the shareware. The changes you have made here affects game play so the demo recording no longer syncs, since the change is intentional a new recording has to be made so that it matches the new behavior.

This is done switching to the shareware mode, and copying the save from the test folder to your save folder, starting the game with the following arguments:
./devilutionx --record 0 --create-reference
Then play the two first levels and exit and add the .dmo and reference save to the test folder.

[rouming]

Sweet, thanks for the explanation. I see that timedemo_test complains that file "game" has different content. I assume that because of the differences in the dFlags array, which now should have more "visible" objects around the player.

Are there any requirements for the demo? Like certain actions? I played back the original WarriorLevel1to2 and the player dies on the 1st dungeon and never reaches the 2nd.

[StephenCWills]

I played back the original WarriorLevel1to2 and the player dies on the 1st dungeon and never reaches the 2nd.

Seems to be because this PR completely breaks the timedemo recording, right from the start. I'm not entirely sure why it would do that, unless maybe the change to visibility causes a monster to wake up early and completely skew the sequence of random numbers.

[AJenbo]

Here is a recording of the time demo from a couple of versions ago: https://www.youtube.com/watch?v=prPVymbw3t0

What you want is to trigger as many things as possible:

• Attack animals and undead with sharp and blunt weapons.
• take damage with and without and armor and with and without a shield.
• use a bow
• use a spell
• repair an item
• break and item
• go level up and apply stats to each type
• enter the secound level
• identify an item (use it both before and after)
• drink both mana and healing potions

Note that you do not want to trigger time sensetive things like:

• using shrines (there message is there for x sec)
  Preferably don't die as that makes it harder to see if there was an issue or not.
  Preferably make the recording short so that it doesn't take up a lot of KB and can be processed quickly when running the tests.

Once submitted you will be able to see if there is a significant difference in test coverage which will let you know if you did more or less things then the previous demo.

[StephenCWills]

• using shrines (there message is there for x sec)

Is that still an issue? I thought I fixed it. #6516

[AJenbo]

Oh i guess not, i suppose that's something we could improve in a new recording then.

[rouming]

I played back the original WarriorLevel1to2 and the player dies on the 1st dungeon and never reaches the 2nd.

Seems to be because this PR completely breaks the timedemo recording, right from the start. I'm not entirely sure why it would do that, unless maybe the change to visibility causes a monster to wake up early and completely skew the sequence of random numbers.

That's actually awesome. I made a side-by-side comparison: https://youtu.be/nhpuuHSKGgk . It all started with the first monster not being killed, then the player had to go to the left arch instead of the right one. Basically, this is a perfect illustration of the butterfly effect. And we can take the reasoning even further: how foresight (seeing of previously invisible objects) leads to death, how the amount of knowledge does not bring happiness, how curiosity becomes a curse :)

I'll prepare the new timedemo.

[rouming]

@AJenbo did the demo, now the test seems passes successfully, please take a look.

[rouming]

Folks, while recording the demo on the latest master I noticed the bug with the health globe. The bug is well depicted on the video I've made: https://youtu.be/UIWqjRxAe3g?t=183 - starting from the 3:05, when the player got a new level, the health was restored, but the health globe reflects that in a weird way. Something known?

[julealgon]

Such an awesome change this is. Great stuff @rouming

[Yggdrasill]

The bug is well depicted on the video I've made: https://youtu.be/UIWqjRxAe3g?t=183

This seems like the same bug as #7835, except for the health globe rather than mana globe.

[rouming]

The bug is well depicted on the video I've made: https://youtu.be/UIWqjRxAe3g?t=183

This seems like the same bug as #7835, except for the health globe rather than mana globe.

Thanks, will post there then.

[rouming]

Converting this to draft, will return to this PR in a couple of weeks.

[rouming]

Initially, I hoped to avoid adjusting the radius, but it turns out this isn't straightforward for any radius value passed to the DoVision function. To accurately create a circle of vision rays around the player, the simplest approach as it is now: is to use an array of length adjustments and then decrement as needed. Remade a timedemo. Now should be all good. Hopefully, I have not missed anything. @AJenbo please take a look.