| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
ray_def::advance() and ray_def::bounce() now check pre- and post-
conditions on validity.
|
| |
|
|
|
|
|
|
|
| |
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).
|
| |
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
| |
Don't store ray lengths in a second array, instead store them in
the rays. Also store their starting index, which makes the
ray_coords indexing a little cleaner.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This way the code is less likely to fall over with negative
coordinates.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
lines.
|
| |
|
|
|
|
|
|
|
| |
los.cc: basic raycasting algorithm; losight(), see_grid() etc.
ray.cc: ray_def implementation.
mon-los.cc: monster_los
This includes adding a bunch of #includes; there's probably some
obsolete includes of view.h now.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
NOTE: This uses a weird hack to prevent a bug which sometimes happens when a
chaos beam is fired into the corner of a room. I think it's caused by
ray.advance(true) and ray.regress() not being symmetrical.
git-svn-id: https://crawl-ref.svn.sourceforge.net/svnroot/crawl-ref/trunk@7783 c06c8d41-db1a-0410-9941-cceddc491573
|
| |
|
|
|
|
|
|
|
|
| |
into a file crawlhistory.txt in docs/obsolete.
I used a perl script to do this under the assumption that all these
change logs used the same system following the keyword "Change History".
git-svn-id: https://crawl-ref.svn.sourceforge.net/svnroot/crawl-ref/trunk@6930 c06c8d41-db1a-0410-9941-cceddc491573
|
| |
|
|
| |
git-svn-id: https://crawl-ref.svn.sourceforge.net/svnroot/crawl-ref/trunk@5940 c06c8d41-db1a-0410-9941-cceddc491573
|
| |
|
|
|
|
|
| |
for my code refactoring.
git-svn-id: https://crawl-ref.svn.sourceforge.net/svnroot/crawl-ref/trunk@2103 c06c8d41-db1a-0410-9941-cceddc491573
|
|
|
crawl_environment, player and monsters classes have been left in
externs.h, which necessitates that all of the enums references by
those classes stay in enums.h, since you can't forward declare an
enum. However, it's a start.
Also, portions of misc.{cc,h} have been split off into traps.{cc,h},
place.{cc,h} and terrain.{cc,h}
git-svn-id: https://crawl-ref.svn.sourceforge.net/svnroot/crawl-ref/trunk@2095 c06c8d41-db1a-0410-9941-cceddc491573
|
