トップ差分一覧ソース検索ヘルプ PDF RSS ログイン

ネットで気になっていた曲を探していまして、それがいわゆる「ギャルゲー」の曲と分かりました。「夏影」という曲で、曲調から久石譲作曲かとずっと思ってたのですが(^_^;;、「AIR」というゲームの曲と判明。

「KEY OFFICIAL HOMEPAGE」と一部の曲が試聴できるサイト。

http://key.visualarts.gr.jp/
http://key.soundslabel.com/

この「鳥の詩」「夏影」のピアノアレンジが気に入ったのでゲーム自身である「AIR（全年齢対象版）」とピアノアルバム「Kanon AIR Piano Arrange Album Re-feel」を買ってきました。「AIR」は名前は知っていたのですが、というよりギャルゲー・エロゲー自身やらないのでノータッチでしたが、物悲しい雰囲気がいいですね。ストーリーも泣かせるものらしいので、ゆっくりクリアしていこうかと。

ちなみに、ピアノアルバムは楽譜もついてます（簡単そうです）。フィーリング系の曲なんで、好きな人はいいかもしれません。意外と言っては失礼ですが、ギャルゲー・エロゲーのものでもいいのがありますね。今まで色眼鏡かけてみてたかも。

携帯からPCにデータ転送（2004/09/25）

東京でも携帯のカメラ機能で景色を撮ってみました。近所の「御殿山ガーデン」です。

http://ft-lab.ne.jp/photo/gotenyama.html

まだまだ使いこなせてないのですが「ファインモード」なるものを有効にしましたが品質はよくわからんです(^_^;;。その他、フラッシュ（モバイルライト）を有効にしたり夜景モード・スポーツモード（ぶれを緩和？）などもあるようです。

今のところ「V301SH」のカメラで分かった点として

暗いところではノイズが多くなる（画質が荒くなる）
明るい部分は白く飛んでしまう（特に暗い部分と共存していると。空・鏡面反射する部分なども影響を受けやすいです。ファインモードだからかな？）
撮影時はしっかりと固定して１秒くらいしてからシャッターを押すこと（ぶれが収まるまで待つ）
景色を撮る場合は、携帯側面にある接写切り替えスイッチは「接写OFF」にすること（でないと全体的にぼける）

があります。

vodafoneの場合は、メール転送（ロングメール）は6KBまでの制限があります（画像などを添付する場合）。ですので、メールを使って640x480pixelの画像を送信することはできません。よって、画像を編集する場合はUSBケーブルでつないでPCに転送することになります。

データ（画像・音・テキストなど）をパソコンに転送する場合は、vodafoneの場合はケータイファイル転送ヘルパーというソフトで行います。ただし、携帯とPCの接続のためにUSBケーブルが必要です。本家ではTDKの専用ケーブルを進めていますが、私はSUNTACの「DS96L-V」というUSBケーブルを使ってます。なお、vodafoneショップでは売ってませんので電気屋で購入するか、TDKのサイトから注文できるようです。（秋葉で探した限りはTDKのはありませんでした）

今は携帯自身が情報端末になりえますので、有効に使いたいところです。携帯に関しては疎いのですが、これだと（これで得られる情報量だけで）パソコンと面と向かって仕事を行っている人以外は満足できるかも、という気もしました。これに、情報発信の機能がついたりしたら（たとえば携帯からＨＰを作れる、とか）大部分の人はこれだけで完結できるかもしれないですね。

大阪に帰郷（2004/09/24）

ひさびさに大阪に数日帰ってました。で、携帯を買い換えました（vodafoneの「V301SH」）。携帯とはいえ、初めてデジカメを持ちましたのでいろいろ遊んでみました。しかし、おまけでも使える画質（「V301SH」は31万画素）ですね。携帯ですでに100万画素を突破しているものもあるとか。いやはや、進化するもんですねぇ。

被写体として大阪堺市の「おおいずみ（大泉）緑地」でいろいろ撮ってきました。Mystっぽく意識してみたのですが（実は自然の写真は大好きだったりします、見ているだけで写真の知識は皆無ではありますが）、パソコンに持ってくると結構劣化が目立っていて1/3くらいはボツに(^_^;;。

http://ft-lab.ne.jp/photo/ooizumi.html

でもカメラって面白いですね。目で見たとおりの画像が撮ることができれば臨場感も出るかもですが、絶対そうはいかないし。私が撮っても雰囲気は伝えられないなぁ。実際の大泉緑地は圧倒されるくらい広大です。もし、大阪に立ち寄る機会がありましたら堺市の「新金岡」に立ち寄ることをお勧めします。

なんかカメラの面白さが分かった気がしたので、東京でも公園を見つけて「自然」を撮ってみようかと思ってます。

8086本（2004/09/19）

本屋に行くと、コンピュータコーナーで8086本が平積みされてました。今の時代になぜ、というか10年くらい前に購入した本ですが・・・流行っているんでしょうかね。8086とは、80x86というシリーズのIntelのCPUです。Pentiumはそれの上位互換（80586以降）のようなものです。アセンブラによるプログラミングでこのような本は役に立ちます。

たしかに、SSEによるプログラムなどではこのような知識があるに越したことはないのですが、旧バージョンの本がなぜあるのか、というのに時代錯誤を感じつつ懐かしさがこみ上げてしまいました(^_^;;。

ちなみにうちにあるそれ関連の本は、

はじめて読む6809
はじめて読む8086
PC9801マシン語入門
PC9801プログラマーズBible

マシン語覚えたのは6809ですが（FM-8/FM-7とかの富士通の8bit「マイコン」です（笑））、このころはアセンブラ（いわゆるニーモニック）ではなくて16進数直打ちでした。純粋にアセンブラと呼ばれるのが出てきたのはFMシリーズの後期くらいだったように思います。「YAMAUCHIコマンド」という隠し機能があって、これを入力（16進数としてマシン語に埋め込む）することでプログラムを高速化する、なんて遊び心がありましたねぇ。この手のユーモア好きです（笑）。PC98では「PC9801プログラマーズBible」でほんとにハードウェアの性能を極限まで引き出す、みたいな濃いことをしてましたねぇ。この本、その名の示すとおりいろんなことを網羅したBibleでした。

今は、こちらもC/C++言語にインラインアセンブラで埋め込む程度しかCPUを直接操作することはしなくなりましたが、最近のグラフィックアクセラレータはそのへんの「面白さ」に通じるものがあるのかもしれませんね。（特にシェーダーあたり）

そんなこんなでGeForce 6600のボードが輝いてみえる今日このごろです(^_^;;。ほしぃですなぁ。でも、買うと今は遊ぶときではないのでガマンです。

空間分割の手法（2004/09/18）

たまたま見つけたページですが、いろんな空間分割手法が載ってます。（言葉の意味とテスト結果だけですけど）

http://sgi.felk.cvut.cz/BES/egwr2000data/egwr2000paper-data.html

Shadeで使われているのはBVH(Bounding Volume hierarchy)で、どっかの論文で見たのですが一番最適化されたシーンではBVHが速度的に有利だとか。RedqueenはBSPですね。

それにしても、八分木（Octree）の手法がいっぱいありますねぇ。この他に「HOO（Hierarchy of octrees）」ってのもあるみたいです。

http://www-lsi.ugr.es/~rosana/investigacion/posterEG03.pdf

これを見ると、八分木も結構有効そうですね。（以前、八分木やってみて遅かったのですが実装が間違っていたのかもしれません）それぞれ得手不得手がありますので（前処理に時間がかかる（BSP）、シーンが大きいと速度が極端に低下する（UG）、トラバース速度のボトルネック（たぶん普通のUGが一番速いかも）などなど）もっと空間分割については深くあさってみようと思います。日本語サイトでいいのが少ないので、英語の苦手な私としてはいろんな意味でつらいっすねぇ(^_^;;

机上プログラミング（2004/09/15）

昔の人なら必ずやっていたであろう「机上プログラミング」、これを実践するときがやってきました(^_^;;。実は、私は昔っから落書き帳や広告紙の裏なんかにプログラムを書いてアルゴリズムを練りつつソースを鉛筆で書いてから、最終的にPCでは入力していく、というスタイルをとってました。しかし、最近はPC上のIDEでアルゴリズムの考案から実装まですべての流れを行ってます。普通の頭をフルに使わないプログラム（というと失礼ですが）はそれでもOKなんですが、「アルゴリズムを練る」となるとそうもいきません。ほとんどが頭の中で構築した結果をコード化するわけですので。そう考えると、プログラムのいろいろな開発経験は大事な資産っすね。自分の引き出しから「パターン」を引き出せば経験として存在するもの・似たようなものならなんでもできるわけですので。

ただ、レンダラを作るにあたって速度といろいろな情報のI/Oを考えると、「やっぱ紙上で書いてアルゴリズムを固めないと回らない」みたいな状態になってしまいました。というか、現状でアルゴリズム的にすっきりしてません(^_^;;。これはプログラムを長いことやってないと理解が難しいかもしれませんが、開発では「美しくまとまる」という瞬間があります。これはデータ構造だったりアルゴリズムだったりコーディングでの構成だったりしますが、今回はそのへんもしっかりしたいのでコア部分は一度机の上でにらめっこしようかなぁ、と思ってます。

これなら、紙と鉛筆さえあれば喫茶店でも公園でもぶっちゃけどこでもプログラムできるわけですし。ちょっと場所を変えてアルゴリズムを固めてみようかと考えてます。もうちょっとですっきりする、ってとこなんですがねぇ。無いものを造りだすのは難しいものです。・・・でもそれが楽しいわけですが（笑）。

一度はやってみたいこと・・・・。プログラムソースを全部プリントアウトしてそれをリファクタリングしながらデバッグ・再コーディングもすべて紙の上で行う・・・う～ん、夢のようです(^_^;;。

Eclipse 3.0（2004/09/14）

主にJavaの統合開発環境として有名な「Eclipse（http://www.eclipse.org/）」の3.0でウィザード的な機能がついたり、なんかルックアンドフィールが丸く（？）なってますねぇ。ひさびさにいじってみました(といってもHelloWorldを実行してみただけ)。Eclipseはフリーでありながら、実際の開発でもバンバン使われているみたいですね。というか、使いやすいし便利ですのでJava開発される方にはお勧めです。（「SWT」というOSのAPIを使ったウィジット群を使って作られてますので、JBuilder(Swing使用)よりも軽いです）

ところで、テキストエディタの背景色ってみなさん何色にしているでしょうか？私はメーラーもテキストエディタ（秀丸）もFlashのActionScriptエディタもVC++のIDEも、全部背景黒にしています。理由は目が疲れにくいから。ほとんどの時間をエディタ上でプログラムをすることに費やしていますので、白地に黒文字は負担が大きいです(^_^;;。おかげでWebブラウザの白色がまぶしいこと。

ちょっと止まっていたFlash関連の情報をWikiに追加しました。元ネタとして「ネタ帳」のノート（いわゆる大学ノート）があるのですが情報量としてはまだまだ写しきれてません。管理の都合上デジタル化というかサイトにアップしてますが、作業（プログラム）の息抜きで適当に更新することにします。結構アップした情報量が増えてきましたねぇ。しかし、まだまだ(^_^;;。Wikiのおかげで更新が非常に楽になりました。いちいちHTMLを書かなくてもいい（デザインなどの制限はありますが）、というのは「ドキュメント化」が進みますねぇ。

so-netのほうにあるShade情報や（これもShade7にしないといけないですね）リアルタイム系のプログラムなども、順次こっちに移行しなくては。このへん、ぼちぼちやっていきます。

メイドカフェ（2004/09/12）

知り合いとまたまた行ってきました、メイドカフェ「Mai:lish」。２回目です。普通にメイドさんのカッコをしている店員さんがいる喫茶店って感じで客層も普通（以前行ったときよりもお客さんもノーマル（？）だったり）でした。タイムリーかどうかよく分からないですが、以前日記で話題にした「ミルメーク」がメニューにありましたねぇ。この店、つい先日にテレビの深夜番組でも紹介されてましたが・・・「いらっしゃいませ、ご主人様」は無かったです(^_^;;。テレビだけのリップサービスだったんかな。

知り合いは「普通過ぎてつまらん」みたいなことを言ってましたが、たしかに昼行くと普通ではありますねぇ。何を期待してるんだかですが(^_^;;。夜も行こうとかいう話で盛り上がっていたのですが（夜はなにやらイベントがあるらしい）、さすがに同じ店をハシゴするのは気が引けるということで結局行きませんでした(^_^;;。

そこで知り合いと話していた内容が仕事とかの固い話ばっかりしてたんで、抜群に浮いてただろうなぁ・・・。

秋葉原にはMai:lish含めて３件くらいメイドカフェがありますね。（Mai:lish以外は知らなかったんですが、もう１件見つけました。というか教えてもらいました）

VisualStudio.net 2003（2004/09/11）

これの「ステップアップグレード版」というのを買ってきました（以前仕事用に使っていたのと分けるという意味で。ようは、個人開発用です。同じ開発者だったらこのあたりはライセンス上は問題ないのかな）。で、旧バージョンがVC++6.0なのでそのままではアップグレードできないだろうと思って、「VC++ .NET 2003」（踏み台用(^_^;;）も買ってきました。けど、VC6 ==> VisualStudio.net 2003って素でアップグレードできますね。うぉ～、２万円の無駄発生(T_T)。ステップアップグレードの表記が紛らわしいので（VC6も入れてほしい）なんとかしてほしいっす(^_^;;。

以前、Borland C++(BCC)に対するTipsを書いたのですがこれ関連でちょっとけったいなことを考えてまして。OS Xであれば「Xcode」がOSについてきていますので、開発はいわば無料でできます。Windowsの場合はBCCなどを入れると無料では開発できるのですが、多くのソフトはVC++などの比較的高価なソフトで開発されています。個人で楽しむ場合は安いほう（もしくは無料）が手を出しやすいですので、そのあたりの「ブリッジ」を作ってみようかと（あくまでも遊びで）。ターゲットはShade7プラグインSDKです。可能なのかどうかは分かりません(^_^;;。が、できるような気もします。ちなみにBCCでプラグインSDKの関連ソースを持ってきて再ビルドしたのですが、これは（おそらくですが）クラス関連の整合性が取れなくてうまく動きませんでした。もちろん、BCCを使うとフリー目的以外で（営利目的で）利用できないのですが、ちょっと遊んでみたい、という人にとってはお手軽なほうがいいんでないか、と思った次第です。後は、「私ならこう書く」というSDKの自分なりの理想をラッパーとして書いてみようかと思ったりも（笑）。

でも、実際開発ツールが無料っていい時代になりましたねぇ。私はフリー（無料）のほうがうれしい反面（個人的にはフリーであってほしい、という気持ちのほうが強いです）、実際は開発を商売にしていると仮に開発ツール自身が売り物にできない方向性に向かってしまうとなるとそれはそれで危機のような感じもして、正直どちらがいいのか結論は出せないです。3Dツールもしかりではありますね（なんで、市販だとそれに見合ったプラスアルファが必要になるんでしょうねぇ。機能の規模で対応ってのもあるかもですが）。後はコミュニティの発展などを考えると、商売とは切り離したほうが進めやすいというのもありますので、いろんな要因でツール自身は模索が必要なのかもしれないですね。

メモリ管理の徹底（2004/09/09）

プログラムにおいては「メモリリーク」は天敵です(まぁ、C/C++特有ではありますが。Javaの場合は言語自身が徹底していますのでよっぽどのことをしない限りはメモリ関連で落ちることは少ないです)。

C言語ではmallocでメモリ確保するのですがfreeで解放し忘れたり、freeしては駄目なメモリ領域をフリーしてしまったり。なんで、私の場合はデバッグ時にメモリマネージャを作ってこれを通すようにしています。これは、malloc/realloc/freeを監視して「メモリがどれくらい使用されているか、freeしてはいけない領域を解放していないか、解放を忘れていないか」などを把握することができるようになってます。また、ガベージコレクション機能付きです。実は、mallocやC++のnewなどのメモリ確保ではメモリ使用が細切れになることもあり（スキマができる）効率が悪くなることが多いです。いわば、ハードディスクで言うデフラグですね。これを自動で行っているのがJava言語です。

で、このメモリマネージャなんですがこれを使うと、メモリリーク関連はデバッガ無しでも検出可能です。レンダラは大量のメモリを扱いますので、思わぬところで不安定要因を引き起こしてしまったりします。メモリを下手に食い尽くしているってこともありますのでそのあたりは徹底したいところです。

しかし、問題はこのメモリマネージャは管理用のリスト構造を持ちます。ですので、メモリの確保量（malloc回数）が多くなるとリスト分のメモリも消費して検索回数も増えて多少速度落ちする、というのがネックではあります。が、デバッグのみで使用となると不安定要素も事前排除できて楽ですね。malloc/realloc/freeは、ラップして使用するのが吉かと思います。（ですので、C++のnew/deleteはよっぽど自信がなかったら使ってなかったり(^_^;;）

以前紹介した「HUG」ですが、これは階層構造を持つということはそれだけメモリ消費量が激しいです。レンダラでは、膨大なシーンになって総ポリゴン数が億単位を超えると、さすがにメモリにはシーン情報を収めることができなくなります。この場合は、メモリに確保するとボクセル構造の保持だけで最大でも100MBを超えてしまう可能性が大です（プラス、ボクセル情報（インデックス）を保持すると1GBのメモリがあっても不安ですね）。なんで、こんな場合は「ハードディスクをメモリのように扱う」ということが有効です。いっそのことメモリ自身をキャッシュとしてしまい、データはハードディスクに整列した状態で格納してしまいます（なんで、データ構造命！です）。

ちょっと変わった考えですが「レンダラをコンパイラのように扱う（中間ファイルとして作業データをファイルに出して、最終的に１枚のレンダリング画像を生成）」ってのは結構有効ではないかなぁ、と思ったりします。むしろ、大規模構造だと必須かもしれないですね。

CEDEC（2004/09/08）

新宿の工学院大学のほうで「CEDEC」というゲーム開発者向けのフォーラムがあり、そこの打ち上げに参加させていただきました。実際の開発現場の話が聞けてなかなかタメになりました。みなさん好きでやってるんだなぁ、というのが垣間見れてモチベーションをもらってきた感じです(^_^);;。

最近はリアルタイムのほうのプログラム（DirectX/OpenGL）からは遠ざかっているのですが、話を聞いていると「おお、やりてぇ！」という話が多いですねぇ。今はオフラインのいわゆる静止画向けの方に力を入れているのですが、一段落したら(WGFに間に合うのならば）また遊んでみたいところです。

HUG（2004/09/07）

レンダラの空間分割を再度見直しています。といっても、全体的にソースを一から書き直しているのでそのついでに、なんですけども。今の問題は「広大にシーンの真ん中に密な物体が密集している」といったシーンです。この場合は、空間分割によっては交差判定処理が極端に低下することになります。本命はBSPなんですが、今回はHUGというのを取り上げてみます。（まだどの空間分割を採用するかは未定。ハイブリッドが効率いいのかなぁ）

HUG(Hierarchical Uniform Grids)とは「階層的なユニフォームグリッド」のことです。シーン全体を軽く等間隔で分割し、さらに個々のボクセル単位で分割を行います。これを階層的に保持します。

トラバース時は3DDDAを行うことになり、（最悪の場合）階層分の3DDDA処理を繰り返すことになります。が、上位階層のくくりで「カラ」の場合はスキップできますので普通の１階層だけのユニフォームグリッド(UG)よりは効率がよさそうです。また、部分的に密に分割できるために「広大なシーンの真ん中に小さな物体」のシーンは効率アップできそうです。

突き詰めていくと「八分木（Octree）」に近づきそうなのですが、なんとなくですがHUGのほうがよさげかなぁ、ということでとりあえずの実装候補です。その他利点としては、分散処理にしやすい（交差判定の予測がつきやすいため）ということでしょうか。このほうが重要かも（BSPやOctreeの場合は、検索方法が分散しにくい感じなので分散対応するのはつらそうです）。

でも、結局はHUGでも分割解像度の上限の問題もありますので、1/2の分割で収束していくBSPのほうがいいかもしれませんね（トラバース処理は3DDDAで行えるほうが単純なだけにUG/HUGのほうが効率がよさそうではありますが）。何はともあれ実験、です。

ミルメーク（2004/09/06）

一時期ニュースで紹介されていた大島食品工業の「ミルメーク」を買ってきました。牛乳に入れる粉状のものでこれを牛乳に入れると甘くなります。ココア味やメロン味があります。これ、学校給食で出されていたらしいのですが、私の時代（昭和60年代くらい）はなかったですねぇ。実は今回初めて使いました。ジュースみたいなもんかと思いましたが独特の甘さで、これなら牛乳嫌いな人でも飲めるようになるなぁ、と思いました。しかし、飲んだことなかったですが懐かしい味です。昔駄菓子屋でこんな粉ジュース（？）を飲んだことがあるのですがそんな感じ。

また、学校給食を再現した店もありますね→「給食当番」。懐古主義者にはたまらんですねぇ(^_^;;。カレーとか絶妙のおいしさだったなぁと思い出しますわ。鯨もあるのかぁ・・・今や食べることができなくなりましたねぇ。昔の給食ではあったんですけども。

ということで、昔好きの層がいろいろ模索しているのを感じる今日この頃です。定期的に「ミルメーク」は買うことにしようかな。ミルメークはスーパーにて8袋入りで100円くらいで売ってました。

レイの境界のハザマで（2004/09/05）

レンダラにてレイトレースを行う場合ポリゴンとの交差判定を行うのですが、以下のようなプログラムで仮想スクリーン上のピクセル位置を求めることになると思います（アンチエイリアス処理は行わない場合）。

for(y = 0; y < 240; y++) {
    for(x = 0; x < 320; x++) {
        col = raytrace(x, y);
        ...
    }
}

raytrace関数で示された(x, y)の位置より視線ベクトルを計算して、シーン上を走査します。ところが、この場合は境界部分がガタガタと「ゆれる」状態ができてしまうことがあります。

これは、実はレイが「スクリーンのピクセルの中心を通っていないから」微妙な境界位置に立たされている、というのが原因になります。（ポリゴンの交差判定処理内で小数点演算の仮数部の精度を上げると、この段階でも緩和することができます）

解決策としては、レイをたどる場合はスクリーンのピクセル位置をピクセルの中心にします。(0, 0)、(0, 1)、(0, 2)・・・というピクセル位置は実はピクセルの間である、と見るわけです。(0.5, 0.5)、(0.5, 1.5)、(0.5, 2.5)・・・と走査します。

for(y = 0; y < 240; y++) {
    for(x = 0; x < 320; x++) {
        col = raytrace((float)x + 0.5f, (float)y + 0.5f);
        ...
    }
}

で今度はガタガタが消えます。ということで、小数点で1.0以下の値を使う処理を行う場合にこの小さい値がいかに画質に影響を与えるか、というのがなんとなくですが垣間見れるかと思います。

この問題は、小数点演算（交差判定含む）が限りなく無限の精度であればゆれないはずです。このあたり、「誤差」といえば誤差なんですね。この手の誤差は、シーン全体に対し1.0の間隔でグリッドを敷き詰めるイメージを持つと原因が理解しやすいです（というのも、ポリゴンの頂点座標自体を整数で与える場合は、頂点が境界線上にあると見ることができるため）。

家の周りに猫増えた（2004/09/02）

なんか、家（アパート）の周りで猫が子供を産んだらしく出かけるときには必ず猫と遭遇します。それも２・３匹と（どうも親子の模様）。猫達が道を占領しているので、そのまま突進したら子猫はすぐ逃げるのですが親猫はどっしり構えてますね。というか、慣れたのかも（いつも見るし）。おかげさまで今年はネズミがぜんぜん出てこないです。ありがたや。

ただ、大家さんとこの猫（親子猫とは別です）は堂々と部屋に入ってこようとしていて大変です(^_^;;

さて、いきなり開発の話。レンダラを共有ライブラリ（DLL）として提供できるようにするため、インターフェースを練っています。C-PartsではC++の形だったのですが、Borland C++やDelphi/VBなどからでも呼び出せるようにしたいのです。で、「Ｃ言語の関数形式でやりとりしよう」ということに落ち着きそうです。C++のクラスでDLLの外部関数(クラスのメンバ)を作ってやりとりすると、libを作ったときにVC++以外で互換性がなくなったり大変です。また、多言語とのやり取りが事実上不可能になってしまいます。

本来はDLLは言語やバージョンには依存しないものだと思うのですが、このあたり言語により方言が出ちゃってますね。C++の罪なところでしょうか。

さらに、仮にBorland CやVB/DelphiなどでVC++で作ったDLLを呼び出す場合は「LoadLibrary」でDLLを動的に呼び出して「GetProcAddress」APIで個々の関数をマッピングしてやります。これだとlibファイルは不要で本来のDLLの役割をまっとうできそうですね。

再びC言語の魅力というか「枯れた」存在価値を見出せた気がします。またこのあたりも技術情報としてまとめることにしますね。

Future's Laboratory 技術格納庫 2004-2013 Yutaka Yoshisaka.

独り言日記(2004/09)