11/06/21 19:29:12.62 63a9Z6UZ
>>471
アドバイスありがとん
ＤＸライブラリでアンチエイリアスの指定ってできたっけ？
まぁ、色々いじって、解決させたので方法書いておきます
・SetCameraNearFarで手前クリップ位置を遠くしてみる
これでだいぶ軽減できました。でも見えるときは見える
・くっついた位置に描画されるポリゴンを描画しない
ブロック同士の境目のポリゴンを消しとけば、隙間なくうまってるように見える。
要するに何らかの加減で、縦方向のポリゴンの一部が見えてるってことらしい。
479:名前は開発中のものです。
11/06/23 16:57:31.52 fyYcjHqX
LoadSoundMem 使うと、読み込むファイルの倍近くメモリ食うんだけどこんなもん？
480:名前は開発中のものです。
11/06/23 17:32:53.79 QnDjyPpc
読み込んでるのが圧縮ファイルなら
SetCreateSoundDataTypeがDX_SOUNDDATATYPE_MEMNOPRESS（デフォルト）だからかもしれない
481:名前は開発中のものです。
11/06/23 19:26:55.04 DnQjdRmc
おぉ、そんな設定があるんだ
知らんかった
482:名前は開発中のものです。
11/06/23 19:36:12.62 fyYcjHqX
>>480
素早いレスポンスまじ助かる
用途に合わせて使ったらメモリ使用量がスゲー減ったよ
本当にありがとう
483:名前は開発中のものです。
11/06/23 20:03:47.01 8jCWoIDE
描写の基礎中の基礎だと思うのですが
例えば落ち物パズルゲーム（ジャンル関係なく）
落下物を一番下まで置く
次の落下物
以下ループ
移動物は当然、描画→消す→再描画が必要になると思いますが
動かなくなった物もこのルーチンに組み込むしかないのでしょうか？
484:名前は開発中のものです。
11/06/23 20:07:04.40 UJG7O4KB
>>483
そうだよ、毎回全部再描画
全消し＆全再描画が基本
485:名前は開発中のものです。
11/06/23 20:11:03.75 AbrHzuoP
一昔前のスペックのPCでも、60フレームで毎回数千枚画像を描画しても問題ないしな
ゲーム作り始めた人は大抵最初疑問に思うよな、コレ
486:名前は開発中のものです。
11/06/23 20:22:51.26 5vtX6Rn6
むしろDxLibのサンプルを読むと、裏描画→スワップ→裏消す→ループの流れになってたから素直に馴染んでた。
487:名前は開発中のものです。
11/06/23 20:40:33.33 3TDZtZ67
>>483
処理速度の遅い、昔のパソコンだと、いかに描画部分を減らすかが勝負だったから、
貴方の考えてるような事（動かないものは再描画しない）は重要だった。
ファミコン等で使われてるスプライトやBG機能はそういうのをハード的に処理する事で、
軽快な動きを実現させていた。
今のPCはそんな事考える必要ないくらいの処理速度なので、やってる人はいないでしょう。
もちろんできなくはないけどデメリットが多くてメリットは少ない。
488:名前は開発中のものです。
11/06/25 11:42:26.53 cdu6xBQg
>>483
画面のほとんどが将棋みたいに静止してるゲームを除いて
削れる対象って少ないよ。（高速化が必要なゲームで使えない手法）
小さな領域で何回も描画すると遅くなるし。
489:名前は開発中のものです。
11/06/25 11:49:53.47 cdu6xBQg
ハイポリゴンの3Dがぼけっと止まってるとかなら
描画した結果を写真みたいに1枚のテクスチャにしてしまうのが有効