W.Deeの2008年9月の日記

今気づいたんですが、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-09-28 17:45 epics : はじめまして。吉里吉里3を楽しみにしています。二つの階層が必要だというのにはとても同意します。ただ、シナリオスクリプトの記述のレイヤをこれ以上シンプルにするのも難しそうに感じます。いっそ、統合開発環境的なアプローチで複雑さを隠蔽するしかないかなぁ、というのが持論なのですが、やっぱりテキストエディタ以外のものを導入するのは無理がありますでしょうか。別に書いたテキストをコピペで貼り付けられたらそれで十分じゃないかなぁ、なんて思ったりもするんですが。
2008-09-28 18:05 L.Entis : こんにちは。私も同じように2層で実現していますが、その理由はコンテキストセーブ処理の共通化（オレ言語）と、簡便なプリプロセッサによるゲームスクリプトとして記法の柔軟性（2層）でしょうか。
2008-09-28 18:57 [トラックバック] [ゲーム技術] ゲーム開発で独自言語が生まれるわけ - Game Scripting Memo : 続:ゲーム開発現場で多くのオレオレ言語が生まれるのはなぜ? - kwatchの日記トラックバックを頂いていたことに、W.Deeさんの日記経由で上記記事を見て初めて気づいた体たらくなわけですが。話題は「ゲーム開発現場で多くのオレオレ言語が生まれるのはなぜ？」というお話で
2008-09-28 21:38 W.Dee : >epicsさんはじめまして。素のテキストはいいんですが近年複雑になりがちなのが演出なので、そっちが特にヴィジュアルに編集できないとそろそろ辛いかなーといった感じです。たとえばTYPE-MOONさんはすでにそういうエディタをFateの時に作成されておりました(しかもそれ自体が吉里吉里製だったり)。吉里吉里3向けとしては https://sv.kikyou.info/trac/kirikiri/wiki/documents/kirikiri3/development/stagecraft_editor こういうのがいいかなーなんて考えていたり。
2008-09-29 14:56 Miliardo : エディタについては、一応吉里吉里自身にアニメーション制御機能とより高度なGUI機能を搭載させて、そして吉里吉里自身でエディタを作るほうが一番だと思います。そうすればユーザーの拡張とハックをサポートできます()。
2008-10-01 00:47 epics : 演出もどこまでサポートするかが悩みどころですね。昔ながらのトランジションだけでよければいろいろやりようもありそうですが、上限まで行くとFlashの編集画面くらいの機能が必要になりそうで、考えただけでくらくらします（＾＾；演出エディタ案はちょうどその中間あたりのよい落としどころに見えます。個人的には、ゲームとエディタでは必要なGUI機能が違いすぎるので、開発環境まで吉里吉里で、というのは難しいように感じています。吉里吉里エンジンに外部から動的に再生データを流し込める口を作って、別に作った開発環境からそこへプレビュー用のデータを随時流し込む、というほうがよいのではないかと。クロスプラットフォームと考えると、開発環境側は Eclipse が筆頭候補ですが、なんだかんだ言っても少々重いんですよね……。
2008-10-01 01:18 W.Dee : や、わりとFlashの編集的なものを考えていたんですけど、というかこの先の演出にはおそらくそれぐらいのものが必要。もちろん大変ですので、実際にどこまで作るかは別の話ですね。ツールについては、吉里吉里で動くもののためのものを作るのですから、ツールを吉里吉里それ自身で作るのはわりと自然だと思います。実際に吉里吉里２ではもともとレイヤーがウィジェットとしても動作できるように設計されているため、(公開されていませんが)十分実用的なウィジェット群を作っていらっしゃる方も居て、それらを組み合わせて統合環境的なものができています。TYPE-MOONさんのFateに使用されたやつは、編集画面から直接KAGのインスタンスを作成することができて、同じプロセス内で、その場で動作検証とかできるようになっていたり。いずれの場合も吉里吉里内で完結しちゃってます。
2008-10-02 00:43 W.Dee : ああ、たとえばフラッシュ作成ツールで作ったデータを吉里吉里用に変換するとかは十分ありえると思います。デザイナーさんにも仕事を頼みやすいしそういう方向性はありだとは思います。

吉里吉里2 2.30 安定版 Revision 2 出した

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

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

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

吉里吉里3の地味な機能

吉里吉里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-10-04 09:53 RednaxelaFX : あのスクリーンショットを見ると、ふと思いますが、import Sound in risa.sound;みたいなimport構文はツールに厳しいです。だって、packageが知らないと自動補完できないでしょう。その順番を逆にしてほうがいいかもしれませんね。
2008-10-04 21:49 W.Dee : どうにしろ動的な言語なので自動補完自体が難しいかとおもいます。なのでそこはその困難さからみればさほど問題にはならないところでしょう。
2008-10-05 00:45 RednaxelaFX : そうですね。でも、同じ動的な言語のRubyにも自動補完つきのIDEがいますよ。Ruby In Steelというのです、http://www.sapphiresteel.com/Ruby-IDE-Screenshots-of-Ruby-In。import構文を\"from risa.sound import Sound\"（Pythonのimport構文もこんな形です）にしたら、せめて自動補完に邪魔はならないでしょう。セマンティックスが変わらないから、パーザにしか影響が及ばないはずですね。
2008-10-05 20:52 W.Dee : Rubyの自動補完はそれはかなり無理やりな実装ですよ。当然ながらクラスやコンテキストがわからないオブジェクトのメンバの補完はできませんし ( http://japan.zdnet.com/news/devsys/story/0,2000056182,20350197,00.htm ) 。あとやっぱりimport構文をそう変えることでなぜ自動補完に邪魔にならなくなるのかがよく分かりません。少なくとRisseは現状のそれをパーザの段階で正確に解釈できていますよ。
2008-10-06 00:25 RednaxelaFX : あの、よければこれを読んでください：http://www.sapphiresteel.com/Ruby-IntelliSense-Libraries-code。彼らのアプローチは、インタプリタみたいにソースコードを解釈（実行とは違うが）、動的にシンボル情報を集めることです。100%正確は無理ですけれども、何の自動補完もないよりはましだと思います。Risseにimport構文は、いまimport [class_name] in [package_name]のかたちですので、クラス名を入力している時は、そのクラスがどのパッケージからがわかりません、よって自動補完は無理です。その順番を逆にしたら、from [package_name] import [class_name]のかたちで、クラス名を入力している時はすでにパッケージがわかります；そのパッケージからのシンボル情報に加えれば、なんとか自動補完はできそうではないか、と。参考（「well toolable」…）：http://www.computerworld.com.au/index.php/id;1149786074;pp;2
2008-10-06 00:39 W.Dee : え、import <パッケージ名> まで入力してからカーソル戻して import <識別子> in <パッケージ名> ってやるんじゃだめですか?どうせIDEの専用エディタならば入力方法の改善なんかはいくらでもできると思うんですが……(あと他の理由としてはfromなどという単語をいまから予約語にしたくない)。まぁそうだとしてもどのパッケージに何が入ってるかなんてのはRisseで記述されたパッケージとかはなんとか解析可能だとしてもバイナリで提供されているパッケージとかいろいろあるからなぁ (もともと完全な自動補完は無理と考え方からそこらへんそもそもあまり考えていないので)
2008-10-06 01:56 RednaxelaFX : ww そうですね、専用エディタならば入力順番が変わったとしても、なんとかなりそうかもしれません。バイナリライブラリについては、ホスティングAPIがあれば大丈夫ではないか。どうせインタプリタみたいにシンボルを集めるんだから、「プロジェクト」に必要なバイナリを入れて、そのシンボル情報をエディタに、というのはどうでしょう。

吉里吉里2とWindows9xについて補足

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

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

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

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

2008-10-20 00:15 うんもあ : Windows98で動かしたいのですがやっぱり無理なのでしょうか？
2008-10-20 14:06 W.Dee : ご質問の意図がよく分からないのですが、この日記のこの記事を読んだ上でのご質問でしょうか？

サンシャインクリエイション41行ってきます

10月5日ですねー。

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

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

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

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

スクリプターという職の人に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-09-22 00:23 Miliardo : ええど、Luaなどの現存言語を基づき、テキスト翻訳の方法で特化したスクリプトを作れるのも一つの方法じゃない？マクロプロセッサやプレコンパイラーなどのツールを使えば難しくないはず…それに、RPGやアクションなど、演出やコントロールが複雑なゲームであれば（特に３D絡む場合）、スクリプターにも汎用言語を使わねばならない場合があると思います。　ええど、もしかして新しいKAGが、単独なアプリからライブラリに変わって、VMで直接動作するコードによってコントロールされるものになるの？（YU-RISと似ているかも？）
2008-09-22 01:04 W.Dee : まあ、おっしゃるとおり、いろいろな場合があると思いますが、要は言いたいことは「適材適所」ということですね。

みみけっと行ってきます

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

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

2008-09-21 00:43 沖田かず : 縛るものをｐｌｚ！！(ﾟ∀ﾟ)　あ、テールを、です。
2008-09-21 00:52 W.Dee : えーーーー、、、、、、わかめとか？
2008-09-21 16:22 W.Dee : 結局かんぴょうを持っていきましたwwwwwwwwwwwwwww へんなものばっかり持っていってすみませんw > 両氏
2008-09-21 23:41 沖田かず : 惹ヵゝれぁぅ勹ｻﾘと勹ﾋ〃ヮ･･･ﾏｼ〃切なぃょね☆　本当にありがとうございましたwwwww
2008-09-22 14:07 W.Dee : …ああ、絆の力ってなんてすばらしいのでしょう(惚)

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

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

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

2008-09-27 16:49 W.Dee : 行ってきました。懇親会とそのあと知り合った人たちとの飲みで精魂使い果たしたorz
2008-09-29 15:16 W.Dee : 取り合えずこれを張っておく http://www.4gamer.net/games/042/G004287/20080928002/
2008-09-29 20:17 Miliardo : 日本在住ではないですけど、欧米と比べは日本での「同人」に対する考えそのものが違うだと思います。日本での「同人」は文化的すぎます（格げーやSTGでもほどんどが完璧な設定やストーリー、あるいは原作を持っている）、ゆえに形式と風格の面で自らに制限を課せた。逆に欧米の方がおもちゃつくりと似ているから、「あそび」そのものに集中できるからより技術的なものを生み出せる。
2008-10-01 01:07 W.Dee : ああ、考え方はだいぶ違うと思いますよ。そりゃもちろん。

吉里吉里2 2.30 安定版リリース

吉里吉里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-09-16 11:08 W.Dee : 書き忘れましたが今回のリリースではごうさんやmiahmieさん、じんさんなどから特にVistaに対する動作検証で多大なご協力をいただきました。この場を借りてお礼申し上げます。
2008-09-16 22:29 はむはむ : 別件で Vista対応をやった事あります・・・・確かに微妙に困らせてくれますね Vistaたん。　ってか、警告の暗くなるエフェクトは心臓に悪い。　あれで何人か心臓マヒ起していないか心配
2008-09-16 22:35 はむはむ : ２行に渡りすみません。　安定版リリースお疲れ様でした。m(_ _)m
2008-09-17 11:58 keakon : おめでとうございます！
2008-09-18 19:49 W.Dee : ありがとうございますー！Vistaは困った子です。悲鳴がいろんな所から聞こえて来ました。
2008-09-22 00:30 Miliardo : アップデートおめでとう。Vista、ね。確か、SP1でいろんな不具合（特に互換性の方面で）が修正されたみたいです。

Ubuntu 五ヶ月目

メイン環境を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-09-16 22:02 W.Dee : わーい！wineの日本語入力8文字問題周りがついに本家で治ったぞよ！これでもうwinex11.drvにパッチ当てなくていいんだね！

水絆創膏

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

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

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

この激痛がたまらん

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

2008-09-14 23:45 京秋人 : さすがDeeさんだ。
2008-09-16 08:04 みまちゃか : ふふふ…マゾですね(笑)
2008-09-16 22:20 W.Dee : ふふふ、埼玉県マゾヶ島ハロリムポポ村の住人ですから当然ですとも。

吉里吉里3開発再開

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

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

2008-09-08 18:51 はむはむ : 開発再開、楽しみにしております。　ではでは！
2008-09-15 18:54 W.Dee : どうもですーノロノロと頑張ります！

W.Deeの2008年9月の日記

2008年9月28日

2008年9月27日

2008年9月26日

2008年9月25日

2008年9月20日

2008年9月18日

2008年9月16日

2008年9月15日

2008年9月14日

2008年9月8日