過去の独りごち/独りごとはこちら
過去のJavaアプレットは
こちら

 

9/16 秋、まだ秋じゃない

 最近は果物が美味しくて。

 近所のスーパーの前に農家の人がやって来て安価に売ってる物を好んで買っているのですが、これがなかなか。今の時期は桃・梨・葡萄かなぁ。もう暫くしたら栗も良い。

 値段自体は一回買うと200〜600円くらい掛かるので、食材の値段としてはバカにならない金額ですが、2〜3日くらい食べつづけられるのでジュースや菓子を消費するのに比べると幾分経済的だと思います。今日は箱入りの巨峰を1kgで600円。3日ってところか。

 なにより、包丁で梨むいて食べる独り暮らしというのも乙なものではないかと(^^;)

 ホームページアプレット、ほんのり高速化しました。

 20%ほどの高速化…

 はて。

 20%高速化という言い方では一体何に対してどう20%早くなったのか、よく分かりません。というのも、そういった場合、以下の2通りが考えられるからです。

  1. 1フレームあたりの平均処理時間が前より20%短縮された
  2. 単位時間あたりの描画フレーム数が20%向上した

 今回の場合、1の事を指しているのですが…

 1の場合、以前まで10fpsだったら、1フレームあたり0.1秒掛かっていたことになります。新しいバージョンではそれが20%短縮されて0.08秒、つまり、フレームレートは12.5fpsになります。

 2の場合、10fps→12fpsになるわけですね。

 つまり、1と2では結果が違うのです。20%程度ではそれほど顕著な差にはなりませんが、仮に、単位時間あたりの描画フレーム数が2倍になったとしましょう。この場合、先の表現1,2にあてはめると

  1. 1フレームあたりの平均処理時間が前より50%短縮された…50%の高速化
  2. 単位時間あたりの描画フレーム数が100%向上した…100%の高速化

 …単に高速化と言った場合の数値が全く違います。

 よって、安易に高速化という言葉を使って、数値を出しちゃだめなんです。フレームレートが何%上がった平均処理時間が何%短縮された、と言わないと分からないんですね(^^;)

 そういえば、パーセンテージに対する相対値を出すとき…例えば、5%→8% という変化を+3%の変化と言ってはいけなくて、+3ポイントの変化と言わなくてはならない、と怒られている人が居た事を思い出しました。

 ふむ。

 SXLibの拡張工事の妨げになるという理由から、Diablo IIをアンインストールする昨今です(ぉ

 さてさて、SXLibの目下の作業は…ごく当たり前だけど今の今までサボってた事ですm(__

  1. 半透明体の描画順序を意識する
  2. ビルボードを置けるようにする
  3. 画面上の2Dな座標から、フレームを返すメソッドを作る
  4. 3に伴って、フレームに当たり判定を付けられるようにする

 1について、半透明じゃなくて、加算・減算に対してだけ破綻の無い描画ができればまあいいかな、という程度で、さらにポリゴン単位でなく、メッシュ単位で描画順序を正すつもりです(^^;) それでもそんなに困ることは無い…でしょう。困るケースが出たら対処します(ぉ

 2について、実装の方法が結構悩みどころです。「フレームの座標→画面上の座標」なメソッドを作って、あとはPrimitives使ってね…というのが一番スマートかなぁ…と。

 3、4について、これは主にモデラとかを作るのに欲しくなりがちだと思いますが、SXLibはツール類への利用を全く考えていなくて、それが証拠に平行投影の事をちっとも考えてません。

 

 そういえば、平行投影は遠くのものでも近くのものでも同じ大きさに描画するような視界ですね。僕らの視界は、一般に遠くのものほど小さく見えます。

 逆に、遠くのものほどデカくみえる視界というので画面を作るとどうなるんでしょうね(^^;) 視野ピラミッドの手前を太くして、奥をすぼめれば良いだけなので、実装は容易そうです。

 …やってみるか

 こうしてSXLib拡張計画は脱線しまくり〜

Taku Hayase(SANDMAN)

戻る