[OSASK 2107] Re: adarrel3, monza3.

["Solid" <kimura !Atmark! mb.meidensoftware.co.jp>]

  こんにちは、Solidです。


川合 さんは 2001/09/11 20:17 の「[OSASK 2100] Re: adarrel3,
monza3.」で書きました：

>  そう言えば、tetra01やtetra02のフレームレートはどのくらいなんで
>しょうか？・・・test014のフレームレートは16FPSです。僕としては、
>負荷との兼ね合いもあることですし、これくらいで十分だと思っている
>のですが・・・。

実は tetra01は２度ほど「こそこそ」っと上げ直していて、
古いソースも残っていないため、確認はとれませんが
チラツキが目立たない範囲で 15〜20FPSに調整してあったと思います。
(１フレームの移動量も調整してます)
負荷という意味では遅いマシンの事を考えるとどの程度で調整すべきか
いつも迷います。

>  きっとSolidさんは、斜めラインルーチンを誤解しています。Solid
>さんは、「斜めラインルーチンはバッファへ斜めの点を打って、その
>バッファをflushしているだけだ」と思われているのでしょう。違いま
>す、全然違います。

これは誤解といえば誤解なのですが・・・
当初 lib_drawlineがラインに対応していない、(VRAM直の代わりに)
グラフィックボックスを用意、ライン関数を用意・・・
という流れで来れば、グラフィックボックスのバッファへのライン関数だと
思ってしまうのが普通かと・・・私だけかも(笑)

tetra01を新ライン関数に書き換え、実行してブロック転送していない事
には気がつきました・・・(test014のソースから予想できましたが)
でもこれは lib_drawlineが lib_drawline0となって(正確には違いますけど)
ラインに対応したもので、グラフィックボックスの利点のひとつである
ブロック転送によるチラつきの低減が使えないのが残念です。
(もちろん lib_drawline0が有用なものである事に間違いはありませし、
問題になる事もありません)

誤解(勘違い)も解け、比較自体が無意味になってしまいましたけど、
tetra01を上げておきます、フレームレートは 16FPSに合わせてあります。
CPUパワーが変動しないように回転はさせていません(演算、描画はそのまま)。
tetra01o.binが flush方式、tetra01n.binが line方式です。

http://www.geocities.co.jp/SiliconValley/1157/tetra01t.lzh

今回のようにライン数が少ないものでは(オーバーヘッドや消去の関係で)
ブロック転送よりもライン関数の方が有利な事は分かっていましたのから、
旧来のライン関数の時に考えたチラツキを抑える方法を、時間がある時に
試してみたいと思います。
昨日は１０時以降(他の多くの人と同じように) TVに見入っていましたので、
何もできませんでした(一昨日は台風で同様でしたので寝不足です)。

プログラムの実行速度はケースバイケースなので、色々な実現方法が
用意されているとありがたいです。
最近ではハードによっては VRAM直よりもシステムメモリの方が速かったり、
アクセラレータよりも CPU演算の方が速いとか、CPUのアーキテクチャに
よっては、昔ながらの固定小数点やテーブル展開よりも FPUに任せた方が
速いとか、マシン依存で速さのポイントが変わるため、処理によっては
最適化が難しいものもありますね。
(そのため DirectXのゲームなのでは、選択方式になってます)