ゲーム制作 雑談スレ【part39】at GAMEDEVゲーム制作 雑談スレ【part39】 - 暇つぶし2ch■コピペモード□スレを通常表示□オプションモード□このｽﾚｯﾄﾞのURL■項目テキスト65:名前は開発中のものです。 25/09/07 01:09:06.63 qucJSDY/.net すでに5の質問とはかけ離れてるし、平行線で続けて長くなるんなら別スレ作れば？ 66:名前は開発中のものです。 25/09/07 01:30:11.02 qucJSDY/.net 最後に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方式と性能差はありませんが、プロシージャルダンジョンなどゲーム開発のベストプラクティスとして最も推奨される方法です。 次ページ最新レス表示レスジャンプ類似スレ一覧スレッドの検索話題のニュースおまかせリストオプションしおりを挟むスレッドに書込スレッドの一覧暇つぶし2ch