draw_text 高速化 その2

前回、
「デフォの draw_text は自動縮小がめっさおせぇ」
と書いたけど、アレはやっぱ綺麗に縮小されてるのと関係が
ありそうな、そうでもないような。
その辺大して考えずにやってる na と fast の糞画質に比べて、
割と綺麗に縮小してるっていう。

一応、縮小に関してはもう少し綺麗にする余地というか
ネタというか、そんな感じのものがあるので、描画速度が
ガタ落ちしなければバージョンうｐするかも。

しかし、GDI+ の DrawImage はやっぱ遅い。
VXTilesetTool のロードが遅いのもだいたいこいつのせい。
一応、Bitmap 生成時の PixelFormat を 32bppARGB から
32bppPARGB にするだけで劇的に速くなったりするので、
もしかしたら他にも高速化できる要素があるのかも試練。

---

せっかく Wii があるので、何か Wii ゲーを買いたい今日この頃。
現時点での候補はアークライズ、トワプリ、スマブラあたりか。
MH3 は、PS2 版を見た限りではどうも性に合わないのでパス。

プレイした中では、↓この2本が神。
Wii のグラはショボいって言うが、実際にやってみた限りでは
「ほんとかよ？」と言いたくなる罠。

・・・うちの TV がブラウン管だからかもね！

draw_text 高速化

ヤター draw_text 高速化デキタヨー
ついでに縁取りも入れてミタヨー

↓クリックで原寸表示

上から
　・ 通常の draw_text
　・ draw_text_na （ノンアンチエイリアス）
　・ draw_text_fast （高速 draw_text）
　・ draw_text_na 縁取り
　・ draw_text_fast 縁取り
の順で、いくつかのフォントで表示してみた。

次に、描画速度。
　1. 影なし
　2. 影あり
　3. 影あり & 縮小
　4. 縁取り
　5. 縁取り & 縮小
という条件で、

# 縮小なしの場合
(1000).times { |i|
  bmp.draw_text(0, 0, 200, 24, "RPGツクールVX")
}
# 縮小ありの場合
(1000).times { |i|
  bmp.draw_text(0, 0, 24, 24, "RPGツクールVX")
}

こんな感じの処理にかかる時間を draw_text, draw_text_na,
draw_text_fast それぞれに対して 10 回計測し、
平均を出してみた。
（縁取りのみ draw_text は除外）

↓クリックで原寸表示

単位はミリ秒。バーが短いほど速いという意味。
draw_text_na, draw_text_fast 共に draw_text に勝利。
縁取りしても draw_text より速いので、ゲーム中の
全テキストを縁取りにしても問題なさげ。
テキストを描画先のサイズに合わせて縮小する場合でも、
draw_text に比べて処理時間の増加がかなり小さいので、
多くの場面で高速化が期待できそう。
（メモリ消費量は比較していないので不明）
それにしても、縮小時の draw_text の遅さは何なのか・・・。

問題点は、欧文フォントが draw_text よりでかめに出るとこ。
でかいとは言っても、日本語フォントと同じくらいのサイズに
なるだけなので、そこまで大問題ではないのかもしれないが、
欧文フォントを多用する場合は気になるかも。

ノンアンチエイリアス on RGSS

XP/VX の文字に自動でかかるアンチエイリアスを無効化
できたら面白いYO!!

というネタをいただいたので、早速試してみた。
↓大体こんな感じ（クリックで原寸表示）


左が普通の draw_text で、右がアンチエイリアスせずに
描画したやつ。
実際に見てみると、これはこれで味があってなかなか
いいかもしれないぞ Σd(・∀・ )
難点は、Ume Plus Gothic みたく Bitmap フォントが
埋め込まれていない(?)フォントは汚くなるということか。
さすがにこれは仕方ないということで・・・。

ちなみに、前に出したクリッピング描画 (clip_blt) と似てて
DLL を介して GDI+ の Graphics::DrawString を呼び、
RGSS の Bitmap に無理矢理描くという力技です。
厳密には、クリッピングは描画に GDI を使っているんですが、
今回は TextOut や DrawText がちゃんと動かなくて涙目な
感じになっていたので、GDI+ で。
どう見ても妥協です。本当にありがとうございました。
でも GDI+ の方が新しいし多機能で扱いやすいんだZE
（GDI より多少遅いらしいけど）

ただ、GDI+ を使ったおかげで、副産物として色々できるように
なった気がします。
↑の画像で言えば、テキストに縦方向のグラデーション（薄い青）
がかかっているのがそれ。
他にも、テキストを斜めに描画したり、綺麗な縁取り文字を
描画したり、色々できそうな予感。

オラなんだかワクワクしてきたぞ。

久々に開発記らしい記事を書いた気がするが・・・。
たぶん気のせいだ。ということにしておこう。

キャッシュ機構-2

巷で噂のドロリッチ飲んでみました。

・・・うめぇ！

---

さて、前回キャッシュの仕組み（と言うか何と言うか）について
掲載したので、今回はキャッシュの実装方法について少々。

能書きの前に、まずは実装例をどうぞ。

# ** データ作成
def create_data
  # ～ 時間のかかる処理 ～
  return result  # 作成したデータを返す
end

# ** データ取得
def data
  if @__data == nil        # キャッシュがなければ
    @__data = create_data  # キャッシュを作る
  end
  return @__data           # キャッシュを返す
end

data メソッドでは、
　・ @__data という変数が nil の場合、作成したデータを
　　 @__data に格納し、@__data を返す
　・ @__data が nil でなければ、そのまま @__data を返す
という処理を行います。
つまり、@__data がキャッシュとして機能するわけです。
（変数名の頭に __ が付いているのは個人的な趣味です）

この処理のポイントは、Ruby の
「未使用の（代入していない）変数は nil」
という仕様です。
@__data に何も入っていない（キャッシュが作られていない）場合、
@__data は nil となるので、この場合にキャッシュを作成して
あげれば良いわけです。
一度キャッシュを作れば、以降 @__data != nil となるので、
二度目以降はキャッシュ作成をスキップするようになります。

ただし、この方法は
「作成した（キャッシュに入る）データが nil を取り得る」
場合にはあまり適していません。
（キャッシュが nil の場合、毎回キャッシュ作成ルートを通る）
こうした場合には、キャッシュの判定を少し変えてあげます。
例えば、

def data
  unless @__data_cached
    @__data = create_data
    @__data_cached = true
  end
  return @__data
end

こんな感じで、キャッシュ作成済みというフラグを作ってみたり。
（nil は偽なので、unless nil は成立します）

キャッシュ機構

なかなかサイトに手が回らないので、Blog だけでも。

たまに
　スクリプトで使ってる「キャッシュ」がよくわからん
というご質問があるので、これについて少々。

まず、簡単に一言で言うと「使い回し」です。
一度作ったデータをとっておいて、後から使うときに楽しましょう、と。

んなこと言われてもいまいち実感できん、と言われそうなので、
簡単な例を。

---

・データの作成に 100 秒かかる
・データを返す（要求元に渡す）のに 1 秒かかる
という条件のもと、同じデータを作成して返すという処理を
キャッシュの有無で比較してみます。
（単純に 3 回実行し、平均時間を出してみます）

　< 毎回データを作成して返す（キャッシュなし） >
1 回目： 100 + 1 = 101 秒　（データ作成 + return）
2 回目： 100 + 1 = 101 秒
3 回目： 100 + 1 = 101 秒

平均： 101 秒

　< 1 回目のデータをキャッシュし、2 回目からキャッシュを返す >
1 回目： 100 + 1 = 101 秒　（キャッシュ作成 + return）
2 回目： 1 秒　（return のみ）
3 回目： 1 秒

平均： 34.3 秒

---

キャッシュの効果が一目瞭然です。
回数が増えれば、さらに効果が大きくなります。

ただし、どんなデータにもキャッシュが使えるかというとそうでもなく、
例えば「頻繁に変化するデータ」には使えません。
（実際のデータは変化するのに、毎回同じ値を返しちゃまずいですね）

ゲームのように、同じデータを使い回すことが多いアプリには
極めて有効です。
「ゲームの動作が重い」と感じる場合は、キャッシュできそうな
データを探してみると良いでしょう。