プレイ日記
コウラン coulank
やっぱBGマップ読み込ませて配置するのには無理があった\(^o^)/ Y軸回転すると隙間もできるし
11そうだね
プレイ済み
返信[1]
親投稿
コウラン coulank
少なくとも16×16はあっという間に512個に到達しちゃうし、軽く5000個も配列が増えて使いにくいから、専用のグラフィックの最低サイズは32×32が妥当かな…
0そうだね
プレイ済み
返信[2]
親投稿
コウラン coulank
ちなみにBGマップは一つのレイヤーごとに最大16532くらいだったと思う 空っぽ以外を反映しても、あっという間に大変なことになっちゃう… 回転についてはY軸角度からROTは試すよ!
0そうだね
プレイ済み
返信[3]
親投稿
コウラン coulank
とりあえず次は回転の仕様と大きすぎるマップに対して大まかな位置ごとに分割してローカルキャッシュ式にやりくりできるのも作りたい…これもまた難しいけど!
0そうだね
プレイ済み
返信[4]
親投稿
コウラン coulank
うーむ、これどうやっても不揃いになっちゃうやつや Yの差を使って高低差を作るのは捨てた方がいいっぽい?
0そうだね
プレイ済み
返信[5]
親投稿
コウラン coulank
あ、原因のひとつこれだわ、Y軸回転考慮してないのが丸わかり
0そうだね
プレイ済み
返信[6]
親投稿
コウラン coulank
最大高さで後ろにBGを配置して隙間を埋めつつ、更にその後ろにはグラフィック画面で雲とか描くって形で考えてる 誤魔化しをするのも必要だもんね! Y軸回転は単純に三角関数で場合分けするだけだからすぐにできる
0そうだね
プレイ済み
返信[7]
親投稿
ツララ LongIceSword
隙間問題ならSPDEFでスプライトのサイズを周囲1ドットずつ拡張して18×18で設定して使ってみたりしたらいいんじゃないです? SPROTで回転させるとグラフィック画面上での周囲のドット情報も読み取られてるっぽい感じですし。
2そうだね
プレイ済み
返信[8]
親投稿
コウラン coulank
SPROTだけの問題じゃないっぽくて、隙間はスプライトの大きさがなかなか適切にならないってやつなのですー SPSCALEも同様に周囲のドットの情報がはみ出ることがありますし、そこも考慮に入れて作っています! 多分隙間埋めてもYの回転角が45度のときの見辛さという問題には免れないので、Yの回転角そのものを無くす形にします\(^o^)/ 助言いただいたのに申し訳ない限り
0そうだね
プレイ済み
返信[9]
親投稿
コウラン coulank
3Dにある機能を盛り込めば盛り込むほど処理が超重くなりますので、再現できなさそうなとこは取捨選択する形です!
0そうだね
プレイ済み
返信[10]
親投稿
コウラン coulank
ひとつ前のバージョンでもう一度様子見してみて思ったこと… 木を平面扱いしてたときは良い感じだったから…回転はしなくても良さそうな気もしてます あと隙間問題はやっぱ床のみ1px余分に増やすのが確実に見えますね
0そうだね
プレイ済み
返信[11]
親投稿
NAGI KOUCHA_PAN
オープンワールドてきなものができそう。がんばってください
2そうだね
プレイ済み
返信[12]
親投稿
ボーネン gurigura2003
いいですね。そういうのぼくだいすき。 でもグラフィックですると FPSがすごいことになりそうですね…
1そうだね
プレイ済み
返信[13]
親投稿
コウラン coulank
現在グラフィックの反映は全部SPANIMで実装してますので、ぬるぬる動きます! 現在の処理速度から自動的に反映待ちの時間を変えてます! とはいえ待ち時間は多くなると発生しますが、入力判定が快適になるようにVSYNCに頼らず極力入力待ちを増やすようにしてます!
0そうだね
プレイ済み