最近ババドン作ってて思ったのですが、なんか標準命令は描画が遅い！

そう言えばなんだか自分だけがＨＳＰの標準命令にしがみついてる気がします。コンテスト見ててもそうですが、みんな何かしらのプラグンを使っています。そろそろ自分も標準命令から卒業して心機一転、新しい命令を覚えてスキルアップをしてもっともっと面白いゲームを・・・・・・ってそんな前置きいいから早く用件だけ言えって感じですね。

遅いということなのでプラグインを使って高速化を図ろうと考え、いろいろ調べてみたところ

directXを使うことにより高速描画を実現しますと強調しているhspdxfixと、昔何度かお世話になったhgimg3がいいのではないかということになり、早速プラグインをダウンロードしてみました。

さてこの２つのプラグインにたどり着いたのはいいが、標準命令も含めどれが一番早いのか。

ゲームで一番ＣＰＵを食うだろう、「グラフィック描画の速度」を競わせてみようと思い

今後のプログラミングの指標にもなるのでちょっと実験をしてみることにしました。

【実験方法】

・描画速度を調べるため６４×６４ドットのグラフィックを１０００枚表示させるプログラムを、それぞれのプラグインで作ってみました。
ただ表示させるのではなくて半透明にしたり加算合成にしたり条件を変えてそれぞれ

１秒に何回画面を書き換えられるか（以後ＦＰＳと言う）を、ウェイトを全くいれずにフルスペックで計測してみました。

・比較対象にはプラグイン以外に標準命令も参考程度に実験対象に入れてみました。

・hspdxfixは640×480のフルスクリーン条件下で描画しました。標準とhgimg3は640×480ウィンドウで

・標準命令ではgcopy 、 hgimg3ではhgrotateを使って描画しました。

・計測は１回につき５秒で、最初の２秒は準備時間として意味なく計算させ、後の３秒を実測値として測り１秒あたりのフレームレートを割り出しました。

（・※この実験は失敗です。↓にありますがこの次の実験が成功しました）
 

【パソコンのスペック】

参考程度にです。

ＣＰＵ、Pentium M 1.73GHz

メインメモリ 512MB

ビデオメモリ 128MB (DirectXに関係するそうです・・？一応)

結果は以下の通りです。

※グラフ見にくくてスミマセン・・・ 

縦にfps

横に半透明合成とか加算合成とかのgmode

でhpsdxfixに使われるgmode命令は標準命令と意味が異なりますが、標準命令でのgmodeの意味で今は使っています。

直接コピーはgmode 0　黒抜きコピーはgmode 2 　　「3’」というのは半透明コピーのブレンド率を256(100%)にした場合です。gmode 4も同じくです。

【結果の考察】

　まず何と言ってもhgimg3が早すぎる！！実行画面の時点ですでにこりゃhgimg3がダントツだろともう火を見るより明らかでしたが、結果を見てさらに驚きました。それに引き換え同じdirectXを使っているはずのhspdxfixが標準命令になに一つ勝ってません・・・

しかも直接コピーが黒抜きコピーに負けるってなんぞ！？謎の多いhspdxfix・・・

何が起きた！！？？

俺のソースがおかしいのか・・・？？

これでは高速描画をうたっているdirectXの開発者microsoftのプログラマーの顔が浮かばれません・・・

試しにdirectXで同じく命令が書けるhmm.dllも緊急に追加してまた再実験を試みました。

今度はうまくいくかな･･･と実験結果を見たところ今度はうまくいった模様

hpsdxfixの半透明コピーの速度が３倍に上昇！

ってあれ・・・結局　gmode 0　と　gmode 2　の速度逆転の謎は解けぬまま・・・・

しかも・・あああああ！

何もしてないのにhgimg3のＦＰＳが81に上がっている！

なぜ！？

同じプログラムなのに急にＦＰＳが上がるなんてことあるのか！！？

いやまてよ・・よく考えたら今までデバッグ用にＦＰＳを表示する命令も使ってたっけ・・・（上の失敗の原因）

もしかしてそれが処理を食って重くしていたのかもしれない。

ＦＰＳ表示命令のところだけ「；」コンロを入れたり消したりしてＦＰＳを調べたところ

結果に大きな違いが！

やはり原因はここにあったようです。

ＦＰＳを計測するのにＦＰＳを表示する処理が邪魔して計測を狂わすなんて・・・本末転倒、プログラムした自分が情けない・・

しかもhgimg3に至ってはフォントテクスチャを使うのを面倒くさがってtitle命令でfspを表示していたのだから・・こりゃ遅くなりますわな。

というわけで完全に邪魔な命令を取り払って再度実験スタート！

使うプラグインは３種類に増え

・hspdxfix.dll (hspdx.dll)

・hgimgx.dll

・hmm.dll

になりました。

hgimg3がぶっちぎりで全部を上回っている！！

標準命令に関してはやはりというかgmode 0の直接コピーが一番早く、一番遅いと思っていた加算合成が下から３番目！

一番遅いのは何とgmode 3とgmode 4 ！？

gmode 2が嫌いで、今まで自分はいろんなゲームでgmode 4を多用してきましたが・・・まさかこれほどまでに自分は非効率なプログラムを書いてきていたのか・・・・

ああ素直にgmode 2にすれば２倍は早くなったのに！！

これからは必ずgmode 2を使うようにしよう・・

また加算合成は加算率αが小さいほどちょっと早くなる傾向にあるそうです。

gmode 5,,,256のときはＦＰＳが１３

に対し

gmode 5,,,1のときはＦＰＳが１７

迷ったら加算率は小さいほうがいいということですね

意外にもgmode 3のブレンド率が256のときだけ急激に速度が上がっていますが実質gmode 0と同じなんでgmode 0を使ったほうがまだ良いですね。

gmode 4にはその傾向が見られませんでした。

ちなみにグラフにはのっていませんがgmode 6の減算合成もやってみたのですが、加算合成と比べて少しだけ早いみたいです。

gmode 6,,,128で　ＦＰＳ　１６でした。

減算率αはＦＰＳに影響しませんでした。

hspdxfixは相変わらず意味不明な結果に・・・

そもそもgmode 0とgmode 2はdirectX

gmode 3(半透明)とgmode 5（加算合成）はDirect3Dをそれぞれ使って描画しているので

もちろん命令自体も違うし命令の中身の構造も全く違うのです（多分）

自分はDirectXについて詳しく知っているほうではないので偉そうなことはいえませんが、

ひとまずgmode 0や2よりgmode 3や5のほうが速度が速いことについては、あまり突っ込まないことにしましょう。

それでもgmode 0の直接コピーより結局gmode 2のほうが早いんですか・・・？？

これは無理にでもgmode 2を使ったほうが早いということに・・・いいのか？。

しかしどのgmodeでも30fpsを上回ることはできず、hgimg3に大敗・・

標準命令に打ち勝っているのは半透明コピーと加算合成

標準命令でもgmode 3をたくさん使うようなゲームじゃない限り必要性はないということになります。

しかしこれについては、パソコンの環境によっても変わってくるでしょうしhspdxfixが全く使えないと結論を下すのにはまだ早いでしょう。

おそらくＣＰＵスペックの悪いパソコンで実行するとhspdxfixは威力を発揮するのではないかと思われます。

しかし逆に、1.5GHzを超えるような高スペックの環境ではもう使えないということになりそうです。

今度の機会にスペックの悪いパソコンでの実験データを採取してみることにします。

えーと、あとは・・・おっと忘れるところだった・・・

hmm.dllの存在を忘れていた・・・

これに関してはもうヒドイの一言。

gmode 0のＦＰＳが30でhspdxfixに勝っていること意外何の取り柄もありません・・・

これも俺のソースがわるいのか！！？？

半透明コピーと加算合成はＦＰＳが１をきりました。（ぇ

0.9です。

しかし、もしかしたらということもあるので

一応自分のソースを疑ってみることにしてhmm.dllの結論は先延ばしにさせてもらいます。

なんだかhmmのグラフがもう見えなくなっちゃってますね・・・

hgimg3がダントツ早いとのことなので、これから標準命令を卒業してhgimg3を主に使っていくことにしますが、

一応、　標準命令　ＶＳ　hspdxfix　（inｽﾍﾟｯｸの悪いPC）

の対決も残ってますし

やる気はあまり無いですがhmm.dllの名誉挽回もあるので

描画速度実験は続けていくことにしたいと思います。