ゲームプログラミング相談室【Part6】

**名前は開発中のものです。** · 04/03/06 01:25

ゲームプログラミング全般の質問スレッド。
扱う話題のダイナミックレンジはやや広め。包容力高め。
他の初心者質問スレとの棲み分けを探りつつ
これからもマターリと活用しておくれ。
　
■過去スレ
【Part2】http://pc.2ch.net/tech/kako/985/985540361.html
【Part3】http://pc.2ch.net/tech/kako/1002/10028/1002894129.html
【Part4】http://game.2ch.net/gamedev/kako/1005/10050/1005040025.html
【Part5】http://pc2.2ch.net/test/read.cgi/gamedev/1036410116/
■関連スレなど
>>2-5

**名前は開発中のものです。** · 2006/01/20(金) 18:36:33

>>DirectXを使用しているのですが、メッセージの来てない時に描画処理を行うというゲームループだと動作が重くゲームになりません。
徹底的に軽量化しる。あとWM_PAINTを使うのはなんか間違ってる希ガス

**名前は開発中のものです。** · 2006/01/20(金) 21:52:48

>>642
FPSちゃんと考えてる？

**642** · 2006/01/20(金) 22:12:05

>>643

**642** · 2006/01/20(金) 22:13:41

すいません。間違って書き込んでしまいました。
返答ありがとうございます。
>>643
十分軽くしてるつもりなんですが・・・。
>>644
考えてません。タスクシステムを使えということでしょうか。

**名前は開発中のものです。** · 2006/01/21(土) 04:36:25

タスクシステムとか関係ない。

**名前は開発中のものです。** · 2006/01/21(土) 10:52:47

>>642
まずは部分毎に時間を測って
どの処理に時間が掛かっているのか特定しよう。

**名前は開発中のものです。** · 2006/01/21(土) 11:12:25

DirectXだと描画命令の時点では、時間が掛からないと思う

**642** · 2006/01/21(土) 11:39:57

while(TRUE) {
if(PeekMessage(&msg, NULL, 0, 0, PM_REMOVE)) {
if(msg.message == WM_QUIT)
break;
else {
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
else {
Paint(); // 描画処理です
}
Sleep(1);
}

**642** · 2006/01/21(土) 11:40:57

>>650
このようなゲームループにしてるんですが、ここに問題はないでしょうか。

**名前は開発中のものです。** · 2006/01/21(土) 11:57:20

まず描画処理とイベント処理のスレッドを分ける。

**名前は開発中のものです。** · 2006/01/21(土) 11:59:39

>>652
返答ありがとうございます。さっそくやってみます。

**名前は開発中のものです。** · 2006/01/21(土) 12:17:55

スレッド

**名前は開発中のものです。** · 2006/01/21(土) 12:24:15

>>642
うちはこんな感じ。スレッドなんかいらんｗ

INTRun()
{
MSG msg;

msg.message = WM_NULL;
PeekMessage(&msg, NULL, 0U, 0U, PM_NOREMOVE);

while (WM_QUIT != msg.message)
{
if (PeekMessage(&msg, NULL, 0U, 0U, PM_NOREMOVE))
{
if (GetMessage(&msg, NULL, 0U, 0U))
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
}
else
{
//ゲームの処理へ
}
}

return (INT)msg.wParam;
}

**名前は開発中のものです。** · 2006/01/21(土) 12:41:58

駄目な書き方の見本提示乙。

**名前は開発中のものです。** · 2006/01/21(土) 12:41:58

>>650
Paint(); をコメントアウトした場合と
掛かる時間を比較しよう。
劇的に速度が違うなら Paint() の中に問題があるんじゃないのかな。

**名前は開発中のものです。** · 2006/01/21(土) 12:58:21

>>656
そうなん？どこが駄目か教えて。
ちなみに少し前のＤｉｒｅｃｔＸＳＤＫサンプルのまんまです。

**642** · 2006/01/21(土) 13:08:25

スレッドを使用してみましたが、多少動作が軽くなった感じはするものの大差はありませんでした。
みなさんありがとうございます。
>>655
うらやましい
>>657
大きな違いはありませんでした。
DirectXを使わなければ問題は起こらないので、初期化の地点で問題があるのかもしれません。
もう少し見直してみます。

**642** · 2006/01/21(土) 13:54:29

解決しました。
D3DCREATE_MIXED_VERTEXPROCESSING　を　
D3DCREATE_SOFTWARE_VERTEXPROCESSING　に代えるだけでした。
まさか初期化にミスがあるとは思わなかったもので・・・。
アドバイスを下さった皆さん本当にありがとうございました。

**名前は開発中のものです。** · 2006/01/21(土) 14:07:21

ttp://lacc.biz/cpp/cpp07.html
ここのサンプルを実行してみたのですが
画面消去の命令があるにもかかわらず、
画面が更新されないで指定画像が重なって表示されてしまいます。
ClsDrawScreen() ;だけが効いていないようなのですが、何が問題なのでしょうか。
ClsDrawScreen() ;をコメントアウトしてもしなくても同じ結果になります。

**名前は開発中のものです。** · 2006/01/21(土) 15:26:20

>>654
SleepしないとCPUの処理時間を占有するからじゃないかなぁ…。
急いで書いたから汚いけど、スレッド分けるとセオリー的にはこんな感じかな？

DWORD WINAPI gMainLoop(LPVOID lpDone){//ゲームのメインループ
　　bool* pDone = dynamic_cast<bool *> (lpDone);
　　while(!(*pDone));//ここでループ
　　ExitThread(0L);
}

class CGameMain{/ゲームクラス
public:
　　CGameMain():done(false){CreateThread(NULL, 0, gMainLoop, &done, 0, NULL);}
　　~CGameMain(){done = true;WaitForSingleObject(hThread, INFINITE);}//スレッド終了
　　bool CGameMain::IsDone(void){return done;}
　　void CGameMain::Kill(void){done=true;}
private:
　　bool done;
　　HANDLE hThread;
};

// WinMain側の処理
　　MSG msg;
　　CgameMain *pGMain = new CgameMain();
　　do{
　　　　if (PeekMessage(&msg, 0, 0, 0, PM_REMOVE)){
　　　　　　TranslateMessage(&msg);DispatchMessage(&msg);
　　　　}else{
　　　　　　if (pGMain->IsDone()) DestroyWindow(g_hWindow);
　　　　}
　　} while (msg.message != WM_QUIT);
　　delete pGMain;

**662** · 2006/01/21(土) 15:26:40

>>668の間違いでした。

**663** · 2006/01/21(土) 15:27:18

さらにまちがい、662は>>658へのレスです。
酔いが回りすぎです。

**名前は開発中のものです。** · 2006/01/21(土) 16:56:03

まあ、656は単発ＩＤの煽りでしょう。
スレッドの話をすると荒れるのでやめとこうｗ

**名前は開発中のものです。** · 2006/01/21(土) 17:14:45

>>665
DirectXのサンプル自体はあくまでサンプルであって、
あくまでDirectXの機能を紹介するために作られただけであのままでは実用出来ない。
理由はサンプルのままだとFlip時にV-Sync相当のウエイトを入れているので、
フレームスキップや、動作が重くなった場合に描画以外の処理だけ先に進めることが出来なくなる。
逆にウエイトを外すと無限にぐるぐるまわすことになり、
ベンチマーク用に能力を測るのなら適切だけど、実際のプログラムとしては不適切。
またループの内側でSleepをすると、その間ウインドウメッセージが処理できなくなる。

だからDirectXの機能紹介と能力測定のサンプルとしては適切なソースでも、
実際のプログラムには不適切な書き方なんだよ。

**名前は開発中のものです。** · 2006/01/21(土) 18:00:17

>>666
メッセージ処理のことなら上の3つは同じことだと思うが違うかな。
スレッドのことなら荒れるので（ｒｙ

**名前は開発中のものです。** · 2006/01/21(土) 18:09:01

目的の違うサンプルソースをみて、それで正しいと思ってしまうことに問題があるんだろう。
さらに間違ったままそれを広めようとする奴とか。

**名前は開発中のものです。** · 2006/01/21(土) 18:11:30

何も考えず変なソース張った俺が悪いなこれはｗすまそん

**名前は開発中のものです。** · 2006/01/21(土) 19:30:15

おし。おれもなにもかんがえずに貼ってみようかな

for( ; ; ) {

MSG msgmouse;
msgmouse.message = WM_NULL;
while(PeekMessage(&msgmouse, NULL, WM_MOUSEMOVE, WM_MOUSEMOVE, PM_REMOVE)) Sleep(0);
if(msgmouse.message == WM_MOUSEMOVE) DispatchMessage(&msgmouse);
MSG msg;
while(PeekMessage( &msg, NULL, 0U, 0U, PM_REMOVE )) DispatchMessage(&msg);

if(fpstimer.PeekElapsedTime() > MIN_ELAPSED_TIME_FOR_FRAME)
{
　fpstimer.Reset();

　HRESULT hr;
　if( FAILED( hr = Render3DEnvironment() ) ) { break; }
　if(hr == S_OK) m_pd3dDevice->Present( NULL, NULL, NULL, NULL );

　if(msg.message != WM_CHAR && msg.message != WM_KEYDOWN && msgmouse.message == WM_NULL &&
　　　　　　　　　　　　fpstimer.PeekElapsedTime() + 0.002 < MIN_ELAPSED_TIME_FOR_FRAME)
　　MsgWaitForMultipleObjects(0,NULL,FALSE,2,QS_ALLEVENTS); // sleep until messages come
　else
　　Sleep(0);
}
}

**名前は開発中のものです。** · 2006/01/21(土) 21:35:41

>>668
そしてしったかしたいだけのオマエとかな

**661** · 2006/01/22(日) 06:34:40

DXライブラリさんのほうのサンプルでも同じ現象がおきたので、
そちらでお伺いさせていただくことにしました。
スレ汚しすいません。

**名前は開発中のものです。** · 2006/01/23(月) 14:58:01

>> 602-605
閉じられたハンドルにはまた新しいデータが割り当てられますよね。
これって閉じたハンドルを閉じられたとは知らずに保持していて
ハンドルを参照した時に別のデータを取得してしまう危険性は無いでしょうか？
マジックナンバーがラップして同じインデクスに同じマジックナンバーが
割り当てわれる可能性は十分にあると思うのですがどうなんでしょう？

1. AがHというハンドルを持っていたとします。
2. AはBにHを分け与えました。
3. BはHを破棄したくなりその場で破棄(mgr.Release(H))しました。
4. AはHを参照するも無効なハンドルだと知ることが出来ました。
ここまではいいんですよ。生ポインタじゃこのシナリオは書けません。

上の3.と4.の間で大量のハンドルの生成が行われた場合、
4.でAが(閉じているはずの)Hを参照した時にHと同じインデクス/マジックナンバーの
ハンドルの再割り当てが行われるとAは別のデータを参照してしまいます。

**名前は開発中のものです。** · 2006/01/23(月) 15:33:46

>>673
マジックナンバーの値は増加する一方だから
基本的に同じマジックナンバーは割り当てられない。
ただしマジックナンバーを保持する変数には当然上限があるから
ハンドルの生成数にも限りがある。

と俺は思う。

**673** · 2006/01/23(月) 15:55:07

>>674
ハンドル生成数はインデクスの方ですよね？
マジックナンバーは正当性を保証するだけのもので。
ハンドル数に関係なくハンドルの生成/破棄を繰り返せばそれだけでマジックナンバーは増加します。
マジックナンバーはインデクスとは比べ物にならない位インクリメントされるので
意外とすぐ上限に達してしまうような。

**名前は開発中のものです。** · 2006/01/23(月) 16:00:23

>>675
違うんじゃない？
インデックスの方はマジックナンバーがあるお陰でループしても平気だけど
マジックナンバーの方はそうは行かない。

**673** · 2006/01/23(月) 16:24:21

>>676
それだとハンドル数が例え１個でも生成/破棄の回数が決まってしまいますよね？
インデクスは破棄されたハンドルのものを再利用するのでインデクスに16bit割り振れば
65536個持てるわけですよね。

なんだか本題より前の段階で意見の相違があるみたいですね。
実装はgemsの1.6項のものです。

**名前は開発中のものです。** · 2006/01/23(月) 16:27:52

いやいや、参照カウンタではないから
ハンドルをコピーするだけではマジックナンバーは増えないのでは？

**673** · 2006/01/23(月) 16:32:22

>>678
ええ、確かにハンドルのコピーだけではマジックナンバーは増えません。
ですがマネージャにハンドルを要求すればその分マジックナンバーは増えますよね？
ゲームを動かしていて２時間くらいしたら
「マジックナンバーが一杯なので終了します」じゃ話にならないですよね・・・？

gemsのP73 でもマジックナンバーのラップ処理は記述されてるので、
マジックナンバーはラップ前提なはずですよ。

**名前は開発中のものです。** · 2006/01/23(月) 16:53:58

>マジックナンバーはラップ前提なはずですよ。
そうでしたか。今手元にGems無いんで家に帰ったら確認してみます。

>マネージャにハンドルを要求すればその分マジックナンバーは増えますよね？
>ゲームを動かしていて２時間くらいしたら
>「マジックナンバーが一杯なので終了します」じゃ話にならないですよね・・・？
だから種類ごとにハンドルマネージャ作れるようにテンプレートにしてあるのでは。
無限にというのはいくらなんでも無理だからその中で想定最大数を見積もって
バランスよく分けて管理すると。

**673** · 2006/01/23(月) 17:19:16

>>680
>だから種類ごとにハンドルマネージャ作れるようにテンプレートにしてあるのでは。
と言う事はマジックナンバーがラップして同じインデクスに
同じマジックナンバーが割り当てられてしまうのは仕様って事ですかね。

>無限にというのはいくらなんでも無理だからその中で想定最大数を見積もって
ですね。
ですがgemsでは「インデクスの範囲内でユニークを保証する」といった意味で書かれていると解釈したため
ゲームオブジェクトのようなものにハンドルを割り当てようと思ったわけです。
ですがテクスチャやサウンドなどのリソースに割り当てるなら問題ないってレベルなんでしょうね。

**名前は開発中のものです。** · 2006/01/23(月) 17:30:41

16bit-16bit みたいにインデックスとマジックナンバーで半々にしなけりゃ
同インデックス、同マジックナンバーってのはそうそうでないのではないかな
Gemsでも8-24とかになってたような　気のせいだったかな？
記憶があやふやでスマソ。

**673** · 2006/01/23(月) 17:56:28

>>682
>16bit-16bit みたいにインデックスとマジックナンバーで半々にしなけりゃ
>同インデックス、同マジックナンバーってのはそうそうでないのではないかな
でも確立的に低いからといってゲームオブジェクトなどの場合
オブジェクトの摩り替わりは絶対にあってはならない事ですよね。
しかも一番見つけにくい部類のハグになりそうですし。

>Gemsでも8-24とかになってたような　気のせいだったかな？
たしか半々だったような。テクスチャリソースの管理ならどんな割合でも問題なさそうですけど。

マジックナンバーを本物のGUIDにしたらどんくらい遅くなるんだろうか。
他に早くて確実なユニークIDって何かないかなぁ。

**名前は開発中のものです。** · 2006/01/24(火) 01:14:06

アドレスだと確実にユニークです。

**名前は開発中のものです。** · 2006/01/24(火) 01:23:48

>>684
どういうこと？

void* p = malloc(1);
free(p);
void* q = malloc(1);
assert(p != q);

こうは言えないだろ。

**名前は開発中のものです。** · 2006/01/24(火) 02:27:10

アドレス空間より広いサイズのIDは保持不可能という前提で言ってたんだが。
開放済みのアドレス参照するようなアホはハングアップでもなんでもすればいいんじゃね？

**673** · 2006/01/24(火) 04:33:44

>>686
685氏はアドレスじゃdangling pointerは防げないよって意味でmallocの例を出したんじゃないんですか？
pを他のやつにばらまいて誰かがpを開放したらpの有効性を誰が保証してくれるんでしょう。

上記のハンドルだと再割り当ての可能性があるし、
スマートポインタじゃオーバースペックだから他にユニーク性を保証するものってないだろうかっていう話ですよ。
でももう面倒だから参照カウンタで管理します。

**名前は開発中のものです。** · 2006/01/24(火) 05:27:10

32bitもあれば、１秒間に1000個生成しても、
一ヶ月プレイし続けたところでラップさせられない。

16bitやそこらでも、
16bit値をラップさせるほどオブジェクトが生成されるほどの時間、
ハンドルを寝かせるようなアルゴリズムにしなければいい。

**673** · 2006/01/24(火) 05:46:51

>>688
>32bitもあれば、１秒間に1000個生成しても、
>一ヶ月プレイし続けたところでラップさせられない。
１秒間に１０００個って60FPSのゲームで1フレ約16個ですよね。
局所的に見ればそれ以上生成される可能性は十分にありますよ。
でもまあIPv6でIPが2^128個以上存在する可能性は
将来的に十分ありえるから心配って言ってるようなもんですかね。

>bit値をラップさせるほどオブジェクトが生成されるほどの時間、
>ハンドルを寝かせるようなアルゴリズムにしなければいい。
確かにこれを厳守すれば確立的に問題ないでしょうが、
人間はミスする生き物です。
他人がどうコーディングするかは他人まかせなので・・・。

実際みなさんはゲームオブジェクト(のポインタ)をどのようにして管理してます？

**名前は開発中のものです。** · 2006/01/24(火) 06:30:02

理想に燃えて政治運動に傾倒しちゃうタイプだね。

**名前は開発中のものです。** · 2006/01/24(火) 15:11:47

ミスしないように気をつけてます。
なぜかミスしてなくても止まったり動かなかったりしますorz

いろいろなところで、オブジェクト指向のためのプログラミング理論が
展開されてるなあｗ

**名前は開発中のものです。** · 2006/01/24(火) 17:03:38

>>689
32bit型整数でマジックナンバーを表し、
ゲームが60fpsで1fpsごとに100オブジェクト生成することを考えます。
マジックナンバーがオーバーフローするまでには
2^32 / (100個 * 60fps * 60sec * 60min * 24hour) = 8.28日
かかりますので、仕様として「ゲームは連続一週間以上動かさないで下さい。」とするか、
これで満足できない場合は32bit型整数を2つ使いましょう。
ちなみに、この場合(ry

**名前は開発中のものです。** · 2006/01/25(水) 01:23:31

32bitがフローするようなメモリを扱えるのか？アアン？

**名前は開発中のものです。** · 2006/01/25(水) 01:49:38

滅茶苦茶低レベルな話で申し訳ないんだけど、ＡＩを組むには関数できないと無理？
ひたすら条件分岐しまくりだったらやっぱりみっともないの？

**名前は開発中のものです。** · 2006/01/25(水) 01:55:15

アイボの制御コードを、NHKの番組でチラッっと見たことがあるが、
swith-case文が何十何百と、滝のように流れていたな。

アドバイス欲しいなら言語かいた方が良いかもよ。どのみち関数は出来ないとだけど。

**名前は開発中のものです。** · 2006/01/25(水) 10:01:28

状態遷移は、switch-caseで切り替えてもいいし
関数ポインタで切り替えする手もあるな。

どの状態のときに何をするのか、ちゃんと管理出来るのであれば条件分岐しまくりでも構わないよ。
みっともなかろうが作りやすい手段を取ればいい。

**名前は開発中のものです。** · 2006/01/25(水) 10:03:07

>>696 自分ひとりしか読まなくていいなら、という条件付きで頼む。

**名前は開発中のものです。** · 2006/01/25(水) 13:58:23

使ってるのはＨＳＰ。
本屋でゲームＡＩの本を立ち読みしたら、ファジー理論とかって奴が書いてあったからさ。
理屈は分かったんだけど、関数が自分の理解の範疇を超えてたから、
ちょっと不安になった。

やっぱり、条件分岐連発より関数使った方が処理は早いのかな？
だったら関数で出来るかぎりやってみたいんだけど。
それとも、初めて組むプログラムでそこまでやるのは無謀？

**名前は開発中のものです。** · 2006/01/25(水) 14:30:31

>>698
条件分岐と関数では、処理速度に大きな違いはない
ただソースコードの読みやすさとか修正のしやすさに大きな違いが出る

基本は関数単位で作るものだと思った方がいい
もちろん>>696案のほうが有効な状況もあるけど

**名前は開発中のものです。** · 2006/01/25(水) 14:30:38

自分は条件分岐を連発した関数を使ってます＞＜

**名前は開発中のものです。** · 2006/01/25(水) 22:02:47

俺らはゲームプログラマだ。
一般アプリのプログラマでもOS屋でもない。
作った者が勝ちだ。
動かした者が勝ちだ。
条件分岐のカルボナーラでいいじゃないか。

ずっと書き続けていれば、いつか自然に条件分岐を捨てる日が来るのさ。

**名前は開発中のものです。** · 2006/01/25(水) 22:09:14

うむ。
後で書き直したってせいぜい３日だよ。
それなのに始める前に何日悩むのかｗ

**名前は開発中のものです。** · 2006/01/25(水) 22:42:06

>>700-702を見てやる気が出たよ

**名前は開発中のものです。** · 2006/01/26(木) 01:35:32

>>701
糞コードの量産を正当化するような発言は控えてください。

**名前は開発中のものです。** · 2006/01/26(木) 02:38:40

>>704
どうせ晒さないからおｋ

**名前は開発中のものです。** · 2006/01/26(木) 02:59:37

　 ,j;;;;;j,. ---一､｀　―--‐､_ l;;;;;; 　　
　｛;;;;;;ゝ T辷iﾌ i 　　f'辷jァ　 !i;;;;; 　　
　ヾ;;;ﾊ　　　　ﾉ　　　　　　　.::!lﾘ;;rﾞ
　　 `Z;i　　　〈.,_..,.　　　　　　ﾉ;;;;;;;;>
　　,;ぇﾊ、　､_,.ｰ-､_',. 　　,ｆﾞ: Y;;f 　　そんなふうに考えていた時期が
　　 ~''戈ヽ　｀二´ 　　 r'´:::.　`!　　　俺にもありました

**673** · 2006/01/26(木) 15:37:38

>>692
>32bit型整数でマジックナンバーを表し、
確かにマジックナンバーに多量のbitを割り当てれば問題ないのはわかってるんですが、
ハンドルを32bit(約レジスタサイズ)に収めたいジレンマがあったのでそもそもこんな質問をしたわけです。
しかもその32bitをインデクスと共有するため実用上は最大で20bitほどしか割り当てられません。
単一のインデクスが毎回使いまわされるという最悪なアルゴリズムでは
20bitを消費した直後にハンドルに同じマジックナンバーが割り当てられてしまいます。
均等に12bitのインデクスが使われる確立も低いため、間をとってインデクスの約6bitが平均して使われると仮定すると
26bitですので約3時間で再割り当てが行われる可能性があります。

まぁ32bitにこだわらなくても最近のPCなら（ry

**673** · 2006/01/26(木) 15:47:34

間をとって6bitってアホですな。
8bitで12時間ですか。ゲーマーはご遠慮くださいってとこで・・・。

**名前は開発中のものです。** · 2006/01/26(木) 17:54:38

本当に簡単なマリオ風横スクロールRPGみたいなのを作りたいんだけど、ブロック(壁とかのオブジェクト)の表現ってどうするの？
画面表示用の配列を作って、1ブロック分移動するたびにマップデータ配列から新しいブロック列を読み込む
ってのを使ってるんだけどどうも重くて

**名前は開発中のものです。** · 2006/01/26(木) 18:06:36

その程度の処理で何で重くなるのかがさっぱり分からん。

**名前は開発中のものです。** · 2006/01/26(木) 19:19:29

Pen4 RadeonVEだからかもしれない

**名前は開発中のものです。** · 2006/01/26(木) 19:21:36

Pen4 1.7GHzだった
そろそろパソコン購入を考えた方がよさそう

**名前は開発中のものです。** · 2006/01/26(木) 20:53:11

まあさんざん引っ張って悪いんだが、設計ミスです。

**名前は開発中のものです。** · 2006/01/26(木) 21:07:57

正直自分でもなんとなくおかしいと思ってた
マップとか当たり判定の仕方を解説してるサイトとか無いかな

**名前は開発中のものです。** · 2006/01/26(木) 22:57:30

ミスはシリアルナンバーの方ね。（笑）

マップのサイズってどんなもんよ。　メインメモリをはるかにオーバーしてるんじゃなければ
そうそう重たくならないと思うんだが。

スーパーマリオなんて8bitマシンの４Mhzで普通に動いてたろ。

**名前は開発中のものです。** · 2006/01/27(金) 14:01:24

RPGゲームの作り方教えちくり
ダブルバッファリング使ってマップ描画したいんだけど
そうすると当たり判定とか訳分からない

**名前は開発中のものです。** · 2006/01/27(金) 14:23:04

＞RPGゲーム
ねらって書いただろ？

ダブルバッファリング使ってマップ描画の方法をしりたい。
マップ描画したあとの当たり判定をしりたい。どっち？

どっちにしろ俺はプログラム素人だから知らないがな。

**名前は開発中のものです。** · 2006/01/27(金) 14:25:00

>>717
>どっちにしろ俺はプログラム素人だから知らないがな。

おまい潔いな(　´ｰ｀)y─┛~~

**名前は開発中のものです。** · 2006/01/27(金) 14:50:59

>>717
>ねらって書いただろ？
恥ずかしくて「はいそうです」としか言いようが無い

どちらも
簡単な横スクロールは作ってみたけどどうもおかしい
普通なプログラマのやり方が知りたい

**名前は開発中のものです。** · 2006/01/27(金) 14:54:34

>>719
>> ねらって書いただろ？
> 恥ずかしくて「はいそうです」としか言いようが無い

おまいも潔いな(　´ｰ｀)y─┛~~

**名前は開発中のものです。** · 2006/01/27(金) 15:10:22

キーワードは「自作自演」

**名前は開発中のものです。** · 2006/01/27(金) 16:01:58

マジレスすると、マップの当たり判定はチップナンバーでするか、
細かく判定したいのなら当たり判定用のマップを別に作る。

**名前は開発中のものです。** · 2006/01/27(金) 16:07:12

>>722
チップナンバーとは何でしょう？

**名前は開発中のものです。** · 2006/01/27(金) 16:21:18

なんか釣り臭い気がするなｗ

RPG作るなら、マップエディタがいるだろ？
マップチップはわかるな？

マップチップ0＝海
マップチップ1＝草原
0とか1がチップナンバー。

それを頼りに判定する方法。
海に囲まれた島があったら

0000000000
0011111100
0111111110
0111111110
0011111100
0000000000

こういうマップになるだろ？
で1なら通れるわけだ。

当たり判定にバッファリングは関係ない。

**名前は開発中のものです。** · 2006/01/27(金) 16:23:55

マップ描画用データはマップ描画用データで処理すればいい。
当たり判定は当たり判定用データで処理すればいい。
難しいことは、単純なことに分解、小分けにしていくことで大抵クリアできるんぽ。

**名前は開発中のものです。** · 2006/01/27(金) 17:05:37

>>724-725
ごめん、本当に初心者です
バッファリング用のint二次元配列と当たり判定用のint二次元配列を一緒にしようと思ってたので頭がこんがらがってしまって
別々に作ってみます
ありがとうございました

**名前は開発中のものです。** · 2006/01/27(金) 17:10:51

レイヤ使わないなら、判定用に分けなくてもいい気がする。

**名前は開発中のものです。** · 2006/01/27(金) 18:16:19

BMP読み込み
マップデータ(ブロック種類記述)読み込み
マップデータからマップデータ配列
struct MapData{
　　POINT pt;
　　int type)

**名前は開発中のものです。** · 2006/01/27(金) 18:16:51

うっわ恥ずかしミス

**名前は開発中のものです。** · 2006/01/27(金) 20:46:59

可愛いよ>>729
その恥じらう姿がたまらなく可愛いよ>>729

**名前は開発中のものです。** · 2006/01/27(金) 21:24:04

>>728
書きかけだし、ミスならアレだけど、
なんで POINT が必要なのかな・・・かな？

**名前は開発中のものです。** · 2006/01/27(金) 21:48:01

0とか1とかが並んだマップデータファイルからデータを読み込んでtypeに格納、その際POINT型のptに座標(開始0,0)も格納
座標は1チップ読み込む度に座標+=1チップのサイズ
これを100チップx100チップの仮想BMP(マップファイル)に書き出す
キャラクターの座標はクライアント領域内の座標じゃなくマップ内の座標にする
・・ってのをやってみたいと思ってる
マップ作っちゃうと重くなるかな？

**名前は開発中のものです。** · 2006/01/27(金) 22:41:59

おｋ、把握した。チップ画像の座標てことね。

そんなんでいいと思うよ。

**名前は開発中のものです。** · 2006/01/27(金) 22:43:08

良かった
がんばってみる

**名前は開発中のものです。** · 2006/01/27(金) 22:44:24

参考までに
http://gamdev.org/w/?%5B%5B%A5%DE%A5%C3%A5%D7%A5%A8%A5%C7%A5%A3%A5%BF%5D%5D

**名前は開発中のものです。** · 2006/01/27(金) 22:48:15

ありがとう
今エディタ探してたところ

**名前は開発中のものです。** · 2006/01/28(土) 05:38:41

>732
今のPCパワーなら何ら問題無い
メモリの有効利用がキーになるけど
それよりもマップの画像データを
作るほうが大変

**名前は開発中のものです。** · 2006/01/28(土) 10:21:30

ttp://ian-albert.com/misc/gamemaps.php

有名どころのマップ集。デザインの参考にはなるんでない？

**736** · 2006/01/28(土) 20:54:31

ttp://dream.my-sv.net/upload/src/up0124.zip
ここまでやってみた。画像はマップ作成ツールのサンプル
ただスクロールがなんかおかしい
当たり判定はuser構造体内のPOINT型mptとmapdata構造体配列でやりたいと思ってるけど実装の仕方がわからなくてグダグダ
マップとか画像はセンスが無いからどうにも･･･

**名前は開発中のものです。** · 2006/01/29(日) 01:48:00

ざっとソース見させてもらったけど、気になる点がいくつか。
仮想BMP、まさか本当にマップファイルの大きさのBMPを用意するのはさすがにまずいと思う。
それからマップチップの画像は一枚にまとめておいたほうが扱いやすいと思う。

struct MapChipData {
POINT src; // マップチップ「「画像」」の開始座標を格納
int type;
}

int MapData[MAP_HEIGHT][MAP_WIDTH]; // ここにマップデータをそのまま読んで番号を格納していく

こういうの用意して、例えば0,0からマップを画面に書きたかったら

for (int y = 0; y < 20; y++) { for (int x = 0; x < 15; x++) {
POINT src = MapChipData[ MapData[y][x] ].src; // これでチップの座標取って
// ここらでsrcを使って裏画面にマップを描画。ソースは省略
}}

あと、初心者で普通のRPGのように滑らかな移動を初めから実装するのは無謀だと思う。
まずは、チップサイズ（この場合32ドット）毎にキャラが移動するように作って
それで、仕組みを理解してから滑らかにスクロールするところを作りこんだほうがいいと思う。

当たり判定については、キャラを実座標で扱っているからごちゃごちゃしてるんだと思う。
例えば右に移動するのを+10ドットとするのではなく、右に+1とする。
そのとき、一緒に当たり判定するとか。

// 右に移動したとき呼ばれたとして、typeで判定かな
if ( MapChipData[ MapData[自キャラのY座標][自キャラのX座標 + 1] ].type == 1 )
{ 自キャラのX座標 ++ }

当たり判定用のマップ作りたい場合はマップデータをintじゃなくて構造体にして詰め込めばいい。と思う(´･ω･`)

**名前は開発中のものです。** · 2006/01/29(日) 15:34:49

Direct Graphics の描画時の同期(Present()の終了待ち)をタイマーの代わりにしていたけど、
それだと、ウインドウモードでFPSが変わると速度の変化があるよね。

60Hzと75Hzで同じような処理を行うには、75のときに5回に一回飛ばせばいいだけなの？
それだとカクカクしない？

**名前は開発中のものです。** · 2006/01/29(日) 16:01:50

カクカクする。
でもそれは仕方の無いことだとあきらめてる。
解決策教えてエロい人。

速度を一定に保ちたいなら、１秒間でどのくらい動くかということを考えて
フレームごとの移動量を足していくようにすればいい。