掲示板ランキング  ゲーム(君が望む永遠)  ゲーム(グランツーリスモ)  ゲーム(サクラ大戦)


掲示板利用宣言

 次のフォームをすべてチェックしてからご利用ください。

 私は

 題名と投稿者名は具体的に書きます。
 課題の丸投げはしません。
 ソースの添付は「HTML変換ツール」で字下げします。
 返信の引用は最小限にします。
 環境(OSとコンパイラ)や症状は具体的に詳しく書きます。
 返信の付いた投稿は削除しません。
 マルチポスト(多重投稿)はしません。

掲示板1

管理者用メニュー    ツリーに戻る    携帯用URL    ホームページ    記事検索    ログ    タグ一覧

No.6390

Windowsでのメインループについて
投稿者---K(2006/09/04 12:13:08)


windowsでのメインループについての質問なのですが、
よく下のようなメインループを見ます。

while (TRUE)
{
//キューにメッセージがあればいつもの処理
if (PeekMessage (&msg, NULL, 0, 0, PM_REMOVE))
{
//メッセージがWM_QUITならループを抜ける
if (msg.message == WM_QUIT)
break ;

TranslateMessage (&msg) ;
DispatchMessage (&msg) ;
}
//キューにメッセージがなければ随時処理
else
{
// --- 独自の処理
sleep(1);
}
}

ですがこの場合1秒が60フレームと仮定したときに、
例としてメッセージが送られた1フレームは独自の処理部分を実行しないように感じます。(すいませんこの頃始めたばかりなので見落としがあるかもしれませんが)

しかしながら上記のようなソースが一般的なようで色々なサイトで似たようなものが掲載されていました。

こちらで考えるには、

while (TRUE)
{
//キューにメッセージがあればいつもの処理
if (PeekMessage (&msg, NULL, 0, 0, PM_REMOVE))
{
//メッセージがWM_QUITならループを抜ける
if (msg.message == WM_QUIT)
break ;

TranslateMessage (&msg) ;
DispatchMessage (&msg) ;
}

// --- 独自の処理
sleep(1);
}

のようにelseはいらないんじゃないだろうか?
っと思っています。

どなたかご教授願えないでしょうか?

それではよろしくお願いいたします。


この投稿にコメントする

削除パスワード

発言に関する情報 題名 投稿番号 投稿者名 投稿日時
<子記事> Re:Windowsでのメインループについて 6392 acid 2006/09/04 13:08:36
<子記事> Re:Windowsでのメインループについて 6395 Blue 2006/09/04 15:01:55


No.6392

Re:Windowsでのメインループについて
投稿者---acid(2006/09/04 13:08:36)


あんまり理解していないので、的外れかもしれないが、処理それぞれじゃないのかな。
1フレームで実行するのは、いつもの処理と独自処理のどちらかでいい場合は前者。
独自処理を必ず実行したい場合は後者、みたいな。


この投稿にコメントする

削除パスワード

No.6396

Re:Windowsでのメインループについて
投稿者---K(2006/09/04 15:03:58)


返信ありがとうございます。

>1フレームで実行するのは、いつもの処理と独自処理のどちらかでいい場合は前者。
>独自処理を必ず実行したい場合は後者、みたいな。

非常に納得できるお答えだと思います。

しかしながらゲームプログラミングのサイトですら先ほどのようなループ処理が掲載されていました。(といいますかあれ以外発見できませんでした。)

もし100フレーム連続でメッセージが入ってきたとき、
独自の処理を100フレームも実行しないようなことは考えられませんし、
でもどのサイトもあんな感じに掲載してるし、
正直混乱しています。

つまりゲームでもあのようなメインループを掲載しているのには何か理由があると思いますので、それに納得したく質問いたしました。

すいませんがまだ納得することはできていません。

引き続きご教授願える方よろしくお願いいたします。



この投稿にコメントする

削除パスワード

No.6395

Re:Windowsでのメインループについて
投稿者---Blue(2006/09/04 15:01:55)


>【掲示板利用宣言】
>マルチポスト(多重投稿)はしません。
http://www2.moug.net/bbs/program/20060904000004.htm

感心できませんな。

ついでに
>ソースの添付は「HTML変換ツール」で字下げします。
>環境(OSとコンパイラ)や症状は具体的に詳しく書きます。


この投稿にコメントする

削除パスワード

No.6397

Re:Windowsでのメインループについて
投稿者---K(2006/09/04 15:14:21)


>>マルチポスト(多重投稿)はしません。
>>感心しませんな。

すいませんそういう意味合いだったのですか。
わからなかったとはいえ非常に皆様方の気分を害してしまったと思います。
本当に申し訳ありません。





この投稿にコメントする

削除パスワード

No.6398

Re:Windowsでのメインループについて
投稿者---wis(2006/09/04 15:31:01)


向こうに掲載されたコードとこちらのコードの内容が違うようですが・・・
正しいのはどっちですか??

あとSleep関数はサンプルで本当に使用されていましたか?
WindowsのSleep関数の引数の指定単位は『秒』ではなく『ミリ秒』です。
提示されたコードが本当ならばSleepは殆ど意味がありませんが。。。



この投稿にコメントする

削除パスワード

No.6399

Re:Windowsでのメインループについて
投稿者---K(2006/09/04 15:51:48)


>向こうに掲載されたコードとこちらのコードの内容が違うようですが・・・
>正しいのはどっちですか??

すいません現在確認しました。
こちらのコードのsleepは外に出てるべきですね。
どちらかというと、向こうの方が正確かもしれません。
なんせ俺が手でその場で打ち込んだものでして・・・

>あとSleep関数はサンプルで本当に使用されていましたか?
>WindowsのSleep関数の引数の指定単位は『秒』ではなく『ミリ秒』です。
>提示されたコードが本当ならばSleepは殆ど意味がありませんが。。。

はい使われていたと思います。
なんせ色々なサイトをググッたものですべてお気に入りには入れてませんが結構使われていたように思います。
コメントにはOSに制御を明け渡す等のコメントが書いてありました。





この投稿にコメントする

削除パスワード

No.6400

Re:Windowsでのメインループについて
投稿者---気分屋(2006/09/04 16:40:55)


おそらく独自処理を記述するところに
while文で60FPSを待つための処理が記述されているのでしょう。

また、OSに処理を一度返すためにSleep(1)を使用する人が多くいますが
ここでは、Sleep(0)を使用するのが好ましいと思われます。
実際に、Sleep(1)を使用して、きちんと60FPSが出ないケースなどもありました。

timeBeginPeriod(1)をアプリ起動時に一度だけ呼び出すことによって
タイマーの分解能をあげることができます。
通常分解能ですと、Sleep(1)を呼んだ場合、実際には1ミリ秒ではなく
16ミリ秒位の時間をとめてしまいます。
とめてしまう時間の長さはNT系と98系によって違うのですが、詳しくはネットで調べてください。
ただ、私はSleep(0)に関して検証を行っていませんので、実はtimeBeginPeriod(1)を呼ばなくても
処理に問題はないのかもしれません。



この投稿にコメントする

削除パスワード

No.6403

Re:Windowsでのメインループについて
投稿者---K(2006/09/04 17:26:50)


返信ありがとうございます。

なるほどSleepについては理解いたしました。

しかしながら独自の処理とメッセージの処理を分けるところがまだよくわかりません。
マルチポストしてしまった先には記述したのですが、
様々なサイト(ゲームプログラミングのページ)で目にするこのようなメインループのとき、

if(PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ))
{
// --- メッセージ処理
}
else
{
// --- 独自の処理
}

100フレーム連続でキーメッセージが送られてきたときは、
100フレームの間、独自の処理を行わないことになると考えています。

つまりなぜこのようなソースが一般的になっているのかが知りたいと思っています。

もっと詳細にこちらの気持ちを書いてしまうと、

if(PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ))
{
// --- メッセージ処理
}

// --- 独自の処理

これでいいのではないか?っと思っています。
こちらのほうが全然自然な気がしてしまうのです。




この投稿にコメントする

削除パスワード

No.6404

Re:Windowsでのメインループについて
投稿者---wis(2006/09/04 18:31:35)


>if(PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ))
>{
>// --- メッセージ処理
>}
>
>// --- 独自の処理
>
>これでいいのではないか?っと思っています。
>こちらのほうが全然自然な気がしてしまうのです。
おそらくフレームスキップを独自の処理で実装する場合に、
メッセージが処理された時間が含まれてしまうのを防ぐため
では無いでしょうか?




この投稿にコメントする

削除パスワード

No.6444

Re:Windowsでのメインループについて
投稿者---K(2006/09/09 09:52:29)


>メッセージが処理された時間が含まれてしまうのを防ぐため
>では無いでしょうか?

返信真にありがとうございます。

やはり詰まるところ、Windowsプログラムの場合メッセージ処理時間は、
例外な処理的ということなのでしょうか?

普通ゲームでしたらメッセージだろうが独自の処理だろうが一つのメインループに毎フレーム通るように記述を行うと思います。

最初のほうに記述したかもしれませんがなぜelseで処理を分けるのかに疑問を持っているだけです。普通メッセージがあっても無くても独自の処理は行うべきだと思います。

実際私のプログラムで何か問題が出ているわけではなく、
なぜメッセージ処理と独自の処理を分けるプログラムが様々なサイトで紹介されているかが気になります。

皆様のお考えをぜひ聞いてみたいです。



この投稿にコメントする

削除パスワード

No.6451

Re:Windowsでのメインループについて
投稿者---wis(2006/09/11 11:34:59)


>Windowsプログラムの場合メッセージ処理時間は、
>例外な処理的ということなのでしょうか
それを決めるのはプログラマだということです。
#これをつかって制御しなくてもタイマーを実装すれば
#できそうだし。。。

>最初のほうに記述したかもしれませんがなぜelseで処理を分けるのかに
>疑問を持っているだけです。普通メッセージがあっても無くても
>独自の処理は行うべきだと思います
私は『フレームスキップを独自の処理で実装する場合』にといいましたが
これは、空き時間を作るという意味で、
いつ来るか分からない、回数も不明なメッセージなのに、
常に独自の処理を行って、もしもその処理が長引いて、そこへ
メッセージが送られてきたときそのメッセージの応答時間が過ぎて
しまうという可能性だってあります。
つまり、メッセージがあるときそれを優先して処理するという
書き方でもあるようです。


>実際私のプログラムで何か問題が出ているわけではなく
これは単に安定した目安を考えずに、好き放題描画して
人間に認識できてないだけだと思います。古いマシンになれば
なるほど、ソフトウェアでの対応がモノをいってくるので、
認識できないなら、無駄な実行を省いて、メッセージを優先しましょう
というのがサイトで紹介されている理由ではないでしょうか?
#まぁ、MSが公開したサンプルがそうなってたから、
#そうしたって人もいるかも知れませんが(汗

長文失礼しました。


この投稿にコメントする

削除パスワード

No.6460

Re:Windowsでのメインループについて
投稿者---K(2006/09/11 23:12:01)


本当にこんなわがままな質問に返信してもらえうれしい限りです。

なるほどWindowsはゲームだけが動いてるわけではないですもんね、
ほかの処理に負担をかけないように色々工夫がされているんだなと、
素直に思えました。

ありがとうございます。

しかしながらやはり最後に一つ疑問が残ります、

このプログラムだとやはりキーメッセージが100フレーム連続できた場合、
独自の処理は100フレームとまってしまいませんか?

ん〜ゲームなら100フレームぐらい連続で判定するときもあるんじゃないでしょうか?

そのためには自分で1秒60フレームを処理を作って入ってくるたびに、
メッセージがあるかの判定と独自の処理を記述すべきだということになるのでしょうか?






この投稿にコメントする

削除パスワード

No.6463

Re:Windowsでのメインループについて
投稿者---wis(2006/09/12 13:46:02)


>しかしながらやはり最後に一つ疑問が残ります、
>このプログラムだとやはりキーメッセージが100フレーム連続できた
>場合、独自の処理は100フレームとまってしまいませんか?
Windowsのメッセージは殆どがイベント駆動型ですし、
フレームという単位がこの場合描画速度を表す単位なので、
100フレームはむしろありえないのではないでしょうか。
どちらかといえば独自の処理のほうが常に実行される形になります。
なので前回の投稿のようにメッセージがくればそちらを
優先する書き方をします。

>ん〜ゲームなら100フレームぐらい連続で判定するときもあるんじゃないでしょうか?
ずっと受け付けていなければならない、
又はこの処理は落とされるとまずいといった処理
例えばキー入力などでは、スレッドを生成しそのなかで、
入力を待機させるのが一般的だと思います。

>そのためには自分で1秒60フレームを処理を作って入ってくるたびに、
>メッセージがあるかの判定と独自の処理を記述すべきだということになるのでしょうか?
むしろ逆でしょう。
メッセージがあるかないかを判断した上で、
ゲーム自体の描画速度を制御するという記述をすべきだと
言うことになると思います。




この投稿にコメントする

削除パスワード

No.6528

Re:Windowsでのメインループについて
投稿者---K(2006/09/19 12:33:43)


>フレームという単位がこの場合描画速度を表す単位なので、

なるほどそういう考え方は俺にとっては新しいです。
すごい納得できました。
ありがとうございます。

>ゲーム自体の描画速度を制御するという記述をすべきだと

そうか描画速度と考えれば納得がそこそこ付きます。

つまり描画速度が60フレーム、
独自の処理等にフレームは別物という考え方で正しいでしょうか?

返信遅れ本当に申し訳ございません。

ありがとうございました。


この投稿にコメントする

削除パスワード

No.6529

Re:Windowsでのメインループについて
投稿者---wis(2006/09/19 17:13:33)


>つまり描画速度が60フレーム、
>独自の処理等にフレームは別物という考え方で正しいでしょうか?
すみません、意味が理解できませんでした。。。
貴方の考えてる『フレーム』ってなにを言ってますか?

#わたしが上で述べているのは『フレームレート』(FPS)で
#1秒間に何回描画されたかの基準です
#ゲームなどでは通常60FPSや30FPSなどが基準です(たぶん。


この投稿にコメントする

削除パスワード

No.6530

Re:Windowsでのメインループについて
投稿者---K(2006/09/19 18:26:22)


>貴方の考えてる『フレーム』ってなにを言ってますか?

一応画面の描画更新速度だと思っています。

つまり私の考えでは仮に60フレーム/秒だった場合。
処理(例えばプレイヤーの移動とか)も60/秒
つまり1秒で60回処理を行うものだと思っています。

ですので描画更新と処理(データの更新)を一緒のやるものだと考えていたのです。




この投稿にコメントする

削除パスワード

No.6531

Re:Windowsでのメインループについて
投稿者---wis(2006/09/20 13:44:33)


>ですので描画更新と処理(データの更新)を一緒のやるものだと考えていたのです。
その通りです。
私が上で書いた『描画処理』とは基本的に
次に描画される画面に絵を転送するまでの
ことを指します(ブリットとかいいます)。

移動などはこの転送する位置を変えることで実装されます
転送された絵が『描画』されるまではその前に描画された
絵が画面には表示され続けています(更新してないので)。
つまり、画面が更新されるまでは(ゲームなどの)
計算処理を行っているのです。

そして、全て転送し終わった後に『画面更新(フリップ)』します。
これが『独自の処理』ということになります。
#2dしか作ったこと無いから3dはよくしりませんが。。。


この投稿にコメントする

削除パスワード

No.6420

Re:Windowsでのメインループについて
投稿者---Ban(2006/09/07 00:11:51)


何を優先するか、だと思いますが、
単純にSleep(0)にすると(遷移はしても)CPU負荷が落ちませんので、
うまく外部同期を取るとかしてないと簡単に99%が達成できたりします。
# バッテリ駆動とかしてると消耗烈しかったり熱かったり。
なんで、むやみにやるもんじゃないと思う。
っていうか、ゲームとしてはきれいにフレーム落ちするつくりにして欲しい。
# Windowsの"アプリ"で60fpsの100%保証なんて絶対できないわけで、
# 落ちたくなければ環境を強化するなり、解像度を落とすなり…ってのが個人的好み。




この投稿にコメントする

削除パスワード

No.6401

Re:Windowsでのメインループについて
投稿者---asd(2006/09/04 16:46:24)


>>>マルチポスト(多重投稿)はしません。
>>>感心しませんな。
>
>すいませんそういう意味合いだったのですか。
>わからなかったとはいえ非常に皆様方の気分を害してしまったと思います。
>本当に申し訳ありません。

向こうのスレは放置するおつもりですか?
こちらで進行している旨をURLを併記の上書き込み、向こうのスレは閉じられたらどうでしょう?

質問するだけして放置する人が多いからマルチポストは嫌われるんですよ。

#横槍失礼しました。


この投稿にコメントする

削除パスワード

No.6402

Re:Windowsでのメインループについて
投稿者---K(2006/09/04 17:12:01)


>>>>マルチポスト(多重投稿)はしません。
>>>>感心しませんな。
>>
>>すいませんそういう意味合いだったのですか。
>>わからなかったとはいえ非常に皆様方の気分を害してしまったと思います。
>>本当に申し訳ありません。
>
>向こうのスレは放置するおつもりですか?
>こちらで進行している旨をURLを併記の上書き込み、向こうのスレは閉じられたらどうでしょう?
>
>質問するだけして放置する人が多いからマルチポストは嫌われるんですよ。
>
>#横槍失礼しました。



すいませんご忠告ありがとうございました。

あちらの質問は謝罪をし、解決で書き込みのほうをストップさせました。

それでは今後もよろしくお願いいたします。


この投稿にコメントする

削除パスワード

No.6405

Re:Windowsでのメインループについて
投稿者---asd(2006/09/05 09:50:35)


>あちらの質問は謝罪をし、解決で書き込みのほうをストップさせました。

こちらのスレで質問について議論が進んでいるので、向こうのスレにはその状況をまとめ、報告、またこちらのURLを掲示するのが筋ではないのですか?

#一応URLを記載の上とも書いたのですが・・・

というのもKさんと同じような疑問を抱えた人が向こうのスレだけに行き着いた場合、どこでマルチポストしているのかどのように解決したのか不明になってしまうためです。

まだ解決していないのでまとめを書き込むことができないのであれば、現在進行中のこの場所を向こうのスレに書き込んでもいいでしょう。

そういう意味でマルチポストに対してしっかり”けじめ”をつけてください。


この投稿にコメントする

削除パスワード

No.6414

Re:Windowsでのメインループについて
投稿者---Hermit(2006/09/05 18:30:01)


あちらは、もう閉めてあるので、今後はそういう風にしましょうという意味ですよね?
(再度書き込みが出来る様にすることが出来るのだったら、私のおせっかいですので気にしないでください(^^;)


この投稿にコメントする

削除パスワード

No.6415

Re:Windowsでのメインループについて
投稿者---asd(2006/09/06 09:14:41)


>あちらは、もう閉めてあるので、今後はそういう風にしましょうという意味ですよね?

投稿者本人が見てくれていればの話ですが、そういうことになりますね^^;

>(再度書き込みが出来る様にすることが出来るのだったら、私のおせっかいですので気にしないでください(^^;)

いえいえ、おせっかいだなんてとんでもないですよ。
質問の回答は締め切られても投稿者本人は追記などできるんじゃないかな?と思い込んでいたもので、突っ込んでいただいて感謝です^^


この投稿にコメントする

削除パスワード

No.6443

Re:Windowsでのメインループについて
投稿者---K(2006/09/09 09:37:47)


すいません少し今週は出張しておりまして、
(しかもなぜか山奥で携帯すらつながらないところに・・・on_)

マルチポストについては色々ご指導いただきありがとうございます。




この投稿にコメントする

削除パスワード

管理者用メニュー    ツリーに戻る    携帯用URL    ホームページ    記事検索    ログ    タグ一覧





掲示板提供:(有)リアル・インテグリティ