ゲーム制作　雑談スレ【part39】

[過去ﾛｸﾞ] ゲーム制作　雑談スレ【part39】 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

47: 09/06(土)15:03 ID:i+R/pY0x(1) AAS
せっかくの週末にレベルの低い話をするなよ
こんなのは「好きに作れ」が答えだろ

48: 09/06(土)15:19 ID:nuZTTbZ9(8/9) AAS
そのとおりだよ。質問に対して「俺ならこうする」だけでいい。
質問者はお礼を言ってその中でいいと思ったやり方で作ればいい

49(1): 09/06(土)15:36 ID:w/QEgYfo(1/4) AAS
画像ﾘﾝｸ

画像ﾘﾝｸ

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

50(1): 09/06(土)16:31 ID:gwr+bGfK(7/10) AAS
>>49
pygameは知らんけど、どんな低レベル描画エンジン使ってるにしろ、低レベル描画エンジンがカリングしてくれるだろ

51(1): 09/06(土)16:36 ID:w/QEgYfo(2/4) AAS
>>50
ChatGPTによればpygameはないんだって

52: 09/06(土)16:54 ID:nuZTTbZ9(9/9) AAS
＞pygameは知らんけど

いままでの論争はなんだったんだ。

53: 09/06(土)17:28 ID:gwr+bGfK(8/10) AAS
>>45
「こんな所にS級が？！」とかあるあるやん

・・・アニメでは

54(1): 09/06(土)18:34 ID:gwr+bGfK(9/10) AAS
>>51
Pythonスクリプト層内での低レベルAPIへの描画コールは間引かれない（APIコールしても低レベルAPI内では間引かれるかも）、て意味じゃないの？知らんけど

55(2): 09/06(土)19:34 ID:w/QEgYfo(3/4) AAS
>>54
画像ﾘﾝｸ

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

56(1): 09/06(土)19:43 ID:7Km6Wgc5(2/2) AAS
そんなにChatGPT が得意なら、pygame のタイルマップのシステムをサクッと作ったら？
たぶん、どこかからコピペしてくるよ

57: 09/06(土)19:50 ID:w/QEgYfo(4/4) AAS
>>56
俺は野球ボーイで上の者ではない
上の者は上の者で自力で頑張ってください

58: 09/06(土)20:30 ID:gwr+bGfK(10/10) AAS
>>55
平行線だな。低レベルの描画エンジンが視野外カリング・テストを行わないのは考えられない
だから俺は、そのLLMの回答はPythonスクリプトレイヤの話だ、と言っている

59: 09/06(土)20:58 ID:/kpwELhX(1) AAS
今週もよく進んだ
着実にBlenderに近づいてる
画像ﾘﾝｸ

画像ﾘﾝｸ

60: 09/06(土)21:17 ID:EXmAikSr(3/3) AAS
これからは質問されたらChatGPTに投げたほうがいいかもな
どうせ荒らしだろうし

61(1): 09/06(土)22:37 ID:zOtGPqEd(1) AAS
>>55
チャッピーに騙された可哀想な人がいる……
もう一度これで質問してみ？

Q: 以下の問いについて事実に基づいた解説をせよ。
1. pygameのSurface.blit() は、ソースのピクセルをdest Surfaceに転写する処理である。
2. この転写時にソースが出力先の範囲を超える場合、その領域は自動的にクリッピングされ、省略される。
3. ソースと出力先が完全に重ならない場合、描画処理は行われず内部的に早期リターンされる。

62: 09/07(日)00:45 ID:qucJSDY/(1/8) AAS
野球マンは、Unity使いなんだし朝から同じ話題に辟易してChatGptで調べただけだから、別にPygameがNinateやLumen使えてもどうでもいいだろう。

63: 09/07(日)00:54 ID:qucJSDY/(2/8) AAS
GoogleGeminiで聞いてみたよ

カリングとblit()の最適化
「カリング」という用語は、一般的にゲーム開発において、描画パイプライン全体で不要なオブジェクトを描画リストから除外する手法を指します。これには、フラスタムカリング（カメラの視錐台の外にあるオブジェクトを無視する）、オクルージョンカリング（他のオブジェクトに隠れて見えないオブジェクトを無視する）などが含まれます。
PygameのSurface.blit()は、このような広義のカリング機能自体は提供していません。つまり、開発者が自分でオブジェクトの座標を確認し、画面外にある場合は描画関数を呼ばないように制御する必要があります。
しかし、以前の回答で述べた「早期リターン」の機能は、blit()関数内部で行われる描画処理の最適化です。これは、特定の描画命令（この場合はblit()）の引数（ソースとデスティネーション）が描画対象として無効である場合に、GPUやCPUへの負荷をかけずに処理を終了させるためのものです。
まとめ
Pygame自体が、シーン全体の不要なオブジェクトを自動的に描画リストから除外するような、高度なカリング機能は提供していない
blit()の内部最適化：blit()関数は、引数で渡されたソースとデスティネーションの矩形が重ならない場合、内部的にピクセル転送処理をスキップするという最適化を行っています。
これは、Pygameの描画関数の効率を高めるための実装レベルの工夫であり、広義の「カリング」機能とは異なります。

64: 09/07(日)01:09 ID:qucJSDY/(3/8) AAS
すでに5の質問とはかけ離れてるし、平行線で続けて長くなるんなら別スレ作れば？

65: 09/07(日)01:30 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方式と性能差はありませんが、プロシージャルダンジョンなどゲーム開発のベストプラクティスとして最も推奨される方法です。

66: 09/07(日)01:31 ID:qucJSDY/(5/8) AAS
Geminiの総括
最終的な結論と最適な選択肢
100x100タイルの規模であれば、A方式とC方式はどちらも十分に高性能です。
手軽さ、シンプルさを最優先するなら「A方式」
巨大なSurfaceを最初に1回だけ作成すれば、あとはblit()のオフセットを調整するだけで済みます。コードが非常にシンプルになります。
拡張性、将来的な複雑なゲームシステムを考えるなら「C方式」
マップデータが配列として存在するため、ゲームの規模が大きくなったり、タイルごとに異なるプロパティ（通行可能か、イベントが発生するかなど）を持たせる場合に柔軟に対応できます。
どちらの方式も今回の条件では問題なく動作するため、あなたのゲームの要件や実装の好みで選ぶと良いでしょう。

67: 09/07(日)02:09 ID:w+4ozsCS(1) AAS
Geminiに聞いたことをコピペして意味なんか無いから
お前は荒らし

68: 09/07(日)02:19 ID:c3Q3zl9k(1/2) AAS
のたうちまわった末に出てきた歪なうんこ、みたいな回答

69: 09/07(日)04:34 ID:cdtbdgBv(1) AAS
AIの回答は質問者のレベル以上にはならないってのがはっきり分かるなぁ

70: 09/07(日)06:56 ID:qucJSDY/(6/8) AAS
一気に60ぐらいスレ進んだな。忍者みたいなのがいるのか

71: 09/07(日)10:53 ID:5TMUfK9O(1) AAS
>>61
問いになってないと思うのだが

72: 09/07(日)11:34 ID:4AU0/eMl(1) AAS
この時代に2Dスクロールが問題になるとはなぁ

73(1): 09/07(日)12:01 ID:ahzATgAC(1) AAS
2DLODによって
例えば32pixel*32pixelの画像が
画面の端に行くにしたがって
16*16, 8*8, 4*4,2*2の画像に置き換わる
これによってテクスチャ使用料は大幅に下がり
VRAMをより自由に使うことが可能になる
ドローコールは80%以上下がる計算だ
人間は画面のプレイヤーを表示する中心点の周りしか見ないため
このような技術を使っても実際の見た目はプレイ感ほぼ変わらずできる

74(3): 09/07(日)12:36 ID:c3Q3zl9k(2/2) AAS
# 低評価のレビュー

画面の端に向かって何故かボヤけが強くなっていくというバグがあって製作者に問い合わせしましたが、泥コーラがどうのこうのと意味不明な説明をされ、さらに見た目はほぼ変わらないので対応できないと返信がありました。
そのため即返金要求しました。
この製作者からは二度と購入しません。

こうなるだけだぞ、余計な最適化はすんな、もう一度言う、無駄な最適化はすんな

75: 09/07(日)12:48 ID:W/Q1K9c6(1) AAS
中心窩レンダリングかぁ？

76(1): 09/07(日)12:57 ID:8iqlIUfk(1) AAS
画像ﾘﾝｸ

pythonでゲームを作ったよ
でもデプロイ先がねーよ（公開するほどのクオリティでもないけど）
やっぱりフリゲはUnityRoomに落ち着くな

上下前次 1-新書関写板覧索設栞歴

あと 926 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ

ぬこの手ぬこTOP 0.017s