厨房に分かる程度優しく教えてくれた方にはお礼をｲｲﾏｽ
#include <stdio.h>
main()
{
printf("1:ぐー 2:ちょき 3:ぱー\n");
getchar();
if (0)
printf("あなたの勝ちです\n");
else
printf("あなたの負けです\n");
}
じゃんけんプログラム
copy con janken.c
でやりました
のですが基本はやっぱどのプログラムもｵﾅｼﾞなんですか？
2にあるじゃんけんに勝てたら教えてあげます
同じ物が作れるくらいになりたいんですけど
毎日６時間以上みっちり勉強したとして1年以上かかりますね。
それくらいの覚悟はありますか？
プログラムが組めるようになった人っているのでしょうか？
たいてい根性なし＝無理
このサイトがおすすめだよ。全部解決すると思う。
http://www.google.com/
ｵﾏｴ親切すぎ。
http://game.2ch.net/gamedev
＞CDチェックやプロテクトを解除したり、やりたいゲームと
＞同じ物が作れるくらいになりたいんですけど
とにかくコピーしたいんだね。素晴らしいこころざしだよね。板違いだろうね、きっと・・・・・・
シネ
>CDチェックやプロテクトを解除したり
ﾜﾛﾀ。
真性ですね。
http://plaza28.mbn.or.jp/~Q_A_Q_A/same.lzh
クソスレもageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
∧＿∧ ∧＿∧ age
（・∀・∩）（∩・∀・） age
（つ 丿 （ ⊂） age
（ ヽノ ヽ/ ） age
し（＿） （＿）Ｊ
レス30以下のゴミスレはageてやるからな！
￣￣∨￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
∧＿∧ ∧＿∧ age
（・∀・∩）（∩・∀・） age
（つ 丿 （ ⊂） age
（ ヽノ ヽ/ ） age
し（＿） （＿）Ｊ
／ ﾟo＼
（´Д｀Ｏ ）
（⊃o⊂ﾟ）
Ｕ Ｕ
＿＿＿＿＿＿∧＿＿＿＿＿＿＿
自動age
は矢口。
/´,,,._｀ヽ
（ ﾉ _.ヾ、)
f､ ,_.ﾉゞ´ このｽﾚが邪魔だと思うならここへきなさい・・・
＿| ー,´_ http://qb.2ch.net/test/read.cgi/saku/1032639736
/ / ／__ ヽ、
/ 〈"｀´ ,/ﾐ)━･~~~
/ __,,.-''￣/ノ ヽ､ ヽ
（＿＿,,.-''￣ | ／ .／
ゝ 彡⌒〉／
／⌒ヾ ^ヽ
/ ''"γ⌒ヽ i""'';;
/ /;|ﾞ "i＿）_ノ,,,,.;;''ﾐ
/ /,,| | ,,;;;ﾐ
/ ／ | |'┰""""""
/ 〈 .| |.┃
／_ノ ） | .| ┃
<二-'"l」 / |）┃
|_ノ/」 ┃
<__ノ ┃
━━┻━━
/´,,,._｀ヽ
（ ﾉ _.ヾ、)
f､ ,_.ﾉゞ´ このｽﾚが邪魔だと思うならここへきなさい・・・
＿| ー,´_ http://qb.2ch.net/test/read.cgi/saku/1032639736
/ / ／__ ヽ、
/ 〈"｀´ ,/ﾐ)━･~~~
/ __,,.-''￣/ノ ヽ､ ヽ
（＿＿,,.-''￣ | ／ .／
ゝ 彡⌒〉／
／⌒ヾ ^ヽ
/ ''"γ⌒ヽ i""'';;
/ /;|ﾞ "i＿）_ノ,,,,.;;''ﾐ
/ /,,| | ,,;;;ﾐ
/ ／ | |'┰""""""
/ 〈 .| |.┃
／_ノ ） | .| ┃
<二-'"l」 / |）┃
|_ノ/」 ┃
<__ノ ┃
━━┻━━
終了厨やアホどもには構わずがんばれ
std::cout << "namespace付いてない！" << std::endl;
≡≡≡≡≡≡≡ ∧ ∧ ／￣￣￣￣￣
Ⅱ ∩ ［］ ％ 曰 （ﾟДﾟ ;） ＜ こねぇなぁ。
＿＿＿＿＿＿＿＿_|つ∽）_ ＼＿＿＿＿＿
―――――――――――
━┳━ ━┳━
￣ ┻ ￣￣￣┻￣￣￣￣
気に入らなかったら言ってね。また引っ越すから。
前にいたスレはこちら。
http://pc5.2ch.net/test/read.cgi/gamedev/1074347252/l50
・5人以上のパーティが作れる2D-RPG。
・WinでもMacでも動く。Java1.4で動かす予定。
・最低スペックはセレロン400MHz。にしたいけど、無理ならG4-700MHzくらい。
今できていること。
・画像の合成とスプライトの表示。
・レイヤ数はメモリの許す限り。
目標
・今年の冬くらいまでにシステム作って、来年の夏休み頃にゲーム完成。
サポートWebサイト
・ありません。ごめん。
・わたしの作業がある程度進んだらシナリオ担当の子が作ってくれるはず。
・今動いてるものはあるけど、素材の版権問題で表に出せないんです。
あいことば
・まったりまったり。
なんだかんだで一ヶ月もあいちゃったなあ。
なんかもうだいぶ忘れてるような……。
と言われて、そんなのわたしに言わないでよ、とか思いながら見てみると、
脱衣ブロック崩しでした。
でもそのアプレット、Macでは動きがへん。
納得いかないのでちゃんと動くようにバグ取りました。作者さんには言ってないけど。
そんな感じで週末が終わってしまった。……ゲームづくり進んでません。
ただチップを並べるわけにもいかないなあと悩む今日この頃。
ツクールの通行方向設定もいいアイデアなんだけど、
それだけじゃ見た目が変になっちゃうケースもあるんだよねぇ。
うーん。困った。
マップを２層にして、下の層はキャラより下になる物、上の層はキャラより上になる物って感じにして、キャラは上の層と下の層の間を歩く。
橋を上の層にしておけば、キャラは橋の下をくぐれるよ。
実はもう一個悩んでたのがあって、
ツクラーで物好き(?)な人なら試した人あるかもしれないけど、
ドアを開けて中に入ろうとすると、ドア枠の上に乗ってしまうという現象が！
高さと奥行きをいっしょに扱おうとするからややこしいんだと思うんだけど、
別々に扱うのはめんどうで……。
CVSROOTはどこに書くのかしら。
1.2は2で1.5は5?
えらい人の考えることはよくわからないですね。
わたしは当分1.4でいきます。
一応横スク。
メタル ヴァり～知らん 知らん
マリオみたいな感じで。
>940
何もやらんよｗ
リーダーみたいなもんだわさ。
・絵師
他のメンバーは絵に引かれてやってくる人多し、
生産低いＯＲ逃亡で一気に崩壊の危険高い
逆、絵師がみんなをリードしていき完成まで行く可能性が高い。
・ＰＧ
他のメンバーを素材をして利用、
企画としては長く続く。
会話は、 材料の指示などでつまらない。
あと、精神的に異常がある人多し、問題多々。
・音や
どうでもいい。
フリーで十分なのが得られるので、
神音ではないかぎり必要性を感じない。
モチベは低いだろう。
・シナリオ
神シナリオでないと集まらない。
シナリオは批判など多いので、タフなやつではないと生き残れない。
・無能
本人のやる気なし。
一番、終わりやすい。
逃亡率１００％
プログラムはほぼ初心者。
今、Ｋａｇでゲームを作り始めて、ＴＪＳをすこしだけ理解した。
言うまでも無いと思うが、俺がゲームを作り上げることが出来るかどうかはお前達しだいだ。
どうか力を貸してほしい。
作りたいゲームは、「ポトリス」「アサルトギア」「ガンバウンド」などに代表されるタイプの
放物線を描く弾を敵に当てるゲーム。
どういうゲームなのか、知らない人は以下のURLの「対戦！ねこ戦車」をプレイしてもらえばすぐに分かる。
ねこ戦車はブラウザゲーなので、すぐに始めることが出来る。
アカウントの作成も必要ないのでぜひ一度おためしあれ。
ttp://mogera.jp/gameplay?gid=gm0000000578
①ウインドウを表示する。
②地形を表示し、その上に戦車を置く。
③地形の凹凸に応じて戦車自体の角度が変わる。
④車体角度とは別に砲台角度を変更できる。車体角度+砲台角度が発射角度になる。
⑤スペースキーを押す時間に応じて弾の発射力が変わる。弾は放物線を描いて飛ぶ。
⑥弾のぶつかった地形が、着弾点を中心に円形にえぐれる。
⑦一定以上の角度の地形は移動できない。
いろいろあってよく分からない。
ネット対戦を前提にして、なにを使えばいいか教えてくれ。
.NET Framework SDK
すべてお前等の努力にかかっている。
http://www.microsoft.com/japan/msdn/vstudio/express/
ここからVisualC++をダウンロードして使え
今日の勤務時間中にＣ++の入門ページを読んで
画像の表示方法でも調べてみます。
帰宅後、また教えてください。
まずは、地面の表示とキャラクターの表示をしてみようかと思うのですが、
これには、地形とキャラクターの当たり判定と、キャラクターにかかる重力の計算が必要になると思います。
このあたりから教えてもらっていいですか？
一般的なプログラムの勉強の仕方としては、
もっと別のことから段階を踏んでステップアップしていくべきなのかもしれませんが。
キャラクターの下側の座標が地面の座標を超えたら
キャラクターの下側の座標を地面に合わせる。
重力はキャラクターのY座標に速度を常に足していく。
キャラクターが地面についてなかったら
速度に加速度を足していく。
地面についたら速度を0にする。
スタート地点がおかしい？俺にはわからん。
>>115
そういうこと。
で、具体的にどうすればいいかが分からない。
今日の勤務中にＶｉｓｕａｌＣ++の説明をしたホームページで勉強したが、
基礎の部分が長すぎて読みきれなかった。
今週いっぱいくらいかかるだろう。
ところで、地形の素材を作ってみた。
背景と地形の画像は別々に用意している。
ほかに、白黒２色の画像で、地形だけ黒くした画像も、当たり判定つけるときに役に立つんじゃないかと
思って用意した。
ttp://www.dotup.org/uploda/www.dotup.org1388328.jpg
プロジェクト名は 2tank だ。
とりあえずは仮名で。
そのうちかっこいい名前を考えるぜ。
画像を表示させるのはpictuerboxを使えばいいんですか？
このさい、pictuerboxの使い方も教えてほしいけど、そこは自分で調べます。
pictuerboxってのがどうも、画像を表示させるのに使う道具らしいってのは感で分かりますが、
こういう場合は他の道具で表示させたほうがいいのかもしれないから、やるまえに教えてください。
今日はここまで。
この後当たり判定をつけるにはどうするか教えてもらえるまで待ちます。
定期的に処理を呼び出す方法は調べたの？
ゲームは１秒間に３０コマくらいは処理を繰り返さないとだよ。
あとpictuerboxって処理が重い気がするな。
まあ俺も初心者だけど知ってる限りアドバイスする。
実装の難度が変わってくると思うよ
>>108の⑥を入れるか入れないかが分かれ目かな
pictuerboxって重いのか。
それじゃあ、どうやって画像を表示させたらいい？
あと、定期的に処理を呼び出す方法とかも知らないので教えてください。
>>123
⑥=着弾地点を中心として地形が円形にえぐれる
これは絶対にはずせません。
穴を掘って敵をうめたり、穴の中に隠れたり、敵をフォールアウトさせたりと
細かい戦略がこのゲームの面白いところですので。
地形を折れ線で定義するとか、ビットマップで定義するっていうのはどうやるんですか？
今、私が出来るのは描いた絵を貼り付けることだけです。
調べるヒントになることだけでもいいので教えてください。
windows用のゲームはだいたいdirectXが使われてるよ。
まあ使い方は結構めんどくさいけどね。
定期的に呼び出すのはスレッドを作ってsleepするか
WM_TIMERを使うといいよ。
ビットマップで地形を表示したいなら
ビットマップのフォーマットを調べて
座標に変換するようにすればいいと思う。
一度に言われても分からない。
とりあえずビットマップのフォーマトを調べてみます。
pictuerboxを使うと重いって話もあったんで、他の画像の表示方法も教えてください。
一度に聞いたのはお前じゃんｗ
ビットマップより先に画像表示が先だと思うよ。
俺は画像表示にdirectX9のスプライト機能使うのがいいと思う。
何が分からないか書かないのかよｗ
アクションゲームじゃなくてターン制のゲームだったら
とりあえず描画が重くてもなんとかなるんじゃないかな
>>124
やりたいことを完全に実装したいなら、
まず、ステージの広さ分の仮想画面で地形を定義して、
ウィンドウサイズ部分を切り出して表示する処理が必要だよ
説明はまたあとで読みます。
>>131
これまでのこれ系のゲームはターン制だったけど、
それって先行がかなり有利な場合があるんです。
そういう不平等をなくすために、ターン制は半分廃止にします。
なので、リアルタイムの通信が必要で、軽く出来るところがあるなら軽くしときたいです。
で、
>ステージの広さ分の仮想画面で地形を定義して、
>ウィンドウサイズ部分を切り出して表示する処理
この部分、具体的にＶｉｓｕａｌＣ++でどうやったらいいかとか、教えてもらえません？
１枚の画像の表示はできたの？
それをただ地形の形になるように並べるだけだよ
pictuerboxでＪｐｇ画像を表示することは普通に出来ました。
地形の形になるよう並べるって言うのはどういうことですか？
まったくわかりません。
背景画像と地形とマスク(地面の有無)の３枚の画像があるんだよね？
pictureboxとやらでちゃんと合成できるの？
できるとしたら、処理速度的にどうなの？
知らない。
やっぱり地形の有無を示すためのマスク画像ってのが必要なんだな。
で、それをどうやったら表示させることが出来る？
jpegでやるんなら透過使えるんだからマスク画像なんて必要ないでしょ。
処理速度がpictureboxだと遅くてアクションだときついって言ってるのに
そこは考えないの？
directXの場合地形を１枚の画像でやろうとすると
ビデオカードが大きいサイズに対応してなかったりするから
512pix以内に地形画像を分割して並べて表示するのがいい
だから、具体的にやり方を言え能無し。
directX9のスプライト機能使えって言ってるだろ
教えてあげてるのにその態度はなんだよ
お前は馬鹿だからもっと具体的に教えてやらないとダメみたいだな
directX9 スプライトで検索しろ
人間として生きる価値ないよお前
新店舗をまかされたはいいが、客が来ないだけだ。
最初からそういいたまえ。
まずは気負わないで出来そうなことから部分的にやると良いと思うよ
平坦な地面を左右に動くだけのプログラムを作るとか
あといきなりDirectX9は敷居が高い気もする
11は簡単らしいけど知らん
なに、directx9は敷居が高い？
使わなくてもやれるの？
平坦な地面の上をキャラクターが左右に動くだけのプログラム。
それでもいいからやり方教えてくれ。
つDXライブラリ
画像程度なら簡単に表示できる。
まずはこれをインスコして動かすだけでもやってみ。
directX9でもスプライトならサンプルコピペで簡単に画像表示できるはずだよ
それ、ＤＸライブラリっての聞いたことがある。
ゲームを作りやすいものだって、ニコ動で誰かが言ってた。
仕えるようになるまでの設定もめんどくさそうだけど、詳しく説明してくれてるページがあるんで
ちょっとやってみる。
> まず適当なグラフィックファイルを以下のフォルダにコピー等で入れてください。
>
> VisualC++6.0 又は VisualStudio.net の場合
> サンプルプログラム用フォルダ( DxSample ) の中の『VC』というフォルダ。
ＶｉｓｕａｌＣ++２０１０Expressの場合、どこのフォルダに画像を入れればいいですか？
作られたexeファイルのあるフォルダに入れて実行すればいいんじゃない？
あとＤＸライブラリ使うならやり方しらないからアドバイス出来ないな
俺はPCでのゲーム作りはdirectX9のコピペから初めた。
まあコピペだからdirectXの本質はあまり理解してないが
とりあえず形あるゲームは作れた。
これなら俺にもなんとかなるんじゃねｗ
>>151にあるような『ＶＣ』とかいうフォルダ探すのをあきらめて
ためしにプロジェクトフォルダに入れてみたら出来た。
でも画像サイズがでかすぎる。
調節しないと。
ってか、説明ページを読みながらやったら、
ウィンドウじゃなくて全画面表示されるようになったし。
次はウィンドウを表示させよう。
せっかくだけど、ＤＸライブラリでやるわ。
わるいね。
協力ありがとう。
とりあえず傍観しようかな
お前の書き込みは一切役に立ってねぇんだよ。
いてもいなくても同じだからとっととうせろｗｗｗ
とか言ったら荒れるからな。
俺大人すぎｗｗｗ
水平な地形を表示して、
自機を表示して、
自機が左右に動くようにしました。
自機が残像みたいになるので、
１ループするごとに画像が消えるようにしました。
そうしたら地形も消えました。
地形画像と自機を別のレイヤーに表示させることって出来ませんか？
レイヤーってのがないんでしょうか。
しかし、関係ないが腕が痛い。腱鞘炎？
力が入らん。
右のような画像との当たり判定をつけるにはどうすればいいの。
ＤＸライブラリで使用するべき関数とか教えて。
透明な小さい四角をギザギザと同じような形に並べといて
その四角と当たり判定つける
int grandY[地面の幅]; //地面のY座標
getGrandY(grandY); //地面のY座標取得
//当たり判定：charactorXは地面の左端からの座標 charactorYはキャラの下側の座標
if(charactorY>grandY[charactorX])charactorY=grandY[charactorX];
void getGrandY(int *grandY)
{
地面のY座標取得の方法
案①(難易度大、スマートさ大)
地面の画像ファイル(jpg?)を解析して座標を求める。
案②(難易度中、スマートさ中)
地形が記憶された白黒のビットマップを用意して、そこから座標を求める。
案③(難易度小、スマートさ小)
手で入力
}
縦×横 １ｘ１ピクセル の画像を並べるというような手作業はムリ。
もっとおおざっぱでもいいんじゃないかって思うかもしれないけど、
ミリ単位の地形の凹凸が戦略に影響するゲームだから、それはちょっと困る。
>>162
肝心の部分が分からないんですが
案① 画像ファイルを解析して座標を求める
って具体的に何をするんですか？
案②
こういう方法を今日思いつきました。同じことですか？
今日の勤務中に、 GetPixel という関数を発見しました。
指定点の色を取得できるらしい。
これを利用して、自機の下の座標が白なら当たってる。
黒なら当たってない。
というふうにやれば複雑な地形でも当たり判定をつけることが出来ると思ったんですが、
レイヤ表示させることができないとこの方法は無理です。
白黒の地形画像の上に本物の地形画像を重ねるわけですから。
逆に言えば、レイヤ表示ができればなんとかなると思うんで、どうにかできる人がいたらどうにかしてください。
③
>>161と同じ方法ですか？
そういう書き方されても分かりません。
白黒画像の地形に当たり判定をつける作業に入る。
①のやり方
http://ex.osaka-kyoiku.ac.jp/~j099608/test/text11.html
ここを参考にして考えよう。
ただし俺も分からんから頑張れ。
まあこの方法が完成したら白黒画像作る必要がなくなる。
②のやり方
http://www.kk.iij4u.or.jp/~kondo/bmp/
ここを参考にして考えよう。
①より簡単だけど結構むずかしいと思うよ。
③のやり方
grandY[0]=1px目の地面のY座標
grandY[1]=2px目の地面のY座標
.....
地面の幅の分だけこれを繰り返して入力しろ。
１番簡単だからおすすめは③だよ
ほんとに分かってんの？
getPixcel調べたらGDIの関数みたいだね。
GDI使ったことないから使えるか分からん。
①は俺にも分からんって言ってるじゃん
③がお前が１番できる確率が高い方法
ネコ戦車であそびおわったからそろそろ作業開始するわ。
int Cr ;
Cr = GetPixel( tankX , tankY ) ;
GetPixelで取得した 色コード ってのがどういうもんなのかよくわからん。
#FFFFFF とかってやつかと思ったんだけど、良く分からん。
なので、取得した色コードがどんな物なのか、表示させてみたい。
どんなふうに書けばいい？
それか、白の色コードをいきなり教えてくれてもいい。
上４行の方法だと水平な洞穴は作れないのと違う？
>>163
白黒画像を地形画像のαチャネル扱いしておけばレイヤー合成できるよ。
っていうか、着弾するごとに地形が変化するようにしたければ
仮想画面の取り扱いは必須だと思うよ。
>>170
COLORREFで検索するといいよ。
>>108に洞穴作るなんて情報書いて無いじゃん
ありがとうございます。
さっそくCOLORREFで調べてみます。
今現在、白黒画像をαチャンネルとして用意して、
背景が見えるようにしてるんですが、
getpicxelでαチャンネル画像の色コードを取得することは出来ないので・・・
まあ、これについては後でかんがえます。
ありがとうございました。
DXライブラリ総合スレをみたり、いろいろ試して、
なんとか地形の上を動くようになりました。
方法は、
自機の下の座標の色を取得して、
黒（地形以外の場所）なら自機の位地を下げる。
白なら（地形の中にめりこんだら）自機の位地を上げる。
というものです。
一応地形の上を動いてはいますが、まったく納得がいかないので
しばらくは地形の当たり判定をうまくする方法と画像をレイヤ化する方法を探します。
それと、ここに居てもあまり有用な情報が得られ無いので
今後はDXライブラリ総合で名無しとして質問しながら製作を進めます。
進展があれば報告くらいにはきます。
ttp://218.219.242.231/~kuroneko/imgboard1/img-box/img20110202012444.jpg
いや、まじでちゃんと教えてくれよ。
教えてくれるならここでやる意味もあるってもんだけどよ・・・。
ところで、今日の16時30分ころにひらめいた。
仕事中だったのでメモ帳に書いて自宅にメールを送って、今実行。
こういうふうにやった。
なお、
機体の下の地形の当たり判定を調べる座標のことは 接地判定点 と呼ぶことにします。
用意した画像は ①背景 ②地形 ③地形とそれ以外の部分の白黒画像 ④タンク
-----------------------------------------------------------------
・描画先を裏画面にする
以下ループ
・③白黒地形を読み込む
・接地判定点の色を得る。
・画像を消す
・①背景、②地形画像を読み込む。
・接地判定点の色が黒ならタンクの座標Yを下にすこし移動させる。
・④タンクを表示する。
ttp://218.219.242.231/~kuroneko/imgboard1/img-box/img20110202200118.jpg
クズ過ぎワロタ
接地している地形に応じて機体の角度を細かく変更させたい場合はどうすればいいですか。
atanで地面の傾きの角度を求めてそれを機体の角度に反映させる。
ところで恵方ってどっちだ。
>>179
atanの存在を教えてくれてありがとう。
でも、角度を求めるには2つの点が必要だけど、
それをどうやって求めるかってところでなやんでる。
>>180
おれもそれを考えた。
でも、getpixelって重いらしいから、多様しちゃだめだって書いてたので気になる。
しかも、実はこれが3つ目の接地点。
いつの間に2つ目の点を作ったかっていうと、
接地点が黒の場合、機体の位地はどんどん下がって、白に1ドットめり込んだ状態でとまる。
その後、横に移動して、山みたいな地形にぶつかると、中にもぐりこんでしまうので、
今度は接地店が白の場合、機体の位置をどんどん上げていくようにする。
そうすると、接地店が白と黒の間でいったり来たりする結果になるので、
接地点を縦に２つ並べて、上の点が黒で下の点が白なら機体の上下を中止するっていうふうにした。
これで、タンク１つにつき3つのgetpixel。
４：４の対戦なら１２のgetpixel。
……
まあ、かんがえても仕方ないから、接地点とタンクを増やしてやってみる。
これでだめなら、当たり判定のしかたを根本的に改める必要がある。
Getpixel より GetPixelSoftImage のほうがいけてるぜぇ～。
との助言をいただいたので、そっちに変更しました。
GetPixelSoftImage って、 赤 緑 青 透過度 の４つを得ることが出来ますが、
これらのうち、一つだけを得ることってできるんでしょうか。
1つだけなら処理も軽くなる気がするんですが。
atanを使うには、一番最初に
#include "math.h"
って書けばいい？
必須ヘッダとか書いてたけど、良く分からん。
while
{ }
の中に、さらにwhileって入れていい？
GetPixelSoftImageの重さが気になるなら
配列用意してロード時に読み込んじゃえばいい
>>183
#include <math.h>
標準ライブラリだからこう書く
>>184
自分でややこしくならないなら入れてもいい
じゃあ、エラーが起こってる理由は別だな。
配列って、
000000000000000
000011111100000
001100000011000
001100000011000
000011111100000
000000000000000
みたいな感じで構造体ってのを並べてマップ表示するやつだろ？
構造体の縦×横が1ドットのものを全部並べるとしんどいからだめだって
>>161の時に言ったじゃん。
接地点を縦に２つ増やし、
タンクを８つに増やした。
Getpixelは全部で１６個。
５ミリ秒ごとに１６のGetpixelをやったけど特に問題なかった。
地形との接触角度を求めるために１タンクごとにGetpixelを３つにするのは問題なさそうだぁ！
というか、やりながら思いついたんだけど、
各タンクの角度を１台のPCにやらせる必要はない。
それぞれのプレーヤーのPCに自分のタンクの角度を計算させ、
計算後の機体角度と位地座標を他のプレーヤーに渡せばいい。
http://www.kk.iij4u.or.jp/~kondo/bmp/
ここを見て作れって言っても全然理解できてないみたいだったから
しょうないから俺が白黒画像読み込み関数を作ってやった。
俺も情報系じゃない大学生だけどＣ言語の基本をちゃんと勉強すれば
このくらい作れるんだよ。
http://www.nigauri.sakura.ne.jp/src/up17895.zip.html
ミスってた
fp=fopen(fileName,"r");
をfp=fopen(fileName,"rb");に直して使ってくれ。
ポトリス系のゲームはやったことある？
プログラムできるんなら君に任せて、
俺が画像や音の素材作りをして、共同制作しませんか？
>>188
それを使えばだいぶ軽くなりそうだな。
実際使ってみてどうなるか分からないけどわざわざありがとう。
getImagePixel(x,y)
>>188でいただいた物の中身を見たら、
getImagePixel(x,y)
って言う物があったんですが、これって
getpixeｌみたいに重くないんですか？
弾が当たったら、その部分が大きく円形にえぐれるんで、
着弾するごとにそのマップデータを書き換える必要があるんですが、
白黒画像に塗りつぶした円を描画
↓
getimagepixelを利用して配列を作る
ってやってたらると思うんですが、
1と0で出来た配列に、直接円形に変化させることもできますか？
できたらかなり助かりますが。
／ |
／ |
／ | x
／ |
／ |
／θ |
￣￣￣￣￣￣￣
y
この角度、θを求めるためには
θ = atan2 ( y , x ) ;
って書けばいけるかと思ったんですが、だめでした。
どう修正すればいいですか？
今のマシンじゃちょっとやそっとじゃ重くならないし。
速度が気になるんなら関数をラップして、
完成して余裕ができたら速い処理に置き換えるよう工夫するとかしたほうがいい。
初心者に分かるように言えYo！ファッキュー！
でも、重いかどうか考えずに作ったほうがいいってのはそうだな。
人間の感覚で重いと思っても、コンピューターにとってはそれほどでもなかったりするし。
思い切って、getpixelいっぱい使っても平気だった。
どんどん作っていったほうがいい。
それで動かなかったらそのとき考えよう。
で、>>194は？
「PC壊れちゃったんでしばらく作業できません」
ってことがよくあるが、ほんとにあるんだな。
俺は風呂が壊れた。
水風呂だ。
http://excel.ara3.net/func/atan2.htm
斜辺と接辺の内積を取る。単位はcosθ。
ラジアンとかで取得したかったら、内積値に逆三角関数で求められる。
事故解決しました。
XとYに(double)つけたらよかった
getImagePixelはメモリから直接読みだしてるんだからgetpixeより全然軽いはず。
http://www.nigauri.sakura.ne.jp/src/up17897.zip.html
↑は円と四角形を描画するプログラムも入れた奴
テストをあまり行ってないからバグがあったら教えてくれ
これで描く塗りつぶし円は、ビットマップ画像に描画して、その後再び
getImagePixelでビットマップを0と1の配列にするんですか？
言ってることが良く分からんが
このプログラムはloadImageでファイルから配列bufに画像を読み込む。
fillRect、drawCircle、fillCircleでbuf内に入ってる画像に書き込む。
getImagePixelでbuf内の画像の色を取得出来る。
お前はgetPixelで白黒画像を読み込んでるみたいだからgetImagePixelに
置きかえれるはず。
着弾して地形がえぐれるたびにgetimagepixelを桁違いに多用することになるから。
fillCircleでbuf内に入ってる画像に書き込んでからgetImagePixelで画像の色を取得
というのが、無駄が多すぎる気がする。
ただ、ゲーム開始時のステージデータ読み込みにはすごく有効だと思う。
あとは、着弾点をどうやって変形させるかさえなんとかなればいける。
というか、あらかじめgetpixelを使って配列を作っておけばいいね。
fillCircleは地形を変化させる時に使えばいいだけで
getImagePixelは１回loadImageで白黒画像を読み込んじゃえば使えるよ。
fillCircleを使った後にgetimagePixelを使わないと、
配列はfillCircleを使った前と後で変わらないんじゃない？って話なんだけど。
配列の中身はfillCircleを使わないと元の画像のままだけど
何か問題あるの？
変わるよ
http://amadela.web.fc2.com/tank/
マシンスペックによっては、ちょっと重いかも。
>>211
getImagePixelは
配列から値を読み取る
じゃなくて、画像から値を読み取る
じゃないの？
getImagePixelで読み取り、
putImagePixelで0と1の配列に書き出す。
↓
0と１の配列が出来上がる。
↓
地形を変形させたいので、
fillCirkleでBMP画像に円を描く
↓
BMP画像は変形したが、この状態ではまだ0と1の配列はさっきと同じ状況。
↓
getImagePixelで読み取り、
putImagePixelで0と1の配列に書き出す。
↓
変形後の0と１の配列が出来上がる。
じゃないの？
すばらしい！
まさに基本はこれです。
地形との当たり判定はどうやってますか？
機体の角度はどうやって測定してますか？
急斜面を上れないようにするのは機体の角度で制限ですか？
全然違う。ちゃんとプログラム読みなさい。
loadImageでファイルからBMP画像を配列bufに読み込む。
(0と1の配列が出来上がる。起動時に１回読み込めばいい。)
↓
地形を変化させたい時はfillCircleで配列内の画像に円を描きだす。
(putImagePixel、drawCircle、fillRectは書き出す形が違うだけでやってることは一緒)
↓
getPixelImageで配列bufからデータを読み取ることができる。
(配列から読み取っていて軽いので当たり判定に多用出来る。)
↓
saveImageでbuf内の画像をファイルへ出力することもできるが、
デバッグ用のおまけなので使う必要はない。
つまり画像ファイルにアクセスする関数は
loadImageとsaveImageだけだよ。
・中心が地面 or 前後両方地面 → 真上に持ち上げる
・中心も前後とも空間 → 真下に落ちる
・前が地面で後ろが空間（もしくはその逆） → 回転させる
でやっています。
マウスホイールで画面を拡大できるので、凸凹の上で少しずつ
動かして観察するとわかりやすいと思います。
戦車を移動させるときは、単純にＸ軸方向に動かすのではなくて、
戦車の前後方向（回転後）の移動量を足しこむのと、
回転させたときの角度も±６０度程度で制限しているのの両方で、
一定以上の傾斜が上らなくなりました。
この辺、調整が微妙なので、時々妙な挙動をするけれど実装は簡単です。
> 回転させたときの角度も±６０度程度で制限している
ではうまくいかなかったので、
「＋(－)６０度を超えているときは前(後)の移動操作入力を中止する」
方法に変えたのでした。
角度制限を外したので、時々絶壁に張り付いて動けなくなるみたいです。
やっぱり納得いきません。
>fillCircleで配列内の画像に円を描きだす。
fillCircleはやっぱり 画像に円を描き出す んでしょ？
配列の一部を直接変化させるわけじゃないんじゃ・・・。
ちょっと良く分からないのでこの話はいったんここまでにします。
画像を0と1の配列に直すアイディアをありがとうございました。
>>217
ほぼ理想どおりの動きです。
マウス操作での画面拡大や画像のスクロールはアサルトギアでもありました。
これが有るか無いかで操作性がずいぶん変わるんです。
接地を判定する点が合計３つ、
□□□ こんなふうに並んでるわけですね。
■■■なら下降
□□□なら上昇
■□□なら、反時計回りに回転。
では、回転した後の判定点は
◆
◆
◆
こんなふうに斜めになるんですか？
俺が頑張って作ったのに使ってくれないのかよ
>画像を0と1の配列に直すアイディアをありがとうございました。
白黒画像ファイルが01の集合だってのは分かってる？
それをloadImageで配列にぶち込んでるだけだから
配列の中身は元の画像ファイルと同じまま。
だからsaveImageで配列の中身をそのまま画像ファイルに書き出すこともできる。
fillCircleは配列の中の01を書き換える関数だよ。
まあ、その辺は弾を打ち出す段階になってから詳しく考えます。
今回は非常に助かりました。
単純に画像配列から判定点３箇所をサンプルしてるだけです。
したがって、戦車の幅は１ピクセルよりも大きいので、多少の凹凸は無視されます。
それが良いか悪いかは今の時点ではわかりません。
また、回転後の判定点も、斜めに並んでいるとは限らなくて、このプログラムでは、
(-w*cos(R),-w*sin(R))、 (0,0)、 (+w*cos(R),+w*sin(R))
※ wは戦車の幅半分の定数、Rは現在の回転角度変数
で計算しています。
>>219
115氏の作成したプログラムはメモリ上に確保している仮想VRAM(＝配列)に、
初期状態での地面の有無を読み込み、任意点の有無判定および地形の更新をするもので、
実画面（ハードウェア）に絵を描くものではないようです。
しかし地面形状を調べる際、実画面(ハードウェア)をアクセスするよりも遥かに効率的にできます。
私も実装方法は違いますが、同じような仕組みを使っています。
ソースを丁寧に読めば、きっと参考になりますよ。
参考になります。
また質問に来ると思うので、暇があったらよろしくお願いします。
>>222の書き込みを参考に機体の角度を計算させようと思います。
そのまえに、floatとか、doubleとか、intについて調べないとうまいことラジアンを計算できないっぽいですが。
>>212
面白かった
各員気合を入れておれに教えるように！
なお、難しいことはわからないのでできるだけ噛み砕いて説明するように！
まずはID:fuYn973Kの書き込みを見直して意味を考えよう。
さっぱりわからん。
まあ、じっくり考えよう。
どうも>>212もパーフェクトってわけじゃなかったみたい。
拡大してよく見ると、角度によっては機体が上下にぶるぶる震えてる。
とはいえ、ほぼ理想どおりだし、引き続きこれを参考に考える。
それを整数に直したかったら、別に int x とか作って、
その中に代入すればおｋ？
四捨五入されて整数になる？
点①と②は中心を( x , y )とする円周上の点であり、地表と円が交わる点である。
なので、半径を 5 とするとそれぞれの点は
( -5*cos(ｒ1) , -5*sin(ｒ1) ) 、 ( 5*cos(ｒ2) , 5*sin(ｒ2) )
という座標であらわせるのかと思う。
点①と②の座標がわかれば、atanを使って r3（タンクの角度）が計算できる。
ではそもそも、円と地表が交わる点のラジアン、r1とr2はどうやってもとめるのか。
点①と点②が空と地面の間にぴったりはまるまで、ラジアンをちょっとずつ変えて
繰り返し試行させる？
ちょっとごちゃごちゃしすぎてる。
>>222で言ってるのはもっと単純なことのような気がする。
そもそも角度が３つも出てくるなんて言ってないし。
そうですか。勉強になりました。
継続的に落下しているときだけ機体を水平に保つとかもやらせたいけど、それはまた次の機会に。
次は玉を発射させることと、地形を変化させることに挑戦です。
というか、いったい何時までおきてるんだおれ。
引き続きよろしくお願いします。
では、質問行きます。
弾飛ばしたいんだけど、弾の軌道と位置はどういう式で表せばいい？
弾は左右に吹く風でながされます。
それと、高速で弾を飛ばすと当たり判定を突き抜けることがあるかもしれない。
そのあたり考えてください。
あと、ここで人に聞くこともできず、自分で考えてもわからないのでインターフェイスつくったりしてました。
ttp://218.219.242.231/~kuroneko/imgboard1/img-box/img20110216201831.jpg
射撃角度を変えたり、発射ボタン（スペース）を押しつづけると下のバーが伸び縮みするようにもなりました。
DirectXや関連ライブラリの知識はないのでアルゴリズムの基本を地でいく。
>弾の軌道と位置はどういう式で
x方向：横からの風は弾のx方向の速度に風速の値を加減すればOKっしょ。
y方向：弾が重力で落ちる→放物線→２次関数という連想を出来るようになるべし。
>当たり判定を突き抜けることがあるかもしれない
基本は、弾が今ある座標と次に移動する座標を結ぶ直線(線分)を考えて、
その間に障害物があるかを判定していく。(中学～高校レベルの代数幾何)
高速／低速の判断なく常時やっても問題ないだろう。(効率の良いやり方は
パフォーマンスがネックになってから考えろ)
でもこれはライブラリにありそうだな。(真偽はエライ人に聞いてくれ)
精進するでござる。ニンニン
弾の軌道は２時関数の放物線軌道といっていますが、
そこに時間の概念も加えないといけません。
弾が等速で動くわけではないということが重要です。
私が最初に考えていたのは、
ｘ＝０、ｙ＝０の座標を発射地点
発射角度を ｒ （ラジアン）
発射パワーを ｐ
重力は 1
cx1,cy1は時間(１ループ)ごとの増加座標
cx2,cy2は弾の存在位置です
cx1=p*cos( r );
cy1=-p*sin( r );
while(以下、座標計算と表示を繰り返す)
{
cy1=cy1+1; //時間当たりの増加分、重力を加算し続ける
cx2=cx1+cx2; ｃy2=cy1+cy2; //弾の存在位置、cx1,cy1の累積
x=cx2 , y=cy2 に弾を表示
}
これに、重力と同じように風の影響も加えたものは以下のような結果になりました。
ttp://218.219.242.231/~kuroneko/imgboard1/img-box/img20110218003141.jpg
もっときれいに滑らかに表示されるように調整します。
その上で問題になるのが、やはり地形との当たり判定です。
どこで当たるのか、どのタイミングで当たるのか。それが問題です。
惜しい。というか、ソース上は考え方はあってる。
普通2次関数を思い浮かべるときはxy座標系が基本だが、重力はy方向にのみ
影響するパラメータで時間tに伴う変化なので、ty座標系になる。つまり
y=at^2+bt+c (^2は階乗)
になるわけだな。これをtで微分(つまり速度)すると
cy1=2at+b (cy1は>>237 の変数ね)
となる。
右辺のcy1→b
右辺の1→2a
「tはどこ行った？」と思うかもしれないが、cy1は累積して加算しているので
while()をまわして+1していることがすなわちtを掛けていることになる。
つまり無意識のうちに２次関数を使っていることになるのだ(考え方が一足飛びだけどね)。
「言葉で言うと小難しいが、ソースに落とすと結構あっさり」というのは
わりとある。(逆も然りw)
x方向にも変な加速度をつけたり、弾の座標によって+1の値を変えたりすると、
異常重力っぽくなってゲームとしてのバリエーションが増えて面白いのだが、
それはまた先の話。
この調子でどんどん行くでござる。ニンニン
誤) 重力はy方向にのみ影響するパラメータで時間tに伴う変化なので、
正) 重力はy方向にのみ影響するパラメータでy方向は時間tに伴う変化なので、
誤) y=at^2+bt+c (^2は階乗)
正) y=at^2+bt+c (^2はべき乗)
０ほとんどの空間 １地表にものすごく近い空間 ２地面
で移動後が０の時は高頻度なので実行速度を稼ぐためスルーし
１の時は２を通過したかを調べて突き抜けを判断し
２の時は通過した地表の点を求める
言われてみれば当たり前のことだけど気づかなかった。
つーか、二次関数とか三角関数とか高校以来１０年ぶりぐらいでなつかしいｗ
これでうまくいきそうだ。
あと、重力加速度の単位って ｍ/ｓ＾2 だったんだな。
最初からこれをググってれば迷わなかったかも。
風の影響も重力とまったく同じやりかたでいいや。
ということで、こういう式で弾の表示位置を計算
pはパワー ｒは角度 ｗは風 ｇは重力 ｔは時間
a = p*cos(r) b = -p*sin(r)
while()
{t++
x = t*( a + w*t )
y = t*( b + g*t )}
ｔ++で
ｔが１増加するごとに弾の表示位置を計算させているけど、
その間に ｔ をもっと小刻みに増やして、当たり判定を計算すればなんとかなりそう
>>238-240
助かった。
ありがとう～。
>二次関数とか三角関数とか高校以来１０年ぶりぐらいでなつかしいｗ
上記に複素数と行列を加えれば、今あるほぼすべてのゲームの数学的要素はコンプリート。
全部高校までに習う内容で充分。
3Dゲーム（擬似／ポリゴン）もこれらの要素だけで出来る。四元数の話があるけど、ゲームで
あればこれは各要素の組み合わせで充分。
あとはOS（Windows/DirectX等）の使い方を知ればゲームプログラマとしては一人前。
ネットワーク使うとなると、さらにその先やね。
これらのほうが数学云々よりも何倍も面倒くさい。（あまり難しくはない）
ある程度いくと Don't think, FEEL！な世界になってくる。
それとx方向の話や当たり判定についてはあえて突っ込まない。（細かいことだし、一概に間違いとも言えないので）
いろいろ試して自分がやりたいことを表現できるようになるべし。
さて、長々と書いたが拙者の講義はここまで。以降は適当にROMって
ニヤニヤしているので、踊りまくるでござる。ニンニン
>>201でうｐされたようなやり方に変えてみたほうがいいかな。
①弾の位置を(x,y)、弾の発射速度を(vx,vy)とする。
※(x,y)は砲台の位置から、(vx,vy)は砲台の角度から計算する。
考え方は>>242のa,bの計算方法と一緒ですが、pは1フレーム期間を基準にしています
②１回の計算ごとに、
- vyに重力加速度gyを足す（gも１フレーム期間あたりの加速度です）
-足し終えた(vx,vy)を(x,y)に加算する
-(x,y)の地面を判定する/および描画更新
を繰り返しています。
風は考慮してませんでしたが、
いくら追い風でも風速より弾丸が早くなるのは不自然かと思うので、
水平方向に加速するのではなく相対速度が一致させるように漸近させる方法にします。
つまり、毎ループごとに vx= (1-k)*vx + k*windx （kは漸近化係数)で更新します。
何ででしょうね。
例の、通り魔予告兄弟の関係で広範囲にアク禁かかってたんでしょうか。
まあ、なんにしろ、ほんの１週間程度で解除されてよかったです。
それで、次にやってみようと思うのは、
弾の当たった地形が円形にえぐれるってことです。
まず、地形画像（地形.bmp）と、それと同じ形の白黒画像（地形_a.bmp）を用意します。
白黒画像をアルファチャンネルとして、地形画像の何も無いところを透明にします。
さらに、白黒画像と同じ形の二次元配列を別に用意して、それで当たり判定を行います。
この配列内に直接円形の変化をつけたいんです。
[0000000111110000000]
[0000011111111100000]
[0000111111111110000]
[0000111111111110000]
[0000011111111100000]
[0000000111110000000]
[0000000000000000000]
こんな感じ。
結論だけいいます。
白黒ＢＭＰファイルを当たり判定に利用したいので
ＢＭＰファイルなどについて質問させてください。
当たり判定用に、画像と別に２次元配列を用意するのは中止します。
1.ファイルヘッダ
2.情報ヘッダ
3.ビットフィールド
4.カラーパレット
5.イメージデータ
というものの集まりだということはわかりました。
そして、5.イメージデータっていうのが２次元配列になってるんだろうってこともわかりました。
ここまで合ってますか？
そして、イメージデータに、 『map[640][2400]』 みたいなハンドルをつけてしまえば、
ＢＭＰファイル内のイメージデータを当たり判定用の配列としてそのまま利用できるんじゃないかと。
>>201のやってることってそういうことですか？ＤＸライブラリじゃない書き方なんでいまいちわかりませんでした。
それによってカラーパレットがあったり、なかったりします。
本題のイメージデータですが、やはり種類ごとに格納形式が違います。
この部分を2次元配列に直接読み込んで使おうとするなら、
256色無圧縮のファイルであることを前提に、配列はchar型で確保しておくことになります。
メモリの使用量を考えると非効率的なので、あれこれ検討していくと、
>>201の方式を含めて、なんらかの方法で2次元配列を用意することになるんじゃないかと思います。
ちなみに現時点で戦車の傾きを求めるとき、ピクセルの有無の参照には何を使っていますか？
ピクセル有無の判定のために、
白黒画像とは別に用意した、２次元配列を使っています。
この配列は、
GetPixelSoftImage で、白黒画像のピクセルを一つずつ調べて、
黒なら 0、白なら 1、といった風に、fprintf でファイルに書き出していきます。
そうやって作っておいた0と1のテキストファイルを
ゲーム開始時にマップデータとして読み込んでいます。
ファイルに書き出したりしないで、
GetPixelSoftImage で、ピクセルが白か黒か調べて、いきなり配列 『map[640][2400]』 に、0と1を入れていってもよかったんですけど。
ここまでの実装をそのようにしてきて、うまく進んでいるのなら、とりあえずそのまま進めるといいと思います。
確認ですが、戦車を処理するときは、GetPixelSoftImage(x,y)ではなく、map[y][x]でアクセスしてるのですか？
もしそうだとするなら、着弾地点を中心にmapの配列を書き換え、かつ画面表示も同じようにすれば、
所望の動作をすると思います。
そう思ったんですが、
白黒ＢＭＰにDrawCircleの塗りつぶしで描いた円と、
配列内に0と1で描いた円が、1ドットでもずれていたら、
何も見えないところに地形が存在したり、
見えている地形を突き抜けてしまったりということがおきると思いますし、
どうやって配列内に円形の変化をつけるかっていうところも、シンプルにまとまった方法が思い浮かばないので。
戦車を処理するときはmap[y][x]を使っています。
画面表示と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]を参照する方法は使えませんか？
おお、さすがです。
２つも解決法をありがとうございます。
１つ目の方法も完璧だと思うのですが、
２つ目の方法の、αチャンネルを使った画像のグラフィックハンドルを配列として使う（？）
方法も興味深いです。
ためしに、地形画像のグラフィックハンドルを配列として扱ってみたら、
なにかエラーが出てしまいましたが、もう少しαチャンネルについて調べてみたいと思います。
ありがとうございました。
指定のファイル名の末端に『_a』が付く画像ファイルを透明情報として自動的に読み込んでくれる
ということで、アルファチャンネルについてまったく何も知らずに使っていたので、
これを機会にすこしだけ勉強します。
たぶん、ＤＸライブラリを使わずにアルファチャンネルを使うには
けっこう複雑なことをしないといけないんだろうなぁ。
引き続き、map[y][x]の代わりにgroundimage[y][x][3]を参照する方法を考えていきます。
なにか、役に立ちそうなホームページとかありましたらまた教えてください。
ではまた。
(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は使ったことがありません。
詳しい人、フォロー願います。
とりあえずは、配列で当たり判定をするのにこだわらず、製作をつづけてみます。
日曜あたりに、
弾の当たった地形がえぐれるのと、
そこの当たり判定がなくなるようになるのを作ってみます。
その次は、一気に難しくなりそうですが、
ネットで対戦することを考えてみたいと思います。
>>260の上の方法で地形の変形はうまくいきました。
DXライブラリのリファレンスを見たところ、ネット対戦を取り入れるのはやっぱり難しそうですね。
どうも、IPアドレスとか調べるのはDXライブラリだけじゃできないっぽいし。
ホストを探したり、プレーヤー同士の交流を行うロビーみたいなものを
無料サーバーを借りて作ろうと思います。
絶対やるべきっていうならそうするけど、
ネット対戦前提で２人対戦ってところから作ったほうがよくない？
ひとつのパソコンで対戦って、ターンが交互に回ってくるようにするだけでいいし。
実現するのが一般的なひと区切り。
TCP/IPの基礎知識（socket利用あたりまで）があるのならこの時点でネット対応やっちゃってもいいけどその力量がワカラン。
ロビーサーバ構築となるとさらに別世界。規模／機能にもよるけどね
戦車が2台出るだけでも色々問題が出てくるだろうし。
それと、とりあえず>>108まで完成したのなら一度見てみたい。
F5押したらデバッグはできるけど、
アプリケーションに作り上げる方法教えてください。
デフォルトならプロジェクトフォルダ内にReleaseかDebugのフォルダがあるでしょ。
ゲームが起動するものはありませんでした。
方法がわかったらうｐすることがあるかもしれません。
それで、もっと細部まで作ってからネット対戦を考えたらどうかという意見ばかりのようですが、
後の細かいところというのは、一つ一つやっていけば自分だけでもできそうなことだと思うので
ネット対戦の部分をどういう風に作るのか、考えていきたいと思います。
他のプレーヤーたちと自分のＩＰを教えあう。
ＤＸライブラリの ConnectNetWork と、ＩＰアドレスを使って相互にＰＣを接続する。
って感じでいいんじゃないかとおもう。
しかし、サーバーってのはどういう風に扱えばいいんだろ。
各プレーヤーのＰＣにＤＬするゲームソフト以外に、
仲介するためのソフトを作って、それをサーバーにおく必要があるってことかな。
これについては既存のネトゲでも各種方式がある。
1)サーバプロセスが常にデータを中継する
たいていの本格的MMOはこれ。データを随時中継する際に中身をチェックしてチートを防ぐ効果もある。
プレイ規模にもよるが、サーバのパワー（ハード、ソフト共）がある程度高くないとプレイに支障が生じる。
例：UO、EQ､WoW
2)ロビーサーバのみ独立させ、プレイ中はプレイヤー間で直接通信をする。
MO的なネトゲはこれ。ロビーサーバで各プレイヤーのIPをクライアントに通知して
プレイ中はロービーサーバを経由せずクライアント間で直接通信する。所謂P2Pに近い。
リアルタイム的な要素に左右されるゲームに有利。
商用のネトゲはチート対策や同期ためにサーバにも随時データを送ってチェックするのが一般的。
例：Diablo（クライアントがゲームサーバの役割も持つ）、各種FPS系
例は古典的な有名どころ。
他にもありそうだけど、大抵はこれら２つの方式をいろいろな組み合わせで実装している。
最近の商用ネトゲだと「MOだけど1)方式」ってのも多い。
IPアドレス情報の交換についてはロビー（ゲームルーム）に入室した時点でロビーサーバがクライアントのIPを
分かっていることになるのでユーザが直に調べる必要は必ずしもない。（そういうつくりにしないといけないけど）
むしろロビーのチャット等で直にIPを教えあうと、いたずら好きなバカがDOS攻撃対象にしたりする可能性もあるので
あまり好ましくない。
システムを一般に公開しないのであればあまり問題はないと思うけどね。
その昔、インターネットでの掲示板も一般的じゃない頃は電話やメールで互いのIPを教えあったものさ・・・。
（２）の方法って、つまり>>267と同じことだよね？
クライアント同士１：１で動かせるように作ってみます。
winsockというものを使ったこんな方法がみつかったんですけど、これでいい？
ttp://members.jcom.home.ne.jp/toya.hiroshi/get_my_ipaddress.html
足元を固めていくという意味ではとりあえずはいいんじゃね？
ipconfigキックで出力をリダイレクト→リダイレクト結果を文字列検索とかのシンプルな方法もアリだろう
複数枚NICがある場合考えるとめんどいがそこはWINSOCK使ってもも同じこと
インターネット経由にする場合はローカル／グローバルの話があるので（一般的には）上記だけでは足りないってのは分かるよな？
分からなければ ローカルアドレス グローバルアドレスでググれ
もっともロビーサーバをグローバルに立てればこれらの話は全部要らなくなるが
起動に必要なデータファイル(画像とか)が同じフォルダに入っていないんじゃないかと思う。
そのとおりみたいでした。
ためしに画像とか適当にぶっこんだら動きました。
ttp://www.dotup.org/uploda/www.dotup.org1407350.zip.html
パス
1111
ネットへの対応はまったく進んでません。勉強もしてません。
遂にここまでできたのか
暫くROMってたけど俺も完成期待してるから
頑張って下さい
一人の応援だけでだいぶやる気が出た。
おひさしぶり。
元気ですか？
私は相変わらず暇人です。
ネットワークの実装やったことないからアドバイス出来なくて残念だ
何をしていいかわからなくなったんで放置。
ＭＭＯＲＰＧの作り方を書いた本でも買ってみようかな。
まあ、うちの近所に大きな本屋がないんで中身を見て確かめられないのは痛いけど。
2) 次に２ＰをCPU制御で実現する
3) CPU制御の機体数を増やす
4) 通信プロトコルを設計する
5) 通信処理を実装する
この順でやるといいよ。
分からない事がまだまだ沢山ありますが
ご指導ご鞭撻の方宜しくお願いします
c/c++の勉強をして行きたいです。
でもまずはＣからお願いします。
基礎からみっちり叩き込んで下さい
ボクも頑張って行きたいと思います。