ゲーム制作 雑談スレ【part39】 (386ﾚｽ)
ゲーム制作 雑談スレ【part39】 http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/
上
下
前次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
抽出解除
ﾚｽ栞
ﾘﾛｰﾄﾞ規制
です｡10分ほどで解除するので､
他のﾌﾞﾗｳｻﾞ
へ避難してください｡
65: 名前は開発中のものです。 [sage] 2025/09/07(日) 01:30:11.02 ID:qucJSDY/ 最後にABCをGeminiに質問してみた 100X100 32Pix A. 巨大なマップ全体を描画してスクロールする:3200x3200ピクセルの巨大なSurface（マップ全体）をメモリに作成し、そのSurfaceの描画位置をずらすことでスクロールを実現します。 描画負荷: 非常に軽い。画面に表示されるのは、その巨大なSurfaceの一部を切り取って描画するだけなので、CPUやGPUへの負荷は最小限です。 メモリ負荷: 非常に重い。3200x3200ピクセルの画像は、約40MBのメモリを消費します（RGBA形式の場合）。現代のPCでは余裕の範囲ですが、ゲーム全体のメモリ使用量によっては問題になる可能性があります。 今回のようにマップサイズが固定されている場合、最もシンプルでパフォーマンスが安定します。実装も非常に簡単なので、手軽にゲームを作りたい場合に最適です。 B. 毎フレーム「必要な範囲だけ」タイルを描画する。画面に見えている11x11タイル（121枚）を、マップデータから読み取って毎フレーム個別に描画します。 描画負荷: 毎フレーム121回のSurface.blit()呼び出しが発生します。メモリ負荷: 最小限。各タイルの画像データのみをメモリに保持すれば済みます。 今回の規模（100x100タイル）であれば、A方式と比較して目に見えるパフォーマンスの差は出ないでしょう。しかし、blit()の呼び出し回数が多いため、わずかにCPUへの負荷が高くなる可能性があります。 C. ハイブリッド B方式とほぼ同じです。マップをデータとして保持し、画面に表示される部分だけを描画します。マップデータを配列として持つことで、ゲームロジックとの連携（例：タイルごとのイベント）が非常に簡単になります。 今回の規模であればB方式と性能差はありませんが、プロシージャルダンジョンなどゲーム開発のベストプラクティスとして最も推奨される方法です。 http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/65
99: 名前は開発中のものです。 [sage] 2025/09/11(木) 21:15:19.02 ID:3R5lIWYK >>94 Unity Roomレベルの習作をSteamで販売して「売れないぢゃん！！」ってキレるのは違うと思うが… http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/99
285: 名前は開発中のものです。 [] 2025/09/18(木) 19:43:09.02 ID:g5/5dUhi 前の方は手足が太くて一定で可愛いんだよな デフォルメ表現やボクセルは試行錯誤中だ いろんなモデルを出力できるようにしたい http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/285
323: 名前は開発中のものです。 [] 2025/09/20(土) 15:39:38.02 ID:j/nI8EW5 以前AIに javascriptでasync関数が完了するまで戻ってこさせないラッピングsync関数の作り方を教えて下さい って質問をしたらあの手この手で関数を返してきたが全部間違っていた もしかしてできないんじゃないですか？って効いたら「鋭い指摘ですね！そのとおりです」って来て何？おまえ何？ってなった http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/323
329: 名前は開発中のものです。 [sage] 2025/09/20(土) 17:26:51.02 ID:E5N77j8t 現状使い物になんねーよ AI遊びはよそでやれ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/329
ﾒﾓ帳
(0/65535文字)
上
下
前次
1-
新
書
関
写
板
覧
索
設
栞
歴
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
AAｻﾑﾈｲﾙ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.034s