>「PLAYERが下方向に進んでいる時の先の障害物調べる」処理

に限定した場合なら…

playerをある移動量だけ下方向に移動させた場合に
その移動先におけるplayerの当たり判定が図で白矩形で表される範囲であるとき，
図で赤くなっているマスのうちの最下段の4マスに関してのみ，それらが壁であるか否かの判定を行えばよい

…という話．
（この場合なら，Topの算出は不要で，{Bottom,Left,Right}だけ求めればいい）

> ソースを見せるのに抵抗があるのでしたら、文章でも流れ図的なものでもいいんで > 具体的な説明お願いできませんか？ 具体的… ざっくりこの程度の話をしているのですが，不足がある感じですか？ （下記コード例は，下方向に移動したときの話に限定せずに，"player"の当たり判定矩形全域に関する形） //マップチップのサイズ[pixel] const int MAP_CHIP_PIXEL_SIZE = 16; //pixel座標から，マップindex座標への変換 // //ただし，素の計算結果のindex値が，マップ配列領域外になる場合には， //有効範囲ぎりぎりの値に修正した結果の値を返す． /...

念のため補足しておくと， 私が書いているのは， >組み立て方 という側の話題に関する事柄のつもりで，質問者のコードが直面している問題への直接の答えではない． だから， 「別に質問者の方法はダメだからこうしろ」とか言っているわけじゃない．そこは誤解なきよう． 質問者のゴールは，質問者のコードのデバッグにあるハズ． > 最初からソースに対するそれくらいの議論、ないしは建設的な回答が頂ければな、 納得できない話かもしれないけれども， その議論自体が，解決のために不要かもしれない　んですよね． 外界の人間がどこまで内容に突っ込まなきゃいけないのか，っていう程度が，外界の人間には最初からはわからない． ...

//調べるべき配列indexの両端を求む const int x_Left = PixelToArrayIndex( playerの当たり判定の左端pixel座標 ); const int x_Right = PixelToArrayIndex( playerの当たり判定の右端pixel座標 ); //調べるべき全配列要素について調査 for( int x=x_Left; x<=x_Right; ++x ) { //配列indexがxの箇所について判定 } この疑似コードにおけるxというのは， 質問者のコードにおいてfor文内で算出しているxに対応している． for内の //配列indexが...

> 組み立て方 とかいう話に相当するかどうかわかりませんけども， 今回の当たり判定の処理というのは 「移動先の当たり判定矩形の底辺を形成する全ての画素について，その画素が所属するマス(配列要素)を調べる」 を行うことに相当すると思われ， だったらそれをその通りに書くのが最も手っ取り早い． 素直にfor文で書いたらpixel座標についてのループになる． 「全ての画素」についてループを回すのは明らかに無駄だと思うならば，forのstep量を適切に増やせばよく， その際に注意すべき事柄は，うっかり最後の座標がチェック対象から外れないようにすることくらいか． さて，（予想通りの無風状態だが） > 組...

わざわざ変数WordSizeがあるんだから

offset = FoundPos + WordUpper.size();
　↓
offset = FoundPos + WordSize;

ですね．

置き換える場所を探す作業は，大文字(あるいは小文字）の世界で行い， 置き換えは作業は元の文字列をベースにして行えばよいのではないでしょうか． （雰囲気コード） //引数を全て大文字化した文字列を返す inline std::string ToUpper( const std::string &Src ) { std::string Ret = Src; std::transform( std::begin(Ret), std::end(Ret), std::begin(Ret), toupper ); return Ret; } //Srcの中で，BadWordの部分を '*'に置き換える． ...

せめて関数の単位の形でコードを提示できませんか．
その抜粋の仕方だと，最初の３行と，以降の条件分岐の処理の関係性が不明です．

少なくとも みたいな形ではないのですよね？

で，それはそれとして，
「playerPos.yを変化させる処理が走るには，条件( playerPos.y>0 )を満たす必要がある」という点が
「鶏or卵」みたいな状態になっていたりしませんか？

> 絶対値をif文で処理する方法が分からなく

・絶対値を計算すること
・計算した絶対値を用いた条件文

の２つに分けたら，少しは見通しが良くなったりしますかね．
> なぜかエラーが出るので；をうっています。。。。

なんつーかもう，そういう姿勢がダメ．

少ない情報からない頭で考えてみるに、複数の壁があるときにおかしくなるということを考えると、 そもそも当たり判定の判定先が一つなのが奇妙に感じます。 もはや無意味だとは思いまが，一応…… 質問者のコードでは，　判定先が一つ　ということはないです． forの奇怪な繰り返し条件により，判定箇所(x)を算出するループが最低2回は回ることが保証されているので， あとは，この繰り返し内で，iの値毎に算出されるxの値が異なれば，複数の箇所が判定先になる． 　↓ つまり，このコードで真っ先に疑うところは， 【iによって変動するxの算出具合がおかしい】のだろうということ． （だから，結果として判定することにな...

さて，もう見てないっぽいけども，もうちょっと回答っぽい雰囲気のことを書くならば…… この当たり判定コードで算出される xの値は連続した値を取ることが期待されるハズです． （そうじゃないと判定が「歯抜け」になってしまうから） 例えば， PLAYERposX = 1 PLAYER横幅 = 33 の場合を考えてみます．暗算で． forループは i={0,1,2} で３回まわるでしょう． i=0のとき，最初のifの条件に合致するので，xは0です． i=1のとき，elseブロックの処理により，xは0です． i=2のとき，真ん中のelse ifの条件を満たし，xは2です． この暗算が合っていれば，x=1に...

全く役にも立たない無駄話だが， > 正面だけの要素を割り出し うまく動かない場合には まずこういう枝葉末節の高速化の工夫みたいな要素をやめて， 素直に"player"の当たり判定の形状全体に関して行ってみればどうか，とか思うわけ． というか，本当に碁盤のマスの個数がたかだか16x16しかないのであれば 調べるべき配列要素を全く絞り込むことなく， 「壁」である全Ｎ個( N <= 16x16 )に関して毎度総当たりで調べても，問題がないんじゃ？とか思われる． 以下は本件とも無関係なさらなる無駄話であるが， まずは「効率はともかくシンプルでわかりやすくて妥当な結果が得られる」方法 から初めて， そ...

>ちなみに、当たり判定を描画して、なんて >やってますから。 >やってて、解決しないから相談してるわけで。 つまり，その描画結果を観測してみた結果として， 【問題が発生する状況下において 当たり判定と重なる配列要素全てが的確に列挙されていることと， それらのうちのいくつかが壁であるという妥当な判定結果が生成されていること までを確認できている】 という主張ですよね． （要するに，このとき，「"player"は壁に当たっている」という結果が得られている，と．） であれば 【問題の原因は「当たり判定」の処理ではない】 と結論づけられるのであって， あたなたの言っている > 私の記載したソース(考え...

んー，だから，あなたの場合において調べるべき事柄を描画して見ましょうよ． playerが上に進む場合は云々～の結果として そのplayerの移動先に関して壁とぶつかるかどうかを判定するために「配列のどこどこの要素を調べることになったのか」という結果に不安があるなら，その結果を可視化してみればどうですか． おそらく，配列の１要素が表示上は16x16[pixel]の領域に相当するんだろうから， "player"の当たり判定領域と，調べることになった配列要素群に相当する領域とを描画すれば 「調べるべき配列要素を列挙する処理」がまともに動いているかどうかわかるでしょ． 何なら，「壁に当たる」と判定され...

＃む？　貼ったコード内の改行がいくつか失われた模様

(1)VisualStudioでWin32プロジェクトを新規に作る →　ビルドするとウィンドウが出るコードが生成される (2)てきとーに外部変数に wchar_t WStr[100]; とか追加 (3)_tWinMain()のど頭に以下を記述 { setlocale(LC_ALL, ""); FILE *fp = fopen( "Test.txt", "r" ); char Buff[100]; fgets( Buff, 100, fp ); mbstowcs(WStr, Buff, 100); fclose( fp ); } (4)ファイル Test.txt は　メモ帳　でANSIで保存．内...

そのような考えをお持ちなのであれば， 自身のコードを提示する時点で，コードの各所に関して「何でこのように書いているのか」の理由を明記した方がよろしいのでは？ あなたのコードを見た人が > なんで mbstowcs が 3つもあるの？ とかならないように． また，掲示板を見る他の初心者のことまで気に掛けるのであれば， 回答に不明瞭な点がある場合には，推測とか察するとかで終わらせずに， その時々でその回答をした相手に不明瞭な点を問うとよいのでは． （あなたの推測が正しくて話がそのまますんなり終わってしまったとしたら，まさにあなたが危惧する「初心者に理解できないログ」だけが残る事態になるのだから） ...

要するに，
【自分ではデバッグ作業とか一切やりたくないんだからお前ら勝手にバグ見つけて俺に教えやがれ．無料で．】
という主張ですよね．

理由を見つける方法の話とかいらねーから，最初から理由だけをよこせ　と．
じゃあ，他者はあなたにその理由を教えるために，どうやってその理由を見つけるんだろうね？
バグの理由を見つけるのには一般に絞り込み作業が必要だと思う．
理由だけをよこせ　という主張は，他人に絞り込み作業をやらせていることに他ならないと思うんだが．
でもそれは相手が勝手にやったことだ！と．

ぐだぐだ言っているけど，ただのクレクレ君ですやん．くだらねぇ．

#14の言い回しは，あれっすよ．TV番組ネタ． そもそもプログラマは教育者じゃないし，ましてボランティアで教育活動をすること求められる筋合いは無いんじゃないかなぁ． （何か，東京オリンピック的な考えですね．） まぁそれはそれとして…… 苦言的な(?)ことを言えば， ステップ実行という調査手段が得られたなら 「TextOutの出力結果を見て異常だったら，真っ先にTextOut時点でのデータの中身をチェックするっしょ」 というのは，なんというか，一般に期待される事柄だとは思うのですよね． （そして，当然ながら，中身がおかしいならばその原因追及を行うことも） 要するに， > 変数の値の変化を丁寧に見...

職場で笑っちゃったじゃないですか…

奇遇ですね．私もです．

この様子だと，素人解釈は邪魔でしょうし，
計算グラフなるものを使う分野の専門家が現れるのを待つしかないですね．

たしかに「計算グラフ」でググるとそれっぽい情報は見つかるが，
ここであなたが求めている
> 『計算グラフ』的なコーディングの仕方
っていうのは，一体どういうものを想定しているのか，何かもうちょっと具体性を持った事柄を言えないのですか？

例えば，各々の演算子を全てstd::unary_functionやstd::binary_functionのようなファンクタで実装したならば
> 『計算グラフ』的
なる事柄の要件を満たすのですか？
と素直に実装したならば，これは
> 非『計算グラフ』的
に該当するのですか？

後半の方は何をおっしゃっておられるのかよくわかりませんが… void func(int arg[]){ ... } は void func( int *arg ){ ... } と同じ． 関数func内の arg[0] = 10; は *( arg + 0 ) = 10; と同じ． func( a ); なる呼び出しは， func( &( a[0] ) ); と同じ． 纏めると， void func( int *arg ) { *( arg + 0 ) = 10; } int main() { int a[] = { 0,1,2,3,4 }; func( &( a[0] ) ); } といった...

あるファイルに(graph.hかな)に
ch_t って突然書いてみたら，
コンパイラに「ch_t　ってのは何だよ？　しらねーよ」と言われた，という感じですか．

> ＜struct.h＞
というヘッダファイルを一体何のために書いたのか？　どう使うつもりなのか？
というあたりを詳しく説明できませんか？