14(1): 名前は開発中のものです。 [sage] 2025/09/05(金) 22:17:38.07 ID:btFndYsa(2/4) AAS
>>11
描画処理を知らんのだな
ゲームみたいな動的映像は常に全領域再描画してるんだよ
11x11の領域しか再描画しなくていいなんて状況にはならない

18(1): 名前は開発中のものです。 [sage] 2025/09/05(金) 22:58:34.11 ID:btFndYsa(4/4) AAS
>>5君が言ってるのは
描画領域外のマップを事前に保持してるかどうかの違いでしかないので
描画領域内に入るたびに描画処理する前者より
事前に裏で描画してある領域を表示するだけでいい後者のほうが当然軽い

20(1): 名前は開発中のものです。 [] 2025/09/06(土) 01:48:37.59 ID:nuZTTbZ9(1/9) AAS
A. 巨大なマップ全体を描画してスクロールする
100×100 キャラ → タイルサイズを 32px としても 3200×3200 ピクセルの画像。現代のPCではこの程度は余裕。
移動に合わせて Surface.blit() の描画位置をずらせば済むのでシンプル。メモリ的にも、数十MB程度なので pygame では問題にならない。

B. 毎フレーム「必要な範囲だけ」タイルを描画する
画面に見えているのは 11×11=121 タイルだけ。
毎フレームこの121枚を描画すればOK。効率的なやり方だけど、現代でも「マップが数千×数千タイル級」になるなら有利。

C. ハイブリッド
マップはデータ（2次元配列など）として持ち、画面更新のたびに「視界に入る部分だけタイル画像を描画」。
ほとんどのタイルベースのゲームエンジンがこの方式。タイル数が大きくても、画面に描画するタイル数は固定なので、性能は安定する。

AでもいけるがBCをつかう。

37(2): 名前は開発中のものです。 [sage] 2025/09/06(土) 13:49:14.31 ID:bbhijobr(1/3) AAS
>>35
いやその人の例えならBのほうが重いよ
GPU負荷はどっちも同じで気にするほどの誤差は出ない
大量のドローコールによるCPU負荷が段違い
描画以外にもCPU処理は必要だから間違いなくBは次第にフレームレートが稼げなくなる
アホなこと考えてないで両方実装して試してみなよ

40(1): 名前は開発中のものです。 [sage] 2025/09/06(土) 14:10:48.91 ID:bbhijobr(2/3) AAS
>>38
どちらも一回なんてありえないだろ
Bは全チップをチップ枚数分描画してるんだよ
ドローコールはAが1回でBは121回
お前の仮定がおかしい

つまり話を何にも理解してない

42(2): 名前は開発中のものです。 [] 2025/09/06(土) 14:24:55.35 ID:nuZTTbZ9(6/9) AAS
喧嘩するなよ。俺が判定してやるよ３２Pixの場合
〜100×100 タイル（3200×3200 px）Aが有利（blit 1回 vs 400回）
300×300 〜 → B/Cに移行するのがおすすめ。

128PIXの場合　100X100でAは現実的じゃない。
想定するピクセルがわからない時点で喧嘩しても意味ないぜ

49(1): 名前は開発中のものです。 [] 2025/09/06(土) 15:36:31.98 ID:w/QEgYfo(1/4) AAS
画像ﾘﾝｸ

画像ﾘﾝｸ

カメラ範囲だけの処理にとどめてくれる機能はpygameにはないらしい
unityにはある
pygameで作るなら昔ながらのc言語のゲームの作り方で作る必要がある
2000年代によくあったゲーム制作本にはそのやり方結構載ってた

45(1): 名前は開発中のものです。 [sage] 2025/09/06(土) 14:41:29.90 ID:nuZTTbZ9(7/9) AAS
>>43 Pygame単体でタイル描画してるなら → glDrawElements とは無関係だよ。

君は PyOpenGL + pygame(OpenGLモード) で glDrawElements を使えといってるのだろうが、そもそも質問者はそのレベルにいないよ。

51(1): 名前は開発中のものです。 [] 2025/09/06(土) 16:36:35.05 ID:w/QEgYfo(2/4) AAS
>>50
ChatGPTによればpygameはないんだって

55(2): 名前は開発中のものです。 [] 2025/09/06(土) 19:34:47.53 ID:w/QEgYfo(3/4) AAS
>>54
画像ﾘﾝｸ

だそうです
ChatGPTの答えはノー