トップページ > 過去ログ > 記事閲覧
重くても動作速度一定
名前:dal 日時: 2008/06/26 16:15

動作速度一定に関してです。割と初心者です。 おそらくScreenFlip,ScreenCopyの挙動あたりが 根本的に理解できていないので質問させてください。 質問内容の要約すると ・おそらく重くないはずの描画処理なのに遅い。ScreenFlipの扱いが  おかしい気がしています。描画とScreenFlipの正しい方法 ・重くない処理でも、動画撮影など裏動作の影響で遅くなる場合の対策。  重い場合の動作速度一定に保つ方法(なめらかじゃなくなってもいいので) です。 たとえば、3秒間の間に画面をだんだん明るくさせたいときに int t,bright; int maetime=GetNowCount(); while(1){ ClearDrawScreen(); t=(GetNowCount()-maetime);//ループが始まってからの時間取得 if (t>3000) break; //3秒たったら終わり bright = t*255/3000; //時間によって明るさ取得 SetDrawBright(bright,bright,bright); DrawKansu(); //描画 IdoKansu(); //キー入力待ちやMapのスクロールなど ScreenFlip(); } サンプルプログラムにあるようなFrameRateを使わずにこのような構造を使っています。 FrameRateを使っていない理由は、使った方が動作が一定にならず遅くなったからです。 しかし遅い理由はScreenFlipの使い方が間違っていたからかもしれません。 16msのwaitを入れてもさらに遅くなるだけのような気がしています。 DrawKansuで描画しているものは、LoadDivGraphで事前に読んでおいた 1マスあたり32×32の画像を、DQのマップ風に、1マスあたり等倍32×32や、40×40に拡大描画、 あるいは2×2ほどに超縮小描画(これが一番重い)などして、640×480のウィンドウに びっしりと敷き詰めて3層ほど描いているだけなので、 たぶん重たいはずがないと思うのでプログラムの書き方がおかしいと思うのですが アドバイスをお願いします。 質問内容は ・サンプルにあるようなフレームレートを使わずに、  このようなGetNowCountで制御する方法の問題点 ・演算が重い場合でも一定速度を保てるような  描画loop、ScreenFlipの正しい使い方。 ・640×480の背景に、100×100ほどの大きさの物体を点滅描画させたいときの  ScreenCopyの使い方 です。 その他のところでも気になったことがあれば アドバイスよろしくお願いします。

Page: 1 |

Re: 重くても動作速度一定 ( No.1 )
名前:管理人 日時:2008/06/29 17:49

> 1マスあたり32×32の画像を、DQのマップ風に、1マスあたり等倍32×32や、40×40に拡大描画、 > あるいは2×2ほどに超縮小描画(これが一番重い)などして、640×480のウィンドウに > びっしりと敷き詰めて3層ほど描いているだけなので、 こちらの処理はPCのスペックに因っては結構重いです。 ・サンプルにあるようなフレームレートを使わずに、  このようなGetNowCountで制御する方法の問題点  もし GetNowCount を使用した自前フレームレート制御が固定フレームレートの 場合はソフト側のフレームレートと画面のリフレッシュレートが一致していないと 動きがガクガクして見えます。 ・演算が重い場合でも一定速度を保てるような  描画loop、ScreenFlipの正しい使い方。  演算が重い場合でも一定速度を保つには可変フレームレート方式が一般的です。 具体的には毎フレーム、前回のフレームで経過した時間分だけ処理を進めるようにします。 サンプルプログラムコーナーの「13.移動速度を一定にする(1)」の FrameTime を 毎フレーム更新するような感じです。 ・640×480の背景に、100×100ほどの大きさの物体を点滅描画させたいときの  ScreenCopyの使い方  ScreenCopy は使用しません。普通に毎フレーム全画面を描画して、点滅描画させたい 物体を描画したりしなかったりをして、点滅しているように見せます。
Re: 重くても動作速度一定 ( No.2 )
名前:dal 日時:2008/06/30 17:15

なるほど。勉強になりました。 ありがとうございました。

Page: 1 |