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

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

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

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

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

452 :デフォルトの名無しさん:2010/09/28(火) 11:17:51
何も定義しないとnewって標準ライブラリのmallocよんでるだけだろ

453 :デフォルトの名無しさん:2010/09/28(火) 11:24:59
>>432-433
そろそろ効率のいいテストの方法を考える必要があるんじゃないか?
WEB系とゲーム系は関数レベルのテストにあまり意味がないといわれてるけどさ

>>434
効率より予定通り進む事が大事だからな
ゲームと違ってブラッシュアップしようって文化がないから
予定より早く終わってもメリットがない

>>441
派遣だから名刺なんて作ってもらえないよ

454 :デフォルトの名無しさん:2010/09/28(火) 11:31:00
>>451
普通にやってて数KB程度なら無視していいよ
停電でゲームが中断する方が確率たかいんじゃないか?

win32で調子のってメモリ使いまくったら
2GBの壁でフラグメンテーションの影響でたことあるけど
そんなにばかすかメモリ使う人は普通じゃないし

455 :デフォルトの名無しさん:2010/09/28(火) 11:32:55
>>454
無視していいっていう判断の根拠は?

456 :デフォルトの名無しさん:2010/09/28(火) 11:47:52
ガベージコレクション以前の世界の人とは通じ合えないな

457 :デフォルトの名無しさん:2010/09/28(火) 11:52:55
ゲームプログラムをユーザーがビジネスで使うことはあまりないから、
細かい部分は大目に見られてるね

458 :デフォルトの名無しさん:2010/09/28(火) 11:54:08
>>455
大体再利用されるから
限界ギリギリまで使ってない限り組み合わせが変わっても誤差の範囲で収まる
メモリを確保するだけで解放しないなら話は別だけど

459 :デフォルトの名無しさん:2010/09/28(火) 11:55:13
ガベージコレクションに対応するのはメモリの解放忘れ
フラグメンテーションとは関係ない

メモリコンパクションと混同してるの?

460 :デフォルトの名無しさん:2010/09/28(火) 11:56:11
すべてはケースバイケース。

461 :デフォルトの名無しさん:2010/09/28(火) 11:59:17
話の元は>>329なんだよな?

462 :デフォルトの名無しさん:2010/09/28(火) 11:59:18
どんな低能なMMU使ってんだ

463 :デフォルトの名無しさん:2010/09/28(火) 11:59:38
>>459
それを言うなら2Gの壁もフラグメンテーションとは関係ない。

464 :デフォルトの名無しさん:2010/09/28(火) 12:06:52
>>459
もちろん参照カウント0のオブジェクトも削除してくれるけど、
基本コンパクションを意識しなくてもいいように作られてるのがガベコレだろ?
時折アフォなVMがトチってコンパクション出すとかが話題になるくらいだぜ。

465 :デフォルトの名無しさん:2010/09/28(火) 12:07:06
winなら.net使っとけって事だな

466 :デフォルトの名無しさん:2010/09/28(火) 12:10:33
>>459←こういう近代的なMMUを知らんアフォが多すぎ

467 :デフォルトの名無しさん:2010/09/28(火) 12:10:49
ゲーム中にガベージコレクションが作動してFPSが遅くなっちゃうんですけどどうすればいいですか?

468 :デフォルトの名無しさん:2010/09/28(火) 12:11:48
>>466
ガベコレとメモコンの混同はよくある話だから恥ずかしくないよ
次から間違えないようにね

469 :デフォルトの名無しさん:2010/09/28(火) 12:11:50
>>467
なわけねーよ。

470 :デフォルトの名無しさん:2010/09/28(火) 12:12:39
おまえら技術的な話をするつもりが全然ないだろw

471 :デフォルトの名無しさん:2010/09/28(火) 12:13:08
>>468
フラグメンテーション云々に関するレスだろ?

472 :デフォルトの名無しさん:2010/09/28(火) 12:16:02
>>467
使いもしないパラメータをお前が無駄に宣言したのをメモリー上でコピーする動作の方がよっぽど時間食ってるって

473 :デフォルトの名無しさん:2010/09/28(火) 12:18:23
>>471
ガベージコレクションがフラグメンテーションを解決する
という話に対して
フラグメンテーションを解決するのはメモリコンパクションだよという指摘
それに対して
ガベコレはコンパクションを意識していないように作られている
との回答

ガベージコレクションはメモリコンパクションを含まない
よってガベージコレクションはフラグメンテーションを解決しない

以上により、上記回答は事実ではない

474 :デフォルトの名無しさん:2010/09/28(火) 12:20:32
>>473
バカなの?
ガベコレが(たまったゴミ)メモリの開放を担当。
MMUがフラグメンテーションを意識させないメモリ活用を担当。


475 :デフォルトの名無しさん:2010/09/28(火) 12:23:02
>>474
>ガベコレが(たまったゴミ)メモリの開放を担当。
やっぱフラグメンテーションを解決しないんじゃね?

476 :デフォルトの名無しさん:2010/09/28(火) 12:24:03
ガベージコレクション入門: Microsoft .NET Framework の自動メモリ管理 Part I
ttp://msdn.microsoft.com/ja-jp/magazine/bb985010.aspx

復習しとけよ

477 :デフォルトの名無しさん:2010/09/28(火) 12:26:13
ガベコレ付きオブジェクト管理がバックエンドがどういうアロケータなのか、によるだろ。

ところでコンパクションと言ってるのは何のこといってる?
OSが細かなアドレスの再配置をしてくれるとでも思っている?
それとも自前アロケータとかの話?
WM_COMPACTメッセージをトリガにしてなんか開放するとかいう話?

478 :デフォルトの名無しさん:2010/09/28(火) 12:27:28
>>475
あんたフラグメンテーションの解決オタク?
MMUが細切れになってるメモリでもまとめて仮想メモリ領域として使ってくれるんだから
フラグメンテーションなんて意識しなくて済むようになってんだよ近代的なMMUは。

479 :デフォルトの名無しさん:2010/09/28(火) 12:35:00
それならMMUが解決するとか
担当を分けずにMMUまで含めてガベコレだって言えばいいんじゃね?

480 :デフォルトの名無しさん:2010/09/28(火) 12:38:26
>>479
あのさ?ここは法廷か何かか?
一言一句核心を外さずに述べないといけないわけ?

481 :デフォルトの名無しさん:2010/09/28(火) 12:42:17
今このスレに必要なのはバカコレだな

482 :デフォルトの名無しさん:2010/09/28(火) 12:43:34
使用中のバカは解放されないよ

483 :デフォルトの名無しさん:2010/09/28(火) 12:43:54
                    ''';;';';;'';;;,.,                  ザッ
                       ''';;';'';';''';;'';;;,.,   ザッ
          ザッ            ;;''';;';'';';';;;'';;'';;;
                        ;;'';';';;'';;';'';';';;;'';;'';;;
                        vymyvwymyvymyvy     ザッ
               ザッ     MVvvMvyvMVvvMvyvMVvv、
                   Λ_ヘ^−^Λ_ヘ^−^Λ_ヘ^Λ_ヘ
     ザッ            ヘ__Λ ヘ__Λ ヘ__Λ ヘ__Λ
                __,/ヽ_ /ヽ__,.ヘ /ヽ__,.ヘ _,.ヘ ,.ヘ    ザッ
    /\___/ヽ   /\___ /\___/ヽ _/ヽ /\___/ヽ
   /''''''   '''''':::::::\/''''''   '''/''''''   '''''':::::::\   /''''''   '''''':::::::\
  . |(●),   、(●)、.:|(●),    |(●),   、(●)、.:|、( |(●),   、(●)、.:|
  |   ,,ノ(、_, )ヽ、,, .::::|   ,,ノ(、_, )|   ,,ノ(、_, )ヽ、,, .::::|_, )|   ,,ノ(、_, )ヽ、,, .::::|
.   |   `-=ニ=- ' .:::::::|   `-=ニ= |   `-=ニ=- ' .:::::::|ニ=|   `-=ニ=- ' .:::::::|
   \  `ニニ´  .:::::/\  `ニニ \  `ニニ´  .:::::/ニ´ \  `ニニ´  .:::::/
   /`ー‐--‐‐―´\ /`ー‐-  /`ー‐--‐‐―´\-‐‐ /`ー‐--‐‐―´
>>481回収に来ますた」「>>481回収に来ますた」「>>481回収に来ますた」「>>481回収に来ますた」

484 :デフォルトの名無しさん:2010/09/28(火) 12:44:39
>>480
揚げ足を取ってるだけなんだから
気に入らないなら無視すりゃいいじゃん

485 :デフォルトの名無しさん:2010/09/28(火) 13:00:18
>>441
いや別に働いてないよ。
趣味で個人で作ってる。

486 :デフォルトの名無しさん:2010/09/28(火) 14:48:18
低脳な議論に見えるのはすぐ馬鹿にした発言をするからだ
もう少し大人になりたまえ

487 :デフォルトの名無しさん:2010/09/28(火) 15:30:52
お前がなww

488 :デフォルトの名無しさん:2010/09/28(火) 17:25:59
草生やした時点で負けですよ
そこのあなた

489 :デフォルトの名無しさん:2010/09/28(火) 17:26:57
なんだ?JAVAでゲームでも作るのか?

490 :デフォルトの名無しさん:2010/09/28(火) 18:03:22
>>489
最近はやりのandroidだとJavaそっくりの何かだぜ。

491 :デフォルトの名無しさん:2010/09/28(火) 18:04:41
あれJAVAじゃなかったのか

492 :デフォルトの名無しさん:2010/09/28(火) 18:20:59
Javaバイトコード&JavaVMでないという意味ではJavaではない。

493 :デフォルトの名無しさん:2010/09/28(火) 18:27:42
通は伊吹マヤ

494 :デフォルトの名無しさん:2010/09/28(火) 18:28:59
休み終わったらレス増えるということはおまいら本職なのか?

495 :デフォルトの名無しさん:2010/09/28(火) 18:58:54
結構な勢いで進んだのに使える情報は皆無
さすがだわこのスレ

496 :デフォルトの名無しさん:2010/09/28(火) 19:01:05
>>495
てめえなんだとっ

497 :デフォルトの名無しさん:2010/09/28(火) 19:13:14
有益な情報得たかったら金だせ

498 :デフォルトの名無しさん:2010/09/28(火) 20:53:45
>>497
ジョンナムで勘弁してください

499 :デフォルトの名無しさん:2010/09/28(火) 21:07:14
・メモリをハンドリングする時間帯が決まるなら、その時間帯でしか使わないヒープを予め作る。
・機能ごとのヒープの分離。テクスチャ、メッシュ、コリジョン、etc...

これ以上の管理が必須になってくるのって
某有名MMOみたいなシームレスな遷移をするゲームくらいじゃないかなあ…

500 :デフォルトの名無しさん:2010/09/28(火) 21:27:56
ダメ人間しか居ないからこの業界

501 :デフォルトの名無しさん:2010/09/28(火) 21:50:55
やっぱりJavaが一番だね

502 :デフォルトの名無しさん:2010/09/28(火) 22:04:54
C++から別の言語にシフトする可能性ってあるの?国内外問わず

503 :デフォルトの名無しさん:2010/09/28(火) 22:07:53
暫くないでしょ

504 :デフォルトの名無しさん:2010/09/28(火) 22:16:04
すべてのプログラムは最終的に機械語に変換されてから実行される。
よって機械語と1対1に対応しているアセンブリ言語はどんなものでも書けることになる。
ゆえにアセンブリにできないことはない。

一方、CPUの中にクラスなど存在しない。

505 :デフォルトの名無しさん:2010/09/28(火) 22:16:55
日本語で一行

506 :デフォルトの名無しさん:2010/09/28(火) 22:20:05
機械語が一番

507 :デフォルトの名無しさん:2010/09/28(火) 22:20:38
チューリングマシン最強

508 :デフォルトの名無しさん:2010/09/28(火) 22:36:46
Javaでなんか作ってよ

509 :デフォルトの名無しさん:2010/09/28(火) 23:04:48
>>502
Haskellあたりはあるかもな、将来的に。

510 :デフォルトの名無しさん:2010/09/28(火) 23:25:32
ガベコレなんてゲームプログラムの敵だろ。
あんなもんは大したパフォーマンス求められてない業務アプリのためのもんだ。

511 :デフォルトの名無しさん:2010/09/28(火) 23:26:50
>>510
はいはい、ファミコン世代の老人はそう思うだろうね。

512 :デフォルトの名無しさん:2010/09/28(火) 23:27:56
ゲーム会社てさ、ゲーム作るのが業務なんだからゲームソフト=業務アプリじゃね?

513 :デフォルトの名無しさん:2010/09/28(火) 23:29:02
>>512
ユーザー企業の業務のためのアプリが業務アプリ。

514 :デフォルトの名無しさん:2010/09/28(火) 23:29:29
だいたいゲームでガベコレつかうメリットってなんだよ

515 :デフォルトの名無しさん:2010/09/28(火) 23:30:14
また批判か。

516 :デフォルトの名無しさん:2010/09/28(火) 23:31:00
>>514
GCの一般的なメリットがそのままメリットだろ。
湧いてんのか?

517 :デフォルトの名無しさん:2010/09/28(火) 23:32:06
>>516
なんでそれがゲームに必要なの?

518 :デフォルトの名無しさん:2010/09/28(火) 23:32:56
>>516
うん。

519 :デフォルトの名無しさん:2010/09/28(火) 23:35:40
>>517
物事の本質のわからんバカだな。
ゲームといわゆるデスクトップアプリと違うものだっていう発想がそもそもアホ。
画像や音声のロードや破棄、クラスのインスタンスの生成や破棄
そういった概念を追って行けば本質は同じだって事がバカだってわかるはず。

520 :デフォルトの名無しさん:2010/09/28(火) 23:43:13
>>519
開発者の想定した物がそのまま動けばそれ以上求められないのがゲーム。
別にメモリの許す限り弾ださなきゃいけないわけじゃないし
そんなものの管理が難しいなんて事は特にない。

必要なリソースを最初に全部確保すれば確実にゲームが動く状況が作れる。
破棄する時はアプリが終了するときだから、そんなものは管理しなくていい、メモリは勝手に全部解放される。

GCあったほうがむしろややこしくなる

521 :デフォルトの名無しさん:2010/09/28(火) 23:45:53
>>520
> 破棄する時はアプリが終了するときだから、そんなものは管理しなくていい、
> メモリは勝手に全部解放される。

お前素人だなw
決まった手順通り終了したり開放したりしないとダメな場合のほうが多いのにw

522 :デフォルトの名無しさん:2010/09/28(火) 23:47:41
>>521
具体的に何が?
GC使ったら決まった手順通りに終了したり解放したりしてくれるの?すごいね。

523 :デフォルトの名無しさん:2010/09/28(火) 23:47:56
>>520
そういっててこれまでメモリ管理にバグがあったりするから
本来入れない壁をキャラが突き抜けたりおかしな挙動をしたりってミスが起きてたんだろ?

524 :デフォルトの名無しさん:2010/09/28(火) 23:50:08
>>518
お前素人だなw

525 :デフォルトの名無しさん:2010/09/28(火) 23:50:21
>>521
>決まった手順通り終了したり開放したりしないとダメな場合
決まった手順があるならむしろガベコレが邪魔になるんじゃね?

526 :デフォルトの名無しさん:2010/09/28(火) 23:50:25
>>522
どちらかというとGCのほうがまだ安全だな。
大抵のライブラリは開放が手動になってることが多いし。
むしろGC付きだからこそ必要な終了処理を見え易くするんだよな。

527 :デフォルトの名無しさん:2010/09/28(火) 23:51:12
そもそもアプリの仕様として
なんでGCに開放させなきゃいけないの?
って思う
だってGCついてなけりゃ無いほうがいいんだろ?

メリット考えたときにPGが面倒だから以上になんか理由あるの?
だから業務系の文化をもってくるなって言ったじゃん
javaってのは超弩級の馬鹿が開発に参加することを見込んでできた言語であって
ゲームPGには必要ないっつの

業務系でとくにjava使う近辺の開発ってのはね
コーディングとビルドボタン押した後で出るエラーとできっちりわけるよ
俺等動作確認しながらコーディングしつつビルドボタンおして確認しながら動作確認すんべ?
ところがjava使う奴等ってのはコーディング中は一発もビルドボタン押さないかんね
んで一発目のビルド押したときに出たエラーとか一つ残らずエクセルに貼り付けるかんね
そーユー文化圏で開発してる奴等の道具よ?GCってのは

528 :デフォルトの名無しさん:2010/09/28(火) 23:51:26
要するに老害はOOP理解できない。
そもそもホットスポットだけ気をつければ
速度は十分確保できるし、設計はOOの方がシンプル。

529 :デフォルトの名無しさん:2010/09/28(火) 23:51:26
>>523
そんな具体的なケース知るかよw
だいたいそれメモリ管理が原因なのか?


530 :デフォルトの名無しさん:2010/09/28(火) 23:51:59
ららるーららるらー♪

531 :デフォルトの名無しさん:2010/09/28(火) 23:52:11
マジレスするとゲーム作りにOOはあまり役に立たない
ゲームでなくてもぶっちゃけ効果は不明
みんな馬鹿に踊らされてるだけ

532 :デフォルトの名無しさん:2010/09/28(火) 23:53:13
GCは要らんがOOは必要だぞ
OOPっておかしくね?とか言う奴は、継承と差分プログラミングを混同してる場合がほとんど

533 :デフォルトの名無しさん:2010/09/28(火) 23:53:39
>>527
>だから業務系の文化をもってくるなって言ったじゃん

こいつバカか?
GCはむしろゲームから発祥した文化だ

534 :デフォルトの名無しさん:2010/09/28(火) 23:54:10
テンプレートはコピペ改変を自動でやってくれる機能だろ
コンパイル速度は遅くなるけど、コード量に差は無いんじゃね

テンプレートを勧めても「コピペでいいじゃん」と一蹴されてしまうのが悲しい

535 :デフォルトの名無しさん:2010/09/28(火) 23:54:38
             /)
            ( i )))
     / ̄\  / /
     |  ^o^ | ノ / < いみが わかりませんなあ
     \   /  ,/
     / _   /´
    (___)/


536 :デフォルトの名無しさん:2010/09/28(火) 23:55:02
自前のログクラスでファイルに出力、変化を見たい場合は画面に出力、
フラグやゲーム内変数はデバッグコマンドで画面に一覧表示、変更も可能って感じにしてる

537 :デフォルトの名無しさん:2010/09/28(火) 23:55:22
>GCはむしろゲームから発祥した文化だ
LISPじゃねーのかよ

538 :デフォルトの名無しさん:2010/09/28(火) 23:56:19
ガベージコレクション(garbage collection; GC)とは、プログラムが動的に確保したメモリ領域のうち、不要になった領域を自動的に解放する機能である。
「ガベージコレクション」を直訳すれば「ゴミ収集」となる。1959年ごろ、LISPにおける問題を解決するためジョン・マッカーシーによって発明された[1][2]。

539 :デフォルトの名無しさん:2010/09/28(火) 23:56:39
>>531
オブジェクト指向を推進してきたのはNTTデータとかのSIerだろ。
オブジェクト指向は下請けに出しやすい構造だからな。

540 :デフォルトの名無しさん:2010/09/28(火) 23:56:50
敵に接触したら「残像だ」の音声が流れ、敵の背後から切りつける

541 :デフォルトの名無しさん:2010/09/28(火) 23:57:33
やSTLやテンプレートが何だとおもってるんだ?w

542 :デフォルトの名無しさん:2010/09/28(火) 23:59:04
GCで面倒なのはライブラリがメモリ管理を自前でやらせてくれない事が多い。
だからキャラ動かしてる途中に0.5秒ぐらいGCでキャラがストップするとかいう現象が
起きたりするのがウザイね。

543 :デフォルトの名無しさん:2010/09/28(火) 23:59:39
GC使ってバグがゼロになるんなら使うけど
結局パフォーマンスだそうと思ったらGCの挙動を把握しなきゃいけなくなるんじゃないの?

544 :デフォルトの名無しさん:2010/09/29(水) 00:00:16
http://ja.wikipedia.org/wiki/ガベージコレクション

>メモリ管理に関するバグを回避する以外に、プログラミングスタイルの選択肢を広げる効果も持つ。
>型変換などのために一時的なオブジェクトを生成する、マルチスレッドを利用したプログラムで
>スレッド間でオブジェクトを共有して使用する、といった処理はメモリ確保・解放の処理の記述が煩雑となることが多い。
>しかし、ガベージコレクションを持つ言語処理系においては煩雑な記述を省略することができ、
>これらの処理をより自然に記述することができる。



545 :デフォルトの名無しさん:2010/09/29(水) 00:01:00
>>543
パフォーマンスは問題ないんだけど、GCが起こるタイミングをコントロールできない場合が
問題なんだよね。
あとGCのアルゴリズムも自由にできないと困るし。
自前でGC実装するならいいんだけどね。

546 :デフォルトの名無しさん:2010/09/29(水) 00:01:09
>>542
ネーよ。

547 :デフォルトの名無しさん:2010/09/29(水) 00:01:34
このスレネタスレ?

548 :デフォルトの名無しさん:2010/09/29(水) 00:02:07
>>545
このシロートがろくに知りもしないくせに。

549 :デフォルトの名無しさん:2010/09/29(水) 00:02:59
ゲームとかメモリの解放タイミングなんてシーン終わりしか無いんだけどな。

550 :デフォルトの名無しさん:2010/09/29(水) 00:03:57
>>548
そのセリフ流行ってんの?w

551 :デフォルトの名無しさん:2010/09/29(水) 00:04:12
>>544
C++使ってる人からしたら、そもそも所有者のあやふやなオブジェクトが存在する事自体が設計が糞ってなるんだが

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

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