#include "angband.h"
#include "floor.h"
#include "spells.h"

geometry.c の依存先関係図:

関数
POSITION	distance (POSITION y1, POSITION x1, POSITION y2, POSITION x2)
	2点間の距離をニュートン・ラプソン法で算出する / Distance between two points via Newton-Raphson technique [詳解]

DIRECTION	coords_to_dir (player_type *creature_ptr, POSITION y, POSITION x)
	プレイヤーから指定の座標がどの方角にあるかを返す / Convert an adjacent location to a direction. [詳解]

sint	project_path (u16b *gp, POSITION range, POSITION y1, POSITION x1, POSITION y2, POSITION x2, BIT_FLAGS flg)
	始点から終点への直線経路を返す / Determine the path taken by a projection. [詳解]

void	scatter (POSITION yp, POSITION xp, POSITION y, POSITION x, POSITION d, BIT_FLAGS mode)

bool	player_can_see_bold (POSITION y, POSITION x)
	指定された座標をプレイヤーが視覚に収められるかを返す。 / Can the player "see" the given grid in detail? [詳解]

void	mmove2 (POSITION y, POSITION x, POSITION y1, POSITION x1, POSITION y2, POSITION x2)

変数
const POSITION	ddd [9]
	キーパッドの方向を南から反時計回り順に列挙 / Global array for looping through the "keypad directions" [詳解]

const POSITION	ddx [10]
	dddで定義した順にベクトルのX軸成分を定義 / Global arrays for converting "keypad direction" into offsets [詳解]

const POSITION	ddy [10]
	dddで定義した順にベクトルのY軸成分を定義 / Global arrays for converting "keypad direction" into offsets [詳解]

const POSITION	ddx_ddd [9]
	ddd越しにベクトルのX軸成分を定義 / Global arrays for optimizing "ddx[ddd[i]]" and "ddy[ddd[i]]" [詳解]

const POSITION	ddy_ddd [9]
	ddd越しにベクトルのY軸成分を定義 / Global arrays for optimizing "ddx[ddd[i]]" and "ddy[ddd[i]]" [詳解]

const POSITION	cdd [8]
	キーパッドの円環状方向配列 / Circular keypad direction array [詳解]

const POSITION	ddx_cdd [8]
	cdd越しにベクトルのX軸成分を定義 / Global arrays for optimizing "ddx[cdd[i]]" and "ddy[cdd[i]]" [詳解]

const POSITION	ddy_cdd [8]
	cdd越しにベクトルのY軸成分を定義 / Global arrays for optimizing "ddx[cdd[i]]" and "ddy[cdd[i]]" [詳解]

関数詳解

◆ coords_to_dir()

DIRECTION coords_to_dir	(	player_type *	creature_ptr,
		POSITION	y,
		POSITION	x
	)

プレイヤーから指定の座標がどの方角にあるかを返す / Convert an adjacent location to a direction.

引数

y	方角を確認したY座標
x	方角を確認したX座標

戻り値: 方向ID

◆ distance()

POSITION distance	(	POSITION	y1,
		POSITION	x1,
		POSITION	y2,
		POSITION	x2
	)

2点間の距離をニュートン・ラプソン法で算出する / Distance between two points via Newton-Raphson technique

引数

y1	1点目のy座標
x1	1点目のx座標
y2	2点目のy座標
x2	2点目のx座標

戻り値: 2点間の距離

◆ mmove2()

void mmove2	(	POSITION *	y,
		POSITION *	x,
		POSITION	y1,
		POSITION	x1,
		POSITION	y2,
		POSITION	x2
	)

◆ player_can_see_bold()

bool player_can_see_bold	(	POSITION	y,
		POSITION	x
	)

指定された座標をプレイヤーが視覚に収められるかを返す。 / Can the player "see" the given grid in detail?

引数

y	y座標
x	x座標

戻り値: 視覚に収められる状態ならTRUEを返す

He must have vision, illumination, and line of sight.

Note – "CAVE_LITE" is only set if the "torch" has "los()".
So, given "CAVE_LITE", we know that the grid is "fully visible".

Note that "CAVE_GLOW" makes little sense for a wall, since it would mean
that a wall is visible from any direction. That would be odd. Except
under wizard light, which might make sense. Thus, for walls, we require
not only that they be "CAVE_GLOW", but also, that they be adjacent to a
grid which is not only "CAVE_GLOW", but which is a non-wall, and which is
in line of sight of the player.

This extra check is expensive, but it provides a more "correct" semantics.

Note that we should not run this check on walls which are "outer walls" of
the dungeon, or we will induce a memory fault, but actually verifying all
of the locations would be extremely expensive.

Thus, to speed up the function, we assume that all "perma-walls" which are
"CAVE_GLOW" are "illuminated" from all sides. This is correct for all cases
except "vaults" and the "buildings" in town. But the town is a hack anyway,
and the player has more important things on his mind when he is attacking a
monster vault. It is annoying, but an extremely important optimization.

Note that "glowing walls" are only considered to be "illuminated" if the
grid which is next to the wall in the direction of the player is also a
"glowing" grid. This prevents the player from being able to "see" the
walls of illuminated rooms from a corridor outside the room.

呼び出し関係図:

◆ project_path()

sint project_path	(	u16b *	gp,
		POSITION	range,
		POSITION	y1,
		POSITION	x1,
		POSITION	y2,
		POSITION	x2,
		BIT_FLAGS	flg
	)

始点から終点への直線経路を返す / Determine the path taken by a projection.

引数

gp	経路座標リストを返す参照ポインタ
range	距離
y1	始点Y座標
x1	始点X座標
y2	終点Y座標
x2	終点X座標
flg	フラグID

戻り値: リストの長さ

The projection will always start from the grid (y1,x1), and will travel
towards the grid (y2,x2), touching one grid per unit of distance along
the major axis, and stopping when it enters the destination grid or a
wall grid, or has travelled the maximum legal distance of "range".

Note that "distance" in this function (as in the "update_view()" code)
is defined as "MAX(dy,dx) + MIN(dy,dx)/2", which means that the player
actually has an "octagon of projection" not a "circle of projection".

The path grids are saved into the grid array pointed to by "gp", and
there should be room for at least "range" grids in "gp".  Note that
due to the way in which distance is calculated, this function normally
uses fewer than "range" grids for the projection path, so the result
of this function should never be compared directly to "range".  Note
that the initial grid (y1,x1) is never saved into the grid array, not
even if the initial grid is also the final grid.

The "flg" flags can be used to modify the behavior of this function.

In particular, the "PROJECT_STOP" and "PROJECT_THRU" flags have the same
semantics as they do for the "project" function, namely, that the path
will stop as soon as it hits a monster, or that the path will continue
through the destination grid, respectively.

The "PROJECT_JUMP" flag, which for the "project()" function means to
start at a special grid (which makes no sense in this function), means
that the path should be "angled" slightly if needed to avoid any wall
grids, allowing the player to "target" any grid which is in "view".
This flag is non-trivial and has not yet been implemented, but could
perhaps make use of the "vinfo" array (above).

This function returns the number of grids (if any) in the path.  This
function will return zero if and only if (y1,x1) and (y2,x2) are equal.

This algorithm is similar to, but slightly different from, the one used
by "update_view_los()", and very different from the one used by "los()".

◆ scatter()

void scatter	(	POSITION *	yp,
		POSITION *	xp,
		POSITION	y,
		POSITION	x,
		POSITION	d,
		BIT_FLAGS	mode
	)

呼び出し関係図:

ddd越しにベクトルのY軸成分を定義 / Global arrays for optimizing "ddx[ddd[i]]" and "ddy[ddd[i]]"