| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
| |
See for example:
http://crawl.lantea.net/crawl/morgue/letownia/crash-letownia-20140224-004021.txt
Introduced by 0.14-a0-622-g0c137b5, which replaced radius_iterator with
C_SQUARE by rectangle_iterator. Unfortunately, the latter did not clip
the iterator to the map. Add a flag to do so: false by default because
iterated rectangles are not always in map coordinates.
|
| |
|
|
|
|
|
| |
Sometimes, they're there to emphasize a break between two sections of code,
which is good. In a majority of cases, though, they're just inconsistent.
|
|
|
|
|
|
|
| |
Valid map coordinates fall in the range [0, GXM-1] x [0, GYM-1], but we
were excluding x and y coordinates of zero from the iterator check.
That caused these edges of the map not to be drawn, and probably other
problems.
|
|
|
|
| |
It turns out it was only an implementation detail of radius_iterator.
|
|
|
|
|
|
|
|
|
|
| |
No rectangle_iterator, no circle_iterator nor circle_def, no los_glob with
an internal radius_iterator then los_base; not even a single multiplication
inside a loop (although the last part is negligibly small compared to a
typical user).
And lookie at this such simple code. It is simple, without nothing naughty
behind these macros, right? Right???
|
|
|
|
| |
If I'm wrong, please revert.
|
|
|
|
|
|
|
|
|
|
| |
This hardly speeds up things, which I did not know as profile runs did not
help to tell these two apart and it turns out adjacent_iterator is not that
prominent... but hey, a 0.1% speedup for two pages of code might still be
better committed than not.
This speedup might disappear when I get around to the actual rewrite of
radius_iterator, though.
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
It was really weird: working on a square, but in almost all cases
restricting it to your view (a circle). Note this is _your_ view rather
than from the iterator's center -- which hasn't been used once in the
obvious interesting way.
As usual, this commit fixes a load of "act through glass" bugs, ando/or
using los modes that don't make sense in the context.
|
| |
|
| |
|
| |
|
|
|
|
| |
It was the only user of non-standard get_los().
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
During conversion, use the old code.
My target will have only two types of functionality:
* iterating over a circle of a given radius
* as above, with a LOS check towards the center
The current radius_iterator/circle_def/los_base tangle either takes a
majority of CPU time or at least a sizeable chunk in profile runs, due to
a bad case of OOP abuse in tight loops. This badly needs a rewrite. The
ability to pass it a square or someone else's los can be done using a
different iterator or checking los manually later, respectively.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The perl one-liner I use for this had a bug where it didn't match "else"
at the end of a line (ie, most of the time).
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|
|
|
|
| |
This is costly (the whole iterator is copied every time!) and we never use this.
|
|
|
|
|
|
|
| |
"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.
|
|
|
|
|
|
|
|
| |
There's no separate cloud type yet (I want greyish but not blocking LOS ones),
and moving monsters/items is not implemented yet.
Pushing so people can suggest an improvement to visual effects which suck
currently.
|
|
|
|
| |
radius.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
It's not an actual spiral; rather, squares at equal distances are returned
in either a random or arbitrary order.
|
|
|
|
|
|
| |
I did review it manually to find places where they made sense (like some
tables), but for a massive sed job like this there might be places that
I missed.
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is all not very nice.
los_base is now an abstract base class for both los_def and
los_glob (global LOS-backed los_def variant), and interators
now take a *los_base.
actor::update_los is gone.
Arena LOS is quite probably broken again at the moment.
|
|
|
|
|
| |
(you don't need to cast an X* to a void* and you don't need to cast
arguments to math.h functions such as sqrt.)
|
| |
|
| |
|
|
|
|
| |
Also add a few previously indirect includes.
|
|
|
|
| |
Also collect actor/player LOS code in actor-los.cc.
|
| |
|
|
|
|
|
|
|
| |
Calls to plain see_cell(pos) were replaced with either observe_cell(pos)
or you.see_cell(pos). observe_cell where related to drawing the
interface and messaging, you.see_cell for game mechanics, and
one or the other in less clear cases (targetting, say).
|
|
|
|
|
| |
This wasn't used anywhere and could easily be restored if
required.
|
|
New: colour.cc, coord.cc, coordit.cc, random.cc, rng.cc.
|