ゲームプログラミング相談室【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/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

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

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

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

>>740
はじめに数枚のマップチップを張り合わせたbmp画像を読み込んでおき、
struct MapChipData {
　POINT src; // マップチップ「「画像」」の開始座標を格納
　int type;
}mapchipdata[読み込むチップ数]
にマップチッブを張り合わせたbmp内の目的チップの座標とタイプを格納して
マップの再描画が必要になったとき(スクロール時等)にマップチップをメモリデバイスに貼り付け
ということでしょうか？

あと当たり判定の
if ( MapChipData[ MapData[自キャラのY座標][自キャラのX座標 + 1] ].type == 1 )
はMapData[自キャラのY座標/チップサイズ][自キャラのX座標/チップサイズ + 1]ですか？

そろそろGDI卒業してDirectGraphic使いと思って本屋で探したけど2Dからの入門書探しても3Dしかない・・

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

自キャラの位置をマップ座標で持ってるなら、32で割る必要なしだと思うが。
そのところは好きに実装すればいいんじゃね？

単にキャラの座標を32倍して保持するか、しないかの差だろ。
歩くたびに割り算するのはあんまり好きじゃないけど、今時のPCならどうでもいいことだろうし。

要は短形で判定する必要はないってことじゃないかね。
1ピクセルが一歩なら別の方法取らなければならんが。

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

MapData[40][40];に自キャラ座標のmapdata[120][130+1]を要求するとおかしくなると思ったので
キャラの1歩を32ドットとして当たり判定は移動先の座標にブロックがあるかないかで判断すると
キャラ移動時のアニメーションが必要になりますね
その辺りも勉強しておかないと

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

判定方法と、移動時のアニメーションの必要性の有無に因果関係はない。

**724** · 2006/01/29(日) 17:36:03

俺は740のソースしか見ていないから違ってるかもしれんが
「自キャラの座標」は適当に直して使えということではないかな？
俺だったら32倍して持たないけど。

745の二行目以降はよく意味が解らん。アニメーション関係あるか？？

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

>>746-747
ポケモンとかのゲームは1歩が1マスで移動時にアニメーション
同じように1歩を1マスにするとアニメーション使わないと見栄えが悪くなるかなと思って
まだまだそんなこと言ってられるレベルじゃないけど
>「自キャラの座標」は適当に直して使えということではないかな？
なるほど。自キャラの座標は実座標で扱ってたのでマスとして扱ってみます

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

勘違いしてほしくないので補足。

/ 32 自体が間違ってるから不要と言ってるのではなくて
まぁ初心者だから、好きなようにやってみるといいんじゃね？
あとから仕組みがわかるだろうさ、という意味。

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

なんかRPG作りたくなってｷﾀｰよ

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

>>750
http://hobby-const.bbs.thebbs.jp/1126798622/
こんな感じのか？

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

便乗質問ですが、ウィザードリィやＭ＆Ｍ、女神転生などの
３Ｄダンジョンはどのように作れば良いでしょう。

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

>>752
「どのように」って質問されてもな。何答えろって言うんだろうな。
大工さんに頼めという答えを期待しているのだろうか？

1,データをどのように持つのか？
　　　→　自分が作りたいものを内部的にどう表現するのか？
2,準備したデータをどのように表示するのか？
　　　→　自分の場所と方向を変化させても通用するように一般化させてコードに落とす

の2段階を考えれば、全体の流れは明確だと思うのだが。

まず着手してもらえるかい。
その中で個別に問題が出てきたら、ここで質問するといいよ。

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

>>752
状態に応じた画像を用意しておきそれを組み合わせて表示する。

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

ttp://dream.my-sv.net/upload/src/up0126.zip
マップ間のリンクなんとかならないだろうか
いちいち位置を指定するのは面倒

>>749
いろいろやってみてるけどやっぱり難しいね
前作った物はキャラ移動の度に全てのチップに大して当たり判定してたから酷かった

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

>>755
ソースをアップするのは自由だが文面から察するに
「誰かソース見て添削してくれ」と言わんばかりだな。
そのスタンスは歓迎されないし自分の為にならない。
僕らは君の先生じゃない。だが焦点を絞って質問すればその限りではない。

>マップ間のリンクなんとかならないだろうか
>いちいち位置を指定するのは面倒
マップを増やすたびにコンパイルが必要と言うのはあまりよくない。
どのマップからどのマップへ移動というデータは外部で持つべき。
そのトリガはマップチップの番号なのは言うまでもない。
とにかくアルゴリズム以外は外部ファイルに追いやる事が慣用。

**名前は開発中のものです。** · 2006/01/31(火) 21:00:44

なんだかんだ言ってソースを見てる>>756に萌え。

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

…ななな何言ってんのよ！！ふっ、ふざけないでよ！
私だって、す、好きでやってるわけじゃないからね！
べ、別にあんたなんか困っててもかまわないんだから！

バカーーーーーーーーー！！！

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

つんでれワロス

**名前は開発中のものです。** · 2006/02/02(木) 16:47:09

マリオ風アクションゲーム作りたくて設計を考えてるんだけど、マップ内の移動と描画はいいとして
敵とかのプレイヤーが動かすことのできないオブジェクトはどうやって表現するの？
出現条件とかもわからないし

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

>>760
>敵とかのプレイヤーが動かすことのできないオブジェクトはどうやって表現するの？
まぁ基本はこんな感じか。
for (i = 0; i < キャラクタの数; i++)
{
obj[i]->Move();// 移動処理&マリオとの当たり判定など
}

>出現条件とかもわからないし
出現条件はマリオの居る現在位置から割り出し、
画面に出現する直前にキャラクタの登録をしてるんじゃないかな？
それかマップのロード時に一括して登録して移動処理はしないで画面で出そうになったら
移動処理を開始するとか。いろいろ方法はあるな。

**名前は開発中のものです。** · 2006/02/02(木) 17:47:28

>>761
なるほど。
やっぱり専用のスレッドを作った方がいいでしょうか？

**名前は開発中のものです。** · 2006/02/02(木) 18:00:45

スレッドを作るほどのことではない。

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

というよりスレッドなんか作ったらいかん。

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

>>763-765
勘違いしてるかもしれないので一応
_beginthread()で生成して_endthread()で破棄するスレッドのことです
現在メッセージループメイン関数(描画処理をプロージャのWM_PAINT内で行う)のほかに
キャラクター表示座標、マップ内表示座標調整スレッドがあります

**名前は開発中のものです。** · 2006/02/02(木) 20:00:39

ありますと言うか予定してます