何人かの方からご意見を頂いたのですが、KAG4はTJSでアプリケーションを作るときに、便利な「部品」として使えるようなコンポーネントライブラリみたいになるかもしれません。主用途はアドベンチャー・ノベルを作るための物です。

存在の主旨や用途が現在のKAGと違うので、別の名前が良いのではないかという意見をsugi氏からいただきました。というわけで名前をKAGじゃなくするかもしれません。名前は何にしましょうかね。無駄に女の子の名前をつけて多方面からヒンシュクを買ってみるとか。

よほどそのコンポーネントライブラリとそれを使ったゲームシステムが充実して、KAG3を使う意味が無くなれば話は別ですが、現状では便利なKAG3が無くなることは無いと思います。

TJS2の後置の!演算子は文字列を式として解釈・実行する演算子ですが、現在こいつがglobalコンテキスト上で式を実行するのを、thisコンテキスト上で実行されるように、そのうち仕様変更しようと思います。

もうそろそろKAG4を考えています。全く画策段階ですので細かいことは決まっていませんが、KAG4はKAG3との互換性を捨てることは確かです。ただし、吉里吉里２の上で動くことと、いままで通りKAG4自体がTJSで記述される点は変わりありませんし、KAGParserはC++で書かれることも変わりありません。

KAG内部の構造は大きく変わるとおもいます。今は大まかに「吉里吉里」「KAG」と分かれていた層がもうすこし分かれるかも知れません。コンポーネント化も進めます。もしかしたら「標準機能もすべてプラグインの集合」、みたいな感じになるかも知れません。

生のKAG4は細かい単機能の集合体の層(おそらくTJSのメソッドの集合)、それともう一つ、その単機能の層をまとめて使うための層(これもTJSのメソッドだが、KAGのタグ一つ一つに対応する物)に分かれるかもしれません。後者を作り替えることにより、そのゲームにあった命令セットを作れることになると思います(ただ「KAG3のマクロ」に相当する機能は引き続き搭載する予定)。

現状のKAGが、作られるゲームの種類をあまり特定していないが為に「汎用性は高いが煩雑な仕様」であるのに対し、KAG4は、「作成されるジャンルを限定するが単純な仕様」となるかも知れません。その仕様を超えた複雑なもの、たとえばモグラたたきのようなミニゲームの類や、マップを表示して移動先を選択するような機能は、KAGの機能を使わずにTJSで記述して頂くことになるかも知れません。

シリアライズをしっかりと行う為、ロード時にセーブ時の状態をほぼ完全に復元でるような機能を予定しています。すなわちセーブポイントを指定しなくても、セーブ・ロードはシステム側が面倒を見る、ということになります。もっともこれは、現状のKAGがラベルを基準にしている為にシナリオの変更に強い(たとえばリリース後にパッチを配布してシナリオを変更しても前のセーブデータを使える)という特徴も捨てがたいので、折衷案を考えます。

レイヤに複雑な描画を行ったりした場合は状態保存が面倒になる為、セーブデータ中にレイヤ画像を直接保存する場合があるかも知れません。セーブデータが大きくなりそうで心配かもしれませんが、もちろん通常では、現状と同じくそのレイヤにどの画像がロードされただとかの情報にとどまるので大丈夫だと思います。画像をセーブデータに含めるようになるのはTJSで直接描画しただとかに限られると思います。

KAGParserは吉里吉里用のプラグイン化をして、吉里吉里本体の外に出します。

シナリオが大規模になってくると支援ツールが吉里吉里/KAG以外に必要になります(私が作るとはかぎらないのですが・・・)。たとえば「次の選択肢までジャンプ」のような機能は、「次の選択肢」を探すなんてのは吉里吉里/KAGで探すと時間もかかりますし非効率的です。こういうのは「支援ツール」のような別のソフトなどであらかじめ探しておけば良いと思います。KAG4は構造が単純になると思うので、このような「支援ツール」との連携もとりやすくなるのではないかと思います。いろいろ考えています。よろしければ是非掲示板やIRCでご意見をください。

レジストラの登録画面でDNSの設定変えたら、なんかよくわからないエラーが出てたようですが、設定はめでたく反映されていたようなのでよし。

あと１日ぐらいの間は、旧DNSサーバの間違った情報をクライアントに伝えてしまうようなDNSサーバもあるかもしれません。ご迷惑をおかけしましたが、今度は安定しそうです。

まだジャパンレジストリから返事ありません。今日で土日に突入したので、返事があるとすれば月曜以降か…。

ちなみに「ドメイン廃止取り下げ依頼書【特殊依頼】」ってやつですが、一度問い合わせた時点では「kikyou.infoの有効期限が切れるまで１ヶ月ほどたってから再度取得してください」という返事でした。「有償でもいいからなんとかしてくれ」と二度目の問い合わせで出てきた書類です。まあドメイン使用料を払い忘れた自分が悪いわけですが、もうちょっと対応よくして頂きたいですね。

TLG6の圧縮率テストです。対象は手元の800x600の画像1,233枚(ほとんどがゲームの背景画像)に対して圧縮を行ってみました。

2006/11/24 PIC2の結果を追加

2007/4/18 WDPの結果を追加

2007/12/14 TLG6圧縮アルゴリズムのバグを修正した版での結果に更新

2007/12/20 PAQ8O8 の結果を追加

これらの画像はTLG6のトレーニング(各種テーブルやフィルタの調整)に使われたので、これらの画像で圧縮率が高くなるのは当たり前かも知れません。

PAQ8O8 はすごい。このオプションでは圧縮時に800MB以上メモリを食いますが(展開時も)。どうしても圧縮率を上げて保存したい場合はなかなかよい選択肢かもしれません。

ERI32はACT(Archive Comparison Test)のDOS/Windows Compression Tests, GRAPHICSでトップにあったので比べてみました。ちなみにACTにおいてあるサンプルではトータルでERI32やERIより劣ります。ACTでのサンプルにおいてTLG6の苦手なのはWaterloo Repertoire ColorSetというところにあるartisticとなっている画像です。予測が派手にはずれまくるサイケデリックな画像です。前の日記でTLG6は「ノイズの少ない人工的な画像に適しています」と書きましたがやはりこれもモノによるようです。

上の表のTLG6の備考で「ロスレスモード、最高圧縮率」と書いてありますがTLG6は実験的にnear-losslessモード(準ロスレスモード)を作りました。R G B 各成分が +1 あるいは -1 されるかも知れないけど圧縮率を稼ぐモードです。劇的にサイズが小さくなることはありませんが、10%ほどは小さくなるようです。

圧縮率指定は圧縮時の時間短縮のための機能です。圧縮時の時間が短縮されるだけで展開速度が速くなるわけではない(逆にデコードすべきシンボル数が増えるので遅くなる)のであまり意味がありません。

どちらもデータ形式に違いはなく、圧縮側のアルゴリズムの変更だけで対応可能です。あまり使わないかな、と思って画像フォーマットコンバータにはnear-losslessモードや圧縮率指定機能はありません。

圧縮にかかる時間はTLG6がもっとも時間がかかります。展開速度が速ければよいし、圧縮なんてコンピュータがしてる間は人間は寝てればよい、という考えなので、圧縮についてはあまり高速化してないです。

…何となくTLG6は吉里吉里だけに使うにはもったいないと思い始めてみたり。

以前にドメイン使用料未払いで取り消されそうになったkikyou.infoですが、今度はDNSのトラブルです。現在 kikyou.info ではセカンダリ DNS に、フリーのサービスを利用していますが、ここのサーバのうちの一つ (ns2.granitecanyon.com) が kikyou.info に対して 127.0.0.2 を返すため、場合によっては kikyou.info にアクセスできないという状況が続いています。

で、このイカれたns2.granitecanyon.comをはずそうと、レジストラ(ジャパンレジストリ) で設定変更を3/24にしたはずなんですが、いまだに .info を管轄しているネームサーバの登録情報に反映されていません。自分もあんまり DNS まわり詳しくないのですが (dns.kikyou.info の zone ファイルからまだ ns2.granitecanyon.com が抜けていなかったのにさっき気づいたぐらいで )、これってそういうものなんですかね。レジストラの説明では「72時間ほどで反映」とのことですが。

一応ジャパンレジストリの方には、3/31の昼に問い合わせていますが、未だ返事がありません。「TV/CC/TO/INFO/BIZドメインと日本語ドメインは、現在ドメイン移管できません。」と書いてありますが、しかし、それにしても思うように対応をして頂けないので、移管を考えています。ゴネないとだめですかね(ゴネるの好きじゃないんですが)。ちなみに前にドメインを取り消されそうになったときに「ドメイン廃止取り下げ依頼書【特殊依頼】」という書類を提出して手続きしましたが、このとき２万円かかりました。

皆様にはご迷惑をおかけして申し訳ありません。とりあえず信頼できるお方にセカンダリDNSを担ってくださるようにお願い致しましたが、レジストラで設定変更しても反映されないんじゃどうしようも・・・。

TLG6ですが、これをサポートした吉里吉里２ 2.21 beta 3 を公開しました。

以前の日記でJPEG2000可逆の圧縮率を上回る、と書きましたが、誤解のないように書くと、もちろん処理する画像によってはJPEG2000の方が優秀です。やっぱりアルゴリズムが単純なせいか、TLG6はCGのような、ノイズの少ない人工的な画像に適しています。写真などではJPEG2000の方が勝る場合があります。

デコード側の処理量を抑えたままで、いかに高圧縮率を達成できるかが鍵でした。TLG6では展開速度を稼ぐために算術符号の類や直交変換系を使ってません。算術符号はうっかりすると特許関連が面倒そうですし。

たとえばサイズ800x600のあるCGでは、JPEG2000では522KB、TLG6では464KBになります。デコード速度はJPEG2000の場合は約800ms、TLG6の場合は約46msになります。ちなみにERI(可逆、拡張フォーマット、最高圧縮)では524KBになります。

JPEG2000の展開って本当にこんなに遅いんでしょうかね。マシンはPentium M 900MHzのノートで、使っているライブラリは JasPer で、gcc 3.3.1 (Cygwin) で -O2 -mcpu=pentium4 -march=pentium4 -fomit-frame-pointer -frename-registers のコンパイルオプションにてコンパイルしたものです。TLG6 デコーダの方は bcc ですが、展開のコア部分はアセンブラで SSE 対応コードが載っています。でも JasPer の最適化が進んでいないだけだとしても、TLG6 との 17 倍のデコードスピードの差を埋めるのは難しいのではないかと思います。

同画像はTLG5では760KBほどになりますが、TLG5は約25msでこれをデコードできます。TLG5は速い。でもTLG6も十分実用範囲だと思います。

PNGではoptipng(PNG最適化ツール)でサイズを最適化しても626KBになります。デコードも、吉里吉里にのっかっているMMX化されたPNGデコーダでも110msほどかかります。TLG6は、(吉里吉里で使う分には)デコード速度と容量面においてPNGの代用として十分なものであると思います。

以前の日記ではMEDを使うと書きましたが、場合によっては左と上のピクセルの平均(平均法)から予測したほうが効率がよい場合があるので、8x8に分割されたブロックのうち、平均法の方がよさそうならばそちらを使うようになりました。結構満足のいくものになってきたのですが、とりあえずは吉里吉里に組み込むだけで、単体のライブラリとして公開するなどの予定はないです。気に入ったら適当に(適切に)引っこ抜いて使ってください。

すみません、去年のネタがこのサイトで発動してました。4/1に発動するように仕掛けていましたが、去年以降スクリプト変えてなかったです。やるつもりはなかったんです(笑)。ちなみに去年のネタというのは「ブラクラ」と呼ばれたエイプリルフールネタでした。

今年は忙しくてネタの用意のしようがなかったので、なにもやりません。