W.Deeの日記

2008年10月11日 - レジスタマシンとスタックマシン

2008-10-11

http://d.hatena.ne.jp/unagi127g/20080811

あーと、なんでTJS2がレジスタマシンかというと、最初はネイティブコードへのJITterをつける予定だったので、あー、こっちの方がJITterの実装が楽そう、と思ってのことだったと思います。結局JITterはつけずにバイトコードインタプリタを積んだだけでしたが。なので元々あれはネイティブコードを吐く前の「中間形式」でした。ソースコード名に「Intermediate」という単語が混じってるのがあるのはそれの名残りです。

ちなみに他にレジスタマシンなのはParrot VMとか。LLVMは中間形式(SSA形式ですが)を実行するバイトコードインタプリタがレジスタマシンですね。

TJS2のVMのモデルとしては、ローカル変数も、計算中の一時変数もすべてレジスタとして扱うモデルです。すべてがレジスタに置かれるため、スタックや主記憶領域のようなものはありません。

こういうモデルでのレジスタマシンのメリットは、比較的命令コード数が少なくなるということでしょうか。

たとえばローカル変数同士の計算で a = b*c + d*e; とあった場合、レジスタマシンでは

load b
load c
mul
load d
load e
mul
add
storep a

みたいな感じの命令列になると思うのですが、TJS2だと基本的に2アドレス命令形式なので

cp  tmp1, b     // tmp1=b
mul tmp1, c     // tmp1*=c
cp  tmp2, d     // tmp2=d
mul tmp2, e     // tmp2*=e
add tmp1, tmp2  // tmp1+=tmp2
cp  a,    tmp1  // a=tmp1

みたいになります (TJS2はコンパイラはおバカなのであんまり命令コード数減ってないですけど)。実際のバイトコードインタプリタの実効効率がこれで上がるかどうかは実のところ比較したことがないのでわかりません。オペランドの分だけ命令に必要なバイト数が長くなってメモリアクセスが増えるしメモリアクセスの局所性もおそらく減るから、もしかしたら結局はトントンじゃないのーみたいな気はしてます。

Risseもレジスタマシンですが、この場合は内部でSSA形式で簡単な最適化を行ってます。SSA形式はそもそもそれがレジスタマシンに近い表現なので、それをそのままVM命令にしちゃったのが今のRisseのVMという感じになります。

Risseは今のところ3アドレス命令形式なので、上記のような計算だったら、

mul tmp, b, c  // tmp = b*c
mul b, d, e    // b = d*e
add c, tmp, b  // c = tmp+b

みたいな命令が出力されます (最終的な答えは c に入る; b と c に対応するレジスタは以降参照されていないことが分かっているので再利用されている)。

RisseはまだVMの最適化には手をつけていないし、そもそも今のRisseのVMは仮の実装なので、これから先どのような構成になるのかは後で考えたいと思います。最近JavaScriptインタプリタ方面で実行速度戦争がおきてるようなので適当にテクニックを盗みつつ……。

2008年10月7日 - pngnq

2008-10-07

ちょっとまえにPNG画像を減色する必要があって適当な減色ソフトを探していたのですが、pngnqというソフトが目に止まりました。

減色には、よく使われているメディアン・カット法ではなくて、ニューラルネットワークを利用した方法でパレットを決めるんだとか。元となっているアルゴリズムのページ NeuQuant: Fast High-Quality Image Quantizationのテストイメージをみると確かにいいかんじ。

このpngnq、先日よく見るとアルファチャンネルつきインデックスカラーにちゃんと対応してるんですね、これ。こっちのメリットは大きいかも。

2008年10月6日 - Blenderの流体シミュレーション

2008-10-06

トキワ荘からの日記移植。

Blenderには流体シミュレーションがついています。

この流体シミュレーションは格子ボルツマン法(Lattice Boltzmann Method; LBM) といって、セルオートマトンの一種です。

http://graphics.ethz.ch/~thuereyn/ntoken3/ ここの方が開発したものらしいです。

LBMは空間を格子に区切って演算を行うのでメモリを食いますが、液体の量が増えても演算速度が(あまり)落ちないというメリットがあります。32bit windows版だとあんまり大きな空間のシミュレーションはできなかったのですが、最近環境をガラリと全部Linux 64bitにしたんで、メモリたくさん食っても大丈夫な演算ができるようになりましたー。

一方、もう一つの主要な流体シミュレーション法であるパーティクル法では、液体をパーティクルの集まりとして近似してパーティクル同士のモーメントだとか衝突だとかを計算するもので、液体の量に応じて演算負荷がかかります。こちらは物理演算アクセラレータなどで高速な演算ができるようにしたものなどがあるようです。

どっちがいいかは用途によるんだろうなぁ。とりあえずBlenderではLBMだということです。

で、お遊び。

http://kikyou.info/misc/miku.avi

どろどろどろどろどろどろ……

モデルデータはまささんからお借りしました。ご快諾ありがとうございます！

2008年9月28日 - 続:ゲーム開発現場で多くのオレオレ言語が生まれるのはなぜ?

2008-09-28

続:ゲーム開発現場で多くのオレオレ言語が生まれるのはなぜ?

今気づいたんですが、MacOS X のことえりには「吉里吉里」が辞書登録されていますね。吉里吉里すげえ。

岩手の地名ですw

うーん、最適化ですかー。まずそれには現場と対象となるシステムの性質をよく知る必要が有るとおもいます。

一つ例をあげれば、たとえばアドベンチャーゲームのスクリプターに以下のような構文を提案してみたとします。

bg.load("校庭-昼.png");
fg.load("みく-通常-泣.png");
msg("voice-miku-0000.ogg", "ねえ、おきてよー。遅刻だよー！！！");
pause();
msg("voice-miku-0001.ogg", "おきないと遅刻なんだよー！！！");
pause();

プログラマから見ると普通かも知れませんが、まず確実に嫌がられます。特に同人とかだとシナリオライターさんがスクリプターを兼任する場合などありますが、IMEを切る(半角を入力する)ことすら嫌ったりします。

じゃあこんなのどうでしょう？

 ＠校庭 昼
【みく 通常 泣】
「ねえ、おきてよー。遅刻だよー！！！」
「おきないと遅刻なんだよー！！！」

一見言語にすら見えないかも知れませんが、劇的に書く量が減っていることが分かると思います。() も ; もこういうのを書くには不要、どうせ一行ごとにクリック待ちするんだから pause(); 見たいのは不要、どうせボイスは連番なんだからボイスファイル名の記述なんかも不要。こういうのが喜ばれます。もちろん、見た目だってとてもわかりやすい。

ちょっと形式は違いますが KAGEX http://kikyou.info/diary/?200605#i26 で行われている例なども参考になると思います。

tjs2のようなほぼJavaScriptな言語をプログラマーではないスクリプターさんに触らせるのは無理です。ゲームシステムのカスタマイズのために、この様な十分な記述性を持った言語は必要です。しかし某氏の言葉を借りれば「なんでもできる＝なんでもできない」という場合もあります。というのも機能が下手についてると放っておくと勝手につかわれてて後からみるととんでもないことになってて収集がつかないことがあるとか。スクリプターという現場で必要とされているのはもっと単純で、スクリプト記述に特化した、制限のついた言語なのです。

僕は吉里吉里の設計段階で、ゲームシステム記述言語としてのtjs2と、シナリオスクリプト記述言語としてのKAGという二つの階層の必要性に気づいたのはよいですが、KAGはあれでも「いろいろ出来すぎ」で複雑なのが設計ミスでした。KAGEXはそこら辺を改善しようとしているのが見られます。

吉里吉里3はどうしようかなーと考えていますが、アドベンチャーゲームについて言えば、たとえば、シナリオスクリプトの記述にはそもそも制御構文すらいらないんですよね。アドベンチャーゲームの場合、選択肢とシナリオの遷移はこれまた別の言語で管理して、シナリオスクリプト自体は極力機能を最低限に絞った単純な言語にするべきというのが今後の方向かなと思ってます。演出すら分離できればいいなーとか思っていますがそれはちょっと難しいかなぁ。

2008年9月28日 - 吉里吉里2 2.30 安定版 Revision 2 出した

2008-09-28

ちょっとしたバグを修正。

affineCopyで転送先左端が画像の左端にある場合に、左端が1ドットかけることがあるのを修正しました。

それと、どうもDirectDrawドライバ(?)の中には変更可能な画面モードの中に、現在(非フルスクリーン時)と同じ画面モードを列挙してこないものがあるようで、その場合に吉里吉里2が適切な画面モードを見つけられず、フルスクリーン化に失敗する問題に対処しました。なんでこんなんあるんだろうorz

2008年9月27日 - 吉里吉里3の地味な機能

2008-09-27

吉里吉里3の「だからなに？」的な機能の紹介。

tmpfsの内容をアーカイブにして保存できる

tmpfs (いわゆるRAM Disk)の内容をアーカイブにしてファイルに保存したり、そのファイルから復帰させたりができます。書き出される形式は tmpfs 独自のもので、XP4 アーカイブ (XP3の後継) との互換性はありません。なにかあらかじめ用意した素材などを中に入れておく用途かなぁ。用途が浮かばず。もともとはデバッグ用途なんですけど。

tmpfs自体は実体はon memoryなRAM Diskなので、保存をしなければプロセスが終了すると中身は消えます。初期状態では / (ルート) ファイルシステムが tmpfs でマウントされています。

ちなみにセーブデータの保存には tmpfs よりも atomfs(アトミックなトランザクション処理ができるファイルシステム;未コーディング) がよいと思います。

画像エンコード機能がある

いまのところJPEG/PNG/TLG5/TLG6を読み込めますが、すべて書き込み(エンコード)もできます。画像変換ツールや合成した画像を吐き出すツールなどを作る用途に。

stdin/out/err がある

標準入出力や標準エラー出力にアクセスできます。コマンドラインツールを作りたくなったときのため。

ファイルシステムやファイルストリームが Risse オブジェクトである

スクリプトでファイルシステムを拡張したり、スクリプトでファイルストリームを実装したりができます。何に使うんだろうか。とりあえずファイルシステムの名前空間をスクリプトで拡張できるのは大きいことかもしれません。

周辺の開発用ツールとかも吉里吉里３コア(Risa)で作成できることを意図しているためです。一応risa.widgetというパッケージにはwxWidgetsのラッパーが集まる予定なのでGUIアプリもそれなりに作れるようになる…のかなぁ。

何にしろやるべきことが多すぎて多くを語れませんorz

とりあえずしょぼい上にOpenALの作成に失敗しているところを表している現状のスクリーンショットをさらしてみる。

2008年9月26日 - 吉里吉里2とWindows9xについて補足

2008-09-26

吉里吉里2は2.30から正式にWindows9x(95,98,98SE,Me)を動作対象外としましたが、実際のところ「そうした」と宣言しただけであって、Windows9xで動作しなくなった訳ではないです。ユーザーさんのほうで動かしてみて、動くって言うのならば「動く」としてしまっていいと思います。

ただ、2.31からは、Windows9xで動かないからという理由で機能追加をしない、ということはなくなると思います。つまり、これからの開発ではWindows9xを無視する予定です。

一応、時代の流れということで……。

吉里吉里３はWindows版ではUNICODEバイナリになる予定。

2008年9月25日 - サンシャインクリエイション41行ってきます

2008-09-25

10月5日ですねー。

主目的は…ご挨拶まわりかなぁ。

再びとなりますが、もし会場で dee にお会いしたい方は dee@kikyou.info にメールくださいー。

2008年9月20日 - ゲーム開発現場で多くのオレオレ言語が生まれるのはなぜ?

2008-09-20

ゲーム開発現場で多くのオレオレ言語が生まれるのはなぜ?

スクリプターという職の人にluaでシナリオスクリプト(KAGにおけるKAGシナリオファイル)を書けとはさすがに言えませんよね。

汎用言語が必ずしも最適解になるわけではないので。現場それぞれに特化した言語を作った方がトータルコストが安くなるならば当然そういう方向になります。

あと、僕について言えば、TJSとかRisseとか作ってるのは半分は趣味。半分はそれ自体がゲームエンジンとしてのフレームワークそのものだからです。ヒープ管理やゲーム内で使うオブジェクトなどの基底のフレームワークは、吉里吉里の場合はスクリプト言語そのフレームワークその物なのです。

吉里吉里２も吉里吉里３もそうだけど、デフォルトの言語がTJS2なりRisseだったりであるだけで、たとえば吉里吉里2用のSquirrelプラグインとかあります https://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/trunk/kirikiri2/src/plugins/win32/squirrel。吉里吉里３はパーザが分離しているので好きな言語のパーザからASTを生成する部分をかけば好きなタイプの言語かんたんに作れるかと。

あとは吉里吉里２はWindows Scripting HostをサポートしているのでVBScriptとかでもスクリプティングできますhttps://sv.kikyou.info/trac/kirikiri/browser/kirikiri2/trunk/kirikiri2/src/plugins/win32/win32ole。

2008年9月20日 - みみけっと行ってきます

2008-09-20

21日のみみけっと行ってきます。主目的は某お方にステキな差し入れをするためですがw いまからプレゼントを買いに行ってこよう。

もし会場で dee にお会いしたい方は dee@kikyou.info にメールくださいー。ここに来るメールはケータイでも受けられるようになっているので、いきなりでもOKです。ラブレターなり脅迫メールなりお気軽にどうぞ～。

2008年9月18日 - 同人ゲームの過去、現在、未来 - 日本デジタルゲーム学会

2008-09-18

イベント案内 | 2008-09-26 (金) 同人ゲームの潮流①　「同人ゲームの過去、現在、未来」（DigraJ公開講座08年09月期） - DiGRA JAPAN | 日本デジタルゲーム学会

興味があるので、懇親会ともにちょっくら見てきます。

2008年9月16日 - 吉里吉里2 2.30 安定版リリース

2008-09-16

吉里吉里2 2.30 安定版をリリースしました。

実は今年の一月ごろに安定版はtrunkからbranchesに移ったのですが、現行のtrunkが安定しているのと長らくbranchesの2.30安定版ブランチをメンテしていなかったのとで、branchesの2.30安定版ブランチを破棄して、trunkから昨日の時点でbranchesの2.30安定版ブランチを作成しなおしました。

2.28に比べての大きなトピックといえば

Vistaへの本格的な対応
フルスクリーン表示アルゴリズムの大幅な刷新

ということになります。他にも細かい修正や機能追加がたくさんあります。

Vistaへの対応ということでは、書き出しが必要なデータはすべて datapath と呼ばれる領域に書き込むように変更されています。これはKAGのセーブデータや各種ログファイルなども含まれます。詳しくはドキュメントを参照してください。そのほかにもVista固有の諸問題(ほんとうにVistaでは些細な不具合が発生しまくる)に対応するためのワークアラウンドを多数含んでいます。過去の2.28などがVistaで動作しないわけではありませんが、よりVistaへの親和性が高くなったという言い方がしっくりきます。また、このバージョンではWindows 9x系とWindows NTへの対応を正式に取りやめました。

フルスクリーン表示アルゴリズムの刷新は、ワイドディスプレイの普及により、従来のフルスクリーン表示では対応が不充分になったためです。ワイドディスプレイではなくても、アスペクト比を保持したまま拡大できないディスプレイ(とくに液晶ディスプレイ)では潜在的に発生している問題でした(例:800x600を1280x1024で表示するなど)。吉里吉里本体はなるべくアスペクト比が保持できるような方法での拡大を試みようとします。必要ならばディスプレイ側の拡大機能でなく、エンジン側で拡大表示を行おうとします。

2.28から約1年ですかー。ながかったなぁ。

2008年9月15日 - Ubuntu 五ヶ月目

2008-09-15

メイン環境をUbuntu(x86_64)にして五ヶ月目になります。

もう Windows に戻る気はしないですー。どっちがいいかというよりは慣れと使いたいアプリの問題なんだと思いますが……。

アンチエイリアスが効いたIPAフォントは可読性もよく、本当に綺麗です。

ただ遭遇したいくつかの問題は、たとえばソースにパッチをあてて自分でコンパイルしなおして修正とか、ディスプレイドライバはnvidiaから落として自分で入れるとか(しかもカーネルがアップデートする度にモジュールコンパイルし直しが必要orz)、まだ本当のエンドユーザが使うには辛いところが多い気がします。

とりあえずよく使うアプリを列挙します。

LimeChat (IRCクライアント): いきなりWindows用アプリですがWineで元気に動いています。XネイティブなIRCクライアントいくつか試したんですがしっくりくるのがなかったのでこれを使ってます。素の Wineでは日本語入力に問題があるので一部をコンパイルしなおして使っています。→ http://bugs.winehq.org/show_bug.cgi?id=9838
Wine: Windowsアプリを動かすために使いますが、そうは言ってもうごかないソフトはたくさんあります。とりあえず吉里吉里は動きます。Photoshopはうごくそうな。
Pidgin (インターネットメッセンジャー): ピジンと読むようです。Windows Live メッセンジャーの代わりとして使っています。標準のものだとOIM(オフライン中に送られたメッセージを表示する機能)に対応していないので、最新版をソースからコンパイルして使ってます。
GIMP (ラスタ画像エディタ): とりあえず自分の用途には必要十分。
Eclipse CDT　(統合開発環境): 吉里吉里３開発用
Rythmbox (ミュージックプレイヤー): 極めてシンプルながら必要十分
Evolution (コラボレーションソフトウェア、Outlookみたいなもの): MUA(メーラ)としてのみ使ってます。
おちゅーしゃ (2chブラウザ): 最近はあんまり2ch見てないですが…。
Firefox (Webブラウザ): とりあえずデフォルトのブラウザ。
VirtualBox OSE (PCエミュレータ): Windows動かすときに使います。WindowsゲームでもDirectXをバリバリ使ってるのでなければ非常に元気に動きます。もちろん吉里吉里製ゲームは元気に動きます。GPU使いまくりなのはだめ。CPU合成系エンジンの底力が試される！(?)
gedit (標準のテキストエディタ): UNIX標準のテキストエディタはedのようですが、GNOME標準のテキストエディタはgeditです。Windows標準のメモ帳とは比べ物にならないほど高機能。
Liferea (RSSリーダ): これもシンプルながら必要十分なフィードリーダ。
FreeNX Server (遠隔操作用ソフト): 出先からPCを操作するのに使います。Bフレッツ同士ぐらいならばほぼローカルで動かしてるぐらいのレスポンスの速さです。
F-Spot (写真管理): デジカメ写真管理用。驚くべきことにC#で書かれてて、monoで動作します。しかも普通に。そつなく。
gThumb (画像管理): 画像ビューアです。ViXみたいなもの。動作が軽快です。ファイルマネージャ(Nautilus)も画像サムネイル表示などはWindowsエクスプローラに比べれば非常に軽快に動作するのですが、やはり専用アプリにはかなわないですね。
Nautilus (ファイルマネージャ): とりあえずGNOME標準のファイルマネージャ。sftpやWebDAVでマウントされた先のファイルなどは、GNOMEアプリだったらまるでローカルにあるかのように扱えて極めて便利です。GNOMEアプリでなくてもfuseのおかげで一般アプリからもまるっきり普通のファイルシステムのようにあつかえたりして。
GNOME mplayer (動画プレーヤー): "The Movie Player" mplayerのGNOME版です。よく形式がわかんない動画に出くわした場合はこれで大抵再生できます。
ターミナルサーバークライアント: RDP(Windowsの画面遠隔操作用プロトコル)に対応したクライアントです。Windowsマシンを遠隔操作するのに使ってます。

不満？ソース直せorz

2008年9月14日 - 水絆創膏

2008-09-14

水絆創膏とか液体絆創膏とか言われている種の薬がある。

なんというか人体用セメダイン？匂いがそう。傷口に塗ると乾いて、薄い皮膜を作って、それで傷口を保護する薬品です。

しかし、塗るときに傷がものすごくしみる。というか激痛。意識が遠のきそうになります。

この激痛がたまらん

やっぱりマゾでしょうか。

2008年9月8日 - 吉里吉里3開発再開

2008-09-08

諸事情あって二ヶ月ほど停止していた吉里吉里3の開発を再開します。

浦島太郎状態なのでキャッチアップしないと。もともと区切りの悪いところで停止した記憶があるからちょっと厄介だな……。