やっぱBGマップ読み込ませて配置するのには無理があった＼(^o^)／ Y軸回転すると隙間もできるし

少なくとも16×16はあっという間に512個に到達しちゃうし、軽く5000個も配列が増えて使いにくいから、専用のグラフィックの最低サイズは32×32が妥当かな…

ちなみにBGマップは一つのレイヤーごとに最大16532くらいだったと思う 空っぽ以外を反映しても、あっという間に大変なことになっちゃう… 回転についてはY軸角度からROTは試すよ！

とりあえず次は回転の仕様と大きすぎるマップに対して大まかな位置ごとに分割してローカルキャッシュ式にやりくりできるのも作りたい…これもまた難しいけど！

うーむ、これどうやっても不揃いになっちゃうやつや Yの差を使って高低差を作るのは捨てた方がいいっぽい？

あ、原因のひとつこれだわ、Y軸回転考慮してないのが丸わかり

最大高さで後ろにBGを配置して隙間を埋めつつ、更にその後ろにはグラフィック画面で雲とか描くって形で考えてる 誤魔化しをするのも必要だもんね！ Y軸回転は単純に三角関数で場合分けするだけだからすぐにできる

隙間問題ならSPDEFでスプライトのサイズを周囲１ドットずつ拡張して18×18で設定して使ってみたりしたらいいんじゃないです？ SPROTで回転させるとグラフィック画面上での周囲のドット情報も読み取られてるっぽい感じですし。

SPROTだけの問題じゃないっぽくて、隙間はスプライトの大きさがなかなか適切にならないってやつなのですー SPSCALEも同様に周囲のドットの情報がはみ出ることがありますし、そこも考慮に入れて作っています！ 多分隙間埋めてもYの回転角が45度のときの見辛さという問題には免れないので、Yの回転角そのものを無くす形にします＼(^o^)／ 助言いただいたのに申し訳ない限り

3Dにある機能を盛り込めば盛り込むほど処理が超重くなりますので、再現できなさそうなとこは取捨選択する形です！

ひとつ前のバージョンでもう一度様子見してみて思ったこと… 木を平面扱いしてたときは良い感じだったから…回転はしなくても良さそうな気もしてます あと隙間問題はやっぱ床のみ1px余分に増やすのが確実に見えますね

オープンワールドてきなものができそう。がんばってください

いいですね。そういうのぼくだいすき。 でもグラフィックですると FPSがすごいことになりそうですね…

現在グラフィックの反映は全部SPANIMで実装してますので、ぬるぬる動きます！ 現在の処理速度から自動的に反映待ちの時間を変えてます！ とはいえ待ち時間は多くなると発生しますが、入力判定が快適になるようにVSYNCに頼らず極力入力待ちを増やすようにしてます！