| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Think of the map tiled with squares (the cells).
Previously, a ray was blocked by any part of an opaque cell
except the very corners (to allow looking through diagonal
maps -- we can move through those after all).
In the new version, the rays are the same, but a dungeon feature
is only considered to occupy the the central "diamond": convex
hull of the mid points of the edges. The corners of the
diamond are considered part of the feature, so vertically or
horizontally adjacent walls still block.
This has some effect on LOS: It's a bit more permissive on
diagonals and around corners.
The main advantage is that most rays will now have a footprint
(the sequence of cells it passes through) that is like the
old anti-aliased rays, without requiring any ray munging.
TODO:
* Make sure we don't hang because of stopping at a corner.
* Implement proper bouncing.
* Reenable setting/getting degrees for chaos beams.
|
| |
|
|
| |
These were used by the temporarily disabled chaos beams.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, rays were always cut short at corners: If a ray really
went like
.....
@**..
..***
.....
it was cut short (for find_ray/targetting/shooting purposes) to
.....
@*...
..***
.....
Note that a wall at the removed cell would still block the given
ray!
This makes ray footprint length matter, so rays are sorted to
prefer those that pass through fewer cells.
However, this gives quite a few ugly beams, in particular around
corners.
|
| |
|
|
| |
Signed-off-by: Steven Noonan <steven@uplinklabs.net>
|
| | |
|
| |
|
|
|
| |
Mostly rename functions from terrain.h that accept features of typ
dgn_feature_type from grid_is_* to feat_is_*.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During precomputation, we store the minimal cellrays by target
and sort them according to niceness.
find_ray now simply picks the first non-blocked ray to a
target, which means looping through the 10 or so minimal
cellrays with that target -- this should be a lot more
efficient. (An extended findray test went from 150s to 40s
(debug) and 40s to 26s (profile)).
The interface to find_ray has changed: cycle_dir=-1,0,1 was
changed to cyle=false/true since we never cycle in the other
direction anyway. find_shortest was removed: all rays to a
target had the same length all along, but now we also return
the straightest one automatically.
The change also eliminates the duplicate corner-cutting code
between ray_def::advance and find_ray as imbalance calculation
now relies on ray_def::advance.
|
| | |
|
| |
|
|
| |
Made some functions "static" and improved quadrant flipping.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This way the code is less likely to fall over with negative
coordinates.
|
| | |
|
| | |
|
