ブロックとプレイヤーのあたり判定でどうしても解決出来ない

[山岡]

現在、上に向かって登っていく縦スクロールの2Dアクションゲームを作っていますが
マップとプレイヤーのあたり判定の処理で行き詰っています。

マップ情報は二次元配列に入れていて
緑色(1)のブロックは上下左右の全面にぶつかり判定のある障害物、
灰色(2)のブロックは
上面だけにぶつかり判定があり、それ以外の面はプレイヤーが
すり抜けられる障害物
と考えて配置しています。

プレイヤーの移動は、Player.cppの更新関数内にて
方向キーやジャンプ(Z)を押して
movespeedX、movespeedYに移動量を格納し、
MapCheckの関数にてその方向の障害物との距離を
計測して移動量を修正し、posX、posYに加える、
そして移動量は初期化、という感じです。

ですが、自分の思った様にならないことが３つあり、
デバッグモードも利用して
二日間さんざん考えたんですがどうにも自力で解決できません。
いったいなにが原因なのか、どうか確認して頂けないでしょうか？
出来れば、解決方法を教えて頂けると嬉しいです。

A、一つ目の問題
　　設定しているつもりなのに
　　一度ジャンプして、着地してもジャンプフラグが解除されずに
　　次のジャンプが出来ない状況になってしまう。
B、二つ目の問題
　　灰色のブロックは、上面以外すり抜ける仕様にしたいのに
　　上面に乗ったと思ったらすぐすり抜けて下に落ちてしまう。
C、三つ目の問題
　　Aの問題の着地した後に、数秒経つと床をすり抜けて画面外に落ちてしまう。
　　(マップ外に出るのでエラーが起きる)なぜ床をすり抜けるのかわからない。

なにかひとつの問題の弊害で、別の問題が生まれている可能性もあるのですが
とにかく、あたり判定がまともに機能しておりません。
どうか、正解へお導き頂けると大変助かります。
頼る者が本当にいないのでどうぞよろしくお願い致します。

※プレイヤーの動作内容については
構想中でして、変数名等、まだブサイクな部分があると思います。
ご了承ください。

軽量化したプロジェクトごとお渡ししますのでお願いします！
http://ux.getuploader.com/sho_gun/downl ... ongame.zip

[ThroughTheMorning]

A、一つ目の問題
　　設定しているつもりなのに
　　一度ジャンプして、着地してもジャンプフラグが解除されずに
　　次のジャンプが出来ない状況になってしまう。
B、二つ目の問題
　　灰色のブロックは、上面以外すり抜ける仕様にしたいのに
　　上面に乗ったと思ったらすぐすり抜けて下に落ちてしまう。
C、三つ目の問題
　　Aの問題の着地した後に、数秒経つと床をすり抜けて画面外に落ちてしまう。
　　(マップ外に出るのでエラーが起きる)なぜ床をすり抜けるのかわからない。



A、→Playerが、オブジェクトに対しても、地面に対しても、きちんと当たり(着地)の判定ができていないようです。

B、→A、と同じことが言えます。

C、→これまた、A、と同じ理由ですね。



"MapCheck.cpp"→MapHitCheck関数内の、キャラの下方向に対する当たり判定が間違っているものだと思います。

大まかで申し訳ございませんが、四角形の領域と直線の当たり判定だけですので、今一度アルゴリズムをご確認の上、コーディングし直して下さい。

[山岡]

＞ThroughTheMorning
申し訳ありません、あなたの能力では力不足です。
そんなこちらもわかってることだけ書かれても、無意味です。
こちらはそこからさらに突っ込んだ部分でご指摘受けたく、
この掲示板の出来る方々に質問させて頂いてるので。

[usao]

オフトピック

>そんなこちらもわかってることだけ書かれても

だったら，最初から「ここまでは把握できている」という
あなたのデバッグ作業の成果等を提示すべきでは？

そもそもそこまで問題箇所が絞り込めているならば
「プロジェクト一式渡すから一から十まで全て最初から確認して解決方法まで教えてくれ」
とかいう　THE 丸投げ　な質問形式にならないと思うのですが．

たとえば
「>"MapCheck.cpp"→MapHitCheck関数
　に入った際，ここから参照されている各種データ値はまともな値になっている　ということまでは確認できている．
　（関数に入る前に既に別の何かが間違っている　というわけではない）
　この関数の処理結果は，あるデータ状態（テストケース）において，正しく動いた場合には
　ある変数の値が○○になっているべきなのだが，実際は××になってしまっている．
　その計算をしている箇所は line xxx～yyy の部分なのだが，自分の考えではこの計算式の各項というのは
　△△という内容の計算しているつもりであり，これで正しく判定できるものと考えているのだが…」
だとかいう具体情報があって問題箇所のアルゴリズム内容のみを見れば良いという話と，
何の情報も無しで他人の書いたプログラムをごっそり渡されるのとでは全然ちがいますよね？

[no name]

double型とint型をキャストもせずに混在している箇所があるのはいいとして、フラグの使い方が結構おかしいですよ！

[山岡]

＞usaoさん

プロジェクトをあげると問答無用で
丸投げに見られるんですね、申し訳ありません。
ただ、自分としては
ソースの一部分だけ切り取って出すよりも
プロジェクトごと渡せば、
プレイヤーの更新関数とMapHitCheck関数の関わりや
自分のプログラムの悪いところなど
把握しやすいのではないかな、と思って
少しでも見やすいようにいろいろ削ったり、修正して
非常に頑張って質問したので
一部分だけのソースを貼って質問する方が
質問する方は簡単ですから
それがいいならそうすればよかったですよ。
けして、こちらがラクしようとしたのではないということを
ご理解頂きたいです。

正直一部分のソースだけ見せて、これはここが原因です、とか
わかる凄い人がいるのでしたら最初からそうしたいですから。
よかれと思ってのプロジェクトアップでしたが
丸投げって思われるならひっこめます。
一部分だけを見ても、わかるんですよね？
usaoさんは凄い人なんですね、ありがとうございます。

[山岡]

ご指摘を受けましたので、質問しなおさせてください。

プレイヤーの移動は、Player.cppの更新関数内にて方向キーやジャンプ(Z)を押して
movespeedX、movespeedYに移動量を格納し、
MapCheckの関数にてその方向の障害物との距離を計測して移動量を修正し、
posX、posYに加える、そして移動量は初期化、という感じです。
ブロックの上面との判定（つまり、プレイヤーの下にあるブロックとの判定）で
下に向かう移動量movespeedYがMapCheck関数を経て、
movespeedY==0となっているのなら下にある障害物と隣接したということで、
プレイヤーが地面についている、と把握します。
一つ目の問題個所は
プレイヤーが地面につくとjimenｆｌgがtrueになり、jumpflgがfalseになって
ジャンプ出来るようになるんですが着地したあともtrueのままなんです。
おかげで一度飛ぶともう二度と飛べません。どうしてでしょうか。
プレイヤーの状況に癖がありまして、
更新関数内が非常にめんどくさい状況になってます、これはほんとすみません。
でも、問題はjumpflgだけですので、それを切り替えるjimenｆｌgと共に
動きを追っていただければ、プロの方々なら問題が分って頂けるかと期待しますが
如何でしょうか

また、二つ目の問題ですがそのプレイヤーの下側にくるブロックには二種類あって
1のブロックは上下左右の全面にぶつかり判定のある障害物、
2のブロックは上面だけにぶつかり判定があり、それ以外の面はプレイヤーがすり抜けられる障害物
となっています。(情報はマップを二次元配列に割っていれてます）
その２のブロックの判定ですが、上に乗った感触のあと、すぐにすり抜けて落ちてしまいます。
MapCheck関数の下ブロックとの判定の部分に問題があるとは思うのですが、
どうでしょうか。

コード:

cPlayer::cPlayer(int x,int y)
{
	hitPosX = x;
	hitPosY = y;
	JumpPower = 0;
	jumpflg=false;
	jumpbutton = false;
	jumpframe = 0;
	jumppoint=0;
	framecount = 0;
	idoumuki=-1; //0=上 1=左　2=下　3＝右
	attackmuki=3;
	attackQmuki=3;
	weapon=0;
	weaponcount=0;
	attackflg=false;
	Jimen_flg=false;

	this->framecount = 0;
	this->movespeedX = 0;//次の移動値
	this->movespeedY = 0;

	this->Abuttonflg = true;
	this->Bbuttonflg = true;

	this->image_w = 16;//用意した画像の幅
	this->image_h = 16;
	this->bounds_w = 16;//あたり判定に利用する幅
	this->bounds_h = 16;

}

cPlayer::~cPlayer(void)
{
}

void cPlayer::Initialize(void){

}

void cPlayer::Update(void){
	framecount++;
	GameMgr::getInstance()->setplayerPosX(this->hitPosX);
	GameMgr::getInstance()->setplayerPosY(this->hitPosY);

	int Key = GetJoypadInputState(DX_INPUT_KEY_PAD1);

	//地面にいる時のmuki変更
	if(jumpflg == false){
		if( Key & PAD_INPUT_DOWN)
		{
		idoumuki=2;
		attackmuki=2;
		}
		else if( Key & PAD_INPUT_RIGHT)
		{idoumuki=3;
		attackmuki=3;
		attackQmuki=3;
		}
		else if( Key & PAD_INPUT_LEFT)
		{idoumuki=1;
		attackmuki=1;
		attackQmuki=1;
		}
		else{
			idoumuki=-1;
			attackmuki=-1;
		}
	}

	//ジャンプ中のmuki変更
	if(jumpflg){
		Jimen_flg=false;
		if(idoumuki==-1){//垂直jump
			if(jumppoint>27 && jumppoint<=30){//垂直ジャンプ後の左右受付時間(一度でも左右を押すともう動けない
				if( Key & PAD_INPUT_RIGHT)
				{idoumuki=3;
				attackQmuki=3;
				}
				if( Key & PAD_INPUT_LEFT)
				{idoumuki=1;
				attackQmuki=1;
				}
			}
		}else{//左右を向いている場合はこちらになる
			//ジャンプ中、攻撃方向は好きに変えられる
			if( Key & PAD_INPUT_RIGHT){
				attackmuki=3;
				attackQmuki=3;
			}
			if( Key & PAD_INPUT_LEFT){
				attackmuki=1;
				attackQmuki=1;
			}

			//飛ぶ方向を修正出来る時間
			if(jumpframe<7){
				if( Key & PAD_INPUT_RIGHT)
				{idoumuki=3;
				attackQmuki=3;
				}
				if( Key & PAD_INPUT_LEFT)
				{idoumuki=1;
				attackQmuki=1;
				}
			}
		}
	}

	switch(idoumuki){
	case 0://上

		break;
	case 1://左
		if(jumpflg==false)
		{
			if(attackflg==false){
			movespeedX -= 0.8;}
		}
		else{
			movespeedX -= 0.8;
		}
		break;
	case 2://下
		if(Jimen_flg==false)
		{movespeedY += 1;}
		break;
	case 3://右
		if(jumpflg==false)
		{
			if(attackflg==false){
			movespeedX += 0.8;}
		}
		else{
			movespeedX += 0.8;
		}
		break;
	}

	// 落下処理
	if(jumpflg==false || (jumpflg==true && jumpframe>8) || Jimen_flg==false){
		movespeedY -= JumpPower ;
	// 落下加速度を加える
		JumpPower -= 0.1;
	}

	if(jumpflg){
		jumppoint+=1;
	}

	// もし地面についていたら止まる
	if( Jimen_flg==true )
	{
		JumpPower = 0;
		jumpframe = 0;
		jumppoint = 0;
		jumpflg=false;

	}

	if(jumpbutton == false && jumpflg == false){
		// ジャンプボタンを押していて、地面についていたらジャンプ
		if( ( Key & PAD_INPUT_A ))
		{
			jumpframe +=1;
			jumpflg = true;
			JumpPower = 2.5;
			jumpbutton = true;
		}
	}
	//jumpボタンを押し続ける長さで高さが増す
	if(jumpflg==true){
		if( ( Key & PAD_INPUT_A ) && jumpframe >7 && jumpframe < 9){
			JumpPower += 0.8;

		}
	}
	if( ( Key & PAD_INPUT_A )==0 && jumpflg == false){
		jumpbutton = false;
	}

	if(jumpframe >0){
		jumpframe+=1;
	}

	//movespeedの値をここで調整
	MapCheck::getInstance()->MapHitCheck();

	//調整終えたら加える
	this->hitPosY += this->movespeedY;
	this->hitPosX += this->movespeedX;

	//リセット
	this->movespeedY=0;
	this->movespeedX=0;

	//各ボタンを離したかどうか判断
	if( (Key & PAD_INPUT_A)==0 ){
		Abuttonflg=false;		//ボタンを放していればfalse
	}else{Abuttonflg=true;}
	if( (Key & PAD_INPUT_B)==0 ){
		Bbuttonflg=false;
	}else{Bbuttonflg=true;}

}

コード:

//自分の下にあるブロック
if((*it)->getmovespeedY()>0){//下に移動中

	for(int i=0; i<2+((*it)->getbounds_w()-2)/MAPCHIP_SIZE; i++){//障害物の境目に当たる

		//移動先の配列のYの添え字を出す
		int y=(int)((*it)->gethitPosY()+(*it)->getbounds_h()+(*it)->getmovespeedY()-1)/MAPCHIP_SIZE;

		int x;//配列Xの添え字を求める
		if(i==0){//自分の画像の左端
			x=(int)((*it)->gethitPosX())/MAPCHIP_SIZE;
		}else if(i==2+((*it)->getbounds_w()-2)/MAPCHIP_SIZE-1){//画像の右端
			x=(int)((*it)->gethitPosX()+(*it)->getbounds_w()-2)/MAPCHIP_SIZE;
		}
		else{//中間
			x=(int)((*it)->gethitPosX()+(i*MAPCHIP_SIZE-2))/MAPCHIP_SIZE;
		}

		//マップ配列との判定
		if(mapHIT[y][x]==1){	//1は四面完全な障害判定
			if(y*MAPCHIP_SIZE > (*it)->gethitPosY()){
				if(mapBKchip[y][x].posy < (*it)->gethitPosY()+(*it)->getbounds_h()+(*it)->getmovespeedY()){
					(*it)->sethitPosY(mapBKchip[y][x].posy - (*it)->getbounds_h());//押し出し(あたり判定を軸に考えている)

					(*it)->setmovespeedY(mapBKchip[y][x].posy - ((*it)->gethitPosY()+(*it)->getbounds_h()));//壁があれば移動量を修正する
								
					//修正されたmovespeedYが0以下なら下に行けないということで
					if((*it)->getmovespeedY()==0){
						(*it)->setJimen_flg(true);//地面についた
					}else{
						(*it)->setJimen_flg(false);//地面から離れてる
					}
				}
			}
		}
		if(mapHIT[y][x]==2){	//2は上側だけ障害判定　イメージでは下からすり抜けて、上に乗れる
			if(y*MAPCHIP_SIZE > (*it)->gethitPosY()){
				if(mapBKchip[y][x].posy < (*it)->gethitPosY()+(*it)->getbounds_h()+(*it)->getmovespeedY()){
					(*it)->sethitPosY(mapBKchip[y][x].posy - (*it)->getbounds_h());//押し出し(あたり判定を軸に考えている)

					(*it)->setmovespeedY(mapBKchip[y][x].posy - (*it)->gethitPosY()+(*it)->getbounds_h());//壁があれば移動量を修正する
								
					//修正されたmovespeedYが0以下なら下に行けないということで
					if((*it)->getmovespeedY()==0){
						(*it)->setJimen_flg(true);//地面についた
					}else{
						(*it)->setJimen_flg(false);//地面から離れてる
					}
				}
			}
		}
	}
}

[山岡]

あ、下側のソースは
MapCheck関数の「プレイヤーの移動量が下方向にある場合の判定処理」になります。

[LL]

指摘したら指摘したで荒れそうですが、指摘しない限りは気がつきそうに無いので言っておきます。
山岡さん。教えてもらう立場でありながら、どうも上から目線の攻撃的な文言が目立ちます。

＞ThroughTheMorning
申し訳ありません、あなたの能力では力不足です。
そんなこちらもわかってることだけ書かれても、無意味です。
こちらはそこからさらに突っ込んだ部分でご指摘受けたく、
この掲示板の出来る方々に質問させて頂いてるので。

＞usaoさん

プロジェクトをあげると問答無用で
丸投げに見られるんですね、申し訳ありません。
ただ、自分としては
ソースの一部分だけ切り取って出すよりも
プロジェクトごと渡せば、
プレイヤーの更新関数とMapHitCheck関数の関わりや
自分のプログラムの悪いところなど
把握しやすいのではないかな、と思って
少しでも見やすいようにいろいろ削ったり、修正して
非常に頑張って質問したので
一部分だけのソースを貼って質問する方が
質問する方は簡単ですから
それがいいならそうすればよかったですよ。
けして、こちらがラクしようとしたのではないということを
ご理解頂きたいです。

正直一部分のソースだけ見せて、これはここが原因です、とか
わかる凄い人がいるのでしたら最初からそうしたいですから。
よかれと思ってのプロジェクトアップでしたが
丸投げって思われるならひっこめます。
一部分だけを見ても、わかるんですよね？
usaoさんは凄い人なんですね、ありがとうございます。

など。
せっかく答えてもらっているのに[無意味][力不足]と言う相手を否定する発言したら(お前は何様だ)というごく一般的な返答が返ってきます。

あくまで質問者は回答者に聞く側なのでこういった発言は結局のところ、関わりたくないという印象を持たれ、
結果として求めたい情報も提供してもらえなくなります。
フォーラムルールにも記載されていますが、この掲示板のモットーはアットホームです。
最近この手を理解で来てない質問者が多いようですが、
質問者は一番最高位の立場ではなく[一番最低辺の立場]だということを忘れないでください。
回答者さんも休みの日や、休憩時間の合間などの貴重な時間を割いて答えてくださってるんですから・・・
答えてもらえて当たり前と言う意識、正しい答えがもらえて当たり前と言う意識は[捨て去りましょう]。
ここは企業のQ＆Aフォーラムなんかではありません。企業相手ならば向こうも商売ですし、多少の荒い語源は我慢してもらえるでしょうが、
ここは[不特定多数の人間が集まる場所]ということを忘れないでください。社会と同じで不快な発言をすれば不審がられ、度が過ぎれば見捨てられます。

[usao]

オフトピック

すてきな返答姿勢ですね．

>一部分だけを見ても、わかるんですよね？

そこをなるべく相手にわかるように説明すればいいのに　という意見を申し上げているのですよ．
（一式を出すことそれ自体が問題だという話ではないのだが．）
意味合いが全く通じないようなので，以降関わりませんが．

[山岡]

＞LLさん

言いたいことはわかりますが、
どんな回答者に対しても敬意を示さなければならないのでしょうか？
どんな回答であっても、その方は私よりも立場は上なのでしょうか？
回答が答えになってなくても？
極端な話、例えば「ググレカス」と回答されも、私はその方に敬意を示して
「わかりました、ありがとうございます」と返事しなければならないのでしょうか？
例えば、誤った回答や、テキトーな回答をされても
私は「ありがとうございました」と敬意を示す必要があるのでしょうか？

私は、それは違うと思うんですよ。
敬意を示す相手とは、コメントをくれた全員では無く
敬意を示すべき回答者だけだと思います。

ThroughTheMorning氏は
わかっている、当然のことを書き込んだだけです。
しかも「そこの判定が間違っていると思われ」です。
薄すぎますよね。回答の意味がない。
こちらも原因がそのあたりにあるのはわかっていますし、
質問からそれを訴えたつもりでしたし。
わかっているうえで打開できないから質問しているのです。
それを回答を頂いた喜びで、いざ覗いてみたら
そんな不毛な回答で、私は非常にガッカリだったんですが
それでも「ありがとう」と言わなきゃならないのですかね。

usao氏も
現段階では「プロジェクトをアップするのは丸投げだ、質問しなおせ」
と言ってくれただけです。ソースを見てもないでしょうね。
なので、掲示板利用者として対等に近い状態で返事しましたが
問題ありますか？

LLさんもそうですよね。
現段階では掲示板利用方法を私に話しているだけですので
利用者として私と対等でしかありませんよね？

もちろん攻撃してるつもりはないですけど、
ちゃんと相談に乗って下さったわけでもない、
ちゃんと確認してくれるわけでもない、
そんな感謝も敬意も抱けない状態なんで
とりあえず掲示板利用者として対等に会話しているつもりなんですが。

あなたは「お客様(回答者)は神様」というモットーなんでしょうか？
どんなお客様でも頭を下げる、この間コンビニを恐喝した事件がありましたが
あんな連中でもお客様だから神のように扱えというのが
あなたのモットーなんですかね。
でもすみません、私は違いますんで。
ちゃんとしたお客様じゃないと神様とは思えません。

それこそ、回答してもらえたからと問答無用で敬意なんて示してたら
まったく知識の無い者までを自分より上にあげることになりますが
それが正しいのですかね？LLさん。
感謝すべき相手、敬意を払うべき相手くらい自分もわかりますから
その時はちゃんとそうします。質問者は皆、そう考えてますよ。

正直、最初の回答が
ThroughTheMorning氏みたいなアバウトな投げっぱなし回答だったことで
もうこのトピックが殺されたようなもんですけどね。
まあこちらが深夜に投稿したのが間違いだったかも。

[山岡]

＞usao
＞そこをなるべく相手にわかるように説明すればいいのに

こちらはまったく説明していないとでも？？
最初の質問、そう見えますか？
説明を書いてるのに、あなたはあんな突っ込みしてきたんだから
プロジェクトをあげたことへの指摘と取るでしょう。

ほんと質問内容と関係無い部分をつつくだけ突いて
こちらに内容も修正させといて、
したらしたで、関わりたくないのでさようならとか、
当たり屋なんですが、やってることが。
だったら正直に「自分は力不足だから横やりしか出来ませんでした、
まさか自分に回答を促される流れになるとは思いませんでした」
と言って去ればいいのに。
別にそう言われれば、こちらも私よりも未熟なプログラマには聞いてもしょうがないので
穏便に見送れるのになあ。

[LL]

ですから山岡さん。
指摘するにしても明らかに自らの立場に合わない発言の仕方をしているのが問題だといっているのです。
相手の間違いを指摘する事自体は否定しません。
ですがあなたは質問者です。
教えてもらう立場です。
相手はもらった情報からいろいろ考えて答えてくれています。
そんな相手に対して[無意味][力不足]
そんなこと言ったら相手の気持ちはどうなりますか？
相手は善意で答えています。
立場云々といいましたが、これは『常識ある、まともな人間として』当たり前の事です。
お互いの顔が分からないから、お互いの正体が不明の匿名掲示板だからだとしてもです。
あなたは今の態度を、ある程度お互いの正体を知っており、仲もそこまで深いわけではない相手にできますか？
少なくとも同じ態度をとれば、組織や集団から孤立するのは目に見えています。
ここは感情の無いBOT相手に話している場所では無いことを理解してください。相手も相手で感情があります。

最低限社会人として(学生だったら学生だったで)それを考えることができるようなってからこういう公共の場所に質問するようにしてください。
あなたの発言一つ一つがこの掲示板を荒らし、このフォーラムのモットーを汚している事にいい加減気付いてもらえませんか？

とりあえず、一度外に出て深呼吸するなどして一度落ち着いてきてください。それだけで状況の判断能力は格段に変わります。

[softya（ソフト屋)]

申し訳ありませんが、フォーラムルールを守って頂く様にお願いします。
フォーラムルールがある理由は守っていただければ不快な思いをしなくて良いことにあります。
http://dixq.net/board/board.html

引用

[C言語何でも質問掲示板でのみ適用される事項]

名前を複数利用して質問する行為
記事の内容を無暗に変更する行為
自分勝手な都合で記事を削除する行為
課題・試験の丸投げをする行為
質問後、お礼を言わずにトピックを閉じる、または去る行為
親しくない人に対して丁寧語を使わない行為 (ネタや冗談などは常識の範囲内で)
円滑なコミュニケーションを心がけない行為
あまりにもプログラミングと関係ない質問を繰り返す行為
複数の名前を使った自演、それの類の行為、または悪質な行為

4. 義務行為

[C言語何でも質問掲示板でのみ適用される事項]

・トピックを立て、解決した場合は「解決しました」とだけ書かず、どうやって解決したか他の人に分かるように書いて 　からトピックを終了して下さい。
・複数の回答者がいた場合、都合の良い、または自分の気が向いた回答者にだけ返信を書かず、回答をくれた人　全員に対して出来る限りの返信を書きましょう。
・回答者のコメントの中に複数質問があった場合、出来る限りその全てに答えるようにしましょう。

ご自分のルールを優先すると掲示板は大抵荒れます。
皆さんのルールも守って下さい。
回答者と質問者さんに言いますが、上とか下とか言い出すと絶対に荒れますので、避けていただきたいです。
喧嘩をする気がないのであれば、「言葉尻を取らない」「オトナな対応を心がける」「意に沿わない回答をけなさい」でよろしくお願いします。
あとは全部を分かってくれるという幻想は持たない事でしょうか。

【補足】
ようするに対面で会話している時に喧嘩になるような態度を掲示板で行ったら同じように喧嘩になるんです。
自分「俺さ～これこれここんな事で困ってんだよね」
グループの誰か１人「それなら、こうしたいいよ」
自分「あんた話になんないよ。黙ってて」
絶対ケンカになります。

[usao]

正直，NO.10と11あたりの素敵そうな長文は読んでませんが，
とてつもなくご不満な様子だというのは十分に察することができましたので
No.7の提示コードをちらっと見ましたよ．

(1)とりあえずあなたの文面から察するに，
「一度ジャンプして着地はできている」のだと解釈します．
このことは，下側コードのline 29あるいはline45が走ったのだと想像します．
このどちらかの行が走ったとき，
・movespeedY == 0
・Jimen_flg == true
・Jumpflg == true
・idoumuki == 2
という状態だと思います．合っていますか？

(2)この状態で上側コード cPlayer::Update() に入ります．
・jumpflg==trueなのでline49のifには入りません．
・line72のifに入ります．line73にてJimen_flgがfalseにされます．
　おそらくこの時点で前回の判定結果が全く無に帰している気がします．
・line126にて，movespeedYの値が1になります．
・line142にて，movespeedYの値がJumpPowerだけ減じられます．結果の値はわかりません．
・line152のifには入りません．
・なんやかんやでline187で 今回のMapHitCheck()へ．
　下側コードline2のifの条件を満たすのかどうかわかりませんが，満たさない場合は，もう状態復帰できない気もします．
　
ほんの２～３分　斜め読みしただけですので，ここに書いた内容自体はどこか読み違えているかもしれませんが，
【こんな感じで，あなたが感触として「ここまではできている」と思える状態から出発して
　変数群の動きをコードに沿って追ってみてはいかがでしょうか？】

[山岡]

usaoさん
なんと。
こんなやり取りの後にちゃんと回答頂いて、頭が下がる思いです。
自分とは器が違いました。さきほどのご無礼をお許しください。
申し訳ございませんでした。ご指摘の個所、すぐ確認致します。
ありがとうございます。

softya（ソフト屋) さん
その通りです、申し訳ありません。
荒れさせたいわけでは無いので
LLさんにも言われた通り、頭冷やしてきます。
ご面倒おかけしてすみません。

LLさん
＞相手の間違いを指摘する事自体は否定しません。

こちらとしても間違いを指摘させて頂いたつもりだったんですが
確かに[無意味][力不足]とか言っては
攻撃的と取られてしまっても仕方ないかもしれません。
ところで、LLさんはそこまで質問者と回答者の立場、
また人としての作法について、こちらに説かれるのであれば、
本来の私の質問に対しては回答者としてお手本といえるべき
まともな回答を頂ければと願いたいのですが如何でしょうか。
こちらも質問者さまに理解を得ようと質問を修正したところなんですけども
よかったらソース見て頂けませんでしょうか。

[softya（ソフト屋)]

ところで、LLさんはそこまで質問者と回答者の立場、
また人としての作法について、こちらに説かれるのであれば、
本来の私の質問に対しては回答者としてお手本といえるべき
まともな回答を頂ければと願いたいのですが如何でしょうか。
こちらも質問者さまに理解を得ようと質問を修正したところなんですけども
よかったらソース見て頂けませんでしょうか。

それも対面で言うと喧嘩になりますよ。
「お前そこまで言うなら見本を見せてみろよ」を丁寧な言葉で言っているに過ぎません。
ポイント → 相手に作業を強要しています。相手に対して挑戦的です。

[usao]

私の指摘内容が現実に合ってたか違ってたか　よりも　【】の内容の方が重要ですのでその点は誤解なきよう．

[山岡]

usaoさん
usaoさんの推測をヒントに調べたところ
「二度目以降ジャンプが出来ない状況」が解決出来ました。
修正前は、マップcheck関数の中で「地面についたと判断したら地面フラグをtrue」にし、
その後でプレイヤー更新関数の中で
「地面フラグがtrueだったら、ジャンプのフラグをfalseにする」という流れだったのですが
その切り替わるまでの少しの間の部分で、
ジャンプフラグが立っているからと地面フラグがfalseにされる部分を通り、
結果「地面フラグがtrueだったら、ジャンプのフラグをfalseにする」を
通らない状況になって、延々とジャンプフラグが立ったまんまだったようです。

それを今回、マップcheck関数の中の
「地面についたと判断した」部分で
「地面フラグをtrue、ジャンプフラグをfalse」と
その場でジャンプが終わった報告もすることにしたら解決出来ました。
と同時に、三つ目の問題だった
ジャンプした後に着地して数秒たったら床をすり抜けて落ちる問題は無くなりました。

非常にわかりやすいアドバイスを頂けて助かりました

おそらくこの時点で前回の判定結果が全く無に帰している気がします．

特にこれは最高のアドバイスでした。しかも場所もピンポイントでしたし。
ありがとうございます。

二つ目の問題である、ブロック２に乗ったら
一瞬乗れたあとにストンとすり抜けて落ちるのはなにが問題なのでしょう？
ジャンプが出来る今、ブロック１の上にはいくら乗っても、乗りっぱなしの状況で居られますが
ブロック２の上に乗ると、一瞬乗って、すぐ真下にストンと落ちるのです。
しかも、これらのブロックの違いは、一重に、
マップcheckのところで、
プレイヤーの上下左右の移動先でブロックの接触判定（1のブロック）を置いている、
か、プレイヤーの下移動だけの場所でブロックの接触判定(2のブロック)を置いている、
か、だけなのです。
一瞬乗ったあとに、っていうのがポイントだと思うのですが、、、
どういう問題が考えられますか？

[山岡]

一瞬乗ったあと、ストンと落ちるというより、
そのブロックの長さ(8ドット)分、
下にワープして落ちる感じです。
それですり抜けてるように見えるようです。

どういう状況が推測されますか？
経験則からでも構いません、アドバイスお願いします。

[usao]

No.7て提示された下側の抜粋コードは
「キャラクタの下方向をチェックするコード」だということですが，
そもそも，下方向にブロックがあるとき，それがブロック1なのかブロック2なのかによって処理をわける必要があるのでしょうか？
あなたの説明を読む限りでは，全く同じ扱いで済む（分ける必要がない）ように思うのですが，どうなんでしょう？

提示コードに存在している分岐の処理内容を見ると，
line25とline41の内容が微妙に異なっているわけです．単にどちらかが正解で，どちらかが不正解だというだけのことでは？

[山岡]

あなたの説明を読む限りでは，全く同じ扱いで済む（分ける必要がない）ように思うのですが，どうなんでしょう？

はい、２のブロックは、右、左、下の面は
すり抜けさせる必要があるので、それらのcheckの部分でははずしますが、
上面に対しては、１も２も同じ処理です。
つまり、「処理をひとつにしてif文で"１か２のブロックがあるならば"としたらいい」
ということでしょうか？
言われて見れば、確かにその通りです。

それで、2のブロックのすり抜け問題が解決するかはわかりませんが
実行してみます！

[山岡]

usaoさん
解消されました！usaoさんのご指摘通り、処理をひとつにしようと
if(mapHIT[y][x]==1)をif(mapHIT[y][x]==1 || mapHIT[y][x]==2)に変えて
処理をひとつにしたら、なぜだか二つ目のすり抜け問題も無くなりました！
どれもこれもピンポイントでご指摘くださって、わかりやすかったです。
イージーなミスでしたが自分ではずっと気づけなかったと思います。
本当にありがとうございました。
最初の無礼はほんと土下座もの、いや切腹ものです、
反省致しております。

usaoさんならびに今回のトピにご回答くださった皆様
申し訳ございませんでした。

[LL]

僕も基本は質問する側の人間ですが、一昔前からこの掲示板に出入りしておりその過程で悪質な質問者の身勝手な行為で嫌気がさして
この掲示板から去った現場のプロの方を何人か見ているのでこんな形で注意喚起することにしました。
(その人は某ソーシャルメディア等でマナーのなってない質問者に対する愚痴をこぼしていました。)
マナーの悪さで回答者さん達がこの掲示板を去ると、それだけ他のマナーを遵守している質問者さんが迷惑をするということを留意していただければそれ以上は何も言いません。

[ISLe()]

地面のないところから落下している途中にジャンプボタンを押すと空中でジャンプできてしまうのではないでしょうか。

通過できない壁が天井にあって、ジャンプして天井にぶつかった場合、ジャンプボタンを押しているあいだ天井に貼り付いたままになるのではないでしょうか。

No.7のコードを見ただけの感想なので間違っているかもしれません。

[山岡]

ISLe()さん

まったくご指摘の通りです。
特に、落下中に空中でジャンプ出来ることは問題でしたので
新しいフラグ(落下している時に立つフラグ）を作り、対処致しました。
（多分、新しいフラグを作らないと対処は無理ですよね？？）

回答を頂いたこの機会に現在抱えている問題を
相談させて頂けないでしょうか。
プレイヤーが左右のジャンプ中に、ブロックに当たった場合
そこから真下に落ちるのでは無く、
ジャンプの方向が反対に向く（そのまま跳ね返る感じ）ようにしたいのですが
自分で作っておきながら、ジャンプの性質はややこしいし
初めての跳ね返り処理だしで、苦心しております。
なにか簡単な方法はないものでしょうか？

[ISLe()]

ウチのブログで公開しているサンプルプログラムでは、地面に立っているかどうかのフラグひとつで足りてます。
あとは、マリオジャンプの解説なんかで出てくる移動差分と同質のものを利用してます。
下から突き抜けられるブロックと通過できないブロックで構成されたマップの2Dサイドビューというプログラムです。
Javaですが、C++が読めるなら理解できるコードではないかと思いますが。
ブログのURLは、わたしのアカウント使った投稿を過去ログから探すとかしてください。

↑のサンプルプログラムではブロック角に当たったときに上下・左右どちらかを優先するかの判定ロジックも入っています。
左右の場合に跳ね返る処理を加えてみたらイケるのではないでしょうかね。

[山岡]

ISLe()さんのブログを確認しているのですが
どのページのJAVAによるソース実行後のサンプル？窓枠が表示されておらず
「アプリケーションがブロックされました」等の警告が出ます。
こちらで調べたところ、
https://www.java.com/ja/download/help/java_blocked.xml
で詳しく記載されており、解消方法に
”このアプリケーションの開発者または発行者に連絡して、アプリケーションがブロックされることについて通知してください。
アプリケーションのコードへのセキュアな措置の実装に関する情報を提供するこれらのリンクを彼らに提示できます。”
とあったので報告させて頂きます。

私だけでなく、今後もさまざまな人たちが参考に訪れるブログかと思いますし、
ISLe()さん側の問題で解決できるのであれば、解決して頂けるとありがたいです。

ただ、うつらないのが私側の問題でしたら、すみません。

[ISLe()]

デスクトップのJavaは少し前のバージョンからセキュリティが強化されました。
完成品でもないサンプルプログラムにいちいち電子署名するのは手間が掛かります。
どうしてもブラウザ上で実行したい場合は、そのページの回避策に書いてある手順で例外サイトに登録してください。
jarファイルをダウンロードしてデスクトップで実行することもできます。

[山岡]

usaoさん、ISLe()さん

すみません、疑問が生まれました。
今回の自分の移動更新の構造を理解してくださっている
usaoさん、もしくはISLe()さんにお尋ねしたいのですが

自分は現在
プレイヤー並びに、キャラクタの更新の中で
移動量movespeedの中の値を
MapCheck::getInstance()->MapHitCheck();
させて修正するという流れにしておりますが
（このトピに書いたソースのままです）

見て頂ければわかると思いますが
そのMapCheck::getInstance()->MapHitCheck();の中では
毎度オブジェクトリストの中の最初から回す処理になっております。
自分でいうのもなんですがこれって、なんだかおかしくないですか？

プレイヤーの更新の中から移動量を投げる様なものなのに、
投げた先では、リストの要素を全部見て回てるんです。

イメージでは、プレイヤーの移動量を投げたら
そのプレイヤーの移動先のブロックの有無を
調べて修正したい感じなんです。
でも、よく見たら今のままだと
MapCheck::getInstance()->MapHitCheck();
を実行するたびに、リスト内の全キャラ分の
移動量を修正していることになりませんか？
それでもいいんでしょうか？
今はプレイヤーしか作ってないんですが
キャラが増えるごとに、キャラの更新関数の中に
MapCheck::getInstance()->MapHitCheck();
を置くことになるとおかしくなりませんかね？

でも、現在の形にした理由もちゃんとあるんです。
最初は、オブジェクトマネージャークラスの更新関数の中で
リスト内の全キャラの移動量の更新をしようとしたんです。
でもそうすると、移動量の更新のタイミングが
プレイヤー更新関数で思ってくれたタイミングと違って更新されるんです。
するとどうなるかというと、今決めてることが途端にくずれるんです。
毎回の移動量の初期化や、ジャンプ中の移動量の処理とか
変になるんですよ。
だから、「キャラの更新の流れの中で、ココって場所で
移動量の修正をさせなきゃならないんだな」って結論になりまして。
現在の形なんです。

でもそれだとしても、やはりどのキャラの更新関数にも
全キャラの移動量の修正をする関数を置くなんて
ちょっと違う気がするんですが、
これは問題ありってわけではないんでしょうか？
それとも、
「もっと綺麗にする方法があるが、バグが出るわけでもないので気にしなくていい」
ってlevelでしょうか？

[softya（ソフト屋)]

すいません。お小言です。
山岡さん。小学生ではないと思いますので言いますが、Javaの動かし方でISLe()さんが対応方法を説明してくれたんですから、大人あるいは大人予備軍としてちゃんとお礼ぐらい書きましょう。
自分のこと、自分中心で話を進めて良いのは小学生までです。

[ISLe()]

とりあえずこちらのトピックを読んでみてください。
Objectを大量に描画したいが…重い。なにかが悪い。

加えてキャラの方もコリジョンは抽象化して扱うのがよろしいです。
矩形などの当たり判定領域を表すオブジェクトをコリジョンとして定義します。
コリジョンで無駄を省いた当たり判定を行い、当たっていると判定された場合は、コリジョンの持ち主にコールバック。
そうするとキャラやマップ同士の関係を疎にできて開発効率の向上を期待できます。

本トピックの質問にあるようなプログラムの場合、四方それぞれの壁にどれくらいめり込んでいるか(あるいはめり込んでないか)、さえ求めれば次の挙動を決められるはずです。


#だいぶ最初の質問からズレてきてる気がしますが。

[ISLe()]

訂正です。

四方それぞれの壁にどれくらいめり込んでいるか(あるいはめり込んでないか)
↓
四方それぞれにどれくらいめり込んでいるか(あるいはめり込んでないか)

壁かどうかは関係ありません。これ重要。

[山岡]

四方それぞれにどれくらいめり込んでいるか(あるいはめり込んでないか)

すみません、オブジェクトたちをすべて抽象的なコリジョンとして判定を行う場合、
どうやって上側、下側、左側、右側という
四方のあたり判定をすればいいのでしょうか？

矩形判定は理解しておりますが、
上下左右となると、わかりません。

[山岡]

考えてみました。
もしかして、相手の矩形のどの面に当たったかを
判断する上で、移動量が重要になりますか？

つまり、移動量に右に進む値が入っていて
コリジョン判定すると
当たる時は必ず、相手の左側ですよね？

移動量に上に進む値が入っていて
なにかと接触したら、必ず相手の下側にぶつかったと言えますよね？

もしかして、
そうやって、判断させるとか、ですか？

[ISLe()]

2つの矩形が重なっているかどうかの判定は分かりますか？
ここでは向きも移動量も関係ありません。

[ISLe()]

その前に、総当りだとすぐに行き詰まる可能性が高いという点は理解できたのでしょうか。


1-a.周辺だけを調べる
1-b.もっとも内側の境界を求める

2.境界より向こうへは行けないのでなんとかする

1と2は分けて考えることができます。
1はキャラにとって外の世界の情報です。
2はキャラの振る舞いに関することです。

境界をどのように扱うかで操作感に個性が出ます。
押し戻す圧力というふうにすると、走る・浮く・流される、といったものを共通の仕組みで表現することもできます。

[山岡]

2つの矩形が重なっているかどうかの判定は分かりますか？

わかります。というか、それって基本中の基本の矩形判定処理でしょう？
これですよね。→　http://gyabo.sakura.ne.jp/tips/rect1.gif
一番シンプルな判定処理。出来ますよ、以前使っていましたし。
でも、今回は敵の頭を踏んだとか、自分の頭を踏まれたとか
必要なんです。横面同士でぶつかるとはじかれるだけ、とか。
なので、矩形がただ重なったというだけの判定処理ではダメなんです。

ですから、
自分は面倒ですが今回のトピに書いたような処理を選んだと。
ただ、シンプルな矩形の判定処理でなにかを足すだけで
上下左右の判定まで出来るようになるなら、そうしたいですんですが
あるんですか？

押し戻す圧力というふうにすると

矩形判定処理にて、重なったときに、戻す処理をすることですよね？
使ったことあります。
めり込んだ→もとの位置に戻す→描画の流れですよね？
なにかとその方がいいのもわかるんですが、
とにかく、今回は上下左右の判定がいるんです。

シンプルな矩形処理を行うとして、
そこでどうやって自分の上下左右、相手の上下左右、
どことどこがぶつかったかを判断するんですか？
ISLe()さんいわく、移動量を使う必要もないんですよね？？
移動量を使わないなら、自分の面、相手の面を割り出すための
面倒な式を書くことになりませんか？

総当りだとすぐに行き詰まる可能性が高い

これはちょっと言い過ぎだと思います。
総当たりの処理を否定されるんでしょうか？
総当たりは、いろんな参考書やサイトでも
基本の回し方として載っていたりもしますよね？
まあ、それが効率がどうとかは自分はまだわかりません。

[usao]

オフトピック

>今回の自分の移動更新の構造を理解してくださっている
>usaoさん、もしくはISLe()さんにお尋ねしたいのですが

別に内容を理解していたわけではなく
理解しなくても怪しい個所がわかる範疇の内容だったから指摘しただけ　だったので，
今まさに
ぼく「>まさか自分に回答を促される流れになるとは思いませんでした」
という感じです，　と正直に言っておきますね．

[ISLe()]

重なっているとはどういうことか、分かっているか？ではないですよ。
判定(の仕方)を分かっているか、とお尋ねしたのですけども。
分かっているなら、矩形の位置関係との関連が分からないはずないのですが。

わたしはわたしの経験から書いているだけなので信じられないのであれば信じなくてかまいませんしわたしは困りません。

[ISLe()]

大事なことに思えたのでこちらにも回答しておきます。

総当りだとすぐに行き詰まる可能性が高い

これはちょっと言い過ぎだと思います。
総当たりの処理を否定されるんでしょうか？
総当たりは、いろんな参考書やサイトでも
基本の回し方として載っていたりもしますよね？
まあ、それが効率がどうとかは自分はまだわかりません。

No.32でリンクをはったトピックで、わたしは総当たりを全否定してますが、
読んでいただいてないのでしょうか。

解説用のコードはあくまでも解説用で、考え方を説明するためのものです。
余計な説明を省き、見通しを良くするため、処理自体は冗長であるコードがほとんどです。

処理の仕組み自体を抽象化することはフレームワーク化するということです。
フレームワーク化するとモジュールは断片的なコードの集合体となるため記事として掲載するには不適切です。
#わたしのブログでもフレームワーク化した部分のコード掲載はありませんし。
なので、『載っている』ということ自体が、処理の内容云々以前に、対象を示していると言えるかと思います。