5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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

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

350 :デフォルトの名無しさん:2010/09/27(月) 23:26:47
ゴミゴミ言ってるだけで説明する能力も無いクズが

351 :デフォルトの名無しさん:2010/09/27(月) 23:28:29
説明できねーよ、どうせ、ふにゃチンだから。

352 :デフォルトの名無しさん:2010/09/27(月) 23:43:54
後だしで欠点を補おうとする奴はクズ
>>340では何もできない

353 :デフォルトの名無しさん:2010/09/27(月) 23:50:38
ほらね、説明できない ┐(´ー`)┌

354 :デフォルトの名無しさん:2010/09/27(月) 23:53:55
>>334
>あるフロアに出現する敵が8種類いて、モンスターの最大数が32だったら
>すべての組み合わせを網羅するには32*8=256体分のメモリを確保しなきゃいけない

何でやねん!

355 :デフォルトの名無しさん:2010/09/27(月) 23:54:01
┌(´ー`)┌はるしるよー


356 :デフォルトの名無しさん:2010/09/27(月) 23:55:08
ゴミに説明するだけ無駄

357 :デフォルトの名無しさん:2010/09/27(月) 23:57:10
だから生成したインスタンス分カウンタを設けて、リミット以上の場合は蹴ればいいだけ。

358 :デフォルトの名無しさん:2010/09/27(月) 23:58:22
>>357
なるほどねー

359 :デフォルトの名無しさん:2010/09/27(月) 23:59:09
バカばっかワロタ

360 :デフォルトの名無しさん:2010/09/28(火) 00:05:15
全てのフロアで共通に使う可変長配列EnemyListを用意しておいて
各フロアの開始時に

EnemyList.push_back( new EnemyA() );
EnemyList.push_back( new EnemyB() );
...

みたいな感じにすれば。

361 :デフォルトの名無しさん:2010/09/28(火) 00:05:43
>>354
8種類で最大32体ということは
フロアが1番目の種類だけで32体埋め尽くされる可能性があるから、事前に1番目のモンスターのオブジェクトを32体確保しなければならない
同様に2〜32番目のモンスターについても32体分確保しないといけないから全部で32*8=256体分のオブジェクトが必要

362 :デフォルトの名無しさん:2010/09/28(火) 00:10:24
モンスターの基底クラスを用意して
派生クラスで動きを変えればいい
それなら32個で済むじゃん

363 :デフォルトの名無しさん:2010/09/28(火) 00:10:46
インスタンスの数だけ把握して管理できた気になってるってすごいな

364 :デフォルトの名無しさん:2010/09/28(火) 00:10:55
>>362
バカ?

365 :デフォルトの名無しさん:2010/09/28(火) 00:11:47
またおまえか

366 :デフォルトの名無しさん:2010/09/28(火) 00:12:01
だって基底クラスの配列だけを用意すれば済むんだから
32個で済むじゃん
何がおかしい

367 :デフォルトの名無しさん:2010/09/28(火) 00:14:58
>>366
フロアに入ってからずっとモンスターが固定で再生産されないならそれでいいけど
シレンの仕様じゃモンスターがフロアに入ってからも増減するでしょ?

368 :デフォルトの名無しさん:2010/09/28(火) 00:16:07
>>366
事前にプールしようって話だろうが。馬鹿か?

369 :デフォルトの名無しさん:2010/09/28(火) 00:18:58
これだから素人は

370 :デフォルトの名無しさん:2010/09/28(火) 00:19:27
deleteでインスタンス削除すれば済むじゃない

371 :デフォルトの名無しさん:2010/09/28(火) 00:22:08
プールじゃなくて
スマートポインタでも良くね?

372 :デフォルトの名無しさん:2010/09/28(火) 00:27:26
もー話がよく分からないよ

373 :デフォルトの名無しさん:2010/09/28(火) 00:31:07
ぐぐるべし

374 :デフォルトの名無しさん:2010/09/28(火) 00:34:23
カウンタA + B + C + D + E ・・・の総計が32以下の場合は任意のカウンタを加算。
一体消去ごとに各担当カウンタを減算。

カウンタ0->1時にそれぞれのカウンタに対応するフラグ(4バイト)を用意。
各個体、インスタンス生成時、ビットをON、インスタンス消去時ビットをOFF。


375 :デフォルトの名無しさん:2010/09/28(火) 00:34:39
スマートポインタは関係ないだろ

376 :デフォルトの名無しさん:2010/09/28(火) 00:35:47
ファクトリクラス

public abstract class OsDbFactory{
// 抽象メソッド
public abstract OS createOS();
public abstract DBMS createDBMS();

// ファクトリクラスのオブジェクトを返すメソッド
public static OsDbFactory getFactory(String db) {
if (db.equals("WinSql") {
return new WinSqlFactory();
}
else if (db.equals("UnixOracle")) {
return new UnixOracleFactory();
}
else {
return null;
}
}

377 :デフォルトの名無しさん:2010/09/28(火) 00:37:32
>>376
だからそれじゃインスタンスを管理したことにならないよね?

378 :デフォルトの名無しさん:2010/09/28(火) 00:37:41
>>374
今は事前に全部確保する場合の話をしてるんだから消去しちゃだめじゃん

379 :デフォルトの名無しさん:2010/09/28(火) 00:38:51
>>378
生成を先読みすりゃいいだけじゃないの?

380 :デフォルトの名無しさん:2010/09/28(火) 00:40:47
>>377
ここのnewでコンテナに追加するんでしょ?

381 :デフォルトの名無しさん:2010/09/28(火) 00:42:03
そもそもシレン程度ならその都度生成しても速度的に問題ないじゃん
容量もMAX確保したって余りすぎ

382 :デフォルトの名無しさん:2010/09/28(火) 00:43:57
CHogeFactoryシングルトンファクトリクラス
class CHogeFactory : public IObectFactory
{
protected:
CHogeFactory(){}

public:
static CHogeFactory& Instance()
{
static CHogeFactory instObj;
return instObj;
}

virtual DWORD Create( sp<IHoge> &spHoge )
{
spHoge.SetPtr( new CHoge );
return 0;
}

383 :デフォルトの名無しさん:2010/09/28(火) 00:44:45
うきゃ

384 :デフォルトの名無しさん:2010/09/28(火) 00:46:08
事前に必要な分を確保という戦略だと
要素の組み合わせが膨大な場合に使ってないメモリの割合が相対的に大きくなる
これって当たり前の話ですよね

385 :デフォルトの名無しさん:2010/09/28(火) 00:47:08
要素を全て同一とみなすタスクシステムが最強ってことで

386 :デフォルトの名無しさん:2010/09/28(火) 00:47:26
>>384
そんな無駄なコーディングなんてできるのは学生までだ

387 :デフォルトの名無しさん:2010/09/28(火) 00:49:18
>>386
ですよね
つまり>>332はクソってことで結論出ましたね

388 :デフォルトの名無しさん:2010/09/28(火) 00:51:12
>>384
メモリの最大使用量がゲーム起動中に減ることは無い(ように設計されてる。角度とか。)から、
無駄が多いのは気にしなくていいんだよ。足りなくなるのだけ気にすればいい。

389 :デフォルトの名無しさん:2010/09/28(火) 00:51:18
ようするに何がやりたいのかって、多様な種類のインスタンスを任意の数で生成し、
なおかつ場での登場最大数を越えないようにしたいんだろ?

だったら基本のクラスを作っといて必要な時にインスタンスを生成、増減ごとに生成、証拠をし、
インスタンス最大数をカウンタ(もしくはビットのフラグ)かなにかで管理してやるのが最良の方法。


390 :デフォルトの名無しさん:2010/09/28(火) 00:54:58
>>388
必要になる直前に先読みすりゃいいだけだろ。
必要なくなったらメモリからさっさと消す。
そうすることでマシンパワーを温存できるし
その後の仕様変更の余地を残せる。

全部用意しとくと「あ、もうメモリカツカツなんでーここには何も追加できません。」
て事になる。

391 :デフォルトの名無しさん:2010/09/28(火) 00:55:27
>>389
普通にnewdeleteなんてしてられねーからこうやってプールするんだろうが
見当違いの意見いってねーで勉強しなおしてこい

392 :デフォルトの名無しさん:2010/09/28(火) 00:55:59
多分、問題にしてるのは基底クラスのサイズじゃなくて、基底クラスの参照に動的にnewしてたら
フラグメントは発生するだろうし、そもそもサイズ一定じゃないじゃん、ってことなんだと思うが、
俺はそこんところどうしてんのか知らん。ビヘイビアとかうまいこと使ってサイズおんなじにしてたりするんじゃねーの。

393 :デフォルトの名無しさん:2010/09/28(火) 00:56:36
途中でアロケートするのは例外が怖いからアウト

394 :デフォルトの名無しさん:2010/09/28(火) 00:56:47
>>391
先読みすりゃいいだけのことじゃん。
音楽の再生ファイルなんてみんなそうやってるよ。

395 :デフォルトの名無しさん:2010/09/28(火) 00:59:29
>>393
>アロケート

それは読む時にちゃんと読み込み先の空メモりサイズを確認せずバンバン読むからだろ。
自分のヘボを棚に上げてよく言うよ。

396 :デフォルトの名無しさん:2010/09/28(火) 01:00:45
きゅ



397 :デフォルトの名無しさん:2010/09/28(火) 01:01:35
>>395
サイズ足りなくてアロケートできない場合はどういう動作になるんだよw
基本、newが失敗したらそのアプリケーションって落ちるようにできてるんだぜ?

398 :デフォルトの名無しさん:2010/09/28(火) 01:04:01
>>336

BYTE *psb, *psg, *psr, *psa;
BYTE *pdr, *pdg, *pdb, *pda;



399 :デフォルトの名無しさん:2010/09/28(火) 01:05:55
>>397
空メモリのサイズも見ずにnewしてんの?こりゃあきれるわ。
new失敗したらアプリが落ちるなら絶対失敗しない条件を用意してnewすればいいだけのことじゃん。

400 :デフォルトの名無しさん:2010/09/28(火) 01:06:45
メモリサイズだけ見てnewが失敗しないとか安心してる男の人ってちょっと・・・

401 :デフォルトの名無しさん:2010/09/28(火) 01:08:15
>>400
自分の人生顧みてみなよ。
さぞ酷いコード吐いてきたんだろうよ。

402 :デフォルトの名無しさん:2010/09/28(火) 01:08:26
おまえらバグとりきれないだろ

403 :デフォルトの名無しさん:2010/09/28(火) 01:09:28
このスレって人を納得させる理論をもって意見を言える人が皆無だよね

404 :デフォルトの名無しさん:2010/09/28(火) 01:09:40
>>400
絶対失敗しない条件を用意≒メモリサイズだけ見て

405 :デフォルトの名無しさん:2010/09/28(火) 01:09:53
>>399
よく考えろ。
・メモリほしい!

・メモリありません

・空きメモリを探します!

・空きメモリはありません

・メモリほしい!
の無限ループになって、フリーズするだけだぞそれ。
それに、絶対失敗しない条件って結構難しいと思うんだが。


406 :デフォルトの名無しさん:2010/09/28(火) 01:11:02
>>405
>・メモリありません

↑この段階で場のインスタンスの最大数の設計に問題があるとは思わんのかねクズ

407 :デフォルトの名無しさん:2010/09/28(火) 01:11:33
よくわからんが、コンシューマだとnewが失敗するような状況だと何してんの?
そういうケースって、空きメモリ探しても多分無駄だと思うんだけど。

408 :デフォルトの名無しさん:2010/09/28(火) 01:12:55
あいあい、最近の坊やは>>405みたいに能無しなのにプランナみたいなこと気取るからダメだよね

409 :デフォルトの名無しさん:2010/09/28(火) 01:15:49
>>407
アンタみたいなバカでも
最大サイズのクラスがいくつロードできるかぐらいは設計段階で検討するよね?
もう話が空きメモリが足りなくなるって前提で進めてるじゃんそれ。
メモリが足りなくなることがないようにするのは設計力だよね。
そこが欠落してるよねアンタ。

410 :デフォルトの名無しさん:2010/09/28(火) 01:17:44
ゲーム機によってメモリ容量は事前に解ってるし
ゲーム中にほかのアプリ使うってんでもない
だから容量効率考えずに速度効率を最大化するように最初に取れるだけとってしまえばおk

411 :デフォルトの名無しさん:2010/09/28(火) 01:20:03
>>410

>>384
話ループしてますが。

412 :デフォルトの名無しさん:2010/09/28(火) 01:20:25
>>409
よくわからんけど、フラグメントの問題はどう解消してるわけ? ぎっちりつめれば最大数までいけるだろうが、
フラグメントのこと考えたら 最大クラスの最大インスタンス数=最小クラスの最大インスタンス数 になって
結局最初に確保しても後に確保してもかわらねえじゃん、って話になると思うんだが。

413 :デフォルトの名無しさん:2010/09/28(火) 01:21:50
>>411

>>410は小鳥の脳みそだから許してあげて。
インスタンスがオーバーロードすることばっかり気にしてるアホウドリ

414 :デフォルトの名無しさん:2010/09/28(火) 01:26:20
インスタンスがオーバーロードってどゆこと?

415 :デフォルトの名無しさん:2010/09/28(火) 01:26:38
クラスのサイズを揃えればいいんだよ
>>385で結論でてるじゃん

416 :デフォルトの名無しさん:2010/09/28(火) 01:26:57
>>412

そのひと言で確信したけど
同じメモリ量でやれって言われても
俺、お前より多様な種類のキャラを1シーンに代わる代わる登場させる事できる自信あるワ

417 :デフォルトの名無しさん:2010/09/28(火) 01:32:01
つーかオブジェクトのままプールしようとするから無駄が出るんだよ
普通にプールから生メモリ取って配置newすればいいじゃん

418 :デフォルトの名無しさん:2010/09/28(火) 01:32:19
>>416
ああ、漏れは富豪プログラミングしかできない畑の人だから、
ピーキーな環境で何かしようとしたことが無い。
だからそういう環境においてのTIPSとか知りたいのさ。
特に、クラスのサイズが揃わない環境で動的newしようとする場合の対策をさ。

419 :デフォルトの名無しさん:2010/09/28(火) 01:34:06
ここの連中たいしたネタ持ってないよ

420 :デフォルトの名無しさん:2010/09/28(火) 01:34:13
>>417
よくわからんけど、それってガベコレって言うんじゃないの?
ゲームひとつ作るのにガベコレまで作るもんなのか?
速度とか犠牲になってる気もするし。

421 :デフォルトの名無しさん:2010/09/28(火) 01:37:34

古畑任三郎でした

422 :デフォルトの名無しさん:2010/09/28(火) 01:39:01
>>420
いや…全然ちがうよ

423 :デフォルトの名無しさん:2010/09/28(火) 01:45:14
>>422
何が?

424 :デフォルトの名無しさん:2010/09/28(火) 01:46:23
32個分メモリエリアをマッピングして確保しときゃいいじゃん。
最大クラスのサイズで。先頭アドレスを32個。

425 :デフォルトの名無しさん:2010/09/28(火) 02:00:43
クラスの最大サイズが更新されるたびにコンパイルし直しじゃねーかかったりい

426 :デフォルトの名無しさん:2010/09/28(火) 02:06:51
プログラム書くのもかったるいんだろお前

427 :デフォルトの名無しさん:2010/09/28(火) 02:14:40
変更の影響が全体に及ぶような作り方は嫌だな
テストやり直しになるじゃん

428 :デフォルトの名無しさん:2010/09/28(火) 02:19:12
え?及ばない方法などあるの?

429 :デフォルトの名無しさん:2010/09/28(火) 06:49:42
また10年前にタイムスリップしてるな、このスレ。
ゲームプログラマあがりのおじいちゃんが住み着いてるような気がする。

まずページングが有効な環境では、大きくても数 KB の C++ オブジェクトの
new がフラグメンテーションの影響で失敗するなんて事はありえない。
普通に new/delete しとけばいい。 Windows/Linux など OS の載ってる
環境ではページングが有効。・・・なはずなんだけど、稀に時代錯誤な
おじいちゃんが最初に一括確保するうんこアロケータを強要してきて
ページングの恩恵を台無しにしようとするから注意が必要。

ページングが使えない環境でも、数十 KB の画像データなんかを RAM に
ロードするような環境ではどうやってもそっちが先にひっかかるんで、
C++ オブジェクトの new がフラグメンテーションの影響で失敗する状況は
かなり稀になる。・・・はずなんだけど、稀に時代錯誤なおじいちゃんが
自前で書き起こしたフラグメンテーション耐性の無いうんこアロケータを
強要してきて数バイトの確保も致命的問題につながってしまうことがあるので
注意が必要。

つづく

430 :デフォルトの名無しさん:2010/09/28(火) 06:50:22
つづき

もっとタイトな環境では、 C++ オブジェクトの new が
フラグメンテーションの影響で失敗する可能性がわりとあると思う。上記の
環境も含めて、そういった問題が見つかった場合はメモリをプールしておく
などの対策をとる。ただし対策は局所的でいい。タイトな環境では似たような
対策がたくさん入ることになる。昔のゲーム機でのプログラムがこの状態に
なることが多かったんで、おじいちゃんは今のプログラムにそういった
対策が見られないのを心配してくれてるんじゃないかと思う。

とまぁ、フラグメンテーションが実際に発生している状況を確認する前から
ソースコードレベルの対策( new/delete 禁止とか)を取るのはほとんど無駄。
「割り算よりシフトが速いよ」とか言ってソースの可読性を劣化させるのと
同じ方向の間違い。

431 :デフォルトの名無しさん:2010/09/28(火) 06:53:22
結論: シ ン グ ル ト ン 最 強 !

432 :デフォルトの名無しさん:2010/09/28(火) 06:53:24
皆さんはテストの自動化やってますか?

433 :デフォルトの名無しさん:2010/09/28(火) 06:55:56
>>432
自動化できるようなのはテストじゃない

434 :デフォルトの名無しさん:2010/09/28(火) 07:00:24
下手に業務系の文化もってくんなよ
あいつら下手したらコーディングとVCのビルドボタン押したときに出るバグ取りが別工程とかいう文化だからな
まったくゲームと文化が違う上に非効率この上ないことを延々とやり続ける集団だから
コード組んでる時間よりエクセル弄って資料作ってる時間のが多い奴等だからな

435 :デフォルトの名無しさん:2010/09/28(火) 07:08:11
ここはゲームプログラムスレなので
自分でnew/deleteを実装するほうが普通ですよね。

436 :デフォルトの名無しさん:2010/09/28(火) 07:24:03
>>435
なんでゲームプログラムだと new/delete 実装するのが普通なの?
ゲームプログラマにはバカが多いって話?

437 :デフォルトの名無しさん:2010/09/28(火) 07:25:30
コンシューマーだとそれが普通だと思うんだけど
お前んところは違うの?

438 :デフォルトの名無しさん:2010/09/28(火) 07:31:24
>>437
new/detele 実装することはあるけど、そんなのは環境固有の止むを得ない
事情なんで、「普通」だとは思わない。

それが「普通」だというのなら、どういう事情で new/delete を自前で
実装しないといけないのか言える?
それがゲームプログラム一般(あるいは「コンシューマー」一般)に共通の
事情なら >>435 が正しいってことになるね。

439 :デフォルトの名無しさん:2010/09/28(火) 07:34:10
何勝手にコンシューマーという条件を前提にしてるわけ?

440 :デフォルトの名無しさん:2010/09/28(火) 08:01:13
>>433
またまた、ご冗談を。
http://www.google.co.jp/search?q=%E8%87%AA%E5%8B%95%E3%83%86%E3%82%B9%E3%83%88

441 :デフォルトの名無しさん:2010/09/28(火) 08:47:59
なあお前ら本当にゲーム会社で働いて(いる、いた)んの?

名詞でもうpしてみろよ

442 :デフォルトの名無しさん:2010/09/28(火) 09:00:29
誰が言ったのかが問題になるようなことは、元々技術的に重要ではないということだ。
気にするな。

443 :デフォルトの名無しさん:2010/09/28(火) 09:02:10
この時間にいる時点で現役では無いと言うことだ
俺も含め


444 :デフォルトの名無しさん:2010/09/28(火) 09:17:55
おまえら同じネタで延々と盛り上がれるな

445 :デフォルトの名無しさん:2010/09/28(火) 09:20:16
new/deleteオーバーライドして8B以下はこのヒープから〜
とかはやるけど。

446 :デフォルトの名無しさん:2010/09/28(火) 09:22:37
フラグメンテーションが起こらない起こりにくいメモリの管理方法ってどんなのがあるんですか?

447 :デフォルトの名無しさん:2010/09/28(火) 09:57:47
>>274
つまり本編中で培ってきたマヤと文明の人間関係は全て無に帰する
〜どころか本当にくっついたのなら、大人文明から子供文明にマヤが浮気した・寝取ったとすら言えちゃう
つまり人間関係の一番大事な部分を根こそぎカットして最終回Cパートへぶん投げてる事になるのね

>>285
そう、どんなことがあってもおかしくない
つまりあなたの主張と違う解釈があってもおかしくない
なのに他の主張を封殺する今の状態は、自己否定に繋がっちゃうよ


448 :デフォルトの名無しさん:2010/09/28(火) 10:11:02
伊吹マヤはレズだから寝取られとかの官能性はあんまり無いんじゃないの?

449 :デフォルトの名無しさん:2010/09/28(火) 10:55:55
もう全部luaで好きに書けよ

450 :デフォルトの名無しさん:2010/09/28(火) 11:06:00
最初に質問したのは俺なんですが
クラス設計のことを聞いたんですが、、、

184 KB
★スマホ版★ 掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)