Honeycombのエディタ部であるwxStyledTextCtrlの設定をいろいろといじっていたのだが、どうもUnicode化する際に色々と手間のかかる仕様らしく、あれこれと調べまわる羽目に。

wxStyledTextCtrlをUnicodeに対応させるためにはwxUSE_UNICODEをコンパイル時にdefineしてやらなければならない。これを定義すると、そもそもTextCtrlの方がUnicode化するので後々操作が楽。その後デフォのwxStyledTextCtrl::LoadFileはUTF-16やUTF-32には使えないのでLoadFileをオーバーライドする。

どういうわけかwxUSE_UNICODEを利用しているにも関わらずchar型でテキストを読み込もうとしている。これはUTF-8しか使えませんということなのだろうか…
バッファとして用いているwxStringのコンストラクタでは*wxConvCurrentを指定しているので、ロケールをそもそもUTF-8にしないとUnicodeを利用するのは無理そうだ。

というわけで、ファイルをバッファに読み込むのは独自に実装するとして、

SetText(バッファ);
EmptyUndoBuffer();
SetSavePoint();

でエディタにバッファを投げ、アンドゥ・セーブポイントを初期化。
InitializePrefsでStyleを拡張子に合わせてセットしてスクリーンショットのような状態まで持っていった。

うーん、なかなか。

Honeycombの設定ウィンドウを、PreferenceDialogから派生させたToolPreferenceDialogで実装し、基底部分のみを継承させて使い回せるように変更してみた。

ダイアログ右と左のSizerの周りの枠の部分だが、これはSizerのGetSize()とGetPosition()を利用して、EVT_PAINTでOnPaintを捕捉後にwxPaintDCで描画している。
初めは、どうやってSizerの周りに枠を描こうかと悩みに悩んだが、結局この方法が一番楽なのでそうした（多分、これ以上に楽な方法は無いと思う。Bolderの色の変更など、どうやってやったらいいのかわからないし）。

ただ、これだとwxCLIP_CHILDRENをスタイル指定しているにも関わらず、どうしても表示がちらつく。どうやったらこのフリッカを防止できるのかが今後の課題になりそうだ（もし、設計からやり直しだとつらいなぁ）。

どうもwxWidgetsをwxUSE_UNICODEでコンパイルかけると、MinGWのgettextでは上手くいかないようなので、とりあえず他にwin32プラットフォームにポーティングされたgettextが無いか調べてみた。
で、発見。

http://sourceforge.net/projects/gettext

koronさんがポーティングしたこのWin32版gettextを利用してpoファイルを作成、テキストはutf-8、charsetもutf-8にして保存し、後は_()でソース内展開してみた。昨日の_GT()は使わない。

そうしたら、すんなりと日本語化できてしまった…原因はgettextだったんだろうか。

むむ、とりあえず結果オーライってことで。

大分と形になって来た。Project関係をもう少し煮詰めた上でHornet.exe、ALink.exeとの連携を上手くやればなかなかのIDEになる。

ただ、エディタ部をどうやって煮詰めて行くかが問題。インテリセンスのようなコード補完機能をどうやって作るか。
wxWindowを枠無しで生成した後でそれにwxComboBoxを付けて、内部にあるオブジェクトリストを表示させる。
リストの表示までは簡単だが、問題はリストをどうやって作り、エディタの編集に同期させてどのように更新するか。
この部分のアルゴリズムを練らなきゃだなぁ。

とりあえず、SDL_kanjiのベンチもやってみた（SDL_kanjiのSJIS->JIS変換にバグがあって、回避するのが大変だった）。

今回は、
1.フォントサイズは16
2.N=1000
3.AthlonXP2000+の環境で、SDL_ttfの結果と比較
4.レンダリング先サーフェースは32bpp

とした。

とりあえず、結果からはSDL_kanjiは、SDL_ttfよりもレンダリング済みフォントの生成速度はほとんど同じ（大体5us程度の違いしかない）。

自分は、レンダリング済みフォントの方がサーフェース生成のための速度は速いんじゃないのかと思っていたが、意外とそうでもなかった。
多分、ベクタデータがレンダリング済みフォントのデータよりも容量が小さいため、メモリへの読み取りアクセス数がレンダリング済みフォントデータの時よりも減り、ベクトルデータをラスタライズする処理とレンダリング済みフォントデータを読み込む処理に掛かる時間が相殺した結果、ほぼ等しい処理時間になったんじゃないかと思う。

SDL_kanjiはSJISの変換には問題があることが露呈したので、それが修正されない限りは使うのは控えた方が良いかもしれない（ただ、半角カナ文字や一部のSJISコードを使わなければ通常の文字表示なら実用に耐える）。
個人的には、BDFよりもTTFやOTFの方が扱いが楽だし、安定性やサポートもSDL_ttfの方が良いからSDL_ttfを推すけど、まぁ使いやすい方を使えばそれでよいかと思う。

SDL_ttfに関して、http://diarynote.jp/d/35749/20051112.htmlに書いた通りベンチマークを行って性能テストをしてみた。

条件を以下に示す。
1．テストにはAfter X-TT ProjectのFS-Gothicを利用する。
2．フォントのラスタライズ・ピクセルデータの生成・ピクセルデータの破棄の一連の動作を、「フォントの描画処理」と定義する。
3．今回は、一つのフォントの描画処理にかかる時間を評価対象とする。
4. フォントは24ポイントのものに限る。
5. ラスタライズするのに使う関数はTTF_RenderUNICODE_Blendedを用いる。
6．OSは、手元にあるWindowsに限る。

計測に用いるタイマーの精度が1(ms)であるため、もし1回の描画が1(ms)以下で終わってしまった場合には、描画速度が計測できない。そこで、今回はN回描画と生成を繰り返しすことで、1(ms)以上描画に時間がかかるようにNを設定し、そのデータをNで割ることでタイマーの精度を超えた計測を可能にする。
また、測定データに対してN回同期加算を行い、同期加算回数で正規化することで、測定に影響するような外乱に対して√N倍の精度で測定が行えることが保障されている。そのため、外乱はたいした問題ではない（ただし、変化しない、例えば常駐ソフトなどによるコンスタントな外乱や、真の測定データに対して大きすぎるデータの変化は問題となる）。

7．同期加算回数はN=100とする。

測定データを示したグラフの縦軸はフォントデータのラスタライズとBlendedピクセルデータの生成（アルファチャネルにラスタライズデータの描画）にかかった時間（ms表示）、横軸は文字コードを示している。

結果から考察できることを列挙する。

1．Celeron 733MHzやMobile Duron 900MHzでは常駐ソフトが起動していた。そのため、描画にかかる時間は他の場合に比べて急激に上昇している（常駐ソフトの影響は大きい）。
2．2.以外の場合ではフォントの描画には平均して0.1[ms]程度しかかかっていない（AthlonXP2000+においては30[us]程度でフォントの描画処理は完了してしまう）。

通常、文字生成はリアルタイムで行えることが望ましい。画面のFPS=60の際、1FPSの処理時間に対してフォント描画処理が占める時間的割合を計算すると

0.1/(1/60*1000)=0.006=0.6[％]

従って、たった0.6[％]となる（ただし、これは1FPSに一文字生成する場合に限った結果である。文字間の表示ウェイトは10〜20[ms]であることがほとんどなため、1FPS(16.777...(ms))で1文字表示ちという計算が妥当であると判断した）。1FPSに100文字描画しなければならない場合は、10[ms]かかることになる。この場合

10/(1/60*1000)=60[％]

となり、リアルタイムで100文字生成は難しいことがわかる。

もし常駐ソフトが起動していた場合は、平均して約0.5[ms]フォント描画処理にかかるとすると

0.5/(1/60*1000)=3[％]

となる。経験上、1FPS中の3[％]の処理にかかる割合は大きい（ここにリアルタイムでの画像処理や楽音信号の処理が入ってくるからだ）。従って、常駐ソフトは起動しないことが望ましい。

今回のテストで大体わかったが、SDL_ttfを用いても描画速度的には全然問題無い。一応、次はSDL_kanjiを用いてやってみようと思う。

ようやく見ました。長かった。世間では恋人たちが公開されていますが、こっちは、それどころじゃないですね（苦笑

いやー、始めは昔のまんまの絵で出てきたので、昔のフィルムをデジタル処理して補正かけてノイズとったのだとばかり思っていたんですが、新作カットやストーリーの変更などもあるんですねー。
確か、オリジナルでの15話分くらい詰っているんで、時間にして25*15=375分分の内容が90分に詰っているわけで、確かにそりゃストーリーの変更も必要になってくるわな…と思いました。

が、いくらなんでもこれは飛ばしすぎだろと思ったのは、百式がいきなり配備されていたり、MarkIIのカラーが勝手に塗り替えられていたり、エマ中尉に30バンチのG3ガスによる虐殺を見せるのがノートパソコンでの映像だけだったりした点でしょうか。

あと、ライラやシロッコ、ロザミアとの戦闘なんかは新しいカットが沢山入っていて面白かったんですが（MSの戦闘はすごい綺麗になっていますね）、これだけやるんだったら、他の部分も全部書きなおしゃよかっただろうにと、全体としては不満が残るようなできでした。なにせ、オリジナルと、新作のカットの差があまりにもありすぎて、不自然だ！と思うんですけどね。

まぁ、Zは面白いので我慢します。恋人たち、早くDVDで出ないかなぁ。

なんか、それっぽく形になってきているので、とりあえずインポートしてみた。

これからディテイルは詰めてゆく。

自分としては、プロジェクト管理と、デバッグ機能がつけばそれでもう十分かもと思っている。それ以外に、何を付けれというのか。ネットを介した他IDEとの同期？そんな馬鹿な（苦笑

というわけで、とりあえず今後のロードマップは

11月中 Honeycomb完成、セットアッププログラムに組み込んで、Hornet使って遊べるように。
12月 4号館物語完成、配布開始
12月 闇色童話製作開始
1月 セネカ製作中盤
2月 セネカ完成、配布開始
4月？ 闇色童話完成

ちなみに、前のサークルのお狐様にお願いを、オーバーホールして、こっちのサークルで作成、TEARS.様に還元したい次第（大汗
ごめんなさい、浅葉さん。クロスプラットフォーム対応には、2年かかりました。

ちなみに、セネカは深海喫茶のリョウさんとの共同。かわいい絵を描いてくれる素晴らしい方！うっれしーなーっと。

HornetのソースをCVS管理するためにリポジトリにインポートした。結構遅くなったが、これならまぁ、出しても良いだろうということで、とりあえずインポート。

しかし、総ファイル数が117と、やっていることはそれほどでもないにも関わらず、やはり多い。実際にいじるのはScenarioLoader.*ppとスクリプトシステムフォルダ内程度だけれども、やっぱりもう少し短くしたいと思うのは自分だけなんだろうか。

一応、今日は文字コードがどのようにアプリケーション内で流れるかをまとめてみた。

とりあえず、Hornet用テキストエディタではwxStringがwchar_tに依存するのでUTF-32かUTF-16をUTF-8として保存。これはバイトコードを見ればすぐに変換可能。
その後、UTF-8として保存されたものを、Hornetで再度wchar_tへ変換。SDL_ttfでは入力はUTF-16限定なので、もしかするとこの辺は柔軟性を考えてFreeTypeを直接叩くようにするかもしれない。そうすれば、wchar_tのサイズによってFreeType側で調整できる。
スクリプト側には、wchar_tのデータを送り（もしLuaならばUTF-8に変換して送る）ファイルパス指定の場合のみローカル文字列、もしくはUTF-8をそのまま使用する。

そうすると、何回もHornet内で文字コード変換しないとだめなんだよなぁ。まぁ、今の処理速度から考えると文字コード変換なんか全体の処理に対しては微々たるものだろう。