[過去ﾛｸﾞ]
ゲームプログラミング相談室【Part5】 (970ﾚｽ)
ゲームプログラミング相談室【Part5】 http://echo.5ch.net/test/read.cgi/gamedev/1036410116/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
必死ﾁｪｯｶｰ(本家)
(べ)
自ID
ﾚｽ栞
あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
433: 415 [sage] 03/11/16 02:57 ID:2l7gzWNA >428 >Javaゼンゼン分かってない >C++もゼンゼン分かってない プログラムを専門に勉強したことがないため 十分に理解してるとは言えないので何か思い違いをしているのでしょうか？ どの部分がどのような理解不足をしているのか勉強のためにお教えください >429 >432 new、mallocをオーバーライドするって考えは思いつきませんでした 確保したメモリアドレスを随時監視して未実装メモリの場合 エラーとして返すようにすればいいのですね ちょっと考えてみます >430 簡単にいえばそうなのですが いつもはＯＳやコンパイラのメモリ管理に頼り切ってるので オブジェクトに必要なメモリ量、その配置が実際どうなってるのか知らないのです http://echo.5ch.net/test/read.cgi/gamedev/1036410116/433
434: 415 [sage] 03/11/16 02:58 ID:2l7gzWNA 続き 少し前に同じような質問をプログラム板でもしたのですが 「メモリ管理機構を自前で作れ」という答えで終わってしまいました 数年前流行っていた時期に作ってみたときには用意するオブジェクト数が少なく 完璧とはいえませんが、何とかプログラマ側で管理しきれていました。 しかし、今回の企画にあわせてオブジェクトの数を増やしていくにしたがって 「どの状況下でどの程度の量がどの部分に配置されて使用されるのか」 が、把握できなくなってしまいました そこで、ゲーム系プログラムならこのような多数のオブジェクトを使用する例が多いため 自分の知らない「ちょっとしたテクニック」であえて動的にオブジェクトを量産しなくても 静的、もしくは準静的な確保によって乗り越えることができるのでは？ はたまたオブジェクトを量産することなく動作させる方法があるのでは？ と思い質問してみた次第です やはり根本的にコンパイラ自身を書き換えて問題のないメモリ確保の方法を確立する といった考え方のほうがスマートだという意見ばかりですので こちらの方向で考えてみようと思います http://echo.5ch.net/test/read.cgi/gamedev/1036410116/434
440: 415 [sage] 03/11/16 12:57 ID:2l7gzWNA >>435 コンパイラを書き換えるという表現はよくなかったですね＾＾； gccをつかっているとオープンソースであることの利点でコンパイラやライブラリ 今回の場合だとLibcあたりを簡単に書き換えれるのでオーバーライドするよりも 直接書き換えるほうが面倒がすく問題点がわかり易いので、そんな風に考えていました >436 その最適なメモリ管理の方法を教えてもらいたかったのです どういうソフトか？はオブジェクトをメモリ一杯まで量産するようなタイプって事なのですが >437 たしかに今のＯＳとＣＰＵとコンパイラに守られてかつメモリが豊富にある 現在の開発環境の状況からみれば、動的なメモリ管理自身をを疑って あえて静的な方法を取ろうとする事は、時代に逆行しているような意見かもしれません しかし、必要なオブジェクトを作成しようとして正常に動作せず その原因がメモリが足りず実装外のアドレスに確保している などということがあるため この部分が解決されないとメモリ不足で動かないのか それともバグで動かないのか把握できません すくなくとも最低限の規則を作らないとダメなのではないでしょうか？ もっと簡単に質問するならば みなさんは動的なメモリ確保で問題がでたとき たとえばNew演算子を使った場合にエラーがでたとき どのように対処しているのでしょうか？ http://echo.5ch.net/test/read.cgi/gamedev/1036410116/440
441: 415 [sage] 03/11/16 13:05 ID:2l7gzWNA >435 ＪＡＶＡもインタプリタ、コンパイラ、ＪａｖａＶＭがそのＣＰＵに対応していないと 動かないと思うのですが、それとも自分の知らない別のＪＡＶＡ言語があるのでしょうか？ Ｃ++とＣ言語の根本的な違いはクラスオブジェクトを使用するオブジェクト指向型言語に 進化していると言うことだと理解していたのですが？ それとも、オブジェクト指向型言語はオブジェクト自身の完成度が高ければ 用意したオブジェクトを動的に追加，開放することで コードの簡易化、開発効率の向上が見込めるが 生成されるオブジェクトにとって十分なメモリ領域が必要である といった認識がまちがっているのでしょうか？ こちらはスレ違いなので・・・スルーしてもらってもよいです http://echo.5ch.net/test/read.cgi/gamedev/1036410116/441
446: 415 [sage] 03/11/16 15:02 ID:2l7gzWNA >442 使用しているCPUが汎用のSH4ですのでsh4のgccノクロスコンパイラを使用しています node,メモリ確保の方法malloc等はそのまま使えるもの（言語付属のもの？）を使っています 不正かどうかはまだはっきりしていませんが、正規の手続きでないので SEGAに相談のはもってのほか、開発環境を明らかにするのもためらいます もちろん、趣味でやってるだけなので仕事なわけではありません >443 全然関係ない問題といわれる意味がわかりません みなさんのメモリ管理の意識はどうなっているのでしょう？ OSによってメモリ領域が保護されている場合ならともかく >ロードしないとオブジェクトが正しくロードできてるか どうかもわからない は普通に起こりえる事態だと思うのですが、なにが間違ってるのでしょうか？ >444 べつに環境のせいやコンパイラのバグで騒いでいるわけではありません 問題がでるので別の回避方法を模索しているだけです 問題なく動くのであれば理論が判らなくて言語がなんでも気にしません >445 専門に勉強していないので表現が正しくなく混乱を招くのは申し訳ないです クロスコンパイラが必要というはその動作環境で動くように動作設定することと 大雑把に括って表現しました JavaでいうのであればもちろんそのCPU用のJavaVMが必要なので ということです http://echo.5ch.net/test/read.cgi/gamedev/1036410116/446
449: 415 [sage] 03/11/16 15:27 ID:2l7gzWNA すこし、話題がズレてきてしまっているので もう一度整理しなおして質問しようと思います OS等によってメモリ領域が管理されていない かなり特殊な動作環境でのプログラムをしています そのためメモリの確保、開放については プログラム側で常に注意しないといけないと思っています 特にコード的には確保できる領域も実際には 実装されていない事も考慮にいれないといけません 静的なメモリ確保方法ではコンパイル時に確保位置が把握できるため 問題をみつけることが簡単です しかし、動的なメモリ確保では変動するメモリ状況にあわせて 確保位置，量が変化するためプログラム側で逐次チェックするのが難しいです つづく http://echo.5ch.net/test/read.cgi/gamedev/1036410116/449
450: 415 [sage] 03/11/16 15:27 ID:2l7gzWNA 現在考えている企画はシューティングゲームのような 同時制御するキャラの多いプログラムです 各キャラを一つのオブジェクトとして構築したため 多種多なオブジェクトを量産する必要がでてしまいました このときオブジェクトの生成によって確保された動的メモリの 状況把握が十分できない為コンパイル時には問題がなさそうでも 実際動かしてみるとメモリ状況によって動作しない事があります このような場合、問題なく動かすためには どのような仕組みを最低限用意しないといけないのでしょう？ 現状では動的メモリの確保時に成功、失敗にかかわらずエラーは起きませんが エラーであることを示すように改良することが可能かもしれません が、できればその仕組みを作らなくても良い方法を教えていただきたいです 使用してるコンパイラはgccのSH4用クロスコンパイラです http://echo.5ch.net/test/read.cgi/gamedev/1036410116/450
452: 415 [sage] 03/11/16 15:29 ID:2l7gzWNA >447 すみません、なぜ重要なのかが判りません 「一度溢れるまで」にはどのような意味が含まれているのでしょうか？ http://echo.5ch.net/test/read.cgi/gamedev/1036410116/452
458: 415 [sage] 03/11/16 17:05 ID:2l7gzWNA 議論が「メモリ確保が失敗するわけがない」というその一点に絞られているようですが どうやら、OSの無い状況下でのプログラムというのが 理解してもらえないようですね＾＾； 携帯電話、炊飯器などの組み込み機器などようなイメージで捕らえて貰えると わかりやすいかと思います >453 OSが存在しないのでメモリを確保するのにAPI等は使用しません 自由にメモリを使える反面、エラーが起きているのかも判断できません 自分で勝手に確保して勝手に開放します 正確にはmallocを定義しているLibcのコードにしたがって確保開放を行います >454 オブジェクトはコードとデータの集合体という理解は間違ってないですよね？ 「オブジェクトを量産する」という表現に誤解があるようですね これは同じインスタンスのコピーを作るということです 一つ目のオブジェクトは仮にロードすることが出来たとしましょう 一つだけなら問題なく動作することが確認できます 次に、このオブジェクトを量産することにします このオブジェクトに含まれるコード部分は共有できますが 含まれるデータについてはその独立性を保たないといけないので共有できません そこでオブジェクトを量産するためには、追加されたオブジェクト用に 逐次動的にメモリを確保していくことになると思います しかし今回の環境のような場合動的なメモリを確保できなかった場合に 成功したのか失敗したのかがわかりません とりあえず確保成功したことにして動作を開始しますが 実は不確定なエリアのメモリを確保していたりすると正常に動作しません 専門用語についての知識が薄く表現が曖昧で申し訳ありません http://echo.5ch.net/test/read.cgi/gamedev/1036410116/458
459: 415 [sage] 03/11/16 17:15 ID:2l7gzWNA >457 まったくおっしゃる通りでこのまま作成するのは無理のある状況だと思います しかし、無理を承知でなんとかこじつけながら作成していこうと考えています プログラム自身が単純でメモリの残量についてあまり考慮しなくていい場合は 難しいメモリアロケートの心配などせずに、まさに適当に勝手に確保することで それなりのモノが作れました が、それでは上手くいかない事態に陥ったので、みなさんの知恵をかりにきた次第です メモリとハードの仕様は不完全ながらも、使える程度には理解しているつもりです http://echo.5ch.net/test/read.cgi/gamedev/1036410116/459
464: 415 [sage] 03/11/16 17:53 ID:2l7gzWNA >460 あまりレベルの高い話でなくてすみません 「システムコール」は MS-DOSでいうシステムコール WindowsシリーズでいうWin16、Win32API もっとローレベルでいうならBIOSコールのことだと推察したのですが？ 違っていたのでしょうか? OSが存在せずメモリ確保のためにシステム側から用意された関数が無い場合 自分でメモリを確保しないといけないと思います そのメモリ確保方式に問題があり、異常の原因となることは理解しているのですが そのための良い解決方法が見つからないので相談にきました >461 メモリ確保の方法についてはgccのmallocをそのまま使用しているので gccのNewlib内のlibcのなかにmallocのコードがあるのでソレを参考にしてください メモリマップ自身は不完全ながら資料としてあるので 「ほんとに使えない領域なのか」は判りませんが「問題なく使える領域」は判ります 「どういう基準で確保可能領域を割り当てるんだろうか？」 まったく同じ疑問をもっています この環境においての動的なメモリ確保については完全に信頼できないと考えています そこで動的なメモリ確保をすることなく、オブジェクトを量産したいのです 一番初めの投稿の形にもどってしまいましが＾＾； http://echo.5ch.net/test/read.cgi/gamedev/1036410116/464
469: 415 [sage] 03/11/16 18:18 ID:2l7gzWNA >465 mallocの実装自身にOSは関係ないと思います mallocの性能には関係するとおもいますが 一番単純な実装は指定された量確保してポインタをずらすだけですから 大雑把にいって今つかっているmallocのコードはそうなっています 「ありえない、出来ない、出来るようにしろ」の議論ばかりで 「問題を回避するためにどう工夫したらよいのか？」については意見がもらえないようですね どうも、OSのない環境でのプログラムについての議論はここでは出来ないようなので どこか別のスレッドを探して質問してみることにします お騒がせしました http://echo.5ch.net/test/read.cgi/gamedev/1036410116/469
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.030s