トップページ⇒tech
1001コメント224KB

ゲームプログラムなら俺に聞け10

■ このスレッドは過去ログ倉庫に格納されています
0001デフォルトの名無しさん2010/09/09(木) 17:51:54
ゲーム開発に関してプログラムの観点からアプローチするスレッドです。
一応質問も受け付けます。
ソースをうｐするとアドバイスがもらえるかもしれません。
なお、このスレの内容は鵜呑みにしないこと。

【前スレ】
ゲームプログラムなら俺に聞け9
http://hibari.2ch.net/test/read.cgi/tech/1281851738/

【過去スレ】
ゲームプログラムなら俺に聞け
http://pc12.2ch.net/test/read.cgi/tech/1230890476/
ゲームプログラムなら俺に聞け2
http://pc12.2ch.net/test/read.cgi/tech/1247292664/
ゲームプログラムなら俺に聞け3
http://pc12.2ch.net/test/read.cgi/tech/1251324391/
ゲームプログラムなら俺に聞け4
http://pc12.2ch.net/test/read.cgi/tech/1255833802/
ゲームプログラムなら俺に聞け5
http://pc12.2ch.net/test/read.cgi/tech/1267290018/
ゲームプログラムなら俺に聞け6
http://pc12.2ch.net/test/read.cgi/tech/1269578438/
ゲームプログラムなら俺に聞け7
http://pc12.2ch.net/test/read.cgi/tech/1274521960/
ゲームプログラムなら俺に聞け8
http://hibari.2ch.net/test/read.cgi/tech/1278304182/
0153デフォルトの名無しさん2010/09/12(日) 18:24:58
結局これといった（誰もが納得する）シーン遷移のコードは無いし
C++しらんかったらグローバル変数使ったダサいコードが出てくるわけで
いつも議論がループする要因になってる。
0154デフォルトの名無しさん2010/09/12(日) 18:25:24
C++のいいところはその間違ってる場合を選択的にコンパイルエラーにすることもできる所だよね
0155デフォルトの名無しさん2010/09/12(日) 18:25:28
タスクシステムでひちよぅ十分
0156デフォルトの名無しさん2010/09/12(日) 18:25:56
>>154
そんなことできるの？具体的に。
01574552010/09/12(日) 18:26:58
へえ
0158デフォルトの名無しさん2010/09/12(日) 18:28:38
>>156
ＴＭＰとかその手のイディオムでできるっしょや
まあ全部が全部できるわけじゃないけどね
0159デフォルトの名無しさん2010/09/12(日) 18:29:00
>>152
ステートパターンって何回もでてるでしょ。
0160デフォルトの名無しさん2010/09/12(日) 18:30:21
>>158
それじゃぜんぜん役に立たない
0161デフォルトの名無しさん2010/09/12(日) 18:30:29
みんなすげーな
HSP ではどうすればいいの？
0162デフォルトの名無しさん2010/09/12(日) 18:31:11
窓から投げ捨てる
0163デフォルトの名無しさん2010/09/12(日) 18:37:48
ドライバと併せて不得手な場面の底上げに注力するのがGeForce。結果最低フレームレートがラデよりかなり高い。

ドライバと併せて得意な場面をより伸ばし、不得手な場面を犠牲にするのがRADEON。結果最高フレームレートがゲフォよりかなり高い。

しかしそもそもモニターのリフレッシュレートは60Ｈｚが標準なので、得意な場面で200ｆｐｓとかｗでてもまったく無駄。

電力の無駄なのでV-Syncを待つなどの設定でgpu側を強制的に60ｆｐｓにリミットするのが常識。

しかし未だに60fps以下でしか描画出来ない重い場面での底上げの最適化をGeForceは常に怠らないのでそういった局面で非常にパワーを体感できる。

逆に馬鹿なRADEONはベンチの結果だけを優先させるのでボトルネックとなっている問題点をいつまでも改善せず、決してモニタに反映されることの無い

無駄な上澄みを紙面に載せるベンチの為だけに稼ぐ様な改善を未だに続けている。これ事実、使えばわかるよ。
0164デフォルトの名無しさん2010/09/12(日) 18:37:49
>>160
たとえば？
全然って言うほどだから挙げ切れないぐらい発生してるんだよね？
0165デフォルトの名無しさん2010/09/12(日) 18:38:37
>>164
たとえば多重継承の阻止はどうやってするの
0166デフォルトの名無しさん2010/09/12(日) 18:41:41
必要だから可能なのであって阻止する必要がない
0167デフォルトの名無しさん2010/09/12(日) 18:42:14
おまえは議論を読み直せ
0168デフォルトの名無しさん2010/09/12(日) 18:42:59
レベルが低すぎて読む気にならない
0169デフォルトの名無しさん2010/09/12(日) 18:43:26
逃げたｗ
0170デフォルトの名無しさん2010/09/12(日) 18:49:21
>>165
すべて拒否するのは知らん
でも特定の組を拒否することは静的な能力照会でできる
ほかには？
0171デフォルトの名無しさん2010/09/12(日) 18:50:06
>>170
すでに意味なくなってるけどテンプレートを禁止するには？
0172デフォルトの名無しさん2010/09/12(日) 18:50:42
Cでコンパイルする
0173デフォルトの名無しさん2010/09/12(日) 18:52:13
まあでもCで大規模なプログラムやったことないから
C++になって俺らがどれほどの恩恵うけてるのかってのは正直実感無いんだよな。

クラスでプログラムが整理しやすくなって効率よくなってるのか
間違った継承とかで無用にバグを増やして効率わるくなってるのか
どっちもあると思うがどっちが優勢なのかわからん
0174デフォルトの名無しさん2010/09/12(日) 18:53:36
アホが使うとマイナス
そうでなければプラス
もう結論は十年以上前に出てるだろ
0175デフォルトの名無しさん2010/09/12(日) 18:54:32
>>174
なんの意味もない結論だな
0176デフォルトの名無しさん2010/09/12(日) 18:57:15
いや、意味はあるだろ
少なくともアホはC++使わないほうがいいってことがわかるだけでも有益
0177デフォルトの名無しさん2010/09/12(日) 18:58:08
といっているやつに限ってアホという矛盾に対応できないから無駄
0178デフォルトの名無しさん2010/09/12(日) 18:59:44
OOPが問題なのは、最初に勉強した時に「これは便利だ！」って思った使い方が大体間違ってる事なんだよ
そんでそれが間違いであることをちゃんと言う入門書がほとんど無い。
すくなくともC++にとって差分プログラミングなんて害悪でしかないんだが
0179デフォルトの名無しさん2010/09/12(日) 19:01:22
>>145
D&Eに書いてあったと思うけども、ストラウストラップとしては
適宜C++の機能を一部制限したサブセット言語としての実用も想定していたっぽい
要するにコーディング規約のレベルで対応すべきってことなんだろうか
（グーグルが有名だが、例外は禁止とか）
0180デフォルトの名無しさん2010/09/12(日) 19:03:54
C++にコーディング規約チェックツールってあったっけ
0181デフォルトの名無しさん2010/09/12(日) 19:10:48
俺はタスクシステム好きだぜ。
面白いじゃん、関数ポインタひとつで、単なるメモリブロックに
「クラス」と「状態」の両方の意味を与えてしまうあたりが。
状態に関しては、今ならStateパターンとかStrategyパターンとかって話に
なるんだろうが、昔はそんなの無かったしな。
関数ポインタで状態を表せることはタスクシステムの重要なメリットの一つだと
思ってるんで
0182デフォルトの名無しさん2010/09/12(日) 20:13:33
そうなのか？
0183デフォルトの名無しさん2010/09/12(日) 20:24:45
シンタックスのサポートがないと多態とかカプセル化とかを簡単に実装できないけど、
Cでも意識すれば十分OOPできるもんな。
0184デフォルトの名無しさん2010/09/12(日) 20:40:53
アクセス修飾子はCでは難しいと思う。
0185デフォルトの名無しさん2010/09/12(日) 20:48:18
publicかprivateの2択だね
0186デフォルトの名無しさん2010/09/12(日) 20:50:36
クラスインスタンスメンバをprivateにするのは容易じゃないだろ
0187デフォルトの名無しさん2010/09/12(日) 20:54:56
typdef struct iface_ { void (*hoge)(void *); } iface;

typedef struct impl_ { iface i; data d; } impl;

impl_hoge(void *) { ・・・ };

iface * create_impl(void)
{
impl * p = (impl*)malloc(sizeof(impl));
p->i.hoge = impl_hoge;
p->d = init_data;
return (iface*)p;
}

iface * p = create_impl();

p->hoge(p);

でもめんどい
C++でvirtualしたほうが１０倍楽だよね
0188デフォルトの名無しさん2010/09/12(日) 20:59:40
virtual関係ない
0189デフォルトの名無しさん2010/09/12(日) 21:03:03
>>188
いや、ある
0190デフォルトの名無しさん2010/09/12(日) 21:07:04
多態じゃない限りないだろ
0191デフォルトの名無しさん2010/09/12(日) 21:10:27
impl_hoge_2(void *) { ・・・ };

iface * create_impl_2(void)
{
impl * p = (impl*)malloc(sizeof(impl));
p->i.hoge = impl_hoge_2;
p->d = init_data;
return (iface*)p;
}

iface * p = create_impl();
iface * q = create_impl_2();

p->hoge(p);
q->hoge(q);

どうやら多態したようです
0192デフォルトの名無しさん2010/09/12(日) 21:12:47
そりゃ書きゃできるだろ。できるできないの話じゃない。
0193デフォルトの名無しさん2010/09/12(日) 21:14:15
書きゃできるとか、もっとましな反論できないの？
0194デフォルトの名無しさん2010/09/12(日) 21:16:26
お前絡むねｗ。
＞クラスインスタンスメンバをprivateにするのは容易じゃないだろ
でvirtualは難易度の差に関係ないでしょと言ってるのｗ
0195デフォルトの名無しさん2010/09/12(日) 21:16:41
ゲームプログラムの話は無いのか
0196デフォルトの名無しさん2010/09/12(日) 21:19:31
オブジェクト指向もゲームプログラムの話ではある。
俺様オブジェクト指向で開発ママならなくなるプロジェクトいくつも見た。
0197デフォルトの名無しさん2010/09/12(日) 21:20:09
>>194
別にそいつへのレスで書いたんじゃない
>>183のつぶやきにつられて俺もつぶやいただけだよ
これはすれ違いが生んだ悲劇だってことさ
0198デフォルトの名無しさん2010/09/12(日) 21:26:03
ここはツィーターじゃねーっつーの
0199デフォルトの名無しさん2010/09/12(日) 22:51:34
コンピュータで出来ることはすべて
アセンブラやC言語により記述可能である。
CPUの中にはクラスなど存在しないのだから。
0200デフォルトの名無しさん2010/09/12(日) 23:02:00
ゲームプログラミングで多態やらずしてなにやるの
0201デフォルトの名無しさん2010/09/12(日) 23:02:25
間違えた、Ｃ＋＋使った上の話で
0202デフォルトの名無しさん2010/09/12(日) 23:18:03
多態が必要なとこなんて限られてるし最初から設計するものではない。
0203デフォルトの名無しさん2010/09/12(日) 23:20:35
継承ってクソじゃね
0204デフォルトの名無しさん2010/09/12(日) 23:21:15
シーンもポリモ、キャラもポリモ、描画対象もポリモ、ゲームはポリモのオンパレード
0205デフォルトの名無しさん2010/09/12(日) 23:24:28
同じようなものしか作らないならだんだんパターンがわかってポリモになるけど
ゲームがよく分かっていないうちからやたら継承しようとするやつは
たいていバグだらけの上に細部にも凝れず仕様変更にも対応できない。
0206デフォルトの名無しさん2010/09/12(日) 23:25:42
まあ継承でガチガチに固めてにっちもさっちも行かなくなるのは中級者のおちいりがちなところだわな
0207デフォルトの名無しさん2010/09/12(日) 23:48:09
なら種類の違う敵を動かす時とかどうすんの
0208デフォルトの名無しさん2010/09/12(日) 23:54:21
ポリモ
0209デフォルトの名無しさん2010/09/12(日) 23:54:37
それ用のタスクを生成して呼び出すだけ
0210デフォルトの名無しさん2010/09/12(日) 23:58:44
タスクってポリモ使わないのか
0211デフォルトの名無しさん2010/09/13(月) 00:00:00
タスク自体がポリモみたいなもんだ
0212デフォルトの名無しさん2010/09/13(月) 00:23:50
ポリモでメモリ計算ちゃんとできてるのかね。
0213デフォルトの名無しさん2010/09/13(月) 00:41:52
えっ
0214デフォルトの名無しさん2010/09/13(月) 00:54:00
えっ？
0215デフォルトの名無しさん2010/09/13(月) 01:31:25
>>210
ゲームプログラムの場合、ポリモだろうがなんだろうが動的にメモリを確保することはしないので
そのシーンさえ初期化できれば問題ねー
0216デフォルトの名無しさん2010/09/13(月) 01:37:37
ところがどっこい今時のゲームプログラマーは普通に動的メモリ確保します
0217デフォルトの名無しさん2010/09/13(月) 03:18:49
>>216
mjky。
設計的にどういう都合でそういうのが発生するん？
パズルゲームとかアクションゲームとかRPGでもまず無いよな？
0218デフォルトの名無しさん2010/09/13(月) 03:37:07
いまどき設計時点で動的なメモリ確保を気にする必要は無いということだ。
0219デフォルトの名無しさん2010/09/13(月) 05:37:30
な、驚愕だろ？
0220デフォルトの名無しさん2010/09/13(月) 07:59:28
書ける事と、それがやさしい/むずかしいとは別の話
特に、はじめてゲームプログラミングに挑戦しようとする人にとって、
少なくとも現状だと、オブジェクト指向の壁は、あまりに高すぐる
0221デフォルトの名無しさん2010/09/13(月) 10:50:47
つか15年位前のア０ケードゲームを書いてたころからアロケーター自作で動的にやってたけどな。
数決め撃ちでつくって全場面とおしてキャラクターは画面内に８対しか出ませんとかありえないだろｗ
0222デフォルトの名無しさん2010/09/13(月) 10:56:30
スプライトとかハードウェアの制限があることもあるし、
弾なら弾速と画面さいずで最大数は決まってくるし、
最大数固定っていう設計は十分ありうる。

動的に確保するってことは、確保できないかもしれない可能性が出てくるわけで。
0223デフォルトの名無しさん2010/09/13(月) 11:01:33
ありえるなんて事はどうでもいいし、過去にあったよ。
けどそういう保守的な設計のゲームは表現的に寂しい物がおおかったね。
0224デフォルトの名無しさん2010/09/13(月) 11:35:36
>>221
キャラクターが多いときは弾が少なくて
弾が多いときはキャラクターが少なくなるの？
0225デフォルトの名無しさん2010/09/13(月) 12:05:09
そういうこともできる。

そもそも現在存在していないキャラや演出ぶん事前に確保なんかしてたら、
現在進行している場面で使えるリソースが少なくなるでしょうが。
0226デフォルトの名無しさん2010/09/13(月) 12:23:15
>>225
ボスの直前にリセットして空きを確保するって意味？
0227デフォルトの名無しさん2010/09/13(月) 12:56:29
なんでそこだけ特別な処理しなきゃいけないの？
0228デフォルトの名無しさん2010/09/13(月) 13:08:04
>>225
逆に言うと、新しい敵が出てくるたびにロードするようなシステムだったら、
PSとかのディスクゲームだったら致命的なラグでしかねーだろ？
0229デフォルトの名無しさん2010/09/13(月) 13:10:57
>>228 ロードだけ先に済ませとけばいいじゃん。あるいは非同期ロードとか。
0230デフォルトの名無しさん2010/09/13(月) 13:12:36
あっそ
0231デフォルトの名無しさん2010/09/13(月) 13:13:13
>>228なんでそんなにバカなの？
0232デフォルトの名無しさん2010/09/13(月) 13:16:21
シューティングならボスがでる前に
一度雑魚キャラが消えるエリアを設けて
その間にボスを読み込むとか割りとありがちな演出のような
0233デフォルトの名無しさん2010/09/13(月) 13:22:45
>>229
ロードしたんならメモリ確保してるじゃんよｗ
0234デフォルトの名無しさん2010/09/13(月) 13:31:18
>>232-233
そいう類のリソースは事前確保だよ。
それを何個使うかって所を動的にするって話じゃないのかよ。
0235デフォルトの名無しさん2010/09/13(月) 13:33:39
>>223
まるで今のハードには何のリソース制限も無いような言い方だな
お前、何かプログラム作ったことあるの？
0236デフォルトの名無しさん2010/09/13(月) 13:44:27
>>234
>>232の「ボスを読み込む」は「ボス分を確保する」に読み替えといて
0237デフォルトの名無しさん2010/09/13(月) 13:50:41
>>233
「ロードしたんならメモリ確保してる」が真だとしても、その逆
「メモリ確保したんならロードしてる」が真だとは限らない。
0238デフォルトの名無しさん2010/09/13(月) 15:00:42
ひょひょ
0239デフォルトの名無しさん2010/09/13(月) 15:12:13
このスレってしょっちゅう話がかみ合わなくなると思ったら
頭が石化してるおじいちゃん世代が住み着いてるわけね
なるほど納得したわ
関数ポインタ使えない定数厨とかもその類だったわけだ
0240デフォルトの名無しさん2010/09/13(月) 15:15:55
むふふ、ココではそんな煽り鼻くそほど役にもたたぞ
0241デフォルトの名無しさん2010/09/13(月) 15:36:33
凄い不毛な会話だな
ストレスたまるだろ？
仕事で疲れてココで疲れてどうすんの？

0242デフォルトの名無しさん2010/09/13(月) 15:52:23
ストレスになるほどマジになってるやつなんていないだろ
0243デフォルトの名無しさん2010/09/13(月) 16:21:03
基本、みんな相手の反応をみてニヤニヤしてるだけだよ
一部顔を真っ赤にしちゃってる人も混ざってるみたいだが
0244デフォルトの名無しさん2010/09/13(月) 16:23:09
>>237
よくわからんが、最初はメッシュだけ読んでおいて
テクスチャとかは後で読み込む、ってなら何となく理解できる。
0245デフォルトの名無しさん2010/09/13(月) 18:30:05
うはー
0246デフォルトの名無しさん2010/09/13(月) 18:40:23
現在ではシングルトンを実装する最善の方法は単一要素のenum型を用いることです

ってEffectiveJAVAに書いてあるぞ
0247デフォルトの名無しさん2010/09/13(月) 20:10:54
ほっほっ
0248デフォルトの名無しさん2010/09/13(月) 22:36:34
相変わらず口だけのやつばっかだな
0249デフォルトの名無しさん2010/09/13(月) 22:39:34
前後左右のキャラ素材はあるんだがなかなか斜めも含めた８方向のフリー素材って見つからないな…
0250デフォルトの名無しさん2010/09/13(月) 22:47:48
動的確保したらメモリ足りなくなって敵少なくなったらどうすんの、とか結構愚問
そういうステージ作らなければいい
0251デフォルトの名無しさん2010/09/13(月) 23:51:33
ふっはっ
0252デフォルトの名無しさん2010/09/13(月) 23:55:14
>>251どうした老害
■ このスレッドは過去ログ倉庫に格納されています