ゲーム制作 雑談スレ【part39】 (447ﾚｽ)
上下前次1-新
1: 09/05(金)05:01 ID:8xjvC6lP(1)調 AAS
楽しく雑談しましょう
次スレは>>980が立てる
前スレ
ゲーム制作 雑談スレ【part34】
2chｽﾚ:gamedev
ゲーム制作 雑談スレ【part35】
2chｽﾚ:gamedev
ゲーム制作 雑談スレ【part36】
2chｽﾚ:gamedev
ゲーム制作 雑談スレ【part37】
2chｽﾚ:gamedev
ゲーム制作 雑談スレ【part38】
2chｽﾚ:gamedev
2: 09/05(金)07:56 ID:F4WKOx5q(1)調 AAS
皆で寄生虫berを駆除しようぜ！
3: 09/05(金)09:29 ID:YwyOiKf6(1/2)調 AAS
景気の良い話題頼むぜ
4: 09/05(金)10:29 ID:n2QpHKy9(1)調 AAS
たて乙
5(6): 09/05(金)17:39 ID:xUKvzI2+(1)調 AAS
縦100キャラ×横100キャラの広さマップの、11キャラ×11キャラの範囲だけが表示されて
移動に伴いマップがスクロールする、て感じのゲームをpygameで作りたい
ファミコンのドラクエみたいな感じの
マップはその範囲の地形を描画すれば描ける、
スクロールは地形をちょっとずつずらしながら描いていけばできる、
ということは分かった
ただ、表示される範囲だけ・新たに現れる地形を描いていく、というのは、
低スペックなハードではそうする必要があるかもしれないけど
きょうびのPCでそこまでしてやる必要あるのか？という気がしてきた
最初から100キャラ×100キャラの巨大なマップ画像を作成して、
移動にあわせて表示させる位置をずらしていく、という方式をやろうと思ってるのだけど
性能は悪いかもしれないなと
ポピュラーな方法というと、どんなやり方なのだろう
6: 09/05(金)17:49 ID:LnWYjq0I(1/2)調 AAS
pygame はタイルベースのマップをサポートしてるんじゃろ？
普通にそれを使えばいいじゃない
7: 09/05(金)18:29 ID:79SQncrN(1)調 AAS
性能じゃなくて頭が悪いんだよ
8: 09/05(金)19:07 ID:y4GvjTlJ(1/2)調 AAS
必要なのはマップタイルのプーリング
最初から100x100のリソースを読み込んでたら固まるから必要に応じて使い回しと追加
まあ試してぶつかりながら解決していけばいいさ
9: 09/05(金)19:11 ID:1ufGACaE(1)調 AAS
表示される範囲だけ・新たに現れる地形を描いていく、これがもっとも多くのドラクエ風ゲームで用いられているポピュラーな方法です。
お役に立ちましたか？ 今後のご活躍をお祈り申し上げます。
10(1): 09/05(金)20:16 ID:btFndYsa(1/4)調 AAS
>>5
認識が間違ってるよ
後者のほうが処理軽い
そして当然のことながら後者がポピュラー
11(2): 09/05(金)21:49 ID:YwyOiKf6(2/2)調 AAS
>>10
流石にそれは無い。100×100が11×11になるんだったら、単純計算でも処理が1/81になる
12: 09/05(金)22:01 ID:bNECSadG(1)調 AAS
いまどき珍しいものを実装したいのにポピュラーさに頼るのってなんか勿体ないな
13: 09/05(金)22:17 ID:LnWYjq0I(2/2)調 AAS
4K画像一枚絵で、タイルではできないマップを作りたいなら、それも面白そう
絵を描ける人じゃないとできないけど
14(1): 09/05(金)22:17 ID:btFndYsa(2/4)調 AAS
>>11
描画処理を知らんのだな
ゲームみたいな動的映像は常に全領域再描画してるんだよ
11x11の領域しか再描画しなくていいなんて状況にはならない
15: 09/05(金)22:24 ID:y4GvjTlJ(2/2)調 AAS
最近はハードのスペックに頼りすぎて最適化のノウハウが積めないらしいな
UE製のコンシューマゲームとか酷過ぎるとか論争になってる
16: 09/05(金)22:48 ID:XQ1vHSrP(1)調 AAS
クソスペPCだし考えざるを得ない
まあ業界に入れるやつは金持ちなんだろうな
17: 09/05(金)22:50 ID:btFndYsa(3/4)調 AAS
>>11
いや違うな
君は話そのものを何か勘違いしてるね
11x11を描画するか100x100を描画するかって話じゃないから
そもそもの>>5君のレスがちょっと意味不明な感じあるけど
18(1): 09/05(金)22:58 ID:btFndYsa(4/4)調 AAS
>>5君が言ってるのは
描画領域外のマップを事前に保持してるかどうかの違いでしかないので
描画領域内に入るたびに描画処理する前者より
事前に裏で描画してある領域を表示するだけでいい後者のほうが当然軽い
19: [aｓげ] 09/05(金)23:10 ID:9PC6rZI3(1)調 AAS
LODは
20(1): 09/06(土)01:48 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をつかう。
21(1): 09/06(土)03:22 ID:gwr+bGfK(1/10)調 AAS
>>14
行ってることイミフ。毎フレーム全描画してるのはその通りだが、エンジンが内部で視野外カリングしてくれなかったら、全タイル描画は尚更重くなる
最近の低レベル描画エンジンは視野外をカリングしてくれるとはいえ、それでも100×100の内の11×11に限定すれば付随処理は1/81になる
>>18
裏で描画とかイミフ。上でも言ったが内部では毎フレーム、画面バッファをクリアして視野内を全部レンダリングし直している
マップ用テクスチャをあらかじめ描画しておいてゲームシーンで使い回すにしても、テクスチャサイズには限界がある。最近の高解像タイルには不向き
22: 09/06(土)05:27 ID:nuZTTbZ9(2/9)調 AAS
>5 固定のドラクエ固定マップ、テラリアのプロシージャルなマップ、リアルタイムステラテジーのマップ、自由に地形を変えれるマップを作りたいとかで作り方かわるから回答者が困らないようにもう少し情報くれた方がいい。
23: 09/06(土)07:55 ID:wNaD85zc(1)調 AAS
ピープホール型RPGという用語すら知らん奴らおるんか
24: 09/06(土)09:12 ID:sL2TO1kg(1)調 AAS
才能の無いゴミがピーピー泣いてて草ｗ
25: 09/06(土)09:30 ID:gj8crVsc(1/4)調 AAS
>>21
部分描画も事前描画も知らないのはゲーム製作者として致命的では？
サイズがでかすぎるなら分割してメモリに保持してればいいだけ
26: 09/06(土)09:45 ID:gj8crVsc(2/4)調 AAS
100x100←マップサイズ
11x11←描画サイズ
この場合事前に描画した100x100のマップの必要な11x11領域をくり抜いて毎フレーム描画するんだから
余計な処理はしてないからカリングなんか必要ないし
1/81とか言われても何言ってるんだかって感じ
静的マップを事前に保持しないで毎フレームいちいち描画してたら描画回数が1回から121回(11x11)に爆増するだろ
ドット絵のくせに何でこんなに重いんだよ！って最適化不足ゲームの出来上がり
27: 09/06(土)09:48 ID:gj8crVsc(3/4)調 AAS
普通にゲーム作っててこんなアホな実装するわけないので
結局は話をよく理解してなくて何か勘違いしてるだけだね
28: 09/06(土)10:17 ID:nuZTTbZ9(3/9)調 AAS
質問者のPygameの練習で低ドットの迷路とか作るレベルじゃないのかな。
いつまでも揉めてないで、自作ゲームを自分のポリシーに沿って最適化すればいいんだよ。
29: 09/06(土)11:11 ID:gj8crVsc(4/4)調 AAS
質問した人は質問だけして消えたけど
話理解してない人が横から絡んできたんだから仕方ない
30: 09/06(土)11:14 ID:ntBmkgul(1)調 AAS
Unityででっかいマップを作った時って描画はカメラに応じて最小限になってんのかな
31: 09/06(土)12:05 ID:hIKwuN7F(1)調 AAS
レンダリングパイプラインってのを調べるといい
そもそも上でもめてる内部処理と画面に表示されてるもの（たぶんお前が描画といってるのがここでごっちゃになってる）は別だから、その辺も含めて勉強するといい、隙間時間でも2週間くらいやれば理解できるだろ
基礎中の基礎だから、ここが自習できない理解できないわかんないならゲ製は無理マジでアキラメロン
32: 09/06(土)12:51 ID:EXmAikSr(1/3)調 AAS
まあこの程度のことを聞いてるって事は１枚絵だけじゃなくてキャラとかも全部100x100に乗せそうだから
画像１枚をスクロール描画するとかという前提での議論は無意味だよ
33: 09/06(土)12:51 ID:nuZTTbZ9(4/9)調 AAS
>理解できないわかんないならゲ製は無理マジでアキラメロン
流石に一言余計。忍者といい地罰信者といいマウント取りたいだけの人がいるなぁ
34: 09/06(土)12:54 ID:nuZTTbZ9(5/9)調 AAS
絡んでこられてもスルーが吉。息抜きの雑談スレで無駄な体力使うことない
35(1): 09/06(土)13:28 ID:gwr+bGfK(2/10)調 AAS
>>20のＡが重いか軽いかという話なら、やっぱり>>20のＡの方が処理としては重いだろ
マップタイルを描画する場合、全体マップのテクスチャを使っても使わなくても、いずれにせよ描画コールは１回だけで済む。デカいテクスチャを使う方が重い
そもそも数千px四方に納まる全体マップという条件が特殊過ぎるので、レトロ作風か習作にしか通用しない。横に１画面程度スクロールさせるだけで世界の端かよｗ
反対に全体マップが数千px四方程度なら細かいこと気にせず、全体マップも作成せず、低レベルの視野外カリングに任せて、毎フレーム100×100描画で無問題
36: 09/06(土)13:48 ID:7Km6Wgc5(1/2)調 AAS
今のハードウェアなら、2Dスクロールなんか大した問題じゃない
誰か、PC8801SR でパララックススクロールを実装する技術でシメてくれ
37(2): 09/06(土)13:49 ID:bbhijobr(1/3)調 AAS
>>35
いやその人の例えならBのほうが重いよ
GPU負荷はどっちも同じで気にするほどの誤差は出ない
大量のドローコールによるCPU負荷が段違い
描画以外にもCPU処理は必要だから間違いなくBは次第にフレームレートが稼げなくなる
アホなこと考えてないで両方実装して試してみなよ
38(1): 09/06(土)13:58 ID:gwr+bGfK(3/10)調 AAS
>>37
だからドローコールはどちらも１回だと言ってるだろ。テクスチャサイズの方がネックとしてデカい
39: 09/06(土)13:59 ID:gwr+bGfK(4/10)調 AAS
>>37
アホアホうるせえんだよ、このアホが。お前が試せｗ
40(1): 09/06(土)14:10 ID:bbhijobr(2/3)調 AAS
>>38
どちらも一回なんてありえないだろ
Bは全チップをチップ枚数分描画してるんだよ
ドローコールはAが1回でBは121回
お前の仮定がおかしい
つまり話を何にも理解してない
41: 09/06(土)14:24 ID:EXmAikSr(2/3)調 AAS
まだ地罰の話してたほうが平和だったなｗ
質問した奴もほくそ笑んでることだろう
42(2): 09/06(土)14:24 ID:nuZTTbZ9(6/9)調 AAS
喧嘩するなよ。俺が判定してやるよ３２Pixの場合
〜100×100 タイル（3200×3200 px）Aが有利（blit 1回 vs 400回）
300×300 〜 → B/Cに移行するのがおすすめ。
128PIXの場合 100X100でAは現実的じゃない。
想定するピクセルがわからない時点で喧嘩しても意味ないぜ
43(1): 09/06(土)14:25 ID:gwr+bGfK(5/10)調 AAS
>>40
つ 例：glDrawElements
何も理解してなさすぎワロタ
44: 09/06(土)14:26 ID:gwr+bGfK(6/10)調 AAS
>>42
失礼だな！喧嘩腰なのは奴の方だぞ
45(1): 09/06(土)14:41 ID:nuZTTbZ9(7/9)調 AAS
>>43 Pygame単体でタイル描画してるなら → glDrawElements とは無関係だよ。
君は PyOpenGL + pygame(OpenGLモード) で glDrawElements を使えといってるのだろうが、そもそも質問者はそのレベルにいないよ。
46: 09/06(土)15:00 ID:bbhijobr(3/3)調 AAS
>>42
Aをマップ画像をゲームフォルダに入れとくことを言ってるなら
そんなの最初から考慮しないでしょ
そのうちファイルサイズえらいことなるじゃん
最初から>>5の後者がCでしょ
視界に入る部分だけってのがどの範囲なのかよく分からないけど
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
https://pbs.twimg.com/media/G0JLSr4a0AAHTZY.jpg
https://pbs.twimg.com/media/G0JLUtQawAAd_xV.jpg
カメラ範囲だけの処理にとどめてくれる機能はpygameにはないらしい
unityにはある
pygameで作るなら昔ながらのc言語のゲームの作り方で作る必要がある
2000年代によくあったゲーム制作本にはそのやり方結構載ってた
50(1): 09/06(土)16:31 ID:gwr+bGfK(7/10)調 AAS
>>49
pygameは知らんけど、どんな低レベル描画エンジン使ってるにしろ、低レベル描画エンジンがカリングしてくれるだろ
上下前次1-新書関写板覧索設栞歴
あと 397 ﾚｽあります
ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ
ぬこの手 ぬこTOP 0.019s
