ゲームプログラミング相談室

**プチ9627ｍ** · 01/11/06 18:47

ゲームプログラミング全般についての質問スレッド。
駄スレ立てる前にココで聞きましょう。

■旧スレ（プログラミング技術板より）
○パート１
http://piza.2ch.net/tech/kako/969/969984472.html
○パート２
http://pc.2ch.net/test/read.cgi/tech/985540361
○パート３
http://pc.2ch.net/test/read.cgi/tech/1002894129/

**名前は開発中のものです。** · 02/10/30 01:49

>>857
> いや、freeに一個ラッパーを掛けて、そこへ渡すポインタを
> 参照渡しにして関数内でNULLを代入しようってだけのことね。
それでは不正なメモリアクセスの問題は解決しないんだけど。実例が
想像つかない？

**名前は開発中のものです。** · 02/10/30 02:18

>858
もともと不正なメモリアクセスは別問題。それは単にバグ。
>818を読む限り、単に解放済みポインタとそうでないポインタで
条件分けしたくないだけなら、NULLを代入すればいい。
NULLは解放済みを示すマークで、free(NULL)が素通りという
仕様はそのためにある。

ループのある枝分かれリストみたいのを解放するケースを
考えてるんだろうけど、そこまで来ると各ノードを直接freeで
解放しにいくのは無理でしょう。削除マーク付けといて、
後でＧＣで一括解放するしかない。

**名前は開発中のものです。** · 02/10/30 07:39

正直、メモリ管理は人間がやるべき仕事ではないような気がしますた。
生産性低くなる原因の一端。

**名前は開発中のものです。** · 02/10/30 08:46

しかし明示的に開放する機能が無いとメモリが無駄になり、下手すると
足りなくなる罠。メモリ確保の機能がある限り人間が管理するしかない。

**名前は開発中のものです。** · 02/10/30 09:22

２重開放はエラー出たりしてすぐ発見できるからあまり問題にならない
ような気がする。メモリリークは表面化しにくいから厄介なバグになるが。

**846** · 02/10/30 12:54

素通り･･･

**名前は開発中のものです。** · 02/10/30 20:43

>>862
> ２重開放はエラー出たりしてすぐ発見できるからあまり問題にならない
そうでもない。

メモリ関係の問題はどれもそうなんだが、問題が出たときと原因が遙か彼方に
隔たってることが多い (二重 free なら一回目の free はどこで行ったんだ？)
から、原因を突き止めるのは大変だよ。特に微妙な条件でのみ発生するとか、
マルチスレッドや DMA が絡むと死ねる。

>>859
818 はそもそも「free() しなくても良いやん」つー例のような気がする。その
メモリ領域をプロセス内で再利用するなら free すべきだけど、コンパイラ
の型システムの情報なんかは、

　コンパイルが終わった時点でプロセス終了させるから、ちまちま free せずに
　投げ捨てろ

っつー情報だよな。

そこで労力をかけて free() したところで、

1. コンパイラのプロセスが終了するのを遅らせる
2. キャッシュを汚す
3. あまつさえ二重 free() なんてバグを埋め込んで SIGSEGV を食らった日には、
　ただのバカ

だろう。

**名前は開発中のものです。** · 02/10/31 00:04

>864
一回目のfreeは、無効なデータを解放するつもりでやってるんだろ？
それを問題が起こらないようにとただ消してしまうのは、
無効なデータへの不正なアクセスを隠してしまうだけだと思うが。
NULLポインタで明示的エラーを出させたほうが、安全。
落ちないバグの原因探すほうがよっぽどやっかいだろう。

こまめな解放はいらないとしても、一応プロセスの最後には明示的に
解放してやるべきだと思うが。
ＶＣ＋＋だと、メモリリークが大量に警告されてうっとおしくない？

**名前は開発中のものです。** · 02/10/31 00:17

boost::shared_ptrとSTLのコンテナを使えばいいのに．．．

**名前は開発中のものです。** · 02/10/31 09:37

C#を使え

**名前は開発中のものです。** · 02/10/31 16:06

ません

**名前は開発中のものです。** · 02/10/31 18:22

か？

**名前は開発中のものです。** · 02/10/31 19:45

ﾁｮﾄﾏﾃ!

ｺｺﾊ､
ゲームプログラミング相談室
ﾃﾞﾂﾖ!

**名前は開発中のものです。** · 02/10/31 20:02

>>865
状況によるだろう。アセンブラのラベル情報とか 864 が言ってるようなコンパイラ
の型情報とかは、free したところで直後にプロセスが終了するのが目に見えてる
ので、free せずに終わらせるのもアリだ。

そこで free しても単なる自己満足。ユーザにとっては、むしろ邪魔なだけ。

**名前は開発中のものです。** · 02/11/01 00:07

>871
ちょいまち、ユーザの「邪魔」って、具体的にはなんのことだ？
ユーザには関係ない、というのなら分かるんだが。

あとでメンテナンスする人のこと考えたらメモリリークつぶすくらいは
常識だと思うがな。大量の警告メッセージに埋もれて、つぶすべき
メモリリークが見えにくくなる。

**名前は開発中のものです。** · 02/11/01 00:32

>>872
> ちょいまち、ユーザの「邪魔」って、具体的にはなんのことだ？
キャッシュを汚すわ、終了に(本来不要なはずの）余計な時間を食うわ、
開発コストは上がるわ。

> あとでメンテナンスする人のこと考えたらメモリリークつぶすくらいは
> 常識だと思うがな。
プロセスの寿命とデータの寿命が一致してる場合にはメモリリークとは言わん
だろ。メモリリークというのはその名の通り「漏れ」であって、使えないメモリ領
域が増えることを指すわけで。

> 大量の警告メッセージに埋もれて
_CrtSetDbgFlag() なんかが実装してる「終了時に free してないメモリ領域の
一覧を表示する」機能のこと？　あれはそれなりに便利だが、万能じゃない。

（っつか BoundsCheker 使え)

**名前は開発中のものです。** · 02/11/01 00:44

>873
ＯＳに暗黙的に解放してもらったって時間は掛かるだろ。
開発コストったって、ただメモリ確保に一枚ラッパーかませて
最悪の場合でも終了処理で明示的に解放されるように作るだけだろ。

その「万能じゃない」機能をさらに使いにくくしてどうするのだ。
俺は引き継いだソースがメモリリーク放置していたら、
ちょっとウンザリするがな。

**名前は開発中のものです。** · 02/11/01 00:54

この流れに便乗して質問させてください。

VC++でシューティングゲームを作っているのですが、敵や弾をたくさん表示させては
消すために、メモリをnew、deleteしまくっているのです。
ところが、実行しているとすぐに重くなってしまいます。

メモリリークに関しては、デバッグモードで
_CrtSetDbgFlag(_CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF)
を呼び出して確認したのですが、一つもありませんでした。

これって、ちゃんと解放していても、メモリの確保が原因で重くなることってあるのですか？
ちなみに、表示させたオブジェクト(newしたインスタンス)の数に比例して
重くなっていくことは確認しました。

**名前は開発中のものです。** · 02/11/01 01:02

>>875
> 表示させたオブジェクト(newしたインスタンス)の数に比例して
それって、ふつうに処理量が増えてるんじゃないの？

**名前は開発中のものです。** · 02/11/01 01:23

>>875
敵や弾の画面表示だけしない場合も重くなるか？

**名前は開発中のものです。** · 02/11/01 01:24

> ＯＳに暗黙的に解放してもらったって時間は掛かるだろ。

いわゆるunixあるいはwin32ならばかかりまへん

**名前は開発中のものです。** · 02/11/01 01:28

>>876
いえ、そういうのではありません。
キューに、敵だの弾だの詰め込んで、敵をやっつけ(deleteし)ます。
その後しばらく敵を出さなければ、キューがちゃんと空になっていることも
確認しました。
そして、その後また同じように敵を出して…と繰り返すと、だんだん重くなっていくのです。
プログラムを終了したときなんか、数秒フリーズしたように止まります。

>>877
画面表示をしないでやってみましたが、変わりませんでした。

**名前は開発中のものです。** · 02/11/01 01:34

>>875
たぶんソース見ないと原因は分からない。

**名前は開発中のものです。** · 02/11/01 01:39

>873はVBかJavaでもやってろってこった（藁

**名前は開発中のものです。** · 02/11/01 01:39

>>879
HDDにスワップしているから遅くなっているとかそういうのは？

**名前は開発中のものです。** · 02/11/01 01:44

メモリを解放しているから、メモリが足りなくなることはない
→スワップはしない。

って考えるのは間違ってますか？
スワップしてる気配はないのですが…

**名前は開発中のものです。** · 02/11/01 01:47

>>879
１個１個new/deleteせずに、最初に一定数一括確保して使い回すように
してみて、軽くなるようならnew/deleteで重くなっていると見る。

**名前は開発中のものです。** · 02/11/01 01:53

>>875
profilingしてみりゃいいだけじゃん?

**名前は開発中のものです。** · 02/11/01 01:53

ありがとうございました。わかりました、やってみます。

ところで、new/deleteで重くなるとしたら、どうしてなんでしょう。
deleteする瞬間に重くなるなら分かるけど、後々にも響くってのは
理解できませんよね。

**名前は開発中のものです。** · 02/11/01 02:02

あまりにも頻繁に確保・開放を繰り返すと、それを管理する
ほうも大変なんじゃないの。確保・開放を繰り返すと割り当てた
メモリが断片化するよね。そんな状態で効率よく領域を割り当てる
ようにするにはどうすればいいんだろうね。

**名前は開発中のものです。** · 02/11/01 02:03

>>874
> ＯＳに暗黙的に解放してもらったって時間は掛かるだろ。
free() のソースを読んで、どういう処理をしているのか調べてみ。OS の
方の処理とはまた別に、いろいろやってるから。

**名前は開発中のものです。** · 02/11/01 02:07

>>887
仮想記憶を採用している環境なら、気にしないのが正解だと思う。スワップは
喰うかもしれんが、実メモリの断片化はページングにお任せってことで。

仮想記憶がない環境だと、最初にメモリのレイアウトを決めてしまって、固定
長のメモリブロックを割りあてるのが常套手段。

**名前は開発中のものです。** · 02/11/01 02:17

>888
それが問題になるほど大きな処理なのか？
もしそうなのだとしたら、最初にどんとメモリ取って、
それを小分けにして使って、最後にどんと解放したら
いいじゃないか。だったら一回で済む。

**名前は開発中のものです。** · 02/11/01 02:34

>>890
そこまでして、わざわざヒープの解放に拘る意味があるのか？
だいたい使ったメモリ全部解放しろっつーなら、スタックやテキスト
はどうするんだか。

**名前は開発中のものです。** · 02/11/01 02:38

そこまでって言うほどの手間じゃねえだろ、と言っている。
最後にしか解放しないと割り切れば、簡単に実装できるだろ。

**名前は開発中のものです。** · 02/11/01 02:42

>>892
そんな丼勘定な実装に何の意味があるんだ？だいたい最初からサイズが
見積れるなら static でとれば良いだけだし。

**名前は開発中のものです。** · 02/11/01 03:20

メモリリークをつぶせるという意味がある。警告メッセージ潰し。
サイズ見積もれなんていってないじゃないか。
allocに一枚ラッパーかぶせて、ポインタを全部記録しておいて、
終了時に順にfreeするだけ。

**名前は開発中のものです。** · 02/11/01 03:35

ダイナミックに確保するならちゃんと開放しないとダメだよ。
メモリを再確保するたびに使用メモリ量が積もっていく。
ゲームの場合はメインの処理がループなので、たいしたことないと思っていても、
処理によっては１秒60回でメモリリークされたりしてちょっとまずいことになる。

開放しないメモリを確保するくらいなら初めからスタティックに確保した方がいい。

**名前は開発中のものです。** · 02/11/01 05:41

>894はループの中で確保するのを前提にした話ではないよ。
どうしても解放するのが面倒くさい場合の最後の手段で言ってるだけ。
シューティングゲームのバッファなんかはstaticでいい気が。
数の上限は知れてるし、容量もたいしたことないでしょう。

**名前は開発中のものです。** · 02/11/01 09:10

.NETのガベージコレクタを使え

**名前は開発中のものです。** · 02/11/01 09:22

boost::pool ﾀﾞ! (ｳｿ

**名前は開発中のものです。** · 02/11/01 09:55

メモリ開放しないプログラムはそのまま再利用できないからクソ。

**名前は開発中のものです。** · 02/11/01 14:36

>>899
スレの内容を全く読んでいない馬鹿発見！

**名前は開発中のものです。** · 02/11/01 16:44

メモリ開放しないやつは開発者の姿勢としてクソ。

**名前は開発中のものです。** · 02/11/01 19:58

boost::poolって早いの？

**名前は開発中のものです。** · 02/11/01 20:41

>>902
そんな抽象的すぎる質問にどうやって答えろと（藁

**名前は開発中のものです。** · 02/11/01 21:08

突然ですみませんが当たり判定のアルゴリズムでOBBについて解説してある日本のサイトなどはないでしょうか？

**名前は開発中のものです。** · 02/11/01 21:49

メモリ開発しないやつは解放者の姿勢としてクソ。

**名前は開発中のものです。** · 02/11/01 23:22

>>904
日本のサイトは知らん。
海外ならいっぱいあるけど。

**名前は開発中のものです。** · 02/11/01 23:58

>>900
まんざらそうでもない。
javacなんかがそれで一時期ハマってたらしい。

**名前は開発中のものです。** · 02/11/02 00:24

＞９０６
すみませんが、できたらそのサイトをおしえていただけないでしょうか？申し訳ないです。

**名前は開発中のものです。** · 02/11/02 00:29

>>908
最近の厨房様は検索と言う言葉をご存知ないらしい。

http://www.google.com/search?num=50&q=OBB+collision

**名前は開発中のものです。** · 02/11/02 00:46

日本語のサイトは皆無だよな･･･

**名前は開発中のものです。** · 02/11/02 01:01

>909
すみません、すみません。（´Д｀；）

**名前は開発中のものです。** · 02/11/02 02:32

>>902
開発は、早くなり増田。

**名前は開発中のものです。** · 02/11/02 15:33

>>899
本当に、そのプログラムは再利用されるのか？汎用性は諸刃の剣だぞ。

**名前は開発中のものです。** · 02/11/02 16:06

>>913
まあ、C/C++に限って言えば再利用なんて、ほとんど幻想に過ぎないんだが、
ここは希望的観測の意味も込めて、「安易な手法での再利用は諸刃の刃だぞ」にしとこうや。

**名前は開発中のものです。** · 02/11/02 16:19

んでも、普段からメモリを解放するクセをつけておかないと思わぬところで…ってこともあるかもね。
GCがサポートされてる言語なら別として。

**名前は開発中のものです。** · 02/11/02 16:23

・処理速度至上主義
・プログラムコードは基本的に使い捨て
・激しく機種依存するプログラムばかり組む
ゲームプログラマは特に価値観が偏っているから常識は通用しないよ。
偏りすぎていて他のジャンルでは通用しない気もするけど。

**ゲーム業界の真相** · 02/11/02 16:45

再利用ができない
↓
生産性が上がらない
↓
労働者が沢山必要
↓
１人あたりの賃金が安くなる
↓
貧乏

**名前は開発中のものです。** · 02/11/02 18:52

>>917
再利用を念頭においた結果、過度に複雑なクラスライブラリができて、結局
使われずに封印ということもある。バランス感覚重要。

っつか、ゲーム業界に限っていえばプログラマの数はむしろ少ないと思うが。

**名前は開発中のものです。** · 02/11/02 20:59

ゲームばっか作ってると、変な癖がついてしまう面はあるんじゃないの。
パフォーマンスを追及するあまり、超複雑・可読性ゼロ・再利用性ゼロみたいな。
まあ、ゲームに限って言えばそれでいいのかもしれないけど。
資産が継承できないとしたら賽の河原状態かな。

**名前は開発中のものです。** · 02/11/02 21:41

> ゲームばっか作ってると、変な癖がついてしまう面はあるんじゃないの。
気のせい。ファミコン時代ならいざ知らず、今時はそんなコードでは通用しない
程度には開発の規模が大きくなってる。

プログラマ一人で三ヵ月の仕事と、プログラマ三人で十八ヵ月の仕事だと、最適
な仕事の進め方は変わってくるわな。（さらに SI みたくプログラマ何百人みた
いな体制だと、また違ってくる）

**名前は開発中のものです。** · 02/11/02 22:36

今だと、プログラマ２～３人ぐらいのプロジェクトが多いのかな。
平均的な話。

**名前は開発中のものです。** · 02/11/02 23:03

>>916
> ・処理速度至上主義
ここはその通りだとおもうけど、下の２点は同意できないなぁ
特に機種依存コードを多用したりすると恐ろしく読みにくいコードになって、
デバッグ困難になったりするよね
もし担当が交通事故で急死したとしても、他のメンバーが問題無く引き継げるように
読みやすさ優先でコード書けって先輩にたたきこまれたクチなんだけど…

**名前は開発中のものです。** · 02/11/02 23:10

>>922 自己レス
916 は、ゲームプログラマはそういうのが多いって言ってるだけだね
勘違いしてた、もうしわけねぇ

**名前は開発中のものです。** · 02/11/02 23:18

多いって一般のプログラマとどうやって比較したのか出所提出を小一時間求めたい
ありもしない妄想を根拠として抽象的な論理を展開するのが流行りか？

**名前は開発中のものです。** · 02/11/02 23:31

そこまであちこち顔を出してる人ってそんなにいるとも思えんのう

**名前は開発中のものです。** · 02/11/02 23:32

>>924
いちいち根拠になるデータを提示しないと話が進まないような話題とは
思えませんが？そういう不毛な煽りも流行なのですか？
まず、あなたのその「一般のプログラマ」の定義からお聞かせ願えませんか？

**名前は開発中のものです。** · 02/11/02 23:50

「～という傾向がある」に対し「そうでもないんじゃない？」
という発言がきたら、論拠なり証拠なりを出さないと話が進みませんよ。

**927** · 02/11/02 23:51

あ、煽り屋か・・・スマソ

**名前は開発中のものです。** · 02/11/03 00:33

>>927
それはそうなんですが、あまり度が過ぎるとどうかな？と
端的な例ですが、
　「最近の若い者は礼儀が悪すぎる」
　「そんな事はないでしょう。論拠を示してください」
という会話を見てどう感じますか？
感想レベルの話題に対しては無意味でしょ？

**名前は開発中のものです。** · 02/11/03 00:50

920が示しているように、規模やコード資産の量などの違いでもって
やりかたは変わってくるし、それが元で傾向に違いがでてきてもおかしくないと
思うのよ。

それを「ゲームプログラマだから」とかいう括りでやっちゃうのが間違いだろ？
という話にもってくなら分るけど、>>924,926にあるようなつまんない指摘は
煽り屋と思われても仕方ないよ。

**名前は開発中のものです。** · 02/11/03 01:28

完成するころには次のハード

**名前は開発中のものです。** · 02/11/03 09:43

>>931
携帯電話プログラマも大変だねえ

**名前は開発中のものです。** · 02/11/03 10:28

>>932
そうやって無理やり変な解釈するのもどうかと思うよ。煽り？
実際、でかいプロジェクトだと、そんな感じになるっしょ

**名前は開発中のものです。** · 02/11/03 10:39

933は一行目と二行目を書く間にトイレにでも行ったんだろうかね？

**名前は開発中のものです。** · 02/11/03 10:54

多重人格者でちょうど入れ替わったタイミングと見た

**名前は開発中のものです。** · 02/11/03 11:46

>>934-935
そうか？
俺は特に違和感なかったが。

**名前は開発中のものです。** · 02/11/03 11:52

933 の２行目は、931 の事を言ってるのでは？
話の流れから言ってそうとらえたほうが自然かと

**名前は開発中のものです。** · 02/11/03 12:22

ゲームプログラムというのは基本となる技術が浅いのでは。
それで、高度な部分は激しく機種依存で数年おきにリセットされる。
熟年のベテランより体力のある若者のほうが有利な業界。

**名前は開発中のものです。** · 02/11/03 12:52

ラッパーライブラリで全部吸収…しきれないんだよねぇこれが

**名前は開発中のものです。** · 02/11/03 12:54

> 933 ：名前は開発中のものです。：02/11/03 10:28 ID:???
> 933は一行目と二行目を書く間にトイレにでも行ったんだろうかね？

> 935 ：名前は開発中のものです。：02/11/03 10:54 ID:???
> 多重人格者でちょうど入れ替わったタイミングと見た

面白い。俺は違和感なかったが、そういう発想もあるのかと。

**名前は開発中のものです。** · 02/11/03 14:02

> ゲームプログラムというのは基本となる技術が浅いのでは。
SI と携帯電話業界には言われたくない…。

**名前は開発中のものです。** · 02/11/03 14:36

931-935の解説キボン

**名前は開発中のものです。** · 02/11/03 15:01

>>938
> ゲームプログラムというのは基本となる技術が浅いのでは。
その「基本となる技術」とは具体的にどういうものを指しますか？

> それで、高度な部分は激しく機種依存で数年おきにリセットされる。
ゲームコンソールに関して言えば、メーカ提供のライブラリが
ある程度吸収してくれていると思いますが

> 熟年のベテランより体力のある若者のほうが有利な業界。
そんなことはないでしょ
若い衆は体力はあっても場数を踏んでいない分、ちょっとした
トラブルに対処できずに途方に暮れる場面をよく見かけます
業界で生き残れている年寄りプログラマは、それなりに利用価値があります

**名前は開発中のものです。** · 02/11/03 15:28

この手の話題は抽象的でいい加減な話ばかりで何の意味の無い
知ったかの横行で痛いだけ
語る前にデータを出せ、出せなきゃ語るな
だろうだろうでまともな話になるわけ無いだろう

**名前は開発中のものです。** · 02/11/03 16:13

>>943
> ゲームコンソールに関して言えば、メーカ提供のライブラリが
> ある程度吸収してくれていると思いますが
世の中そういう方向に進んでるとは思うけど、目下の最大勢力 PlayStation 2
に限って言うと、メーカ提供のライブラリはきわめて低レベル（ハード寄り）
で「メーカ提供のライブラリがある程度吸収」してくれません。

特に PlayStation 2 のアーキテクチャは特異で、VPU 用のアセンブラと DMA
の使い方が性能の鍵になるので、「CPU キャッシュって何ですか」みたいな
高レベルな世界に済んでいる人間は揃って逝きました。

>>938
> それで、高度な部分は激しく機種依存で数年おきにリセットされる。
リセットされるのは、高度な部分というより低レベルな部分だと思うけど。
衝突検出やら AI のアルゴリズムなんかは、別にハードにゃ依存しないし。

それにリセットというほどじゃないやね。新しいハードが出てきたときに
いち早く使いこなすのは、やっぱり蓄積のある人間だったりするので。

**名前は開発中のものです。** · 02/11/03 17:34

なんというか、特定ハード、特定環境でしかツカエネー奴って
本当に存在するのか謎だよ。
ここ数年でもめぐるましく環境変わってるよね。

**名前は開発中のものです。** · 02/11/03 18:42

>>946
ある程度のライブラリが整備されている PlayStation から参入したメーカー
が、PlayStation 2 時代になって

ライブラリはねーわ
開発コスト（特にグラフィック関係）はかさむわ

で撤退に追い込まれたという話は、何度か聞いた。せいぜい、その程度だろう。

**名前は開発中のものです。** · 02/11/03 18:51

瞬間最大風速だけのハードで付加機能が全然なく
出来たものはジャギーだらけのブツブツゲーム
どのハードとは言わないけれど

**名前は開発中のものです。** · 02/11/03 19:16

ゲームの価値基準って「面白いかどうか」だから、技術力が高い
だけでは評価されるとは限らない。しかも売れるものと売れない
ものの格差が激しい。技術者としては遠慮したい業種。

**名前は開発中のものです。** · 02/11/03 19:23

>>949
そういうモチベの低い人は業界的にも願い下げです
せいぜいご自身の業界でがんばっていて下さい

**名前は開発中のものです。** · 02/11/03 19:48

>>949
そりゃゲーム業界に限らん。携帯電話業界だって FOMA は普及していないでしょ？
ただし、技術力があれば表現の幅や可能性が広がる。

**名前は開発中のものです。** · 02/11/03 22:52

FOMA が普及しないのは、技術力があるかどうか以前の問題だと思うが……

**名前は開発中のものです。** · 02/11/04 00:04

FOMAが売れないのは宇多田ヒカルが結婚したせい

**名前は開発中のものです。** · 02/11/04 05:19

>>953
そうに決まってる。

ﾄｵﾓﾜﾅﾔｯﾃｹﾅﾋ...

**名前は開発中のものです。** · 02/11/04 08:08

FOMAがヒットしなかったのは名前が悪い。
MONAにしろ。

**名前は開発中のものです。** · 02/11/04 10:40

互換性が無かった
ただそれだけ

**名前は開発中のものです。** · 02/11/04 11:04

存在価値が無かった
ただそれだけ