なぜ　ここの数字は 2 なのか、とか　コメント書くのが　めんどくさいので
Qiita に書いて　プログラムのコメントには　参照:、参照:、ばっかり書くことにする。

画像が１６枚ならんでいるとしよう。

わたしの感覚では　左上から　０、１、２　……　と番号が振ってあると分かりやすいんだが、UnityのTexture2D は左下が原点と言って聞かん坊なので　それに合わせることにする。ループ・カウンターは

Ｙが　３から　－１の手前、
Ｘが　０から　４の手前、

まで回せばいい。Ｃ＃風に書くなら

// オヌヌメの書き方
for( int y = 3; -1 < y; y-- ){
    for( int x = 0; x < 4; x++ ){
    }
}

だろうか。ここで、 次のようには書かない という考え方がある。

// わたしが避ける書き方
for( int y = 3; 0 <= y; y-- ){
    for( int x = 0; x <= 3; x++ ){
    }
}

違い

書き方Ａ	書き方Ｂ
３から－１の手前まで	３から０まで
０から４の手前まで	０から３まで

これは、数字をなんだと思ってるかによって　違ってくる。

指を使って　１、２、３　と数えるときは 書き方Ｂ が分かりやすい。

これで十分じゃないか、と考える人は

３時に待ち合わせしましょう、という時に

３時２９分にやってくる。

３時に待ち合わせといったら　３時００分だろう！　というのは 解釈の１つだと思うんだが 口に出すと怒られるので言わない。

一応もうひとつ例を出しておこう。

ここで　青い日と　赤い日　は、休日ではなく遊ぶ日 だ。ここで仕事の締め切りが１７日なら、仕事はいつまでに終わらせればいいだろうか。

１７日に締め切りといったら　１７日００時００分だろう！

２０日の朝６時３０分　とか答えていいのは　インディーズ・ゲーム開発者だけであって　わたしの感覚的には　１７日いっぱいの１７時３０分ぐらいかな、と思うんだが　これも 解釈の１つだろう。

つまり　指には、

３．９９　とか無いのだ。かっこよく言うと　離散的だ。

むしろ

くそ小学生から見れば　数字に途切れなんか見えない。

りんご１つと　りんご１つを足すと　りんご２つというのは　りんごのサイズはみなだいたい同じという　算数を教えたい教師の都合のようなもので、

くそ小学生には　りんごが２つであることに　どういう意味があるのか分からない。

むしろ

りんごは　沼の下で１本の根につながっているかもしれない。ワンチャンある。算数が大嫌いだ。

つまり　これらの方法は　１点を指そう、としているところに問題がある。

オヌヌメの方法は　閾値（しきいち）を使うことだ。

この図が言わんとしていることは、０時から、３時は含まないその手前だ。

日本語にすると　３時より手前で待ち合わせしよう、ということになる。

じゃあ、待ち合わせ場所に　０時に来てもいいし、２時５９分５９秒に来てもいいことが分かる。

あのカレンダーで言うなら、

日本語で言うなら　１８日より手前が締め切りだ、　ということになる。

１７日の２３時５９分５９秒までオッケーだろう。実際　イベントの締め切り日の２３時４５分から　Ｗｅｂサイトを開いてフォームにキータイピングを開始する時間ぎりぎり平気症の人もいるだろう。

じゃあ、２３時５９分５９秒までオッケー でいいじゃないか、という人もいるが ２３時５９分５９秒９９９ナノ秒はオッケーなのか？ダメなのか？ という疑問が晴れない。解釈の１つだ。

数字は　どんなにピンポイントで示しても　小さな端数　が気になってしまう。
１８日の手前まで という閾値を用いた方法は　小さな端数　を気にしなくてよくなる　良い方法だ。

くそ小学生も　一時的におとなしくなるだろう。

これからは　もう　こう書きたくなるだろう。

// オヌヌメの書き方
for( int y = 3; -1 < y; y-- ){
    for( int x = 0; x < 4; x++ ){
    }
}

この症状が　ひどくなってくると、こんな書き方をしたりもする。

// 我流
for( int tickY = THIS_Y; NEXT_Y < tickY; tickY-- ){
    for( int tickX = THIS_X; tickX < NEXT_X; tickX++ ){
    }
}

tick というのは　チックタック時計が進んでいくことだが、刻んでいる。図で示すと……。

例えば THIS_X が 10 で、NEXT_X が 18 ということになる。tickX は 10から17だ。

この方法の利点の１つとして、NEXT_X を THIS_X に移せば、そのまま次のディビジョンが始められることだ。ディビジョンという言葉が難しければ、セカンド・シーズンとか　次の区画とか　そんな意味だ。

ホリデーから始まるディビジョンとか　嫌なものを見た。

で、このことの何が利点なのかというと、

開始地点だけ示せば　いいわけだ。これが閾値を使う利点。

閾値を使わない場合、

開始地点と、終了地点の２つを毎回　用意することになる。 これが　煩わしい。 開始地点があれば、終了地点も兼ねるのだから。

再掲しておこう。

// オヌヌメの書き方
for( int y = 3; -1 < y; y-- ){
    for( int x = 0; x < 4; x++ ){
    }
}

// わたしが避ける書き方
for( int y = 3; 0 <= y; y-- ){
    for( int x = 0; x <= 3; x++ ){
    }
}

お絵描きに疲れたので　いったん休憩して　またこの続きに記事を続けたい。

ＲＧＢは　２５５，２５５，２５５　とは限らない

ところで　月面宙返り３回転ひねりをしていいだろうか。

バグが取れんなぁ、と思って　たんたんとログ出力する内容を広げていたんだが、RGB値を見てみると 0.5019608 とか出ていた。

128 を 255 で割ると 0.50196078431……　なので、何が起こったのが想像に難くない。

どうも、Unityは何でもかんでも数字を 0.0～1.0 に normalization したいのかもしれない。おっちゃん、泣けてくるほっほ。

コメントに一言　書いていてくれれば　こんな記事　書かずにさっさと 255 掛けてたんだが……。

一応　あとで　記事は続ける。

バグを取ること

Visual Studio 2015 のC#のライブラリで書いたコードを UnityのC#ライブラリで書いたコードに移植したつもりなんだが、

生成物を比較してみると　部分的に同じで、部分的に異なっている。

処理の途中の生成物を出力してみるのもいいかもしれない。

コピペ・プログラマーもこんな気分だろう。おっ、いけるいける、と思って Rectangle を Rect、Bitmap を Texture2D に置き換えたら　コードは張り替えられてコンパイルも通るのに　処理内容の詳細が違うわけだ。

ぶっちゃけ　Ｙ座標　に関わるところが　ごっそりおかしく、その他に　ちょいちょい違うところがある程度なので　見た目の相違ほどのひどさもないと思うが。

あとで　記事は続ける。

ループのことなんかどうでもよくなってきた

不具合の探し方なんだが、

左がバグった出力結果、右が正常な出力結果。

数字を見てみると -1.04 ずれているようだ。

そもそも　この数字が何かというと、Unity の Offset Y に入れる値なんだが、元の画像では1ピクセルであっても、Unityの画面上では　グリッド１つ 100ピクセルだったり、ゲーム・オブジェクトのサイズや、拡縮のスケールが加味されていたりして　なんだか分からない計算結果になっている。

まあ、ここでは 100倍して -104ピクセルずれている、と見ていい。

で、エラーが起こっている個所は　４つごとに１つ飛ばしになっているが、
立ち、跳ね、走り、屈み、その他　を１セットで　４キャラ分あるんだが、立ち、跳ね、走り、屈み　が全部間違ってますよ、ということだ。

１７　というのは　左上を０として１７枚目、ちょうど赤い枠が描かれている画像だが、ここで　赤い枠の場所を読み間違えているというものだ。

で、１スライス　１２８ｘ１２８ピクセルサイズで、グリッドは　８ピクセル単位。
出力された数字は　１２８ｘ１２８ピクセルの枠の中心から相対的に全部　縦－１０４ピクセルずれているというのを示していて、104ピクセルも上にずれているのだろうか。

このタイル画像は 1024x1024 サイズで、Texture2Dは左下原点ということで、Yは1023～-1の手前までループするようにしている。

あ、違う

Yは上に行くほど数字が増えるんだから、-104ずれているんだったら　下に104ずれているんだった。

例えば -128 ずれてるんだったら　分かりやすかった。１スライス分、１段下を見ているということだ。

128 - 104 = 24

この 24 は何か。確かに、赤い箱を見るとグリッド３セル分、24 ピクセルの厚みがあるが……、ん？

24 下にずれているって？

正しい値の -4 ピクセルというのは、画像の中心から上に 4ピクセル上がったところに　赤枠の中心Y があるということなんだが、
（注・この記事で全部間違っているが、正しい値は 4 ピクセルであって、画像の中心から上に 4ピクセル上がったところに赤枠があるというのは合っている。 -4 ピクセルという数字もあるがこれは別の画像の赤枠だ。この記事を読む上で特に困らないだろう）

例えば

そもそも 8 ピクセル上にずれていて、－１段目から検知を開始していて、３段目を調べると　その１段下に赤い枠があって検出してしまっていて、その赤枠の中心位置を求めるときに　Rect の center.y プロパティーを拾っているんだが　縦幅の半分が中心位置とすると　プラス値になっていて　座標は　折り紙を半分折り返したように上に上がってしまう、

と考えてみる。うーん、苦しい。