This test covers a few vision bugs:
1. VisibilityInStraightLineOfSight - test case checks the visibility
of objects in a straight line of sight parallel to the X or Y
coordinate lines:
https://github.com/diasurgical/DevilutionX/pull/7901
2. NoVisibilityThroughAdjacentTiles - test case checks that nothing is
visible through the diagonally adjacent tiles:
https://github.com/diasurgical/DevilutionX/pull/7920
3. VisibleObjects - generic test, which makes sure some objects are
visible, but some - are not.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
* lighting: fix long-standing issue with invisible objects
This fixes an issue with lighting, where objects in a straight line of
sight parallel to the X or Y coordinate lines become invisible. Issue
#6641 perfectly illustrates the bug (see video attached to 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 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, '.' are marked as visible,
were hit by the cast rays. 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. 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.
Fixes: #6641
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
* lighting: rename variables and add explicit comments for clarity
This patch improves clarity and readability without affecting
functionality:
1. Renames `VisionCrawlTable` to `VisionRays` and `crawl` to
`rayPoint` for better clarity on the purpose of these structures.
2. Renames `factors` to `quadrants` to reflect the actual purpose of
the mirror operation along the X or Y coordinate lines.
3. Adds more explicit comments to simplify the understanding of the
ray casting algorithm.
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
* test/WarriorLevel1to2: update timedemo
Recent visibility fix impacts game state and causes the timedemo to
behave completely differently, resulting in a butterfly effect:
https://youtu.be/nhpuuHSKGgk. This patch updates the timedemo, which
was recorded with the visibility fixes applied, ensuring the tests
pass successfully. Here's the latest timedemo video for the future
generations: https://youtu.be/udGcWmarYNI
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
---------
Signed-off-by: Roman Penyaev <r.peniaev@gmail.com>
* Shift item order when selling instead of using last item to fill the slot
Player has items i1, i2, i3, picked up in that order.
Previous Behavior:
1. Sell window at vendor shows i1, i2, i3.
2. Player sells i1
3. i3 is last in list and replaces i1
4. Sell window now shows i3, i2.
New Behavior:
1. Sell window at vendor shows i1, i2, i3.
2. Player sells i1
3. i2/i3 are shifted in index position down to fill the gap left by previous index.
4. Sell window now shows i2, i3.
* Remove whitespace
1. Fixes DrawStringwithColors kerning fit handling and newline handling.
2. Splits tests into one file per function call, making it easier to compare diffs and add new tests.
Also adds `--update_expected` argument to update the expected files with actual results.
The previous implementation didn't behave quite like A-* is supposed to.
After trying to figure out what's causing it and giving up,
I've reimplemented it in a straightforward manner.
Now it seems to work a lot better.
Also increases maximum player path length to 100 steps.
We still only store the first 25 steps in the save file for vanilla
compatibility.
In C++, globals initialization order accross translation units is not
defined. Accessing a global via a function ensures that it is initialized.
This will be needed for #7638, which will statically initialize change
handlers after the Options object has been initialized.
We still have some issues preventing even data_file_test from depending
on the world:
1. `options` transitively depends on everything because of the change
handlers.
2. `sound` depends on `monster` via `sgbSaveSoundOn` and
`monster` depends on `sound` via `gbSoundOn`.
This does not fully address the issue of most everything
being a giant library but it's a start.
Note that the libraries are OBJECT libraries, so they
may (and currently do) contain references to missing
symbols.
Also fixes the implementation of transitive dependency
support for OBJECT libraries.
1. Moves more assets-related stuff from `init` to `engine/assets`.
2. Removes `SDL_audiolib` dependency from `soundsample.h`.
3. Cleans up some unused/missing includes.
Untangles dependencies by splitting up `engine.{h,cpp}` into 3 files:
1. `primitive_render`
2. `ticks` -- only contains `GetAnimationFrame` for now.
3. `GetWidth2` renamed to `CalculateSpriteTileCenterX` and moved to `levels/dun_tile.hpp`.
1. Load assets from the bundle on Mac.
2. In timedemo_test, load MPQs before overriding pref path,
so that they can also be loaded from the user/system location.
3. Fix various double directory separators ("build//assets" etc).
Our implementation has a more modern interface and only
supports the features that we care about.
It always outputs `\n` as newlines and does not output BOM.
The modern interface eliminates awkward `c_str()/data()` conversions.
This implementation preserves comments and the file order of sections
and keys. New keys are written in insertion order.
We now also support modifying and adding default comments,
which may be a useful thing to do for the especially tricky
ini options (this PR doesn't add any but adds the ability to do so).
Sadly, this increases the RG99 binary size by 24 KiB.
I'm guessing this is because the map implementation generates
quite a bit of code.
Note that while it might seem that using `std::string` for every key and
value would do a lot of allocations, most of these strings are
small and thus benefit from Small String Optimization (= no allocations).
staphen
Gleb Mazovetskiy
Eric Robinson
Anders Jenbo
Roman Penyaev
Yggdrasill
chasedjones88
Andrew James