[過去ﾛｸﾞ] ゲームプログラミング相談室【Part5】 (970ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ
433: 415 03/11/16 02:57 ID:2l7gzWNA(1/12) AAS
>428
>Javaゼンゼン分かってない
>C++もゼンゼン分かってない
プログラムを専門に勉強したことがないため
十分に理解してるとは言えないので何か思い違いをしているのでしょうか？
どの部分がどのような理解不足をしているのか勉強のためにお教えください
>429
省9
434(2): 415 03/11/16 02:58 ID:2l7gzWNA(2/12) AAS
続き
少し前に同じような質問をプログラム板でもしたのですが
「メモリ管理機構を自前で作れ」という答えで終わってしまいました
数年前流行っていた時期に作ってみたときには用意するオブジェクト数が少なく
完璧とはいえませんが、何とかプログラマ側で管理しきれていました。
しかし、今回の企画にあわせてオブジェクトの数を増やしていくにしたがって
「どの状況下でどの程度の量がどの部分に配置されて使用されるのか」
省9
440(1): 415 03/11/16 12:57 ID:2l7gzWNA(3/12) AAS
>>435
コンパイラを書き換えるという表現はよくなかったですね＾＾；
gccをつかっているとオープンソースであることの利点でコンパイラやライブラリ
今回の場合だとLibcあたりを簡単に書き換えれるのでオーバーライドするよりも
直接書き換えるほうが面倒がすく問題点がわかり易いので、そんな風に考えていました
>436
その最適なメモリ管理の方法を教えてもらいたかったのです
省15
441(1): 415 03/11/16 13:05 ID:2l7gzWNA(4/12) AAS
>435
ＪＡＶＡもインタプリタ、コンパイラ、ＪａｖａＶＭがそのＣＰＵに対応していないと
動かないと思うのですが、それとも自分の知らない別のＪＡＶＡ言語があるのでしょうか？
Ｃ++とＣ言語の根本的な違いはクラスオブジェクトを使用するオブジェクト指向型言語に
進化していると言うことだと理解していたのですが？
それとも、オブジェクト指向型言語はオブジェクト自身の完成度が高ければ
用意したオブジェクトを動的に追加，開放することで
省4
446(1): 415 03/11/16 15:02 ID:2l7gzWNA(5/12) AAS
>442
使用しているCPUが汎用のSH4ですのでsh4のgccノクロスコンパイラを使用しています
node,メモリ確保の方法malloc等はそのまま使えるもの（言語付属のもの？）を使っています
不正かどうかはまだはっきりしていませんが、正規の手続きでないので
SEGAに相談のはもってのほか、開発環境を明らかにするのもためらいます
もちろん、趣味でやってるだけなので仕事なわけではありません
>443
省15
449: 415 03/11/16 15:27 ID:2l7gzWNA(6/12) AAS
すこし、話題がズレてきてしまっているので
もう一度整理しなおして質問しようと思います
OS等によってメモリ領域が管理されていない
かなり特殊な動作環境でのプログラムをしています
そのためメモリの確保、開放については
プログラム側で常に注意しないといけないと思っています
特にコード的には確保できる領域も実際には
省6
450: 415 03/11/16 15:27 ID:2l7gzWNA(7/12) AAS
現在考えている企画はシューティングゲームのような
同時制御するキャラの多いプログラムです
各キャラを一つのオブジェクトとして構築したため
多種多なオブジェクトを量産する必要がでてしまいました
このときオブジェクトの生成によって確保された動的メモリの
状況把握が十分できない為コンパイル時には問題がなさそうでも
実際動かしてみるとメモリ状況によって動作しない事があります
省6
452(1): 415 03/11/16 15:29 ID:2l7gzWNA(8/12) AAS
>447
すみません、なぜ重要なのかが判りません
「一度溢れるまで」にはどのような意味が含まれているのでしょうか？
458(1): 415 03/11/16 17:05 ID:2l7gzWNA(9/12) AAS
議論が「メモリ確保が失敗するわけがない」というその一点に絞られているようですが
どうやら、OSの無い状況下でのプログラムというのが
理解してもらえないようですね＾＾；
携帯電話、炊飯器などの組み込み機器などようなイメージで捕らえて貰えると
わかりやすいかと思います
>453
OSが存在しないのでメモリを確保するのにAPI等は使用しません
省19
459: 415 03/11/16 17:15 ID:2l7gzWNA(10/12) AAS
>457
まったくおっしゃる通りでこのまま作成するのは無理のある状況だと思います
しかし、無理を承知でなんとかこじつけながら作成していこうと考えています
プログラム自身が単純でメモリの残量についてあまり考慮しなくていい場合は
難しいメモリアロケートの心配などせずに、まさに適当に勝手に確保することで
それなりのモノが作れました
が、それでは上手くいかない事態に陥ったので、みなさんの知恵をかりにきた次第です
省1
464: 415 03/11/16 17:53 ID:2l7gzWNA(11/12) AAS
>460
あまりレベルの高い話でなくてすみません
「システムコール」は
MS-DOSでいうシステムコール
WindowsシリーズでいうWin16、Win32API
もっとローレベルでいうならBIOSコールのことだと推察したのですが？
違っていたのでしょうか?
省14
469(1): 415 03/11/16 18:18 ID:2l7gzWNA(12/12) AAS
>465
mallocの実装自身にOSは関係ないと思います
mallocの性能には関係するとおもいますが
一番単純な実装は指定された量確保してポインタをずらすだけですから
大雑把にいって今つかっているmallocのコードはそうなっています
「ありえない、出来ない、出来るようにしろ」の議論ばかりで
「問題を回避するためにどう工夫したらよいのか？」については意見がもらえないようですね
省3
上下前次1-新書関写板覧索設栞歴
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.030s