///////////////////////////////////////////
【開発環境】
Win2000で、VC++6.0、 MFCを使用しています。
スケルトンはSDIで、FormViewを基本にしています。
///////////////////////////////////////////
初めて書き込みをします。
ユキと申します。
今、一時停止機能を持つゲームを作成しています。
流れとしては
1.「一時停止ボタン」を押す
2.ゲームが止まり、「一時停止」の表示が「再開」に変更される
3.もう一度ボタンを押すとゲームが再開し、「再開」の表示が「一時停止」に戻る
以上のようにしたいと思うのですが、 3 がどうしてもうまくいかず、止まっています。
ボタン関数の中で「もう一度ボタンを押す」方法がわかれば進めそうなので、アドバイスいただ
けたらと思います。
まだVC++を初めて間もなく、プログラムの知識も浅いので質問の仕方に問題があるかもしれま
せんが、よろしくお願いします。
チェックボックスをボタン表示形式で使えばいいのでは
Kさん、早速のアドバイスありがとうございます。
知識が浅く、その場でひらめくには至らないので、うまくいき次第また連絡しますね。
> ボタン関数の中で「もう一度ボタンを押す」方法がわかれば進めそうなので、
処理を読む限りこの必要性がわからなかったのですが、
もしかして一時停止中はそのボタンの処理の中で再開を
ずっと待ってたりします?
Banさん、返信ありがとうございます。
Banさんのおっしゃる通り、一時停止を押すとユーザーが再び押すまでゲームは止まったままで
す。
まだまだ作成初期段階で、この処理が必要かどうかと問われるとはっきり必要だとは言い切れな
いのですが、わからないまま別の方法にしてしまうのは落ち着かないので。。。
お手数かけますm(__)m
すみません、わかりづらい書き方だったかも・・・
一時停止中はそのボタンの処理の中で再開を待って、再び押されてはじめて他の関数が動き出し
ます。
そのまま受け答えすればよかったですね(汗)
ボタンの関数の中で停止しているのは好ましくないと思います
ボタンの関数内部は状態変更のみにとどめておいたほうがいいと思います
たとえば、ドキュメントクラスに、進行状態フラグのようなものを持ち
それをボタン呼び出しにより変更する
ゲーム進行側関数、またはスレッドはその状態を判断し進行する
と言う様にしてはどうでしょうか
スレッドに関する知識が無いのであれば「OnIdel」関数にてゲーム進行のメイン部分を
作成しその進行の中で、状態フラグ等をチェックすればよいのではないでしょうか
単なる一案ですので、私はゲームの作成したことはありません
やっぱりそうでしたか。
対策例は wood さんが既に示されてますが、状態フラグなどを持っておいて
ボタンではその変更だけしておき、実際の動作はそれを参照するのがありがちな
手法です。
個人的には、ちゃんと入力状態用クラスを作って、それをゲーム中クラスと
アイドリングクラスで継承してポリモーフィックに挙動を切り替える方が
設計として好みです。
いずれにしても、メッセージハンドラの中からは抜け出さないと他の
メッセージ処理を阻害しますから今の構成は直したほうがいいでしょう。
ポーズしたいようなゲームにどの程度のリアルタイム性が必要化にもよりますが、
リアルタイム命なゲーム(格闘とかシューティングとか)なら多分スレッドが必要。
シミュレーションなどで緩やかな時間進行でいいなら OnIdel でも十分かも知れません。
woodさん、返信ありがとうございます。
確かに関数内でとどまっていては負担も大きいですしよくないですね。
woodさんの丁寧な説明にもかかわらず、吸収しきれないのはもどかしいです。。。
とりあえずOnIdel関数についてMSDNを流し読みしてみました。
バックグラウンド処理が行えるということで、これは使えそうですね。
早速詳細を調べて試してみます。
皆さんの返信をいただいて、まだまだここに書くのは早かったな~と実感しています。
専門書を熟読して、ある程度勉強してからまた質問したいと思います。
ありがとうございました。
Banさん、返信ありがとうございます。
私が発言してる間にいただいたもので前後してしまいましたm(__)m
Banさんのアドバイスでさらに、私が作ろうとしているゲームにはスレッドの知識が必要だとい
うことがわかりました。
やはり丁寧な説明をいただいているにもかかわらず、これだけしか吸収できないのはほんとに申
し訳ないです。
ただ、アドバイスいただいて調べるきっかけができたのは何よりの収穫でした。
改めてありがとうございました。
> Banさんのアドバイスでさらに、私が作ろうとしているゲームにはスレッドの
> 知識が必要だということがわかりました。
誤解があるようだといけないので若干補足です。
今回の動作切り替えだけなら、各ハンドラでフラグを参照・制御すればいいので
OnIdle もスレッドも特に不要です。
また、クラスにした方が好みというのも、今後の条件修正時に全部のハンドラを
個別に直すのが面倒なので私ならそうするかな、という話です。
スレッド無しでも非同期処理はある程度可能ですし、昨今の PC 環境なら
OnIdle などで組んでも結構実用速度は出るかもしれません。
# ゲームの場合たいてい描画速度が最大のネックになってて、
# それに比べたら内部処理なんてどちらでも変わらなかったりとか。
ただ、例えば OnIdle には以下のような制限もありますし、
> OnIdle から復帰するまで、アプリケーションは入力を処理できないので、
> OnIdle では時間のかかる処理はしないでください。(by MSDN)
リアルタイム性を追求するようなゲーム用のバックグランド処理は
スレッドにした方が何かと都合が良いかもしれません。
(ゲームは個体差が大きいのであくまで一般論です)
Banさん、またまた丁寧な説明ありがとうございます。
返信が説明不足ですみません(汗)
さらに、プログラムを作る際の細かい配慮が足りていないことを実感しました。。。
精進しますm(__)m
是非今後の参考にさせていただきますね。
本当に勉強になりました。
ありがとうございました。