数日開きましたが、確認させていただきました。
#9以降のusaoさんや管理人の回答には有益に感じられる内容がいくつかありました。
最初からソースに対するそれくらいの議論、ないしは建設的な回答が頂ければな、
とも思いましたが、ちゃんと相手して頂いたことにはお礼申し上げます。
ただ、いくつか思うところがありますので言わせて頂きたいと思います。
>碁盤のマスの個数がたかだか16x16しかないのであれば
誤解しています。個数では無く、1マスのサイズを16×16で設定してあり、
それが数百×数千と碁盤上に並んだ(二次元配列で作られた)マップです。
「たかだか」のゲームを作っているわけではありません。
(もちろん、今回のプログラミングミスを検証するなら
小さなマップでも作ってからやるのがいいのでしょうけども)
>プレイヤーがインベーダーのような動きをするのか、
>初代ドラクエのような動きをするのか、
>ボンバーマンのような動きをするのか
初代ドラクエって斜め移動できたかは知りませんが
まあ、よくある斜め移動込みのRPG移動です。
斜めもあるんで、判定も少しは面倒だと思うんですけど。
>幅や高さはpixelなのか? PLAYERposXってのは真ん中?左端?その他?
pixelです。基本posは左上のつもりですコリジョン判定する時には
当り判定を座標を割り出してます。
>forの奇怪な繰り返し条件により,
>判定箇所(x)を算出するループが最低2回は回ることが保証されているので,
ここ、一番気になりました。私のソースを理解してくださっていることは
ありがたいのですが、「奇怪」呼ばわりは解せません。
がんばって考え抜いた処理とは言え、未熟者なのは認めますが
なぜこの繰り返しは奇怪なんでしょうか。
合理的では無いのかもしれませんが、
理論的には正解のひとつではないですか?
要は、自分の進行方向にあるインデックスをすべて見ているわけです。
見ないとすり抜けるだろうと踏んでいるので。
で、それに対するusaoさんの提示される処理は
>列挙されるべき配列indexの値は連続的であるハズなのだから
>最初と最後のindexさえわかれば中間のindex群を馬鹿正直に計算する必要はない
>forの主体がpixelであった上記(2)の状態から,forの主体が配列indexである状態へ,自然な形に変換できる
というものですが、アバウトすぎてわかりませんでした。
配列のインデックスは連続的でしょうけど、そのマスが壁か、
そしてその壁が連続かはわからないことです。どこまで壁かもわかりません。
だからいちいち視野に入るインデックスを調べる処理になってしまいました。
1マス16×16が連続してることをさしているのでしたら。
管理人さんの貼った画像みたく、PLAYERが中途半端な場所にいる場合は
どうされるのでしょうか?
16で割ってインデックスを出しても、片側だけのマスしか出せないはずです。
するとそこだけ見て移動しては、PLAYERの画像はすり抜けが起こるはずです。
「調べるべき配列indexの両端を求む」とありますし、
もしかしたらここではPLAYERの座標では無く、PLAYERの幅も考慮してるのかな、とも思いますが
一番重要な
usao さんが書きました: ↑5年前
//配列indexがxの箇所について判定
をusamiさんはぼやかしていらっしゃるんで、わからないです。正直。
ソースを見せるのに抵抗があるのでしたら、文章でも流れ図的なものでもいいんで
具体的な説明お願いできませんか?
あとどうでもいい内容ですが、管理人さん
この掲示板投稿時にメルアド必須なのどーにかなりませんでしょうか?
(メルアド必要ですかね?)