ゲーム制作 雑談スレ【part39】 (386レス)
前次1-
抽出解除 レス栞

リロード規制です。10分ほどで解除するので、他のブラウザへ避難してください。
65: 09/07(日)01:30:11.02 ID:qucJSDY/(4/8)調 AAS
最後に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方式と性能差はありませんが、プロシージャルダンジョンなどゲーム開発のベストプラクティスとして最も推奨される方法です。
99: 09/11(木)21:15:19.02 ID:3R5lIWYK(1)調 AAS
>>94
Unity Roomレベルの習作をSteamで販売して「売れないぢゃん!!」ってキレるのは違うと思うが…
285: 09/18(木)19:43:09.02 ID:g5/5dUhi(1)調 AAS
前の方は手足が太くて一定で可愛いんだよな
デフォルメ表現やボクセルは試行錯誤中だ
いろんなモデルを出力できるようにしたい
323
(2): 09/20(土)15:39:38.02 ID:j/nI8EW5(1)調 AAS
以前AIに
javascriptでasync関数が完了するまで戻ってこさせないラッピングsync関数の作り方を教えて下さい
って質問をしたらあの手この手で関数を返してきたが全部間違っていた
もしかしてできないんじゃないですか?って効いたら「鋭い指摘ですね!そのとおりです」って来て何?おまえ何?ってなった
329: 09/20(土)17:26:51.02 ID:E5N77j8t(1/2)調 AAS
現状使い物になんねーよ
AI遊びはよそでやれ
前次1-
スレ情報 赤レス抽出 画像レス抽出 歴の未読スレ AAサムネイル

ぬこの手 ぬこTOP 0.020s