プログラムを途中で止めたり、また、再開したりする方法

[戻る]
はまち 2001/11/08(木) 09:02:16
初めて質問します。よろしくお願いします。
よくゲームソフトなどで、ゲームの途中、メニューの「一時停止」や「再生」でゲームを
ストップさせたり、続きをやったりすることが出来ると思いますが、あれはどういう風に
なっているのでしょうか。僕自身は、MFCを使って簡単なゲームみたいなものを作ろうと
思っているのですが、作っている途中で先に進まなくなってしまいました。
 ゲームはとても簡単なものです。画面上に一つ円を書いて、それを上下左右4方向にランダムに
ひたすら動かすようなものです。
 ずっとプログラムを動かしてて、プログラムを止めたいときにメニューの「一時停止」
で止めて、また続きを始める時は「再生」で動かし始めるような感じです。
 SetTimerを使うのかと思って、今、実際に作っているのですが、どなたか何か知ってたら
教えてください。よろしくお願いします。

am 2001/11/08(木) 12:25:21
> SetTimerを使うのかと思って、今、実際に作っているのですが、どなたか何か知ってたら
>教えてください。よろしくお願いします。

停止時点で KillTimer を呼んでタイマを破棄し、再開で SetTimer するという方法もあれば、
停止した時点でフラグを立てて、WM_TIMER を受け取る部分で そのフラグを見てタイマ処理を
するかどうかを判定する方法などがあります。

はまち 2001/11/09(金) 00:22:39
amさん、早速のお返事、ありがとうございます。本当に、困っていたので助かりました。
やっぱり、よくゲームなどの「再生」「停止」なんかは、SetTimerやKillTimerを使っているんですね。
そこで、もう一つお伺いしたいことがあるんですが、KillTimerで止めてSetTimerでまた再生するということは、
たとえば、SetTimerでWindowsからWM_TIMERメッセージを0.001秒おきにもらって、OnTimerでそのメッセージを
受け取るということは、そのOnTimerの中に、繰り返し行うプログラムを書けばいいということでしょうか。
どなたか、また、よろしくお願いします。

toru [E-Mail] [HomePage] 2001/11/09(金) 01:12:04
> SetTimerでWindowsからWM_TIMERメッセージを0.001秒おきにもらって

SetTimerだと50msくらいが限界なんで1msでは割り込めませんね。
SetTimerやKillTimerとかでは無くSleepをかけたりしたほうがいいと思います。

あとマルチメディアタイマというのがありますが
あれを使うと極端に処理が重くなります。

> 画面上に一つ円を書いて、それを上下左右4方向にランダムに
> ひたすら動かすようなものです。

これなら不正確なタイマでも問題無いと思いますが...

あとOnTimerに繰り返しの処理を書くのではなくOnTimerでは分岐のみを行って
別の関数で処理をしたほうがいいと思います。

そうしないとOnTimerが危険な量のコードになると思いますよ。

はまち 2001/11/10(土) 04:10:43
[[解決]]
toruさん、お返事ありがとうございました。toruさんの言うように、50msあたりから処理速度があまり変わって
ないような気がしてましたが、そういうことだったんですね。
今、懸命にsleepをMSDNで調べているところです。うまく使えると言いと思います。

>そうしないとOnTimerが危険な量のコードになると思いますよ。

あまりにもVC++は分からないことだらけで今日新たに書籍を1冊購入してよんでたところですが、toruさんの言うよう
書籍の例では、他のメンバ関数でまとめてOnTimerで呼び出すようにしてました。確かに、僕が行ったようにすると
大変な量のコードがOnTimerに入ってしまいますよね。こんな基本的な質問にまで答えてくれたtoruさんに感謝し
します。
 まだまだ勉強しないといけないようですね。amさん、toruさん、今回はどうもありがとうございました。

なると屋 2001/11/10(土) 20:34:39
ゲームを作るんでしたらMFCよりDirectXを薦めます。
MFCはアプリケーションを作るのに向いていますが厳密な
リアルタイム操作(0.001msなど)は結構大変かと思います。
DirectXなら、最初からゲームのためのライブラリなので
DirectXの参考書が1冊あれば作れなくもないと思います。

はまち 2001/11/10(土) 22:18:38
なると屋さん、お返事の方、大変ありがとうございました。
そうなんですか、やっぱりDirectXというのは、ゲームに向いているんですか。昨日、あたりから、うすうす
ひょっとしたらそうなのではないかと感じていました。本屋に行ってもゲーム関係だったらDirectXの方が
多いんですよね。でも、MFCの本をだいぶ読み込んで、MFCはゲーム作りにくそうだけどこうなったらがんばろうと
思ってたところなので、迷ってしまいます。
 そこで、もし、知っていたら教えていただきたいのですが、僕が作ろうとしているのは、実は、生物の
コンピュータシミュレーションみたいなものです。僕自身、まだ学生で、研究テーマがこれ関係のものになりました。
そこで、何でプログラムをしようかと思ったところで、MFCでやってみようかと思ったところです。はじめは
VBあたりでやろうかと思ったのですが、やっぱり速さを求めたら、Cがいいかと思いました。やっぱりどうしても
できるだけ、早い速度が求められそうだったからです。そこでなんですが、DirectXというのはCと同じぐらい
早く処理してくれるものなのでしょうか。そこが一番気になります。もし、なんとなくでも結構なので知ってたら
教えてください。

toru [E-Mail] [HomePage] 2001/11/10(土) 23:42:30
> DirectXというのはCと同じぐらい早く処理してくれるものなのでしょうか

そもそもDirectXとCの速度を比べること自体がおかしいような気がしますが...

DirectXはそれなりに速度はでると思います。
でもまともにDirectXプログラムをやると泥沼にはまります(泥沼にはまった人の体験談)

フルスクリーンにすると統合環境でまともにデバッグができない(俺だけ?)
という罠にはまり、ファイルに変数を書き出してデバッグするという厳しさ...

ちなみにDirectX8はDirectDrawとDirect3Dの統合なんていってるけどウソです。
事実上DirectDrawの抹消です。

2DならDirectX7以前をつかうべきですね。

ちなみにDirectXライブラリを作ったことがあるんですけど
数千行のコードですよ。まじで...

つうかこれあんまり答えになってないですね(笑)

> DirectXというのはCと同じぐらい早く処理してくれるものなのでしょうか

多くの市販ゲームがDirectXを使っているというコトから
速度に関しては信用していいんじゃないでしょうか。

では。

はまち 2001/11/11(日) 00:54:51
>2DならDirectX7以前をつかうべきですね。
>ちなみにDirectXライブラリを作ったことがあるんですけど
>数千行のコードですよ。まじで...
>つうかこれあんまり答えになってないですね(笑)

 とんでもないです(笑)。僕にとってはどれも貴重なお話ばかりです。でも、

>多くの市販ゲームがDirectXを使っているというコトから
>速度に関しては信用していいんじゃないでしょうか。

というのは知りませんでした。そうだったんですか。それなら、意外にDirectXの方がいいのかもしれないですね。
以前、MacでCodeWoriarというソフトを使ってプログラムしてたんですが、今回MFCを使うようになり、一気に
プログラムが難しくなったような気がして苦しんでいます。あまりにも難しいので、「本当に、これを
使ってプログラムなんて作れるのかなあ」とも感じてしまいます。でも、本屋に行ってVC++関係の書籍がたくさん
あるのを見ると、「やっぱり他のみなさんは、これで作ってるんだろうなあ」と改めて感じます。以前、どこかで
エクセルやワードがVC++で作られたソフトってことを聞いたことがあるんですが、これは本当なんでしょうか。
 どなたか、お忙しいところすみませんが、また、よろしくお願いします。

toru [E-Mail] [HomePage] 2001/11/11(日) 02:41:10
> 本当に、これを使ってプログラムなんて作れるのかなあ

少なくとも私はMFCは使いません。理由はわけがわかんないから(笑)
だってあんなバカでかいシロノモつかえませんよ。

だってMFCを内包したら何もしないアプリですら100KBオーバーです。
それに比べてWin32APIオンリーなら20KB〜50KBくらいに押さえることが可能です。

ただWin32APIの欠点は少し踏みこむとMSDNが英語...
その点MFCはオール日本語...これはマイクロソフトの陰謀としか思えません。

はっきりいって英語で書かれると読解不能です。


あと以外に知られてないですけどVC++を入れるときにMFCを外すと
リソースが全くつかえなくなる...どういうことやねん!

あんな使いもしないライブラリなんて入れたくないのに...
.rcファイルを見てみればわかりますが

#include "afxres.h"

MFCを使ってやがります。このせいでMFC無しではリソースが全く使えない...

というかそもそもWin32API無しにいきなりMFCを使うのは不可能かと...


> エクセルやワードがVC++で作られたソフトってことを聞いたことがあるんですが

これはEXCELもWORDも持ってないんで詳しくはわかりませんが、
有名なソフトは結構VC++でできてます。

たとえばWinAmpや秀丸なんかはVC++でできてます。
あと適当に調べてみてわかったんですけど
Internet ExplorerとかOutlook ExpressとかMSN Messenger等は
全部VC++では無いということです。

自社のソフトが自社のコンパイラでできてないって状況はねえ...

まあそれでも他のコンパイラに比べればいいほうだと思います。


つうかまた本題とはかけ離れた方向に突き進んでますね(笑)

はまち 2001/11/11(日) 03:57:11
>つうかまた本題とはかけ離れた方向に突き進んでますね(笑)

いや、とんでもない。今回もとても参考になりました。

>あと適当に調べてみてわかったんですけど
>Internet ExplorerとかOutlook ExpressとかMSN Messenger等は
>全部VC++では無いということです。

これは、とても意外です。確かにどうしてVC++を使わないんでしょうか。僕はぜんぜん、詳しくないんですが、
他のコンパイラといえば、BorlandC++とかDehi(スペルとても自信がないです。しったかぶりしてたらごめんなさい)
とかあると思うんですが、こういうので作ってるということでしょうか。VC++大丈夫なのかと思ってきてしまいます。
 ですが、

>有名なソフトは結構VC++でできてます。
>たとえばWinAmpや秀丸なんかはVC++でできてます。

の書き込みには少し安心しました。そうでもなければ、本屋であんなに書籍がありませんよね。
もう一つお聞きしたいと思ったのですが、本当に、本題と離れていってしまうような気がしたので、新たに
掲示を作りたいと思います。

kazuma 2001/11/11(日) 10:07:53
> .rcファイルを見てみればわかりますが
> #include "afxres.h"
> MFCを使ってやがります。このせいでMFC無しではリソースが全く使えない...

そんなことはないです。
試しに、「新規作成」−「プロジェクト」で、
「Win32 Application」−「標準的な "Hello World" アプリケーション」
としてみてください。

> というかそもそもWin32API無しにいきなりMFCを使うのは不可能かと...

そうでもない思います。確かに API の知識があれば MFC を覚えやすいということはあると思いますが。
C++ の知識がないと不可能です。(体験談)

> 他のコンパイラといえば、BorlandC++とかDehi(スペルとても自信がないです。しったかぶりしてたらごめんなさい)
> とかあると思うんですが、こういうので作ってるということでしょうか。

いくらなんでもそれないでしょう。
VC 以外の自社製コンパイラかもしれないし、そもそも C/C++ 以外の言語を一部使っているという意味かもしれないし。
(勝手な想像です。真剣に受け取らないように。)

toru [E-Mail] [HomePage] 2001/11/11(日) 18:07:12
> 試しに、「新規作成」−「プロジェクト」で、
> 「Win32 Application」−「標準的な "Hello World" アプリケーション」
> としてみてください。

では[新規作成] - [リソーススクリプト]
として見てください。

kazuma 2001/11/11(日) 18:46:30
> では[新規作成] - [リソーススクリプト]
> として見てください。

ほんとですね。でも、
#include "afxres.h"
の部分を消してしまえばいいだけでは?。

toru [E-Mail] [HomePage] 2001/11/11(日) 19:34:22
> #include "afxres.h"
> の部分を消してしまえばいいだけでは?。

消したらコンパイルエラーがでるんでダメですね。

#include <windows.h>
に書きかえればOKですが...

たけみ 2001/11/11(日) 19:41:10
話の腰を折ってしまって申し訳ないのですが、DirectXの話に戻らせていただきます。

はまちさん>
私はDirectXプログラミングはやったことが無いので詳しいことは判りませんが、
なんでもDirectDrawは描画処理をいきなりグラフィックチップに送るらしいです。

ノーマル:描画関数呼び出し→計算(CPU)→表示命令(グラフィックチップ)
DrectX :描画関数呼び出し――――――→CPUは情報だけ提供→計算(グラフィックチップ)→表示
つまり、CPUで描画計算させなくていい分、中心処理に演算能力を集中できるので全体が速くなる。
一方でグラフィックチップに描画処理に加えて演算の負荷が加わるので、
全画面表示で他のアプリなりの描画をシャットアウトさせて一つの描画に専念させる。

ってことらしいですよ。昔(4年くらい前)の話なので細かくは間違ってるかもしれませんが
おそらくアルゴリズムは変わってないでしょう。
最近こういう情報の載ってる雑誌って少ないですよねぇ。

はまち 2001/11/12(月) 03:37:05
たけみさん、とても、丁寧な説明、ありがとうございました。とてもよくわかりました。

たけみさんの図を見ると、DrectXの方は→計算(CPU)→の部分がない分、確かに早くなりそうですね。ますますDrectX
に興味が出てしまいます。

>最近こういう情報の載ってる雑誌って少ないですよねぇ。

僕もまだまだ勉強途中なので、少しでも勉強しようと本屋に行くんですが、僕が知っているC関係の雑誌といえば、
C MAGAZINEしか知りません。他にもなにかMFCやC++、C関係の雑誌をご存知でしょうか。何か知ってたら教えて
ください。明日からまた一週間が始まってしまい、お忙しいとは思いますが、お暇なときによろしくお願いします。

古いスレッドには追加発言できません。