ゲームプログラムなら俺に聞け4at TECH
ゲームプログラムなら俺に聞け4 - 暇つぶし2ch446:デフォルトの名無しさん
09/12/22 20:49:38
>>433
んー、普通に4分木、8分木使ったら?

447:デフォルトの名無しさん
09/12/22 20:51:07
表現が違うだけでそのものじゃね?

448:デフォルトの名無しさん
09/12/22 22:07:43
>>447
大事なとこが違う
木は再帰的な構造であることや、
>>438のような例外もいらないし、
>>443のような全部に登録するような
無駄もする必要がない

449:デフォルトの名無しさん
09/12/23 17:59:04
4分木、8分木、すげー!かっけー!

450:デフォルトの名無しさん
09/12/23 18:43:10
>>448
まず大まかな当たりを調べて次に細かな判定をって意味では同じじゃん
再帰云々っていまの話題に必要か?

451:デフォルトの名無しさん
09/12/23 18:44:53
>>450
必要だろ

452:デフォルトの名無しさん
09/12/23 19:44:26
>>451
なんで?

453:デフォルトの名無しさん
09/12/23 19:49:15
>>452
なんでってなんで?

454:デフォルトの名無しさん
09/12/23 20:02:12
>>453
質問に質問で返(ry

455:デフォルトの名無しさん
09/12/23 20:08:45
相変わらずレベルが高いやり取りだな

456:デフォルトの名無しさん
09/12/23 20:25:25
>>455
同意

457:デフォルトの名無しさん
09/12/24 11:24:29
>>455
Do it!

458:デフォルトの名無しさん
09/12/24 13:50:28
>>448-454
ここまで再帰。

459:デフォルトの名無しさん
09/12/24 14:01:32
対戦するたびに強くなる
将棋や麻雀やオセロや囲碁やチェスや五目並べや格ゲーや落ちゲーの対戦相手のコンピュータキャラの思考アルゴリズム作りたい
が、そういうの作るのにどういうこと学べばいいか分からない

460:デフォルトの名無しさん
09/12/24 14:12:34
大学でそういう研究してるところ探して入ったら?

461:デフォルトの名無しさん
09/12/24 14:40:23
>>459
探せば本も論文もサイトもいっぱいあるよ。
「ゲームAI」「遺伝的アルゴリズム」「ニューラルネットワーク」とかでググってみて。

462:デフォルトの名無しさん
09/12/24 14:46:53
クリスマスの奇跡だな

463:デフォルトの名無しさん
09/12/24 14:53:34
サンタの格好して空飛ぶソリから地上のカップルを射殺しまくるシューティングゲームを作りたいです

464:デフォルトの名無しさん
09/12/24 14:56:44
>>461
thanks

465:デフォルトの名無しさん
09/12/24 15:32:03
これを思い出す

Santa's Sledge Down(Black Hawk Down)
URLリンク(www.youtube.com)

466:デフォルトの名無しさん
09/12/24 15:34:56
キリスト教から苦情がくるな

467:デフォルトの名無しさん
09/12/25 00:13:22
30歳から、ゲームプログラマーになりたいのですが、なれるでしょうか?

468:デフォルトの名無しさん
09/12/25 00:20:10
知り合いに仕事につけなくて30ぐらいで自分で会社たててプログラマもやってる人いるよ

469:デフォルトの名無しさん
09/12/25 00:30:53
>>468
それはゲームプログラマーですか?

470:デフォルトの名無しさん
09/12/25 00:36:29
ゲームだよ

471:デフォルトの名無しさん
09/12/25 00:40:56
就活はこっち
ゲームプログラマの人に聞きたい 40問目
スレリンク(prog板)

472:デフォルトの名無しさん
09/12/25 01:20:10
ゲームだね

473:デフォルトの名無しさん
09/12/25 13:56:16
IPODのゲームぐらいなら個人でも作れるし、ゲーム会社名乗って一人でやれるんでは

474:デフォルトの名無しさん
09/12/25 15:45:29
PCゲームの個人製作公開は今でもやってんじゃん

475:デフォルトの名無しさん
09/12/26 18:37:10
空間分割って分割しすぎると逆に遅くなりませんか?

476:デフォルトの名無しさん
09/12/26 19:32:39
それはパソコンのスペックが1

477:デフォルトの名無しさん
09/12/26 19:44:07
waveoutだけでBGM鳴らしたりできる?

478:デフォルトの名無しさん
09/12/26 20:23:40
できます!

479:デフォルトの名無しさん
09/12/26 20:23:47
わからん

480:デフォルトの名無しさん
09/12/26 23:27:05
>475
空間数が増えることによるオーバーヘッドもちょっとあるかも。
でもそれより、分割線をまたいだ物体が著しく増えることによる
処理速度低下があるね。これは、実際に試して最適値を決めるしかない。

>477
できる。ダブルバッファリングすれば、メモリ内にあるwaveでも
ディスク上にあるwaveでもストリーミング的に再生できる。

481:デフォルトの名無しさん
09/12/27 00:04:53
モートンオーダーとか考えたやつ脳逝ってるだろ
無駄がなさ過ぎて噴いた

482:デフォルトの名無しさん
09/12/27 17:20:56
オーディオのストリーミング再生はリングバッファというのが正しい
空いているバッファを常に先行して埋め続けることにより
事実上無限に再生データが続いているイメージ

483:デフォルトの名無しさん
09/12/31 12:32:52
格闘ゲームとかだとモーション情報と判定情報はセットで外部ファイルにおいた方がいいですかね?

484:デフォルトの名無しさん
09/12/31 13:25:43
そうかもしれませんよ

485:デフォルトの名無しさん
10/01/05 18:18:32
球同士の衝突判定を行おうとしてるんだけど、一般的にどんなアルゴリズム
が使われてるのかな。良いサーベイ論文とかあったら教えてほしいです。

ちなみに自分の環境としては、静的OK、球の数が数百万~1億弱、それぞれ
の球は小さい。とりあえずモートン序列の実装はやってみた。登録は速いの
だけど問い合わせが遅いみたい。

486:デフォルトの名無しさん
10/01/05 18:53:48
レイトレを一から実装まで学べるサイトってありますか?

487:デフォルトの名無しさん
10/01/06 00:24:03
ぷよぷよと同じルールの落ちゲー作りたいんだけど
コンピュータ側の思考ってどうやってんのかな?


488:デフォルトの名無しさん
10/01/06 00:32:22
>>485
球同士の判定って2Dだろうが3Dだろうが、そんな複雑な事やらなくても出来るぞw
楕円とかだと一気に複雑になると思うけど。

489:デフォルトの名無しさん
10/01/06 00:59:23
ひょっとして3行以上の文章は読めない人かな?

490:デフォルトの名無しさん
10/01/06 01:14:13
これはもう読んだ?
URLリンク(marupeke296.com)

491:デフォルトの名無しさん
10/01/06 03:17:39
>>490
実装してみました。ただ、まだまだ遅いっぽいですね。登録は非常に速いの
だけど。アルゴリズム的に、ルートノードに多くのオブジェクトが登録
されるからだと思われます。7000オブジェクトで実験してみたところ、
衝突判定回数は10分の1くらいにしかならなかったです。
全てがxy平面に載ってるだけで全探索になるし。

>>487
単純なのは、評価関数を作って、それを最大化するように積んでく。
例えば、沢山連鎖を作れる状態に近いならば評価値を高くするとか。
積まれたぷよから、どのように評価値を計算するかが難しいですね。

492:デフォルトの名無しさん
10/01/06 03:19:51
>>488
1億個の球で全探索したら今年が終わってしまうw

493:デフォルトの名無しさん
10/01/06 03:19:53
>>485
球の大きさが一様なら空間をグリッドに分割、一様でなければ4分木に分割
空間が無限ならグリッドをハッシュに記憶、有限なら配列に記憶じゃなかろうか。

小さな球ならモートン序列だと
単なる配列のアクセスで済むから読むのも書くのも同じスピードのはずなんだが。
もしかしてどでかい配列へのポインタを記憶してるとか?

494:デフォルトの名無しさん
10/01/06 03:31:34
>>493
あ、>>490のページで、各ノードがオブジェクトへのポインタで持ってた
から、そのまま使ってたけど、どでかい配列のインデックスにすれば結構
速くなりそうですね。今からやってみます。

最初はグリッド分割でやってみたのだけど、分割が甘い場合は衝突リスト
に重複した記録が発生して、重複チェックが大変だったので却下しました。
パラメータ調節も面倒だったし。なので、分割木を使った方法を現在使って
ます。

495:デフォルトの名無しさん
10/01/06 03:37:29
>>494
一般の剛体の衝突判定しようとしてないか?
パーティクルなら中心の座標だけ記憶すればいいだろう

あと、どでかい配列は や め と け

496:デフォルトの名無しさん
10/01/06 03:51:12
>>495
インデックスで参照してみたものの、あんま変わらなかったですね^^;
衝突判定数がオーバーヘッドになってるけど、その部分はポインタ参照
しないようにしてたので。

中心と半径を記憶してます。
え、配列使わずに保持ってどうやるんですか。

497:デフォルトの名無しさん
10/01/06 04:00:11
>>496
どでかい配列で全ての球を管理する件について:
配列には領域を連続で確保するという制約があるので、
例えばdoubleで表現されたx,y座標の組を1億個配列で記憶しようとすると
1.6GBの"連続した"領域が必要になる。
また、メモリ上の位置と、x,y座標の間に関係がないためアクセスが飛び飛びになり
キャッシュヒット率がすこぶる悪くなるので遅い

このため、高速化のためにグリッドに直接座標値を記憶しておくことで
座標の近いデータがメモリ上で近くに配置されるように記憶する方法がとられる

498:デフォルトの名無しさん
10/01/06 04:04:37
>>497
つまり、グリッド内で衝突判定する時に。キャッシュミスが起きづらくなるっ
てことですね。

499:デフォルトの名無しさん
10/01/06 04:07:34
>>498
yes
ちなみにグリッドの並べ方をモートン順序にすると
近くのグリッドがメモリ上でも近くにくるので高速化になる

500:デフォルトの名無しさん
10/01/06 04:11:10
>>498
で、衝突判定だが、
①グリッドサイズを球の最大サイズよりも大きくする
②球の中心座標の属するグリッドに球を登録する
③各球について、属するグリッドと周囲の8グリッドに属している全ての球と衝突判定を行う
とすればいい
パラメータはグリッドサイズだが、グリッド数が大きくならないようであれば
球の半径の最大値にしてしまえば問題ない

501:デフォルトの名無しさん
10/01/06 04:14:25
3次元のため、グリッドは必要に応じて作成してるから、グリッドの順序は
ほぼランダムですね。全部作るとメモリが辛くなるので。

ただモートン順序は衝突判定の計算量が大きそうなのがネックかなと。

502:デフォルトの名無しさん
10/01/06 04:22:34
モートン順序は単に配列のインデックスをジグザグに取るだけなので速度には関係ないよ
順序ランダムだとグリッドにする意味がないな
メモリがきついならグリッドをでかくする。
パーティクルが存在しない空間がでかいなら
グリッドをハッシュに記憶するとメモリが節約できる。

503:デフォルトの名無しさん
10/01/06 04:31:17
>>500
どうもです、ちなみに最初はそれに近い実装をしていました。
ただし、一次元で考えて、グリッドが{0, 1, 2}のように整数上にあり、
球の直径1として、球の中心がそれぞれ0.9と、2.1にあるときに失敗します
ので、もう少し拡大する必要がありそうです。が、125セルに対して衝突判定
したり、グリッドサイズを直径の2倍とかにすると重そう。

そこで、まず各球の中心からの近傍セルに球へのポインタを登録しておき
(上の例なら中心・上下左右・斜めと27つのセルに登録)、同じセル内に
登録された球同士で衝突判定していました。一応O(n)アルゴリズムのはず。
ただ、実装の問題もありますが、1千万点のデータで、メモリ1G近くに
なったので。メモリ的にきつかったり、グリッドサイズを決めるのが難しい
かなと。

504:デフォルトの名無しさん
10/01/06 04:32:35
ちなみに>>490で紹介されている4分木(3Dなら8分木)のアルゴリズムは
物体の大きさが未知のときに使う原始的な方法。
(ノードの並べ方をモートン順序にすると、
O(1)で任意の分割サイズのノードにアクセスできるというだけ)

大きさが既知の、しかも球だと分かっているならグリッド分割でよい。

505:デフォルトの名無しさん
10/01/06 04:36:14
>>502
>グリッドをハッシュにする
それ、やってなかったです、そういえば。かなりメモリは節約できそう
ですね。計算時間は分割木を使った奴よりも速かったので、明日それを
実装してみようかな。

506:デフォルトの名無しさん
10/01/06 04:48:44
>>505
おっと、グリッドサイズは「最大の球の直径よりも大きい」だった。
(グリッドの大きさを一番大きな球の直径よりも大きくすれば、
2つ先のセルの球と衝突することはありえない。)
あと、[0:1]のセルの隣のセルが[-1:0]と[1:2]のセルなのは当然分かることなので、
球の座標からグリッド上の位置の計算と、セルに含まれる球の取得ができれば
近傍のセルにポインタを登録しなくても衝突する可能性のある球すべてにアクセスできる。

結局全部の球を登録するだけのメモリはどこかに必要なので
複数マシンで計算するとか考えなければメモリの量は考える必要ないかも

507:デフォルトの名無しさん
10/01/06 05:01:03
>>506
[0,2][2,4][4,6]のセルに加えて[1,3][3,5]みたいに重複するセルを考えて、
セルからオブジェクトがはみ出さないように登録すれば2次元なら4近傍、
3次元なら8近傍で済みそうですね。

508:デフォルトの名無しさん
10/01/06 05:02:56
あんま意味なかったですw

509:デフォルトの名無しさん
10/01/06 14:28:02
1億個も衝突判定するゲームってなんだろう
3Dゲームだとそんなにオブジェクトたくさん作るの?


510:デフォルトの名無しさん
10/01/06 14:48:32
静的OKと言ってるし、ゲームじゃない可能性のほうが高いだろ
おおかたゲーム屋なら衝突判定を減らす方法はいろいろ知ってるだろうと踏んでここで聞いたのだろよ

511:デフォルトの名無しさん
10/01/06 16:39:09
素粒子分野とか?

512:デフォルトの名無しさん
10/01/06 18:09:23
ゲーム屋ならそんなバカ正直な計算なんてしないで、
手抜きでそれっぽく見えるような手法を使うだろw

513:デフォルトの名無しさん
10/01/06 19:03:23
手抜きではなく
最適化もしくは効率化
ファミコンでドラクエ組め

514:デフォルトの名無しさん
10/01/07 09:18:21
1億個ものオブジェクトを、そもそも扱ったことがねぇw
データとしても10万個くらいをメモリにのっけたのが限度。

515:デフォルトの名無しさん
10/01/07 12:37:32
スパコン使うので余裕です^^

516:デフォルトの名無しさん
10/01/07 12:46:09
一家に一台の時代ですよね

517:デフォルトの名無しさん
10/01/07 13:17:51
OSはMEだよね

518:デフォルトの名無しさん
10/01/07 16:49:34
スパコン安くなったし。

519:デフォルトの名無しさん
10/01/07 17:02:11
スパコンでゲーム作るとか贅沢だよね

520:デフォルトの名無しさん
10/01/07 23:00:12
>>510
誤魔化す手法のがこっちはメインでね
馬鹿正直にやるんじゃ
オクツリー以上の工夫はとくに聞いたことないな
自分アレンジなら腐るほどあるだろうけどね

521:デフォルトの名無しさん
10/01/09 00:39:01
0 = M00 * x + M01 * y
0 = M10 * x + M11 * y

この連立方程式を解いて、ベクトル[x,y]を求めたい。
ただし、[x,y]は、単位ベクトルn[nx,ny]と同じ向きにしたい。
何か方法はありますか?

522:デフォルトの名無しさん
10/01/09 00:46:10
>>521
> [x,y]は、単位ベクトルn[nx,ny]と同じ向き
を式にしてみそ。

523:デフォルトの名無しさん
10/01/09 00:51:20
>>522
x = nx * s
y = ny * s
ですか?
しかし、こうすると正方行列じゃなくなるので
擬似逆行列云々と面倒な方向に・・

524:デフォルトの名無しさん
10/01/09 01:52:13
Mとnが定数だよね。0以外で解けなくね?
M00=1, M01=1, nx=cos30, ny=sin30だったら、s=0のみだし。

525:デフォルトの名無しさん
10/01/09 02:41:03
>>523
問題を書き換えると
 0 = M00 * x + M01 * y
 0 = M10 * x + M11 * y
 0 = ny * x - nx * y
となって変数に対して拘束条件が多すぎる。
更に非自明な(=(0,0)でない)解が求まるためには全ての式が平行でなければならない。
ということで(x,y) = (nx ny)が式を満たすなら(nx, ny)が欲しい解、満たさないならば解なし

526:521
10/01/09 12:57:43
理解しました。
>>521の方向は止める事にします。
ご対応頂きありがとうございました。


527:デフォルトの名無しさん
10/01/10 11:31:51
何を解こうとしたのかが気になる。

528:デフォルトの名無しさん
10/01/10 13:16:20
気にならない。

529:デフォルトの名無しさん
10/01/14 01:00:03
>>1
このスレの↓の板との違いって何?

ゲ製作技術
URLリンク(pc11.2ch.net)



530:デフォルトの名無しさん
10/01/15 00:33:06
スレリンク(gameurawaza板)
スレリンク(gameurawaza板)
助けて

531:デフォルトの名無しさん
10/01/15 01:12:08
>>529
こっちはIDがでないから自演やり放題だけどスルーされる

532:デフォルトの名無しさん
10/01/15 01:15:04
向こうはID出るから自演できないけど食いついてくるのは馬鹿ばっか

533:デフォルトの名無しさん
10/01/15 12:11:58
ゲームってカプセル化にあんまこだわらないほうがいいのかな

534:デフォルトの名無しさん
10/01/15 13:39:24
なんで

535:デフォルトの名無しさん
10/01/15 14:28:48
クラスやモジュールがきちんとカプセル化されているとこんないいことがある。

●仕様変更に強いので調整の幅が広がりゲームが面白くなる。
●バグが減り納期に余裕ができる。販売後に致命的なバグで回収騒ぎになる確率が減る。
●コードの流用性がよくなり、続編やマルチプラットフォームの展開がしやすくなり、
同じコードを何度も使いまわせるので利益率があがる。

536:デフォルトの名無しさん
10/01/15 14:57:05
バグと再利用性については疑問はないんだけど・・・
ゲームってビジネスアプリなんかと違ってentityのどのデータにアクセスしたいのかはじめから分かってるとは限らないと思う
例えば、はじめのうちは敵のステータスを取得するときHP・AP・DPだけ取得できるようにカプセル化したけど
だけど途中で特定のユニットや状況下では他の隠しステータスも取得できるようにしたくなったりしたら、そいつだけのためにインターフェースにアクセサを追加しないといけない
そうするとコンパイルとデバッグモード最初からやり直しだから、仕様の変更にはむしろ弱くならないかな?

537:デフォルトの名無しさん
10/01/15 15:32:44
それは元々、HP・AP・DPだけを管理するプログラムの設計問題であって。
モジュール化のメリットとほとんど関係がない。
例えば構造化設計で、同じようにHP・AP・DPだけを管理するプログラムを作っても
同じ問題がある。

538:デフォルトの名無しさん
10/01/15 15:34:09
モジュール化 -> カプセル化 ミス

539:デフォルトの名無しさん
10/01/15 15:43:25
なんで

540:デフォルトの名無しさん
10/01/15 15:48:35
カプセル化で仕様変更に強くなるのは、直接的には、
インターフェイスを変えない限り、中身をどんなにいじろうとも、それを扱うクラスをいじらなくてもいい。
ここは>>536でもさすがに理解していると思う。

しかし重要なのは、メンバ変数に対する責任を、そのクラスだけが持てばいいということが明らかになること。

人間に例えれば、カプセル化というのは、クラスの役割を決めるということだよ。
機能は担当する業務の内容で、メンバ変数はその仕事を遂行するのに必要なアイテム。
そのアイテムをほかの人に触られないように隠しておくことで自分の業務に責任をもてるようにする。

備品を管理する担当者がいたとして、担当者に黙って台帳を修正したり、勝手に備品を持ち出したりしたら混乱する。
カプセル化せずに混乱を解決するとしたら、社員全員が忘れずに台帳を間違いなく修正するよう努力する必要がある。
そして守らないやつも出てくるから、定期的にたな卸しして台帳と備品を付き合わせることになるし、あわないときのリカバリも大変。

台帳と備品は備品管理担当者が隠蔽しておき、
社員は必ず担当者に備品をくれと頼むようにとルールを決めるのがインターフェイス。
台帳は担当者が修正するからほかの人は台帳の存在を知る必要がない。これがカプセル化。
こうしたカプセル化によって、担当者は台帳と備品の数が常に一致しているということに責任を持てる。

ペン1本もらうのにルールを増やすのはめんどい→仕様変更に弱いという発想なんだろうけど、
実はまったく逆で、書き込む台帳が1つから2つに増えても、
逆に台帳を省略しても、それをほかの社員に教えて徹底させる必要がまったくない→仕様変更に強いというわけ。

もしこれが現実のコードなら、台帳に相当するものが増えたら、
社員全員のコードを全て間違いなく書き直さなくてはいけない。
コンパイルをやり直すってレベルじゃないよ。

541:デフォルトの名無しさん
10/01/15 16:07:03
>>536
Class Entity
{
private:
 int param1;
 int param2;
 ・・・
 int param99;

public:
 int GetParam1();
 void SetParam1(int value);
 int GetParam2();
 void SetParam2(int value);
 ・・・
 int GetParam99();
 void SetParam99(int value);
};
もしかしてこんな実装になってない?
仕様変更でインターフェースを追加しなければならなくなったということはカプセル化に失敗しているのだけど・・・

542:デフォルトの名無しさん
10/01/15 16:25:08
もしそうだとしたらカプセル化に失敗というよりインターフェイスの設計に失敗しているというべきだな。

543:デフォルトの名無しさん
10/01/15 18:32:55
>>540
実装の変更だけで済む場合に有利なのはわかってるんですが
インターフェースを変更(メソッドの追加)せざるをえない時にどうするのかなと

>>541
例としてマージャンゲーを作るとしたら
public
・updateなどのコンセプトの仮想関数
・安全を保てる範囲でより低レベルなアクセサで、敵AIが知り得る情報など(自分の牌の枚数とか捨牌情報とか)

可視性不定
・安全を保てる範囲でより低レベルなアクセサで、敵AIが知り得ない情報など(自分の手牌とか)

↑に加えてAIの継承での拡張or外部関数での拡張orスクリプトでの拡張

って感じでしょうか
ここで相手の手札が見えるイカサマAIを追加しようとおもったらインターフェースから変えないと無理ですよね
必要になる度にちまちま公開していくなら最初から公開してしまえばいいじゃないと思ったんですが

544:デフォルトの名無しさん
10/01/15 18:40:36
本当に必要な情報は何か? それを正しく計画・設計しないで安易に判断する。
素人の考えの例です。
 ↓
>必要になる度にちまちま公開していくなら最初から公開してしまえばいいじゃないと思ったんですが


545:デフォルトの名無しさん
10/01/15 19:04:59
たまに出てくる、「グローバル変数を使った方が簡単だし作りやすい!」
と言っているのと同じ臭いを感じる
その人にとってそれが良ければいいんじゃないかと思う今日この頃。

546:デフォルトの名無しさん
10/01/15 19:58:25
グローバル変数を使った方が簡単だし作りやすい

547:デフォルトの名無しさん
10/01/15 20:04:10
>>543
その例で言えば牌情報を取得するメソッドを一つ追加するだけで解決するし、それによって問題になるようなバグが発生するとも考えにくい。
それに一つのゲームが完成するまでにそんなにコロコロ仕様が変わるものではないと思うんだけど。

548:デフォルトの名無しさん
10/01/15 21:07:21
初心者は、全部publicにしないとか、global変数はあまり使わないとか、を
こころがければいいと思うよ
初心者でないなら好きにすればいいと思うよ
もっと大事なところ(面白くするとか)に頭をつかえばいいと思うよ

549:デフォルトの名無しさん
10/01/15 21:13:41
>>543
ゲームプログラマーになる前に… の本に、なぜ必要かの説明がそれなりに書かれている。
読んでみるといいよ。

550:デフォルトの名無しさん
10/01/15 23:51:03
オブジェクト思考ってむずかしそうだな・・・N88BASICだけで俺はいいや

551:デフォルトの名無しさん
10/01/15 23:57:15
オブジェクト指向なんて最初のうちは↓だと思って組んどきゃいいよ
オブジェクト=自分だけのスタティック変数が持てる小さなプログラム

552:デフォルトの名無しさん
10/01/16 00:06:43
頭の悪い発言するなよ。恥ずかしくないのか?

553:デフォルトの名無しさん
10/01/16 00:14:17
お前の頭の話?

554:デフォルトの名無しさん
10/01/16 00:30:07
>>552
頭の悪い発言するなよ。恥ずかしくないのか?

555:デフォルトの名無しさん
10/01/16 00:32:28
なんでインターフェイスの変更=悪って事になっているのだろう?
オブジェクト指向が理解できるようになるまで1年ROMってろ。

ちまちま公開しないといけないから面倒とかワロスw
寝言言う前にカプセル化したコードをきちんと作ってみろよ。
仕様変更のときに修正するコードの量が目に見えて明らかに減るから。
インターフェイスの追加なんてカプセル化の強力な利点の前には些細なことだったとわかる。

556:デフォルトの名無しさん
10/01/16 01:32:50
カプセル化って何?

557:デフォルトの名無しさん
10/01/16 07:48:36
>>541
って何がいかんの?
ド素人のおれにもわかるようにお願いします

558:デフォルトの名無しさん
10/01/16 08:37:39
>>541
はやく説明して下さいよ

559:デフォルトの名無しさん
10/01/16 08:49:31
いつも"私のオブジェクト指向論"になって荒れるよなw

560:デフォルトの名無しさん
10/01/16 09:11:20
privateなんて最初からないPythonとかは素人の作った言語なんですか?

561:デフォルトの名無しさん
10/01/16 09:12:00
>>556
URLリンク(ja.wikipedia.org)カプセル化

562:デフォルトの名無しさん
10/01/16 09:30:17
>>560
Pythonはアクセス修飾子が無いだけでprivateはあるよ。

563:デフォルトの名無しさん
10/01/16 12:08:18
>>557
privateのメンバ変数を全てアクセサで外部に公開してしまっては実質publicと変わらないので。

564:デフォルトの名無しさん
10/01/16 14:54:02
で?で?

565:デフォルトの名無しさん
10/01/16 15:02:59
あとは>>540>>561を読めば分かるだろ。

566:デフォルトの名無しさん
10/01/16 15:36:27
他人に丸投げwww本当はわかってないんだろwwwww

567:デフォルトの名無しさん
10/01/16 15:41:54
>>565
あなたは無能認定されました

568:デフォルトの名無しさん
10/01/16 16:35:29
>>564
どこが理解できないの?

569:563
10/01/16 17:10:23
実質publicと変わらないのでクラスを隠蔽できていない。

570:デフォルトの名無しさん
10/01/16 17:10:52
お前らだまされるな。俺たち試されてるんだよ。

IT関連企業勤務の暇な社員が
「どうせゲームのプログラマは底辺だからオブジェクト指向もわかってないだろう、
ちょっとからかってやろうぜ」ってモニターの向こうで笑っているんだぞ。

そうでなかったらこんな基本的な質問をしつこくするわけがない。
まさかいまどきのプログラマでオブジェクト指向を理解してないなんてことありえないだろ?

571:デフォルトの名無しさん
10/01/16 17:24:47
class X
{
public:
void set_x(int);
int get_x(void);
private:
int x;
};
これだけでもちゃんとしたカプセル化だよ
int x;をimpl *p;に変えてもクラスの外にはあまり影響しない
全公開と同じとか言ってる奴は勉強し直した方がいい

572:557
10/01/16 17:28:03
なるほど、カプセル化とかの意味は分かった。

でも、例えばゲームなんかでHPだけ取り出したいときは、やっぱり
int GetHP();
みたいな関数作っちゃいそうだよ…

573:デフォルトの名無しさん
10/01/16 17:31:59
魔法の呪文
#define private public
#define protected public

574:デフォルトの名無しさん
10/01/16 18:12:28
>>572
作って何の問題もないが何か?

例えばクラス内では -120のHPが許されてても。
外部に出す時は -数値は0で出したい時(画面表示とか)
int GetHP()
{
 if(this.HP < 0) {
  return 0;
 }
 return his.HP;
}
とか普通にやるぞ、
上限決めもやるしな

>>573
最高の呪文だな。

575:557
10/01/16 18:21:53
>>574
なるほど。
使い方次第で便利に使えそうだな。

576:デフォルトの名無しさん
10/01/16 18:28:33
問題は>>536
これはカプセル化の問題というより全体の設計とか仕様の決め方の問題のような気がする。

577:デフォルトの名無しさん
10/01/17 00:23:30
そりゃそうだ。

カプセル化の利点に気づいて、カプセル化を推し進めると、
個々のクラスの実装はシンプルでバグのないものになっていくけど、
クラス間の関連は逆に複雑で難しいものになっていく。

そこで関連を整理するためのツールとして、
UMLで図を描いてみんなでレビューしたり、
デザインパターンを適用したりするようになる。
こうしたツールを活用すると複雑な関連が一気にシンプルになったりして、
仕様変更にさらに強くなる。

オブジェクト指向のクラス設計というのはオブジェクト間の関連を設計するということ。
カプセル化してないってことは、そういうオブジェクト指向の設計技術をまったく学んでいないってことだから、
うまく設計できてるわけがない。

578:デフォルトの名無しさん
10/01/17 20:00:47
オブジェクトの協調で相互参照が絡むと混乱してしまう俺ブランカ

579:デフォルトの名無しさん
10/01/18 02:36:40
オブジェクト指向わかってないアホの意見乙www
ちゃんと設計してあれば「複雑で難しいものになっていく」なんてねえよwww

580:デフォルトの名無しさん
10/01/18 03:55:15
>>579
>>577と言ってること同じだぞ。

ちゃんと設計しない→複雑
ちゃんと設計する→簡単

そしてその「ちゃんと設計する」方法論ってのがあって、
>>577はそこまで踏み込んで言及している。

581:デフォルトの名無しさん
10/01/18 05:37:27
ゲーPGのいうカプセル化ってちゃんと理解していってるのかわからない
グローバル変数使った時点でこんなの成り立たないんだけど
ちゃんとC++を使っているとしている開発でも普通にグローバル変数使ってたりするからな

グローバル変数を使う使わないなんて低レベルな問題に見えるけど
設計時点ではでない関連をグローバル変数で渡すことによって作られてしまっていることに
気がついてないアフォが結構いて信用できない

582:デフォルトの名無しさん
10/01/18 08:56:42
うるせぇなカス。最初からどこからでもアクセス可能であるって設計なんだよ

583:デフォルトの名無しさん
10/01/18 14:08:59
>>582
カス先輩ゴメンな

584:デフォルトの名無しさん
10/01/18 18:56:44
>>582
そしたらもうカプセル化なんて全く意識する必要ないよ
っていうかしてるつもりでまったくやってないしできてないと思う

これが理解できないところですでに語るに落ちるっていうかw
意味ないなぁ・・・っていうかw
ホントアレな感じw

585:デフォルトの名無しさん
10/01/18 23:25:06
なんでカプセル化語ってるだけで、そんなに偉そうになれるのか分からん

586:デフォルトの名無しさん
10/01/19 00:08:13
>>585
ほとんどの奴がやったつもりになってるだけでできてないから
グローバル変数使ってる奴は100%できてない

587:デフォルトの名無しさん
10/01/19 00:48:09
カプセル化議論スレでもあればいいのにね

588:デフォルトの名無しさん
10/01/19 08:55:59
そんなことよりゲーム作りの話しようぜ!

589:デフォルトの名無しさん
10/01/19 13:48:01
もぐらたたきゲームって難しいね

590:デフォルトの名無しさん
10/01/19 13:51:06
つくるのが?

591:デフォルトの名無しさん
10/01/19 14:17:30
そうだよ。ここ何のスレだと思ってるんだよ^^;

592:デフォルトの名無しさん
10/01/19 14:38:49
雑談?

593:デフォルトの名無しさん
10/01/20 00:18:40
モグラたたきねぇ・・・
まずモグラ一匹一匹をカプセル化して
生き死にのフラグを用意して
頭出す穴の位置と次どの穴から頭出すかの思考ルーチン




594:デフォルトの名無しさん
10/01/20 15:37:34
こんな古典的OO話は前世紀までにしておけよw

595:デフォルトの名無しさん
10/01/21 03:05:47
(´・ω・`)やーだお

596:デフォルトの名無しさん
10/01/21 03:30:53
半年悩んだ不具合の原因がわかったので記念ぱぴこ♪
バグ箇所は目をつけてたとこと全然違かったワロスwww
ゲームって都度都度状況が変わるから、デバッグ難しいよね、

>>597
うるせー、えらそうに!!
詩ね!

597:デフォルトの名無しさん
10/01/21 04:00:45
バカじゃん

598:デフォルトの名無しさん
10/01/21 11:58:04
>>597


599:デフォルトの名無しさん
10/01/21 16:05:39
さすがゲーム業界は底辺クズが多いな

600:デフォルトの名無しさん
10/01/21 16:42:50
自己分析乙w

601:デフォルトの名無しさん
10/01/21 17:15:49
俺に聞け

602:デフォルトの名無しさん
10/01/21 19:23:03
(´・ω・`)いやぷー

603:デフォルトの名無しさん
10/01/21 19:24:01
例外とどうつきあっていけばいいの?

604:デフォルトの名無しさん
10/01/21 19:25:57
次の質問どうぞ

605:デフォルトの名無しさん
10/01/21 21:17:51
この際、例外でもいいから
誰かと付き合いたい

606:デフォルトの名無しさん
10/01/21 21:21:58
>>603
付き合わないのがベスト!

607:デフォルトの名無しさん
10/01/22 14:03:57
例外ってC++の例外のこと?
RAII(ディスポーズパターン)を忠実に守っていたら簡単に付き合えるよ。

608:デフォルトの名無しさん
10/01/22 14:05:12
RAII麦畑で捕まえて

609:デフォルトの名無しさん
10/01/23 00:20:59
投げたのに誰も捕まえてくれません
どうしたらいいでしょうか

610:デフォルトの名無しさん
10/01/23 01:23:27
例外をスルーしたら怒られるようにってできた気がするけどあれは最悪だった
いちいち関数の中みてどういう例外を返してるか調べないといけないの
作った奴マジで死ねと思ったドキュメントも書かねーしよー

自分に酔ってる奴が書いたプログラムってマジで最悪だと思う

611:デフォルトの名無しさん
10/01/23 11:59:47
C++で例外なんか使うなよJK

612:デフォルトの名無しさん
10/01/23 12:08:42
え?

613:デフォルトの名無しさん
10/01/23 19:17:32
ろ?

614:デフォルトの名無しさん
10/01/23 19:24:11
い?

615:デフォルトの名無しさん
10/01/23 19:45:18
か?

616:デフォルトの名無しさん
10/01/23 23:54:31
JKエロイカ完成おめ

617:デフォルトの名無しさん
10/01/24 03:31:47
自作自演プ

618:デフォルトの名無しさん
10/01/24 05:38:40
例外が気の利いた assert だとするなら、コンシューマでは全く不要だ。
出荷時に例外が投げられるケースが全く無い(ハズ)なら、リリース版では例外無しでビルドされて構わないし、そうならば資源的にも例外無しでビルドされるべきだろう。
というわけで、俺もコンシューマではC++例外は不要だと思う。

開発中は、仕様バグとかデータバグとかで一々ハングされても困るケースで、有用なこともあるかと思うけどね。
例外使わなくてもなんとでもなるけど。

619:デフォルトの名無しさん
10/01/24 06:05:12
ていうか、例外だとどこで落ちたのかわかんねーよ
try-catchのどっかだろ?ってなんでそんないい加減なんだよ
範囲でかすぎてまったくつかえねーよ
なんでそんな大まかなんだよ

620:デフォルトの名無しさん
10/01/24 10:40:20
>>618

例外=復旧不可能なエラーだと思っている?
たとえば複数の関数を呼び出して1つでもエラーが発生したらほかの処理、みたいなことってあるだろ?
うちの社内では普通に例外使ってるけど。

>>619

もしかしてintやcharを例外として投げてる?
exceptionを継承したオブジェクトを例外として送出しないとそう誤解するかもしれない。

エラー処理を細かく制御したい場合はサブクラスを深いところでキャッチ、
エラー処理がどんぶりでいいところはスーパークラスを浅いところでキャッチする。
これが例外を使うときの原則。

例えばファイル処理クラスがあったとして、ロード処理でファイルが見つからない場合は
FileErrorExceptionを継承したFileNotFoundExceptionを返すとする。
あるゲームではファイル名に特定のルールがあって、どちらかのファイルがなければどちらかのファイルがある
そのばあいは読み込み処理でFileNotFoundExceptionをキャッチして

621:デフォルトの名無しさん
10/01/24 10:42:48
あれ?今後の流れ
URLリンク(www.unkar.org)

622:デフォルトの名無しさん
10/01/24 10:43:27
途中で送ってしまった。書き直し。

例えばファイル処理クラスがあったとして、ロード処理でファイルが見つからない場合は
FileErrorExceptionを継承したFileNotFoundExceptionを返すとする。

あるゲームではファイル名に特定のルールがあって、どちらかのファイルがなければどちらかのファイルがあるみたいな決まりが合って、
ファイルの存在を見て処理を切り分けているとする。
その場合は読み込み処理でFileNotFoundExceptionをキャッチして、別のファイルを探しに行く処理を書く。

また別のゲームではファイルがなかったら画面にエラーを出すだけかもしれない。
その場合はFileErrorExceptionをmainに近いところでキャッチしておけば、
様々な読み込み処理でエラー処理を省ける。

こういう感じで必要に応じて対応のレベルを切り替えるわけだけど、
そういう対応をライブラリをいじることなく対応できてしまうのが例外のいいところ。

623:デフォルトの名無しさん
10/01/24 13:18:42
例外はエラーが起きた行番号と値を表示してくれないから嫌いだ

624:デフォルトの名無しさん
10/01/24 14:29:58
例外って決定的な矛盾があるんだよな
エラーが発生したら、例外を投げてcatchで復旧を~とか言うけどさ、
catchでやれることなんてないから!
何も出来ないから投げているんであって!
精々abort()呼ぶのが関の山ワロス

仕様が無いから、goto代わりに使っても、
VCはいちいちメッセージうるせーし、使えネーよマジぱねえっす


625:デフォルトの名無しさん
10/01/24 14:34:37
例外は中間の関数は下位のエラーや上位への通知を気にしないで作れるからいいな

626:デフォルトの名無しさん
10/01/24 14:41:43
俺は仕事でC++やったことないけど、
他人の作ったC++ライブラリ使ったソフトのデバッグは、正直死ぬと思う。
C++は何投げられるのかわからんクソ仕様だし、例外まわり網羅出来ないでしょ。
実際どうしてるんだろうね。

627:デフォルトの名無しさん
10/01/24 14:46:19
言語設計が糞だものなぁ
美しいJavaを見習うべきだ

628:デフォルトの名無しさん
10/01/24 14:48:58
返り値チェックだとエラーの伝播がすごいめんどくさい
一番深いところでエラーチェックして、エラーコードを返して、
その上でまたエラーチェックして、さらに上に・・・みたいな事をしなくてはならなくなる
RAIIを守ったうえでの例外なら少ない記述で安全にmainまで返すことができる
mainに戻るまでに復帰したいときもコードを簡単に書ける

629:デフォルトの名無しさん
10/01/24 14:52:24
なに投げるのかなんて実装依存
最初から投げるもん決まってたら実装隠蔽できねーだろ

630:デフォルトの名無しさん
10/01/24 15:08:07
>>628
末端のエラーをmainに返すという発想がおかしい
基本的に、エラーを見つけた階層で(呼びもとの関数とか)で処理しないといけない。
処理できなければさらに上に返すんだけど、それは普通、別の種類のエラーになる。

伝播するというより、それぞれの階層で決められた処理をするべき

631:デフォルトの名無しさん
10/01/24 15:09:09
いるよね、俺が理解できない機能は使うなっていう奴。

今のゲームプログラマって、アセンブラ、C言語、C++まで卒なくこなすプログラマと、
C言語しかわからないプログラマに二極化しているような気がする。

632:デフォルトの名無しさん
10/01/24 15:10:17
>>631
自分ひとりで仕事してるんならお好きにどうぞ

633:デフォルトの名無しさん
10/01/24 15:12:11
>>630

そんなのケースバイケースだよ。
上位でキャッチすべき、下位でキャッチすべきという決め付けがそもそもおかしい。

処理の仕様によって、エラーを見つけた階層で処理しないといけないものもあれば、
もう少しmainよりで処理しないといけないものもある。
完全に復旧不可能なエラーならmainに返すこともある。

利用している関数が同じでも、その関数を利用しているアプリによって、
どの階層でエラーを処理するのかを自由に決めることができるのが例外なわけで、
処理する階層を決め付けられたら例外の利点がだいなしになってしまう。

634:デフォルトの名無しさん
10/01/24 15:13:09
>>632
残念、某大手勤務だけど自分の知っている限り社内全部C++で例外も普通に使ってる。

635:デフォルトの名無しさん
10/01/24 15:20:44
main() {
    game g;
    try{
        g.run();
    }
    catch(以下略

RAII徹底して、これでいいじゃん
細かく見ていきたい場合は末端で個別にtryして復旧する

636:デフォルトの名無しさん
10/01/24 15:40:03
>>634
大手ってどこ?

637:デフォルトの名無しさん
10/01/24 15:52:24
なんでもいいからさっさとfinallyつけろよカス

638:デフォルトの名無しさん
10/01/24 15:53:43
>>630
同意

639:デフォルトの名無しさん
10/01/24 16:00:41
新しい概念に付いていけないだけじゃない

640:デフォルトの名無しさん
10/01/24 16:01:53
mainまで返さなくても例外で階層ごとに処理できるじゃん。しかも簡単に

641:デフォルトの名無しさん
10/01/24 16:04:41
>>630=638

必死だな。

例外わかってないの、お前の会社だけだぞ…。

642:デフォルトの名無しさん
10/01/24 16:06:30
例外初心者はfinallyを欲しがる。

しかしRAIIを徹底すると、むしろ無いほうがよいということに気づく。

643:デフォルトの名無しさん
10/01/24 16:25:04
ゲーム業界でC++が急速に普及しだした10年前を思い出させるような議論だね。
当時はオブジェクト指向不要論が凄かった。
今ではそんな批判する人は業界にはほとんどいなくなったんじゃないかな。

ここで例外を批判している人は、さぞかしすばらしいコードを書いてるんだろう。
バグが少なく、他のプロジェクトにコードを流用するのも簡単なのだろう。
何にも不満が無いから新しいパラダイムに手を出す必要性を感じないのかもしれない。

俺はアセンブラやC言語の時代は、設計ミスによる不具合や汎用性の低さに結構悩まされていた。
同僚の影響でC++を使い始め、STLや例外やデザパタも熟知するようになり、
設計ミスだと感じることはほとんどなくなった。

俺が例外を本格的に使い始めたのはC++を使い始めて数年経ってからだったけど、
エラー処理のコード自体が減るってのが何よりいい。
コード量とバグの量は相関関係があると思う。コードが減るとバグも減る。
やはり先人の知恵は偉大だと思ったよ。

644:デフォルトの名無しさん
10/01/24 17:13:01
きっと未だにタス・・おっと新聞屋の集金がきたようだ

645:デフォルトの名無しさん
10/01/24 21:02:58
タスポ?

646:デフォルトの名無しさん
10/01/24 22:41:13
え?

647:デフォルトの名無しさん
10/01/25 00:57:22
これは釣りだろうな

648:デフォルトの名無しさん
10/01/25 01:17:35
>>640
それに意味を感じないな
trycatchとか書く意味がわからない
ひとつひとつ戻り値や引数でステータス返したほうがいいじゃん
実装するのがそんなに手間か?

っていうか時間かかるのは設計であって実装はそんなにかからないでしょ?
実装に時間かかっちゃうの?

649:デフォルトの名無しさん
10/01/25 01:37:46
剛体変換前後の三次元点(前X1、後X2)がわかっているときに3x3回転行列Rと3x1平行移動成分tを求めるにはどうやったらいいですか?
X2=R*X1+tのRとtです。

650:デフォルトの名無しさん
10/01/25 01:40:46
↑ですけど、わかっている点の数は複数(n点)です。

651:デフォルトの名無しさん
10/01/25 01:40:53
>>649
もうちょっと問題を整理してこいよ
それとそんなピンポイントできかないでぶっちゃけ何がやりたいんだけど・・・
ってきいたほうがよくね?

652:デフォルトの名無しさん
10/01/25 05:23:27
>>622
個人的には、コンシューマではファイルアクセスのエラーはレギュラーケースだと思うので、例外を使うべき場面だとは思えない。

>>649
X1 の座標系にあるn個の点群と、X2 の座標系にあるn個の点群の話でいいんだよな?
X1 の変換から X2 の変換への変換を得るには、X1 の逆行列に X2 をかければよい。
X1 の変換が分からないはずは無い。X2 の点群から X2 の変換を得る方法が分からないということなら、そんな基礎的なことを掲示板の投稿で講義してられないから、勉強しなおすしかない。

653:デフォルトの名無しさん
10/01/25 05:32:18
>>652
レギュラーケースになるかイレギュラーケーになるのかはゲームタイトルによるだろ?
同じライブラリを複数のゲームタイトルに使いまわすだろ?
それともタイトルごとにライブラリを作り直すのか?

654:デフォルトの名無しさん
10/01/25 05:49:24
>>649
「『最小距離による回転』後の平行移動のみによって変換がなされる」として良いならばですが……

変換前の3点から平面〈N1,D1〉、変換後の3点から平面〈N2,D2〉を算出。
法線の変換を、回転軸 A = N1×N2/|N1×N2| と 回転角 θ = arccos(N1・N2) から四元数 q = cos(θ/2) + Asin(θ/2) として求める。
四元数qを行列に変換し、回転行列Rとする。
移動成分tはD1,D2より、 t = (D2-D1)×N2 で求める。

問題を平面の変換として捉えて、"法線の回転"と"平行移動距離の変化"に分けて考えればよいかと思います。

……といっても、上記はコード書かずに頭捻っただけなので過信禁物でお願いします。
もっと効率のよい、セオリー的な解法があるかも。それ以前に間違ってるかも。
「姿勢制御 四元数」でググるとヒントになるかもしれません。

655:デフォルトの名無しさん
10/01/25 07:59:46
>>648
例外のほうがはるかに楽で安全だから例外使うんだよ
むしろ返り値とかでやる意味がわからない
なんでわざわざ手間がかかってバグが潜みやすいほうを選ぶの?

656:デフォルトの名無しさん
10/01/25 10:25:49
>>655

>>648は意味がわからないって言ってるんだし、本当に使い方わかってないだけでしょ。

657:デフォルトの名無しさん
10/01/25 19:51:25
DirectShowで音楽のMP3を再生させるとき、ループ再生ってどうやってる?

例えば、50秒12345サンプルまで再生されたら、再生位置を
12秒510サンプルへ戻す…みたいな処理。
Win32APIのwaveOutならやり方わかるんだけど。

658:デフォルトの名無しさん
10/01/26 01:42:28
>>655
try-catchでかこった部分のどこでコケたのか単純にわかりにくいじゃん
何か利点ある?
動かしてみないとどれがどうなるのかわからないんだぜ
ソース見て書いてあるほうが単純によくね?
わざわざ汚くしてる気がする

659:デフォルトの名無しさん
10/01/26 02:13:53
ダブルバッファって何ですか?

660:デフォルトの名無しさん
10/01/26 02:23:13
ビデオRAM(VRAM)と言うのがある。
画面に表示されるそのままのイメージとしてメモリに保持している。
画面のリフレッシュがあり、通常は60Hzでスキャンしている。
ここでVRAMに直接書き込むとそれが画面に表示されるのだが、
タイミングにより画面がチラチラする、そして非常に遅い。
そこで、
V-RAMを2個用意する、表示するV-RAMと書き込むV-RAMの2個。
そしてリフレッシュにあわせて交互に切り替える。
これで画面のチラチラも無いそして高速で働く。
ダブルバッファより多いトリプルバッファもある。


661:デフォルトの名無しさん
10/01/26 03:01:40
なんか畑違いのPG(多分底辺デジドカ)が自分でも叩けそうなスレ見つけて
ちょっと居着いちゃってるみたいな感じなんだろうか現状は

662:デフォルトの名無しさん
10/01/26 03:26:52
>>660
ありがとう

663:デフォルトの名無しさん
10/01/26 04:33:07
2Dゲームプログラミングの入門にマインスイーパとか倉庫番というのはよく聞きますが
3Dゲームプログラミングの入門ではどういうゲームをまず作ったらいい感じですか。

664:デフォルトの名無しさん
10/01/26 04:49:25
ルービックキューブ

665:デフォルトの名無しさん
10/01/26 07:23:06
ルービックキューブって何ですか?

666:デフォルトの名無しさん
10/01/26 09:50:33
3Dの何をやるかによる。
データは2Dで表示が3Dとかもあるし。
マインスイーパや倉庫番の表示だけ3Dとか、データも3Dにするとかしてみたら。

667:デフォルトの名無しさん
10/01/26 11:03:54
普通に嫌です。

668:デフォルトの名無しさん
10/01/26 11:08:54
FPSじゃねーの


最新レス表示
レスジャンプ
類似スレ一覧
スレッドの検索
話題のニュース
おまかせリスト
オプション
しおりを挟む
スレッドに書込
スレッドの一覧
暇つぶし2ch