Angband Forums targetting and LOS
 Register FAQ Members List Calendar Search Today's Posts Mark Forums Read

June 27, 2009, 08:39   #171
Rizwan
Swordsman

Join Date: Jun 2007
Posts: 292
Quote:
 Originally Posted by PowerDiver This is about the advantage of hexes over squares. In a hex map, two adjacent tiles share a vertex iff [if and only if] they share an edge. In a square map, it is possible to share only a vertex. In the current system, diagonally adjacent #'s are assumed not to touch. Changing that would be a big deal. If you really want to change this, you should widen the discussion to include switching to a hex map where there is no problem, by design.
So in Angband
Code:
```   #           and         #
#                        #```
are treated differently? It seems weird that in the case of vertical or horizontal walls we assume they touch with no gap in between but if you have diagonals then they don't touch. If we put two bricks together in the manner shown on the left then we cannot see through the edge that is touching .
And your diamond representation will not change this?
DFOV mentions polygons right? So could we use hexes instead of diamonds and not have it be a big deal?

June 27, 2009, 09:10   #172
Pete Mack
Prophet

Join Date: Apr 2007
Location: Seattle, WA
Posts: 5,751
Donated: \$40
Quote:
 Originally Posted by Rizwan So in Angband Code: ``` # and # # #``` are treated differently? It seems weird that in the case of vertical or horizontal walls we assume they touch with no gap in between but if you have diagonals then they don't touch. If we put two bricks together in the manner shown on the left then we cannot see through the edge that is touching . And your diamond representation will not change this? DFOV mentions polygons right? So could we use hexes instead of diamonds and not have it be a big deal?

They are certainly treated differently. Surely you recognize the difference between
Code:
```#####################
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
## # # # # # # # # ##
# # # # # # # # # # #
#####################```
and
Code:
```#####################
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
#####################```

June 29, 2009, 05:39   #173
Rizwan
Swordsman

Join Date: Jun 2007
Posts: 292
Quote:
 Originally Posted by Pete Mack They are certainly treated differently. Surely you recognize the difference between Code: ```##################### # # # # # # # # # # # ## # # # # # # # # ## # # # # # # # # # # # ## # # # # # # # # ## # # # # # # # # # # # #####################``` and Code: ```##################### # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #####################```
You know you are right but somehow I always thought there was more of a space between those walls. Just shows you that you can play Angband for umpteen years and still not see whats right in front of you. Now that I know there is no space between those wall sits going to bug me whenever I enter into such a room. Thanks Pete
So if you can walk between the ones on top then you should also be able to walk between the ones on the bottom because the # representation visually fools you into believing that there is space there. Maybe the solid wall configuration would help? I still say that @ should not be able to see or walk thorough the pillars shown in the top view.

Last edited by Rizwan; June 29, 2009 at 05:47.

June 29, 2009, 09:01   #174
zaimoni
Knight

Join Date: Apr 2007
Posts: 590
Quote:
 Originally Posted by PowerDiver You are agreeing with me. In order to add the property of symmetry, you have to remove the property that an interior square can see the wall.
Actually, the current implementation would have to choose between losing strict conical shadows [logical-or symmetrization; the one-off corrector guarantees this] and interior square can see the wall [logical-and symmetrization].

I find it credible that logical-and symmetrization must lose any pre-existing property that an interior square can see the wall. Both Zaiband's algorithm, and V's current LOS painter, attained that only by messing with the angles that would be needed to calculate Permissive Field of View (and in both cases worked with rational tangents of those angles, rather than directly).

Logical-and symmetrization may well be required to lose the lines that enable the LOS, but it's not obvious. Sketching a naive rigorous demonstration is quick (short paragraph), but that sketch suggests it will be more than a couple of paragraphs if it exists.

Logical-or symmetrization: it should be possible to prove squelching of conical shadows on logical-or symmetrization just from an interior square seeing all walls bounding the room.

June 29, 2009, 09:18   #175
PaulBlay
Knight

Join Date: Jan 2009
Posts: 657
Quote:
 Originally Posted by Pete Mack They are certainly treated differently. Surely you recognize the difference between [figA] and [figB]
They are treated differently, but they don't necessarily have to be treated differently.

Code:
```#####################
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
#####################```
is identical to

Code:
```      #####################
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
# # # # # # # # # # #
#####################```
?
__________________
Currently turning (Angband) Japanese.

July 1, 2009, 11:17   #176
flight2q
Rookie

Join Date: Jun 2007
Posts: 7
Quote:
 Originally Posted by Pete Mack As I said, albeit very unclearly, I think that using permissive FOV for visibility but limited FOV for targetting is a good idea; it's very much in line with the current angband model.
+1

Just want to get my vote in while you guys continue to discuss.

While I'm here, but less important... I think visibility should be symmetrical. Targetability doesn't need to be symmetrical, but the exceptions should be simple and memorable, and not depend on the terrain occupied by either party.

July 1, 2009, 19:41   #177
PowerDiver
Prophet

Join Date: Mar 2008
Posts: 2,712
Quote:
 Originally Posted by PaulBlay They are treated differently, but they don't necessarily have to be treated differently. How about a system where Code: ```##################### # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #####################``` is identical to Code: ``` ##################### # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #####################``` ?
Those two *have* to be treated differently. If the #'s touch in both, the second room contains a set of disconnected spaces. If they do not touch in either, there is no way to step between them in the first diagram when you are restricted to only step to an empty adjacent tile.

If you want to treat them similarly, the right way is to go to a hex map, and then you can alternate solid diagonal walls with connected diagonal spaces. There is a reason some wargamers made the switch to hex maps decades ago.

The DFOV model, i.e. the everything is diamonds model, explains the difference consistently in that diagonally adjacent diamonds do not touch but horiz/vert adjacent diamonds do touch. When I reformulate my suggestion, the second room will be impossible in my model, thus removing any consistency issues.

editing: Oh, I see now, you want an asymmetric system where #'s are adjacent to the NE but not to the SE. It will take some time to think that through.

 July 1, 2009, 20:13 #178 Atarlost Swordsman   Join Date: Apr 2007 Posts: 441 You can't use a hex map without abandoning ascii representation because ascii charachters form a rectiliniar grid. That wouldn't be a true roguelike by the narrowest defenition anymore and would be completely inappropriate for vanilla Angband. It would be such a radical change that I would argue it goes beyond even variant territory. __________________ One Ring to rule them all. One Ring to bind them. One Ring to bring them all and in the darkness interrupt the movie.
July 1, 2009, 20:26   #179
Marble Dice
Swordsman

Join Date: Jun 2008
Location: Columbia, MO. USA
Posts: 405
Quote:
 Originally Posted by Atarlost You can't use a hex map without abandoning ascii representation because ascii charachters form a rectiliniar grid. That wouldn't be a true roguelike by the narrowest defenition anymore and would be completely inappropriate for vanilla Angband. It would be such a radical change that I would argue it goes beyond even variant territory.
Now I'm not saying Vanilla Angband should switch to a hex map, but it wouldn't be that hard:

Code:
```# # # # # # # # # # #
# # # . . . . . . . #
# # # # . @ . . . . #
# # # . . . . . . . #
. . . + . . . > . . #
# # # . k . . . . . #
# # # # . . . . . . #
# # # . . . . . . . #
# # # # # # # # # # #```
Hexband, anyone?

July 1, 2009, 21:11   #180
zaimoni
Knight

Join Date: Apr 2007
Posts: 590
Quote:
 Originally Posted by Atarlost You can't use a hex map without abandoning ascii representation because ascii charachters form a rectiliniar grid.
No, double-tiling works just fine. Read below as "one o and one @"
Code:
```##oo#####
##..####
####@@##```
Quote:
 Originally Posted by Atarlost That wouldn't be a true roguelike by the narrowest defenition anymore and would be completely inappropriate for vanilla Angband. It would be such a radical change that I would argue it goes beyond even variant territory.
Agreed.

 Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is Off Forum Rules
 Forum Jump User Control Panel Private Messages Subscriptions Who's Online Search Forums Forums Home Angband     AAR     Vanilla     Development     ToME     Sil     Variants     Competition The real world     Idle chatter     Oook! Obsolete     v4