【ウディタ】ループの処理負荷について

今日調べてたループに関する処理負荷をまとめておこうと思います。

<< ループ内の行数 >>
ループ処理を抜ける場合は
『ループここまで』コマンドまでの行数に応じて
処理負荷が変化します。

ループを抜けると言いましたが、ループを実行しない場合にも
行数が影響します。
-- ▼処理負荷比較 --
     

上記画像の結果のようにループ内の行数が多いほど
処理負荷がかかるみたいです。

行数が多いほど負荷が上がる原因は
ループを終了するときに『ループここまで』コマンドを
探索しているためだと思われます。


<< ループ中断 >>
『ループ中断』コマンドが実行されると
『ループ中断』コマンドの位置から下方向に
『ループここまで』コマンドを探索します。

ループを抜けるときにループ内の行数に応じて
負荷が変わったように
『ループ中断』～『ループここまで』間にある
処理行数に応じて負荷が変わります。

-- ▼処理負荷比較 --




<< ループ開始へ戻る >>
『ループ開始へ戻る』コマンドが実行されると
『ループ開始』地点へ戻ります。
このとき『ループ開始』地点は予め記録されており
『ループ開始』地点へ戻るときの処理負荷は一定だと
思われます。
(※複数のパターンで実験してみての印象ですので
　『ループ開始』地点が記録されていると断定はできません)

ただし、『回数付ループ』の場合は
『ループ開始へ戻る』コマンドが実行されたあとに
指定回数ループしたかどうかの判定が実行されます。
もしループが完了していた場合は
『ループ開始へ戻る』コマンドの位置から
『ループ中断』コマンドが実行されます。

よって『ループ開始へ戻る』～『ループここまで』間の
処理行数が多いほど、ループを抜けるときに処理負荷が
高まってしまいます。

-- ▼処理負荷比較 --




[ 余談（興味ない人はスルーでOK） ]
『ループ中断』コマンドが実行されると
現在のループ処理に対応する『ループここまで』コマンドを
探索します。
ここで言う対応する『ループここまで』コマンドというのは
『ループ開始』コマンドのインデントと
同じインデントに存在する『ループここまで』コマンドです。
インデントというのは以下のイベントコードで言う
<0>や<1>の数値のところです。
▼イベントコード

WoditorEvCOMMAND_START

[170][0,0]<0>()()

[0][0,0]<1>()()

[498][0,0]<0>()()

WoditorEvCOMMAND_END

この場合
[170][0,0]<0>()()　が　『ループ開始』コマンド
[498][0,0]<0>()()　が　『ループここまで』コマンド
インデントの部分を見ると同じ 0 がセットされています。
ここが一致する『ループここまで』を探索します。
つまりイベントコードを弄って本来は違うインデントのところで
対応した『ループここまで』コマンドを置くと
そこをループ終了地点と誤認させることができます。

指定フレームで値を指定値まで変化させる処理

今回は指定したフレームで値を指定した値まで変化させるときの
現フレームの値を求める処理について書きます。

さっそくですが計算式書きます。
『新しい現在の値 = (相対値 * 現在の経過フレーム数) / 処理フレーム + 初回値』

上記の式で求めることができます。

たとえば

X座標20のオブジェクトAを60フレームかけて
X座標100まで移動したい。
このときの24フレーム経過後のオブジェクトAの
X座標は？
   
これを求めるとした場合

「24フレーム後のX座標 = ((100-20) * 24) / 60 + 20」

という風な式になります。

最初X座標が20なので
初回値には「20」を割り当てています。

X座標が20→100と変化させたいので
相対値には「80」を割り当てています。
もし100→20と移動させたい場合は相対値を「-80」にします。



これでなぜ座標が求まるかというと
経過フレームと処理フレームの割合をもとに算出されているからです。

「経過F/処理F」によって割合が求まります。
この割合と最大値を掛け算することによって
割合に応じた値が算出されます。

分かりやすく例えると

「６＊(1/2) = 3」
これは6＊1/2、つまり6の半分の値が求まります。
この「1/2」が割合に相当します。

これがもし「2/2」だった場合、1になり
「6＊1 = 6」
最大数の6が求まるわけです。

この計算を処理に応用した式が
『新しい現在の値 = (相対値 * 現在の経過フレーム数) / 処理フレーム + 初回値』
というわけです。

描画順序を求める処理

久しぶりのブログ更新

とはいえウディタでの開発は一時中断中なので書くことがないので
アルゴリズムの記事でも書こうかなっと

とりあえず
描画に関するアルゴリズムについて今回は書こうと思います。

描画とはいえいろいろあるわけですが、
この画像のようにキャラがオブジェクトの後ろ側か手前側かで
描画順序を変える処理（描画順序を求める処理）についてまとめたいと思います。


マップ上で不特定多数のキャラと不特定多数のオブジェクト同士の
描画順序を求めるアルゴリズムという感じですかね。

というわけで本題に入ります。

まず描画グループとグループ同士の描画順序を設定します。
ここでは例として

描画グループは
・主人公や味方
・敵
・オブジェクト
の３つ。

各グループの描画順序は
(前面)>「主人公や味方」>「敵」>「オブジェクト」>(背面)
とします。

また、
マップ上の３２ピクセルを１座標(１マス)とした
マップ座標系でこの描画順序を管理し、

ピクチャは１０００枚まで使用可能。
（この描画順序処理において描画できる最大の枚数的な感じ）

マップは縦１０マス横１０マスとします。

とりあえず例としての設定はこんな感じで。


じゃあこれでどうやって順序を求めるかというと
割と単純な話で
各マップY座標別に描画IDを割り当てるという感じになります。


これだと説明不足なので細かく説明していきたいと思います。

まずマップが縦１０マス（Y座標0~9）なので
それらの各Y座標にグループを割り当てます。
次に割り当てたグループに描画IDを割り当てます。
データ構造のイメージは以下のような感じです。
 
まぁ描画IDというか描画できる枚数というかそんな感じかも。

もっと詳細に書くと
Y座標０～９にそれぞれ３つのグループを割り当てる(主人公味方,敵,オブジェクト)
その３つのグループはそれぞれ最大でN個ピクチャを登録できるように設定する。

ここでN個の求め方だけど
まずピクチャ(描画)は最大で１０００枚まで登録可能で
マップは縦１０マス、グループは３つ。
つまり
『N = (1000/10)/3』

(1000/10)は各座標に割り当てれるピクチャの最大数
その最大数をグループの数、３で割ることで
各グループに割り当てれるピクチャの最大数が求まる。

この例の場合
(1000/10)/3 = 33（小数点以下は切り捨て

よって
１グループにつき３３枚まで登録が可能になる。

で
もうこれで終わりになります。
あとは登録して描画するだけ。

Y座標が２の主人公のピクチャを登録するときは
Y座標「２」のグループ「主人公味方」に登録。

次にY座標が同じく２の味方を登録するとしたら
Y座標「2」のグループ「主人公味方」に登録。
このとき「主人公のピクチャ」がすでに登録されているので
次のIDに味方を登録するようにする。
よって以下のようなデータ構造になります。


あとはこの登録したデータをもとに描画処理を行います。

マップ上でY座標が0に近づけば近づくほど（マップ上側）背面
Y座標が9に近づけば近づくほど（マップ下側）前面に描画されるべきなので
ウディタであればピクチャ番号の配分を
「Y座標が小さい方」の登録データを小さいピクチャ番号
「Y座標が大きい方」の登録データを大きいピクチャ番号になるように
割り当てて描画すればいい感じ。

ウディタとかのピクチャ番号という概念がない場合は
マップY座標0から順に描画していく。

もちろんグループ内の順序も忘れなく。

ちなみにここでは描画の順序を決める処理を書いただけで
実際に描画処理と連携する部分は書いていないのでその辺は自分で考えましょう
（書くのめんどい）

ウディタならちょっとめんどくさいことになりそうな予感はするけどね。

あくまでこの処理はC言語で実装した処理なので
ウディタで使いやすいように最適化はしていないので注意。


あと登録するときに主人公等のY座標をもとに登録してたけど、
この場合主人公の足元の座標のマップY座標を使うようにしないと
描画が変なことになるので注意ね。

ここまで書いて思ったけどアルゴリズムというより
単なる描画順序保存用のデータ構造の例だよねこれｗ

あとなんかいろいろ説明が変な気もする。
まぁ細かいことは気にしない。
というわけでこの辺で終わりにしたいと思います。

（今回の説明ではデータとして登録していく流れで説明したけど
　それとは別の方法をとって
　各座標の各グループの各描画IDを全て１つの連番IDにまとめて
　そのIDを計算で吐き出す処理に書き換えれば
　ウディタとかのピクチャ番号を計算する処理もできると思う）