Re: Field of view algorithm implementation problems

On Jan 14, 2:36 pm, Elsairon <elsai...@xxxxxxxxx> wrote:
On 2008-01-14 22:11:55, mike3 <mike4...@xxxxxxxxx> wrote:

On Jan 14, 2:07=A0am, jice wrote:
On 13 jan, 09:46, mike3 wrote:

Hi.

I was trying to implement the "recursive shadowcasting" field-of-view
algorithm for a
Rogue-like game, and seem to have ran into a problem.

<snip example >



If I understand, you mark all cells as 'not visible', then use the
recursive shadow casting algorithm to mark some cells as visible. The
problem is that there are several 'shadow-border' rays that traverse
the cells behind the pillar. Especially, the rays that go through the
cells directly left and right to the pillar go through those cells and
mark them as visible. You should try reverse the whole algorithm :
- mark all cells as 'visible'
- use the shadow casting algorithm to mark cells in shadow as 'not
visible'.
Thus, the pillar will necessarily cast a shadow behind it.
I don't know though if this will not generate new artifacts. If fact,
due to the discrete nature of the bresenham algorithm, I'm not sure
that an artifact-free solution can exist without going to sub-cell
accuracy (using a float for the cell visibility instead of a
boolean)...

I'm wondering if it's a rounding problem.
The slope is stored, as you could see from the code
snippet, as a float, then this is rounded to produce
integer coordinates for map tiles.

Aren't the slope values compared to determine collision? If so, it would be
better to compare the slopes before rounding them off, otherwise much accuracy
is lost.


I tried that too, but I still couldn't get the thing to look like
what's
on the webpage.

One thing I noticed was that the slope values given in the
illustrated description of the algorithm did not match mine:
for example, I got 0.60 where they said I should get 0.68.

Also, there isn't any "bresenham" algorithm employed
there (if you mean a pure-integer line-drawing procedure.).
Should I switch to using one? It would do everything with
integer math, and hence relieve the need for that rounding.
Could that have been what the reference diagram was using?

I would stick with the recursive shadowcasting if you can get it working, much
more robust and probably alot faster than raycasting.

I think so, once all the quirks have been worked out.
.

Relevant Pages
Loading