[過去ﾛｸﾞ]
ゲーム制作 雑談スレ【part39】 (1002ﾚｽ)
ゲーム制作 雑談スレ【part39】 http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/
上
下
前
次
1-
新
通常表示
512ﾊﾞｲﾄ分割
ﾚｽ栞
このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索
歴削→次ｽﾚ
栞削→次ｽﾚ
過去ﾛｸﾞﾒﾆｭｰ
37: 名前は開発中のものです。 [sage] 2025/09/06(土) 13:49:14.31 ID:bbhijobr >>35 いやその人の例えならBのほうが重いよ GPU負荷はどっちも同じで気にするほどの誤差は出ない 大量のドローコールによるCPU負荷が段違い 描画以外にもCPU処理は必要だから間違いなくBは次第にフレームレートが稼げなくなる アホなこと考えてないで両方実装して試してみなよ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/37
38: 名前は開発中のものです。 [sage] 2025/09/06(土) 13:58:12.33 ID:gwr+bGfK >>37 だからドローコールはどちらも１回だと言ってるだろ。テクスチャサイズの方がネックとしてデカい http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/38
39: 名前は開発中のものです。 [sage] 2025/09/06(土) 13:59:07.38 ID:gwr+bGfK >>37 アホアホうるせえんだよ、このアホが。お前が試せｗ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/39
40: 名前は開発中のものです。 [sage] 2025/09/06(土) 14:10:48.91 ID:bbhijobr >>38 どちらも一回なんてありえないだろ Bは全チップをチップ枚数分描画してるんだよ ドローコールはAが1回でBは121回 お前の仮定がおかしい つまり話を何にも理解してない http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/40
41: 名前は開発中のものです。 [sage] 2025/09/06(土) 14:24:47.07 ID:EXmAikSr まだ地罰の話してたほうが平和だったなｗ 質問した奴もほくそ笑んでることだろう http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/41
42: 名前は開発中のものです。 [] 2025/09/06(土) 14:24:55.35 ID:nuZTTbZ9 喧嘩するなよ。俺が判定してやるよ３２Pixの場合 〜100×100 タイル（3200×3200 px）Aが有利（blit 1回 vs 400回） 300×300 〜 → B/Cに移行するのがおすすめ。 128PIXの場合 100X100でAは現実的じゃない。 想定するピクセルがわからない時点で喧嘩しても意味ないぜ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/42
43: 名前は開発中のものです。 [sage] 2025/09/06(土) 14:25:42.99 ID:gwr+bGfK >>40 つ 例：glDrawElements 何も理解してなさすぎワロタ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/43
44: 名前は開発中のものです。 [sage] 2025/09/06(土) 14:26:56.21 ID:gwr+bGfK >>42 失礼だな！喧嘩腰なのは奴の方だぞ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/44
45: 名前は開発中のものです。 [sage] 2025/09/06(土) 14:41:29.90 ID:nuZTTbZ9 >>43 Pygame単体でタイル描画してるなら → glDrawElements とは無関係だよ。 君は PyOpenGL + pygame(OpenGLモード) で glDrawElements を使えといってるのだろうが、そもそも質問者はそのレベルにいないよ。 http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/45
46: 名前は開発中のものです。 [sage] 2025/09/06(土) 15:00:17.01 ID:bbhijobr >>42 Aをマップ画像をゲームフォルダに入れとくことを言ってるなら そんなの最初から考慮しないでしょ そのうちファイルサイズえらいことなるじゃん 最初から>>5の後者がCでしょ 視界に入る部分だけってのがどの範囲なのかよく分からないけど http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/46
47: 名前は開発中のものです。 [sage] 2025/09/06(土) 15:03:20.49 ID:i+R/pY0x せっかくの週末にレベルの低い話をするなよ こんなのは「好きに作れ」が答えだろ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/47
48: 名前は開発中のものです。 [sage] 2025/09/06(土) 15:19:07.44 ID:nuZTTbZ9 そのとおりだよ。質問に対して「俺ならこうする」だけでいい。 質問者はお礼を言ってその中でいいと思ったやり方で作ればいい http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/48
49: 名前は開発中のものです。 [] 2025/09/06(土) 15:36:31.98 ID:w/QEgYfo https://pbs.twimg.com/media/G0JLSr4a0AAHTZY.jpg https://pbs.twimg.com/media/G0JLUtQawAAd_xV.jpg カメラ範囲だけの処理にとどめてくれる機能はpygameにはないらしい unityにはある pygameで作るなら昔ながらのc言語のゲームの作り方で作る必要がある 2000年代によくあったゲーム制作本にはそのやり方結構載ってた http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/49
50: 名前は開発中のものです。 [sage] 2025/09/06(土) 16:31:10.68 ID:gwr+bGfK >>49 pygameは知らんけど、どんな低レベル描画エンジン使ってるにしろ、低レベル描画エンジンがカリングしてくれるだろ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/50
51: 名前は開発中のものです。 [] 2025/09/06(土) 16:36:35.05 ID:w/QEgYfo >>50 ChatGPTによればpygameはないんだって http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/51
52: 名前は開発中のものです。 [] 2025/09/06(土) 16:54:34.85 ID:nuZTTbZ9 ＞pygameは知らんけど いままでの論争はなんだったんだ。 http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/52
53: 名前は開発中のものです。 [sage] 2025/09/06(土) 17:28:02.32 ID:gwr+bGfK >>45 「こんな所にS級が？！」とかあるあるやん ・・・アニメでは http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/53
54: 名前は開発中のものです。 [sage] 2025/09/06(土) 18:34:45.05 ID:gwr+bGfK >>51 Pythonスクリプト層内での低レベルAPIへの描画コールは間引かれない（APIコールしても低レベルAPI内では間引かれるかも）、て意味じゃないの？知らんけど http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/54
55: 名前は開発中のものです。 [] 2025/09/06(土) 19:34:47.53 ID:w/QEgYfo >>54 https://pbs.twimg.com/media/G0KCf9ja4AAhQ5i.jpg だそうです ChatGPTの答えはノー http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/55
56: 名前は開発中のものです。 [sage] 2025/09/06(土) 19:43:37.64 ID:7Km6Wgc5 そんなにChatGPT が得意なら、pygame のタイルマップのシステムをサクッと作ったら？ たぶん、どこかからコピペしてくるよ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/56
57: 名前は開発中のものです。 [] 2025/09/06(土) 19:50:02.52 ID:w/QEgYfo >>56 俺は野球ボーイで上の者ではない 上の者は上の者で自力で頑張ってください http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/57
58: 名前は開発中のものです。 [sage] 2025/09/06(土) 20:30:43.00 ID:gwr+bGfK >>55 平行線だな。低レベルの描画エンジンが視野外カリング・テストを行わないのは考えられない だから俺は、そのLLMの回答はPythonスクリプトレイヤの話だ、と言っている http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/58
59: 名前は開発中のものです。 [] 2025/09/06(土) 20:58:21.23 ID:/kpwELhX 今週もよく進んだ 着実にBlenderに近づいてる https://i.imgur.com/8I6EYjF.png https://i.imgur.com/slj6d5E.png https://i.imgur.com/38nLSIk.png https://i.imgur.com/rQtAE6V.png http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/59
60: 名前は開発中のものです。 [sage] 2025/09/06(土) 21:17:35.71 ID:EXmAikSr これからは質問されたらChatGPTに投げたほうがいいかもな どうせ荒らしだろうし http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/60
61: 名前は開発中のものです。 [sage] 2025/09/06(土) 22:37:01.34 ID:zOtGPqEd >>55 チャッピーに騙された可哀想な人がいる…… もう一度これで質問してみ？ Q: 以下の問いについて事実に基づいた解説をせよ。 1. pygameのSurface.blit() は、ソースのピクセルをdest Surfaceに転写する処理である。 2. この転写時にソースが出力先の範囲を超える場合、その領域は自動的にクリッピングされ、省略される。 3. ソースと出力先が完全に重ならない場合、描画処理は行われず内部的に早期リターンされる。 http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/61
62: 名前は開発中のものです。 [sage] 2025/09/07(日) 00:45:01.10 ID:qucJSDY/ 野球マンは、Unity使いなんだし朝から同じ話題に辟易してChatGptで調べただけだから、別にPygameがNinateやLumen使えてもどうでもいいだろう。 http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/62
63: 名前は開発中のものです。 [] 2025/09/07(日) 00:54:55.61 ID:qucJSDY/ GoogleGeminiで聞いてみたよ カリングとblit()の最適化 「カリング」という用語は、一般的にゲーム開発において、描画パイプライン全体で不要なオブジェクトを描画リストから除外する手法を指します。これには、フラスタムカリング（カメラの視錐台の外にあるオブジェクトを無視する）、オクルージョンカリング（他のオブジェクトに隠れて見えないオブジェクトを無視する）などが含まれます。 PygameのSurface.blit()は、このような広義のカリング機能自体は提供していません。つまり、開発者が自分でオブジェクトの座標を確認し、画面外にある場合は描画関数を呼ばないように制御する必要があります。 しかし、以前の回答で述べた「早期リターン」の機能は、blit()関数内部で行われる描画処理の最適化です。これは、特定の描画命令（この場合はblit()）の引数（ソースとデスティネーション）が描画対象として無効である場合に、GPUやCPUへの負荷をかけずに処理を終了させるためのものです。 まとめ Pygame自体が、シーン全体の不要なオブジェクトを自動的に描画リストから除外するような、高度なカリング機能は提供していない blit()の内部最適化：blit()関数は、引数で渡されたソースとデスティネーションの矩形が重ならない場合、内部的にピクセル転送処理をスキップするという最適化を行っています。 これは、Pygameの描画関数の効率を高めるための実装レベルの工夫であり、広義の「カリング」機能とは異なります。 http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/63
64: 名前は開発中のものです。 [sage] 2025/09/07(日) 01:09:06.63 ID:qucJSDY/ すでに5の質問とはかけ離れてるし、平行線で続けて長くなるんなら別スレ作れば？ http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/64
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
66: 名前は開発中のものです。 [sage] 2025/09/07(日) 01:31:40.81 ID:qucJSDY/ Geminiの総括 最終的な結論と最適な選択肢 100x100タイルの規模であれば、A方式とC方式はどちらも十分に高性能です。 手軽さ、シンプルさを最優先するなら「A方式」 巨大なSurfaceを最初に1回だけ作成すれば、あとはblit()のオフセットを調整するだけで済みます。コードが非常にシンプルになります。 拡張性、将来的な複雑なゲームシステムを考えるなら「C方式」 マップデータが配列として存在するため、ゲームの規模が大きくなったり、タイルごとに異なるプロパティ（通行可能か、イベントが発生するかなど）を持たせる場合に柔軟に対応できます。 どちらの方式も今回の条件では問題なく動作するため、あなたのゲームの要件や実装の好みで選ぶと良いでしょう。 http://mevius.5ch.net/test/read.cgi/gamedev/1757016104/66
ﾒﾓ帳
(0/65535文字)
上
下
前
次
1-
新
書
関
写
板
覧
索
設
栞
歴
あと 936 ﾚｽあります
ｽﾚ情報
赤ﾚｽ抽出
画像ﾚｽ抽出
歴の未読ｽﾚ
Google検索
Wikipedia
ぬこの手
ぬこTOP
0.009s