10/01/17 00:23:30
そりゃそうだ。
カプセル化の利点に気づいて、カプセル化を推し進めると、
個々のクラスの実装はシンプルでバグのないものになっていくけど、
クラス間の関連は逆に複雑で難しいものになっていく。
そこで関連を整理するためのツールとして、
UMLで図を描いてみんなでレビューしたり、
デザインパターンを適用したりするようになる。
こうしたツールを活用すると複雑な関連が一気にシンプルになったりして、
仕様変更にさらに強くなる。
オブジェクト指向のクラス設計というのはオブジェクト間の関連を設計するということ。
カプセル化してないってことは、そういうオブジェクト指向の設計技術をまったく学んでいないってことだから、
うまく設計できてるわけがない。
578:デフォルトの名無しさん
10/01/17 20:00:47
オブジェクトの協調で相互参照が絡むと混乱してしまう俺ブランカ
579:デフォルトの名無しさん
10/01/18 02:36:40
オブジェクト指向わかってないアホの意見乙ｗｗｗ
ちゃんと設計してあれば「複雑で難しいものになっていく」なんてねえよｗｗｗ
580:デフォルトの名無しさん
10/01/18 03:55:15
>>579
>>577と言ってること同じだぞ。
ちゃんと設計しない→複雑
ちゃんと設計する→簡単
そしてその「ちゃんと設計する」方法論ってのがあって、
>>577はそこまで踏み込んで言及している。
581:デフォルトの名無しさん
10/01/18 05:37:27
ゲーＰＧのいうカプセル化ってちゃんと理解していってるのかわからない
グローバル変数使った時点でこんなの成り立たないんだけど
ちゃんとＣ＋＋を使っているとしている開発でも普通にグローバル変数使ってたりするからな
グローバル変数を使う使わないなんて低レベルな問題に見えるけど
設計時点ではでない関連をグローバル変数で渡すことによって作られてしまっていることに
気がついてないアフォが結構いて信用できない
582:デフォルトの名無しさん
10/01/18 08:56:42
うるせぇなカス。最初からどこからでもアクセス可能であるって設計なんだよ
583:デフォルトの名無しさん
10/01/18 14:08:59
>>582
カス先輩ゴメンな
584:デフォルトの名無しさん
10/01/18 18:56:44
>>582
そしたらもうカプセル化なんて全く意識する必要ないよ
っていうかしてるつもりでまったくやってないしできてないと思う
これが理解できないところですでに語るに落ちるっていうかｗ
意味ないなぁ・・・っていうかｗ
ホントアレな感じｗ
585:デフォルトの名無しさん
10/01/18 23:25:06
なんでカプセル化語ってるだけで、そんなに偉そうになれるのか分からん
586:デフォルトの名無しさん
10/01/19 00:08:13
>>585
ほとんどの奴がやったつもりになってるだけでできてないから
グローバル変数使ってる奴は１００％できてない
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話は前世紀までにしておけよｗ
595:デフォルトの名無しさん
10/01/21 03:05:47
(´・ω・`)やーだお
596:デフォルトの名無しさん
10/01/21 03:30:53
半年悩んだ不具合の原因がわかったので記念ぱぴこ♪
バグ箇所は目をつけてたとこと全然違かったワロスｗｗｗ
ゲームって都度都度状況が変わるから、デバッグ難しいよね、
>>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
自己分析乙ｗ
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
例外＝復旧不可能なエラーだと思っている？
たとえば複数の関数を呼び出して１つでもエラーが発生したらほかの処理、みたいなことってあるだろ？
うちの社内では普通に例外使ってるけど。
>>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を２個用意する、表示するV-RAMと書き込むV-RAMの２個。
そしてリフレッシュにあわせて交互に切り替える。
これで画面のチラチラも無いそして高速で働く。
ダブルバッファより多いトリプルバッファもある。
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じゃねーの