厨房なおいらにﾌﾟﾛｸﾞﾗﾑ教えるｽﾚ

↑の式では
ｔ++で
ｔが１増加するごとに弾の表示位置を計算させているけど、
その間に ｔ をもっと小刻みに増やして、当たり判定を計算すればなんとかなりそう

>>238-240
助かった。
ありがとう〜。

>>242
>二次関数とか三角関数とか高校以来１０年ぶりぐらいでなつかしいｗ
上記に複素数と行列を加えれば、今あるほぼすべてのゲームの数学的要素はコンプリート。
全部高校までに習う内容で充分。
3Dゲーム（擬似／ポリゴン）もこれらの要素だけで出来る。四元数の話があるけど、ゲームで
あればこれは各要素の組み合わせで充分。

あとはOS（Windows/DirectX等）の使い方を知ればゲームプログラマとしては一人前。
ネットワーク使うとなると、さらにその先やね。
これらのほうが数学云々よりも何倍も面倒くさい。（あまり難しくはない）
ある程度いくと Don't think, FEEL！な世界になってくる。

それとx方向の話や当たり判定についてはあえて突っ込まない。（細かいことだし、一概に間違いとも言えないので）
いろいろ試して自分がやりたいことを表現できるようになるべし。

さて、長々と書いたが拙者の講義はここまで。以降は適当にROMって
ニヤニヤしているので、踊りまくるでござる。ニンニン

次は当たったところを変形させるほうほうだな〜。
>>201でうｐされたようなやり方に変えてみたほうがいいかな。

でも今日はやらねーけどな！

アク禁がやっと解除されたようなので今更ですが、参考までに、>>212では、

�@弾の位置を(x,y)、弾の発射速度を(vx,vy)とする。
　　※(x,y)は砲台の位置から、(vx,vy)は砲台の角度から計算する。
　　　考え方は>>242のa,bの計算方法と一緒ですが、pは1フレーム期間を基準にしています

�A１回の計算ごとに、
　- vyに重力加速度gyを足す（gも１フレーム期間あたりの加速度です）
　-足し終えた(vx,vy)を(x,y)に加算する
　-(x,y)の地面を判定する/および描画更新
を繰り返しています。

風は考慮してませんでしたが、
いくら追い風でも風速より弾丸が早くなるのは不自然かと思うので、
水平方向に加速するのではなく相対速度が一致させるように漸近させる方法にします。
つまり、毎ループごとに vx= (1-k)*vx + k*windx　（kは漸近化係数)で更新します。

おお、あんたもアク禁くらってたんですか。
何ででしょうね。
例の、通り魔予告兄弟の関係で広範囲にアク禁かかってたんでしょうか。

まあ、なんにしろ、ほんの１週間程度で解除されてよかったです。

それで、次にやってみようと思うのは、
弾の当たった地形が円形にえぐれるってことです。

今、当たり判定は二次元配列に0か1の数字を入れたものでやっています。

まず、地形画像（地形.bmp）と、それと同じ形の白黒画像（地形_a.bmp）を用意します。
白黒画像をアルファチャンネルとして、地形画像の何も無いところを透明にします。
さらに、白黒画像と同じ形の二次元配列を別に用意して、それで当たり判定を行います。

この配列内に直接円形の変化をつけたいんです。

[0000000111110000000]
[0000011111111100000]
[0000111111111110000]
[0000111111111110000]
[0000011111111100000]
[0000000111110000000]
[0000000000000000000]

こんな感じ。

すいません、話をうまくまとめられないので
結論だけいいます。

白黒ＢＭＰファイルを当たり判定に利用したいので
ＢＭＰファイルなどについて質問させてください。

当たり判定用に、画像と別に２次元配列を用意するのは中止します。

まず、ＢＭＰファイルっていうのは

1.ファイルヘッダ
2.情報ヘッダ
3.ビットフィールド
4.カラーパレット
5.イメージデータ

というものの集まりだということはわかりました。
そして、5.イメージデータっていうのが２次元配列になってるんだろうってこともわかりました。
ここまで合ってますか？

そして、イメージデータに、 『map[640][2400]』 みたいなハンドルをつけてしまえば、
ＢＭＰファイル内のイメージデータを当たり判定用の配列としてそのまま利用できるんじゃないかと。
>>201のやってることってそういうことですか？ＤＸライブラリじゃない書き方なんでいまいちわかりませんでした。

>>249-259は無視してください。

>>249-250です。すみません。

BMPファイルには、白黒(２値)、16色、256色、フルカラーなどの種類があります。
それによってカラーパレットがあったり、なかったりします。

本題のイメージデータですが、やはり種類ごとに格納形式が違います。
この部分を2次元配列に直接読み込んで使おうとするなら、
256色無圧縮のファイルであることを前提に、配列はchar型で確保しておくことになります。

メモリの使用量を考えると非効率的なので、あれこれ検討していくと、
>>201の方式を含めて、なんらかの方法で2次元配列を用意することになるんじゃないかと思います。

ちなみに現時点で戦車の傾きを求めるとき、ピクセルの有無の参照には何を使っていますか？

>>254
ピクセル有無の判定のために、
白黒画像とは別に用意した、２次元配列を使っています。

この配列は、
GetPixelSoftImage で、白黒画像のピクセルを一つずつ調べて、
黒なら　0、白なら　1、といった風に、fprintf でファイルに書き出していきます。
そうやって作っておいた0と1のテキストファイルを
ゲーム開始時にマップデータとして読み込んでいます。

ファイルに書き出したりしないで、
GetPixelSoftImage で、ピクセルが白か黒か調べて、いきなり配列　『map[640][2400]』　に、0と1を入れていってもよかったんですけど。

この場合、白黒画像のBMPファイルと、0/1のテキストファイルの両方は、重複するんないんじゃないかと思いますが、
ここまでの実装をそのようにしてきて、うまく進んでいるのなら、とりあえずそのまま進めるといいと思います。

確認ですが、戦車を処理するときは、GetPixelSoftImage(x,y)ではなく、map[y][x]でアクセスしてるのですか？
もしそうだとするなら、着弾地点を中心にmapの配列を書き換え、かつ画面表示も同じようにすれば、
所望の動作をすると思います。

>>256
そう思ったんですが、
白黒ＢＭＰにDrawCircleの塗りつぶしで描いた円と、
配列内に0と1で描いた円が、1ドットでもずれていたら、
何も見えないところに地形が存在したり、
見えている地形を突き抜けてしまったりということがおきると思いますし、
どうやって配列内に円形の変化をつけるかっていうところも、シンプルにまとまった方法が思い浮かばないので。

追記、
戦車を処理するときはmap[y][x]を使っています。

今すぐ手っ取り早くできそうなのは>>256のいうとおり、
画面表示とmapの配列を同じように行うのが一番簡単な方法なんですけどねぇ。

できれば、

アルファチャンネル用の白黒画像と、
map[y][x]を連動させるって言うか、
白黒画像そのものがmap[y][x]、
みたいなやり方にしたい。

ゲームの土台になる部分は、ちゃんとしたものにしたいんです。
タンクの画像とか演出は多少陳腐でもでもかまわないけれど。

配列と画面を円でえぐる処理は、こんな方法はどうでしょうか？

void FillCircle(int Xc,int Yc,int R){
　　for(int x=-R; x<=R; x++) for(int y=-R;y<=R; y++) if(x*x+y*y<=R*R){
　　　　if(Xc+x>=0 && Xc+x<2400 && Yc+y>=0 && Yc<640){
　　　　　　map[Yc+y][Xc+x]= 0;　　　　　// 地面判定用配列の加工
　　　　　　SetPixel(Xc+x,Yc+y,背景色); // 画面の(Xc+x, Yc+y)のピクセルを抜く処理
　　　　}
　　}
}

SetPixelと書いた部分は適宜実装する必要がありますが、
配列の0/1と画面のピクセル状態がずれる心配はないと思います。

ところで、そもそも背景に地面を重ねる処理にαチャネルを使っているなら、
地面の画像は[640][2400][4] (R,G,B,A/pixel)の配列じゃないでしょうか？
map[y][x]の代わりに、groundimage[y][x][3]を参照する方法は使えませんか？

>>260
おお、さすがです。
２つも解決法をありがとうございます。
１つ目の方法も完璧だと思うのですが、

２つ目の方法の、αチャンネルを使った画像のグラフィックハンドルを配列として使う（？）
方法も興味深いです。

ためしに、地形画像のグラフィックハンドルを配列として扱ってみたら、
なにかエラーが出てしまいましたが、もう少しαチャンネルについて調べてみたいと思います。
ありがとうございました。

ご存知かと思いますが、ＤＸライブラリでは、

指定のファイル名の末端に『_a』が付く画像ファイルを透明情報として自動的に読み込んでくれる

ということで、アルファチャンネルについてまったく何も知らずに使っていたので、
これを機会にすこしだけ勉強します。
たぶん、ＤＸライブラリを使わずにアルファチャンネルを使うには
けっこう複雑なことをしないといけないんだろうなぁ。

なかなか、望みの情報が見つかりませんが、
引き続き、map[y][x]の代わりにgroundimage[y][x][3]を参照する方法を考えていきます。
なにか、役に立ちそうなホームページとかありましたらまた教えてください。
ではまた。

DxLibは使ったことが無いのですが、リファレンスページを読んだところ、
(1) 地表画像(RGB)および山形状(A)をLoadSoftImageで読み込む
(2) GetPixelSoftImage(handle, x,y, &r,&g,&b,&ground)で、
　　x.,y地点の地面の有無を判定する
(3) 地形の更新は、GetPixelSoftImageに引き続き、groundを0にして、
　　DrawPixelSoftImage(handle, x,y, r,g,b,ground); で書き戻す。
という手順が考えられます。
SoftImageのアルファを判定用にし、かつ地形の変形にも利用します。
敢えて配列を使わなくても、これで、事足りるのではないかと思います。

問題は更新結果を画面に反映させる方法なのですが、
リファレンスによれば、DrawSoftImageを使うか、
GreateGraphFromSoftImageでグラフィックハンドルを作ってから、
DrawGraphで描画するべきではないかと思われます。

DrawSoftImageの説明には負荷が高いようなことが書いてあるので、
いったんグラフィックハンドルを作るのが正式な手続きなのかもしれません。
また、地形の画像が2400x640と比較的大きいので、そういう時は、
CreateDivGraphFromSoftImageを使うべきなのかもしれません。

長々書いていますが、冒頭に書いたとおり、DxLibは使ったことがありません。
詳しい人、フォロー願います。

いろいろとアイディアを出していただいてありがとうございます。
とりあえずは、配列で当たり判定をするのにこだわらず、製作をつづけてみます。

日曜あたりに、
弾の当たった地形がえぐれるのと、
そこの当たり判定がなくなるようになるのを作ってみます。

その次は、一気に難しくなりそうですが、
ネットで対戦することを考えてみたいと思います。

ttp://218.219.242.231/~kuroneko/imgboard1/img-box/img20110227181444.jpg

>>260の上の方法で地形の変形はうまくいきました。

DXライブラリのリファレンスを見たところ、ネット対戦を取り入れるのはやっぱり難しそうですね。
どうも、IPアドレスとか調べるのはDXライブラリだけじゃできないっぽいし。

プレイヤーがホストを立てて、２〜８人までの対戦をできるようにします。
ホストを探したり、プレーヤー同士の交流を行うロビーみたいなものを
無料サーバーを借りて作ろうと思います。

先に、通信抜きで2人対戦できるようにすべきじゃないのかな？

通信抜きでって、ひとつのパソコンで対戦ってこと？
絶対やるべきっていうならそうするけど、
ネット対戦前提で２人対戦ってところから作ったほうがよくない？
ひとつのパソコンで対戦って、ターンが交互に回ってくるようにするだけでいいし。

ひと通りのゲームの流れ（スタート画面->ゲームプレイ->勝敗処理->ゲーム終了）を単一PC内で
実現するのが一般的なひと区切り。
TCP/IPの基礎知識（socket利用あたりまで）があるのならこの時点でネット対応やっちゃってもいいけどその力量がワカラン。
ロビーサーバ構築となるとさらに別世界。規模／機能にもよるけどね

とりあえず、ネトゲ制作のスレとか、ＤＸライブラリのリファレンスを読んで勉強しながら、余裕があればダメージ計算とか細かいとこも作ってみます。

ちゃんとゲームとして成り立つところまで作ってからネット対戦を考えたら？
戦車が2台出るだけでも色々問題が出てくるだろうし。

それと、とりあえず>>108まで完成したのなら一度見てみたい。

>>272
F5押したらデバッグはできるけど、
アプリケーションに作り上げる方法教えてください。

VC++でＦ５押したら普通に実行ファイルがビルドされてると思うが？
デフォルトならプロジェクトフォルダ内にReleaseかDebugのフォルダがあるでしょ。

Debugのフォルダはあったんですが、その中に入っているものをダブルクリックしても
ゲームが起動するものはありませんでした。
方法がわかったらうｐすることがあるかもしれません。

それで、もっと細部まで作ってからネット対戦を考えたらどうかという意見ばかりのようですが、
後の細かいところというのは、一つ一つやっていけば自分だけでもできそうなことだと思うので
ネット対戦の部分をどういう風に作るのか、考えていきたいと思います。

ＩＰアドレスは各自が調べて、ゲームルームに入室したときに
他のプレーヤーたちと自分のＩＰを教えあう。
ＤＸライブラリの ConnectNetWork と、ＩＰアドレスを使って相互にＰＣを接続する。

って感じでいいんじゃないかとおもう。

しかし、サーバーってのはどういう風に扱えばいいんだろ。
各プレーヤーのＰＣにＤＬするゲームソフト以外に、
仲介するためのソフトを作って、それをサーバーにおく必要があるってことかな。

>仲介するためのソフトを作って、それをサーバーにおく必要があるってことかな。
これについては既存のネトゲでも各種方式がある。

1)サーバプロセスが常にデータを中継する
　たいていの本格的MMOはこれ。データを随時中継する際に中身をチェックしてチートを防ぐ効果もある。
　プレイ規模にもよるが、サーバのパワー（ハード、ソフト共）がある程度高くないとプレイに支障が生じる。
　例：UO、EQ､WoW

2)ロビーサーバのみ独立させ、プレイ中はプレイヤー間で直接通信をする。
　MO的なネトゲはこれ。ロビーサーバで各プレイヤーのIPをクライアントに通知して
　プレイ中はロービーサーバを経由せずクライアント間で直接通信する。所謂P2Pに近い。
　リアルタイム的な要素に左右されるゲームに有利。
　商用のネトゲはチート対策や同期ためにサーバにも随時データを送ってチェックするのが一般的。
　例：Diablo（クライアントがゲームサーバの役割も持つ）、各種FPS系

例は古典的な有名どころ。
他にもありそうだけど、大抵はこれら２つの方式をいろいろな組み合わせで実装している。
最近の商用ネトゲだと「MOだけど1)方式」ってのも多い。

IPアドレス情報の交換についてはロビー（ゲームルーム）に入室した時点でロビーサーバがクライアントのIPを
分かっていることになるのでユーザが直に調べる必要は必ずしもない。（そういうつくりにしないといけないけど）
むしろロビーのチャット等で直にIPを教えあうと、いたずら好きなバカがDOS攻撃対象にしたりする可能性もあるので
あまり好ましくない。
システムを一般に公開しないのであればあまり問題はないと思うけどね。

その昔、インターネットでの掲示板も一般的じゃない頃は電話やメールで互いのIPを教えあったものさ・・・。

ってか普通にクライアント同士１：１でちゃんと動くかってところを確認してからだろ

>>277
（２）の方法って、つまり>>267と同じことだよね？

とりあえず、ロビーで対戦相手を探すというところをはぶいて、
クライアント同士１：１で動かせるように作ってみます。

自分のＩＰアドレスを調べるのってどんな方法がおすすめ？

winsockというものを使ったこんな方法がみつかったんですけど、これでいい？
ttp://members.jcom.home.ne.jp/toya.hiroshi/get_my_ipaddress.html

>>281
足元を固めていくという意味ではとりあえずはいいんじゃね？
ipconfigキックで出力をリダイレクト→リダイレクト結果を文字列検索とかのシンプルな方法もアリだろう
複数枚NICがある場合考えるとめんどいがそこはWINSOCK使ってもも同じこと

インターネット経由にする場合はローカル／グローバルの話があるので（一般的には）上記だけでは足りないってのは分かるよな？
分からなければ ローカルアドレス グローバルアドレスでググれ

もっともロビーサーバをグローバルに立てればこれらの話は全部要らなくなるが

>>275

起動に必要なデータファイル(画像とか)が同じフォルダに入っていないんじゃないかと思う。

>>283
そのとおりみたいでした。
ためしに画像とか適当にぶっこんだら動きました。
ttp://www.dotup.org/uploda/www.dotup.org1407350.zip.html

パス

1111

ネットへの対応はまったく進んでません。勉強もしてません。

>>284
遂にここまでできたのか
暫くROMってたけど俺も完成期待してるから
頑張って下さい

＞115
一人の応援だけでだいぶやる気が出た。
おひさしぶり。
元気ですか？
私は相変わらず暇人です。

風邪ひいてきつかったけどやっと直ってきた
ネットワークの実装やったことないからアドバイス出来なくて残念だ

地震で死んだわけじゃないけどね。
何をしていいかわからなくなったんで放置。
ＭＭＯＲＰＧの作り方を書いた本でも買ってみようかな。
まあ、うちの近所に大きな本屋がないんで中身を見て確かめられないのは痛いけど。

1) ネット通信なしで、２Ｐ対戦を実装する
2) 次に２ＰをCPU制御で実現する
3) CPU制御の機体数を増やす
4) 通信プロトコルを設計する
5) 通信処理を実装する

この順でやるといいよ。

ワロタ

基礎から学んで行こうと思います
分からない事がまだまだ沢山ありますが
ご指導ご鞭撻の方宜しくお願いします
c/c++の勉強をして行きたいです。
でもまずはＣからお願いします。
基礎からみっちり叩き込んで下さい
ボクも頑張って行きたいと思います。

基礎から学んで行こうと思います
分からない事がまだまだ沢山ありますが
ご指導ご鞭撻の方宜しくお願いします
c/c++の勉強をして行きたいです。
でもまずはＣからお願いします。
基礎からみっちり叩き込んで下さい
ボクも頑張って行きたいと思います。