初期エリアはエリア移動の度に作り直さず保存するようにした！ 100*100並の配列が10個ぐらいあるので重すぎぃ…

5000行記念 のんびり作る道のり

表示用に参照する配列と表示用配列に読み込む元の配列とで別にしたりしてます？ エリア範囲の情報は他のエリアに移動するまで特に変更を加えないなら、エリアの端に移動した時に、少しずつ更新処理を分割でしておくって手もあると思いますけど。

表示用の配列は作ってないです 並列処理は自分の頭じゃ出来なそう… ツララさんが言ってるように重いなら処理分けないとダメですよね… 初回生成時に待避もしておいて更新がかかった所だけ覚えておくようにしてエリア保存の負荷を減らそうかな？

処理が重いってことは多分、上画面に表示してる11×11の範囲の他に、メインループ中で中身を毎回参照したりしてる配列があるってことだと想像しますけど もし他のエリアの情報はデータファイルとしてセーブして管理してるなら エリア移動の時に配列に読み込んでおくのは4つのエリア分だけで足りますよね？（縦隣と横隣と斜め隣の3つと現在エリアで合計4つ） 分割処理させないまでも、10個を4つに減らすだけでもかなり処理は軽くなるんじゃないかと。 エリアをデータファイルとしてセーブする時に、ファイル名に他のエリアとの繋がりを示すマクロな座標の数値を文字列として入れ込んでおけば FILES命令と組み合わせて検索は可能かと。

最初にプレイヤーがいるエリアだけ保存して他のエリアは毎回ランダム生成みたいな感じのつもりで、マップ用の配列達は最初のマップもランダムマップも共通で１つなので最初のマップから切り替える時に退避用の配列に全部コピーすると重いな～というので書いてました コメント返そうとして思いついた！！ 最初のマップ用とランダムマップ用に配列を２つに増やして、今マップ用の配列を直接触っている所を全部命令にして命令内でどちらの配列を使うか切り分けるgetter/setterモドキ作れば退避なんてしなくていいからマップ切替が重くならない！！

あ、常時重い訳じゃなくて、エリア切り替えの時に重くなるってことだったんですね。勘違いしてました、こりゃ失敬。 getter/setterって何だろう？って思ったら他のプログラミング言語での話なんですね。 自分もユウキさんと同じ様な感じ（と言っても見下ろし2Dですけど）の探索系プログラム作ってるんですけど エリアの範囲外判定するときに現在居るエリアのIDから上下左右方向に隣接してる他のエリアを特定して、表示範囲の2倍くらいのサイズを小出しに読み込んで予め画面外に表示しておいて、スクロールさせる方法でやってますん。 ちなみにBG画面で表現。移動前の表示エリアが画面外に全部出たタイミングで書き換えしてBGOFSを(0,0)に戻す、を繰り返す感じ。BGCOPYとBGFILLを使えば25×14くらいの範囲なら一瞬なので。

key?

ツララさん 見おろし2Dで作ってるんですね～過去の投稿にあったクォータービューも気になる… Guzmaさん This program is still in production. Q3345X73

あ、もしかしたら処理が重い理由をもっと根元の方で勘違いしてたかも。 もしエリア切り替わりタイミングで移動先のエリア情報をランダムで作成してるなら重くて当然ですよね。 基本的に2Dでコツコツ作ってるんですけど、移動コストを高さ依存で判定して動ける範囲を制限して、プレイヤーが移動ルートを考えながら探索するタイプにしようと思ってたので、クォータービューの方が一目で現状を把握し易いかな？という理由で疑似3D視点の作ってたりしてますん。 見た目は似てても目的が全然違うって事はよくありますよね。 でも2Dだとモロにマップの広さが飽きに直結して来るので、最低でも8000×8000くらいの広さのを作りたいなーと思ってたりするんですけども。 でも広くするとエリアの繋がり方を自然にするために使う配列のサイズがとんでもないことになるので、使えるメモリ内で収めるには区切りをどの辺にすればいいのか悩む

マップ生成自体は重くないですね～ まだ段差,川,池,オブジェクト配置ぐらいしかしてないので… あのクォータービューはメインの表示じゃなかったんですね～ 実は前回作ってた時に2Dマップ切替無し(マップ広くしたかった)でやろうとしてました！ その時はデータ用のマップと表示用のマップに分けて１つ１つのマップは小さめにして端に近づくと隣接3マップと現在のマップを合成して表示用のマップにする感じにしてメモリ節約(ロード軽減)してました