HSPポータル
サイトマップ お問い合わせ


HSPTV!掲示板


未解決 解決 停止 削除要請

2006
1119
mzHGIMG3フレームレート変更6解決


mz

リンク

2006/11/19(Sun) 22:31:34|NO.3642

HGIMG3でゲーム作成をしております。

ユーザーにコンフィグで変数framerateを設定してもらい、
0なら秒間15フレーム、1なら秒間30フレーム、2なら秒間60フレームで描画したいのですが、
15フレームに設定してもゲームが軽くなっている印象がありません。
(動きはイイ感じにカクカクになっています)

以下のような考え方で合っているのでしょうか?


*main hgdraw (ゲーム中処理) ; フレームレート設定 ; 15fps if framerate = 0 { ; 4回に1回描画 if framerate_count = 0 { hgsync 60 framerate_count = 3 } else { framerate_count = framerate_count - 1 } } ; 30fps if framerate = 1 { ; 2回に1回描画 if framerate_count = 0 { hgsync 30 framerate_count = 1 } else { framerate_count = framerate_count - 1 } } ; 60fps if framerate = 2 { ; 必ず描画 hgsync 15 } goto *main



この記事に返信する


naznyark

リンク

2006/11/20(Mon) 00:43:39|NO.3645

実際におこなわれるのは

hgdraw : バッファ画面作成(の開始) ( hgsync よりは重い処理 )
hgsync : (作成中でない)バッファ画面を表示画面に転送 ( hgdraw よりは軽い処理 )

という処理のようなので
提示されたスクリプトとは逆(?)に hgdraw を何回かに一度、
hgsync は毎回、または、 hgdraw と同じタイミングで実行というようにするべきだと思います。



Drip

リンク

2006/11/20(Mon) 21:12:17|NO.3671

Dripです。

 mzさん、こんにちは。
画面を書き換える処理を減らすことで動作速度を向上する方法ですが、
mzさんのやり方では毎フレームhgdrawが行われているため、
事実上ほとんど処理速度が高速化することはありません。
正しくは、動作環境を満たしたハイスペックなマシンでのみわずかな高速化が期待され、
本来高速化すべきロースペックなマシンでは全くと言って良いほど効果がありません。

 またnaznyarkさんのアドバイスは少し意味がわかりません。
event_系命令やモーション等の動作を考慮するならば、
hgdrawを毎フレーム行っているmzさんの処理が正解です。
それらの命令が無いにしてもhgdrawを実行していないのにhgsyncを行う事は無意味です。

 hgdraw命令で物体をバッファに描画(転送)し(まだ表示はされない)、
hgsyncで描画を画面に反映するので、実際の描画工程(hgdraw)を減らさない限り、
画面更新の時間を除いて処理速度は変化しません。
現状を分かり易く説明すると、次のような状態と同じです。

omosa=30 //試す処理の重さです。 //3つの処理であまり処理速度が変化しなかった場合は、この重さを調節して下さい。 pos 260,200 objsize 120,30,40 button "60FPS",*c1 button "mzさんの6FPS",*c2 button "正しい6FPS",*c3 stop *c1 dialog {"60FPSで重い描画処理を毎フレーム実行します。 タスクマネージャでCPUの使用率を見ながら実行して下さい。 かなりの負荷が掛かっていることが分かります。"} repeat:redraw 0 color 255,255,255:repeat omosa:boxf:loop color:pos 320,100:mes cnt:redraw 1,0,0:await 15 loop *c2 dialog {"mzさんの6FPSで重い描画処理を実行します。 タスクマネージャでCPUの使用率を見ながら実行して下さい。 60FPSと大して変化がないことが分かります。"} repeat redraw 0 color 255,255,255:repeat omosa:boxf:loop color:pos 320,100:mes cnt if cnt\10=0:redraw 1 await 15 loop *c3 dialog {"正しい6FPSで重い描画処理を実行します。 タスクマネージャでCPUの使用率を見ながら実行して下さい。 かなり軽くなっていることがわかります。"} repeat:redraw 0 color 255,255,255:repeat omosa:boxf:loop color:pos 320,100:mes cnt*100:redraw 1:await 150 loop
 正しいフレームレートの変更機能をhgimg3で取り入れるならば、
addangやsetposで指定される値を、定数ではなく1フレームに変化する量を算出して設定し、
hgsyncのウェイトを変えるべきです。
HGIMG3向けの正しいフレームレートの設定方法を以下に示します。

#include "hgimg3.as" hgini addbox box,10,10 regobj box,box fps=5 //フレームレート(60より大きくするとハードウェアの制約上遅くなる場合が殆どです。) mov=1.0 //【一秒】あたりの変化量 t=0.0 repeat setpos box,sin(t)*100,cos(t)*100,-300 t+=mov/fps //1フレームあたりの変化量を算出して設定 hgdraw hgsync 1000/fps loop
少々面倒ですが、がんばってください。



mz

リンク

2006/11/21(Tue) 00:30:16|NO.3674

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

naznyarkさんの方法では、やはりゲームの動作がおかしくなってしまいました。
やはりaddang、setpos等もフレームレートに合わせて設定してなければならないようです。
Dripさんに提示して頂いたスクリプトがすごく理解しやすく、ためになりました。
わざわざありがとうございます。

こうなると当たり判定の精度なんかも考慮してあげる必要がありそうですね。

hgdraw、hgsyncの設定しだいで簡単にフレームレート設定ができると思い込んで
いたので、あてが外れてしまいました・・・。
既に結構な量のスクリプトを書いてあるので、今から修正するのは大変そうですが、
コツコツとがんばりたいと思います。

お二方とも、ありがとうございました。



mz

リンク

2006/11/21(Tue) 00:39:22|NO.3675

解決済みにするのを忘れていました。



naznyark

リンク

2006/11/21(Tue) 02:09:33|NO.3676

不正確な書き込みをしてしまいもうしわけありませんでした。

ですが一点だけ。

> それらの命令が無いにしてもhgdrawを実行していないのにhgsyncを行う事は無意味です。

一度も hgdraw の実行が無ければ hgsync の実行は確かに無意味ですが、
hgsync の単独実行にも意味はあります。

下記のスクリプトのループ中の hgsync を await に置き換えて実行し
そのウィンドウを他のウィンドウで隠した後、再表示してみてください。

#include "hgimg3.as" hgini setcolor 0, 255, 0 addplate m, 0, 64, 64 regobj o, m setpos o, 0, 0, -100 wait 0 hgdraw hgsync repeat hgsync 30 ;await 30 loop



Drip

リンク

2006/11/23(Thu) 23:25:18|NO.3720

Dripです。

> こうなると当たり判定の精度なんかも考慮してあげる必要がありそうですね。

 当たり判定をレイではなく範囲で指定している場合は修正が面倒になってしまいますね。
定数で移動量を指定している個所については、1描画ループ内でrepeatを使用し、
移動と判定の処理のみを繰り返すことで、当たり判定のサイズを変えずに修正できます。
 単純に60FPS -> 30FPSになるだけでしたら repeat 2 で移動、当たり判定を繰り返せば、
判定領域の再設定などせずに済むので手軽です。

> 一度も hgdraw の実行が無ければ hgsync の実行は確かに無意味ですが、
> hgsync の単独実行にも意味はあります。

 これは意図的に使用すべきではありません。
マニュアルにも記載されているように、hgsyncとhgdrawはセットで使用したほうが安全です。
これはclsblur命令で残像を残して処理したままアプリケーションを終了すると、
別のDirectXを使用するプログラムを起動したときに残像が残ったままになることがあるように、
DirectXでは環境依存による描画の違いがどこで発生するかわかりません。
描画 -> 更新のリズムを崩さない方が良いと思います。



ONION software Copyright 1997-2023(c) All rights reserved.