| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
| |
The {get,set}_degrees methods of ray_def were only used by the chaos
bouncing code, removed in 0.14-a0-1819-g38ea213. The functions
geom::degrees and geom::degree_to_vector were only used by those
ray_def methods.
|
|
|
|
|
|
| |
This commit converts ASSERT(a && b) to ASSERT(a); ASSERT(b);
Assertions of the form !(a && b) are left intact, since there isn't an
obvious readability gain over (!a || !b).
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
It wasn't safe to change the angle of a ray that was on a corner of
the 45-degree diamond grid: if the new angle pointed inside the cell,
we would violate the _valid() checks. Have set_degrees (only called
for chaos bouncing currently) nudge the ray inside the diamond to
avoid this problem.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I had to rename distance() (in coord.h) to distance2() because it conflicts
with the STL function to compare 2 iterators. Not a bad change given how it
returns the square of the distance anyway.
I also had to rename the message global variable (in message.cc) to buffer.
I tried to fix and improve the coding style has much as I could, but I
probably missed a few given how huge and tedious it is.
I also didn't touch crawl-gdb.py, and the stuff in prebuilt, rltiles/tool
and util/levcomp.*, because I have no clue about those.
|
| |
|
|
|
|
| |
For way too paranoid and underinclusive values of "simple".
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
| |
"File:" is shown in your editor's status bar.
"Written by:" was used only for the first person who changed a file. We got
git for that now, and pre-DCSS history is so woefully inaccurate it doesn't
really matter.
|
| |
|
| |
|
| |
|
|
|
|
| |
This mostly puts && and || on the proper lines, per the style guide.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
In particular, round things to grid or corner when they're regarded
as on the grid or corner, and normalize direction vectors.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rays shot directly at diagonal walls should now reflect
appropriately. For this, diagonal walls are assumed to be
flat.
Example:
...###
@***##
...*.#
...*..
It's different from before, but I think it's probably a
nice change without huge impact.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Rays that reflected on corners could go too far.
Now passes the bounce test.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
ray_def::advance() and ray_def::bounce() now check pre- and post-
conditions on validity.
|
|
|
|
|
|
|
| |
Not sure if this helps with the chain lightning problems, but the
assertions should be less likely to trigger wrongly now.
Also deal with "on_corner" in bounce().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In particular, don't flatten outer corners, so air elementalists
aren't hurt too badly. Also, start special casing rays that pass
through corners, though they don't currently work the way I want
for diagonals.
Should now be usable including reflections.
TODO
- Diagonal wall reflections, both for corner rays and diagonal
corridors.
- Reenable chaos beam munging.
- Fix test/los_maps.lua. It would be easy to make the test pass,
but I should really work out what the result should be first.
- Generally clean up reflections code -- it's a mess.
|
|
|
|
|
|
|
| |
Also recenter the cardinal direction rays.
Before, we didn't have centered rays going straight north/south
or east/west, which was awkward for shift-firing.
|
|
|
|
|
|
|
|
|
| |
Reflection is modelled on diamond-shaped features, with gaps
filled in as far as they don't affect LOS.
Working on a case by case analysis: After normalization, a ray
leaves cell * through the south-east diamond face. Then determine
the line of reflection in each case.
|
| |
|
| |
|
|
|
|
|
|
|
| |
For one, rename ray_def::advance_and_bounce to ray_def::bounce.
Then, pass a grid of bools for adjacent cells which states which
cells are considered solid (reflecting).
|
|
|
|
|
| |
1. Add function to reflect vector at a line.
2. Implement scalar multiplication as external operator.
|
|
|
|
|
| |
Seems sensible given they modify the ray, even if it's not really
something intrinsic to a ray.
|
| |
|
|
|
|
|
|
|
|
| |
ray_def should now deal with hitting corners gracefully, though the
raycasting will still discard such rays. If a ray hits a corner
between two diamonds, it will stay there, and calling ray_def::pos
will arbitrarily give one of the squares -- this is not optimal,
but these rays shouldn't usually show up anyway.
|