忍者ブログ

主にウディタを使ってのゲーム製作についてのブログです  ※更新は不定期

CommonEvent.datを最適化して処理の高速化を図る
WoditorOptimizerを大幅アップデートしたVer2.0.0を公開しました!

DOWNLOAD(ダウンロード)

-------------------------------------------------------------------
本アプリケーションは『.NET Framework 4.5.2』 が使用されています。
起動できない場合は以下をインストールしてみてください。
http://go.microsoft.com/fwlink/?LinkId=397708
-------------------------------------------------------------------


< 主な変更点 >

・開発環境をC++/CLIからC#に移植
  各処理を全て一新しています。

・UIの一新
 


・最適化項目追加
  ・ラベル地点を含まない『回数付きループ[0]回』削除
  ・『回数付きループ[1]回』を削除してループ内の処理を取り出す
  ・変数操作の『データを呼ばない』を最適化
  ・DB書き込みを最適化
  ・CSelfX~CSelfYの変数操作分解
  ・コモンセルフ名を削除
  ・コモンイベント名を隠蔽
  ・コモンイベントのメモを削除
  ・数値入力/文字列入力の各引数名を削除
  ・返り値名を削除
  ・コモンイベント色をランダムに変更する
  ・定数回ループの展開

・既存の最適化項目改善
  ・『コモンEv名で呼出』を番号呼出に変換する
    →指定された名前が見つからなかった場合は変換しないように変更。
     従来まではコモンイベント0番が呼び出しに変換されてしまっていた。
  ・ラベル名の最適化
    →特殊文字が使用されている場合はそのコモンイベント内では
     最適化されないように変更。


・データの取り扱いにWodiKsライブラリを使用
  データの扱いをWodiKsライブラリに一任しています。
  WodiKsライブラリを使用すればここまでできるという指標を示す意図もあります。

  ※本ツールで使用しているWodiKsは未公開の最新バージョンです。
   試用してみたい方はフォルダ内のWodiKs.dllを使用していただいてかまいませんが
   マニュアルなどは一切ありませんのでご注意ください。
   (まだテスト中/未テストの機能もあるため新機能はバグまみれの恐れがあります)

・最適化後に各最適化項目に該当したものがどれだけあったか確認できる機能
 

・最適化の実行順序を示す『実行フロー』ウィンドウ
  内部でどの順番で最適化が実行されるかを可視化します。
  将来的に実装されるかもしれないプラグイン機能に向けた機能の1つです。
 

・その他
  上記以外にいくつか細かい修正が施されています。


DOWNLOAD(ダウンロード)

拍手

PR
前回の第1弾に引き続き
ウディタ中級者上級者向けの小ネタ第2弾です!

<< 目次 >>
ラベル名に特殊文字を使用してリアルタイムでジャンプ先を変更する
ラベル名に特殊文字を使用してリアルタイムでジャンプ先を変更する

『ラベル設置』及び『指定ラベルに飛ぶ』コマンドはラベル名に特殊文字を使用できる。

これを利用してゲーム中にラベル名の変更やジャンプ先指定ラベル名を変更できる。

プログラミング言語のswitch文の再現とかも可能。

※あまり多用しすぎるとスパゲッティコードになるので注意

※ラベル文と特殊文字の連携なので重い


『1』か『0』かのフラグは1つの変数に最大で32個管理できる

ウディタのコモンセルフや通常変数、予備変数等の全ての数値変数は
4バイトで管理されている。

1バイトは8ビットで構成されるので4バイトの場合32ビットで構成されている。

各ビットにフラグを設定すれば最大で32個のフラグを管理できる。

※ビット等の詳しい説明をすると長い文章になるので

 ここでは割愛。分からない方は検索してね


コモンイベントの返り値の格納先にCDB等を指定する方法

以下はコモンイベント3を起動し返り値の受け取り先として

『CSelf0(1600010)』を指定した場合のイベントコード

WoditorEvCOMMAND_START

[210][3,0]<0>(500003,16777216,1600010)()

WoditorEvCOMMAND_END

上記イベントコードを改造して

受け取り先を『CDB[0:0:4](1100000004)』に

変更したイベントコード

WoditorEvCOMMAND_START

[210][3,0]<0>(500003,16777216,1100000004)()

WoditorEvCOMMAND_END

UDBを受け取り先として指定すると

UDBの値を書き換えることも可能。


ゲーム中に指定した名前のコモンイベントを起動する

コモンイベントを名前指定で起動する際、

名前入力欄に文字列変数を特殊文字で指定すると

その文字列変数で指定された名前のコモンイベントを起動できる。


ゲーム中にDBのタイプ数を調べる方法

データ数や項目数の取得はウディタに実装されているが、

タイプ数の取得は実装されていない。

しかし、求める方法は存在する。

タイプ名を取得した際、存在しないタイプIDの場合は

『×NoData』が返ってくるので

タイプIDを0から順に判定していけばタイプ数を求めることが可能。


ファイルが存在するか確認する方法※扱い方注意

文字列操作のファイル内容読込機能を使ってファイルが存在するか

どうかを調べることができる。

この機能を使ってファイルを読み込んだ際

ファイルが存在しなかったら『<NoFile>』が返ってくるので

それを判定してファイルの有無を確認可能

※ただし、ファイルが存在する場合は問答無用で読み込まれるので

 データの大きいものを読み込んだ際は重くなる。
 単純に有無だけ確認したい場合は扱いに注意しよう。


先頭ビットのみ『1』をセットする方法

変数操作:Cself[0] = 1073741824 + 0

変数操作:Cself[0] *= 2 + 0

※ウディタでは2000000000以上の値を直接代入できないため


通常変数や予備変数の各変数にメモを記述する

通常変数等はシステムデータベースで管理されているが

それぞれデータベースの項目は使用していない。

ウディタがバージョンアップし通常変数等の

新機能実装が入らない限り

ここの項目は追加しても問題がないので

自分用に変数の説明項目等を追加すると利便性が上がるかも。

(同様にBGMリストに著作権記入の項目を追加しておくとかの

活用方法もある)


ループ中断の処理負荷

『ループ中断』コマンドが実行されると

『ループ中断』コマンドの位置から下方向に

『ループここまで』コマンドを探索する。

よって

『ループ中断』~『ループここまで』間にある

処理行数に応じて負荷が変化する。


つまり

ループ先頭付近でループ中断を行うより

ループ末尾付近でループ中断を行う方が

ループ中断実行の処理負荷は軽い。


※ループ内の処理内容によって適切な中断位置は変わるため

 絶対に末尾付近の方が軽いとは言い切れないので注意。

 中断実行の瞬間の負荷が末尾の方が軽いというだけの話


ループ開始へ戻るの処理負荷

『ループ開始』地点へ戻る際の処理負荷は一定だが

回数付きループの場合

『ループ開始へ戻る』により回数分のループが終了した際は

『ループ開始へ戻る』コマンドの位置から『ループ中断』が

実行される。

『ループ中断』コマンドは

『ループ中断』~『ループここまで』までの

行数が多ければ多いほど重くなるため

『ループ開始へ戻る』コマンドがループ末尾に近いほど

処理負荷は軽くなりやすい。

※ループ内の処理内容によって適切な

 『ループ開始へ戻る』コマンドの位置は変わるため

 絶対に末尾付近の方が軽いとは言い切れないので注意。

 中断実行の瞬間の負荷が末尾の方が軽いというだけの話

拍手

というわけでウディタを使用するにあたっての
小ネタ集的なものを書こうと思います。
主に中級者上級者向けを対象としているので悪しからず。
(第1弾とか書いてるけど第2弾があるとは言っていない……)
※前半は処理負荷に関することが多めです。

<< 目次 >>
コメント文やチェックポイントの処理負荷
2階層下のフォルダにあるピクチャを表示する
Dataフォルダ外のピクチャを表示する

コメント文やチェックポイントの処理負荷

コメント文2.2個につき『変数操作:Cself[0]=0+0』1個分

チェックポイントも同様


空コマンドの処理負荷

コモンイベントの最終行やループ内の最終行に自動的に挿入される

空のコマンドにも処理負荷が存在する。

処理負荷はコメント文とほぼ同等だが、極わずかに軽い。


ラベル処理の負荷

ラベル名の文字列が長ければ長いほど処理負荷が高くなる。


コモンイベントの起動方法の違いによる処理負荷

番号指定のコモンイベント起動に対して名前指定のコモンイベント起動は1.5倍の処理負荷がかかる。


[0]回ループで処理を括ってもループ内の処理行数に応じて負荷がかかる

特定の処理を実行させたくない場合等に[0]回ループで処理を括っても、
[0]回ループ実行時の処理負荷はループ内の処理行数に応じて増える。

コメント文に処理負荷があるので、多数行のコメント文の処理負荷を削りたい。
そう思って[0]回ループで括っている人もいるかもしれないが

これは逆効果である。

[0]回ループで括るとかなり高負荷になるので注意。

ちなみにこれは[0]回ループの実行負荷がかかる分重くなるということではなくて、
[0]回ループ内の行数に応じた負荷がコメント文の負荷より重いということである。

つまり

『多数行のコメント文を含んだ[0]回ループの負荷』

より

『何も中に入れていない[0]回ループの負荷+多数行のコメント文の負荷』

の方が軽いということ。(※コメント文の行数は同じ)


使用するピクチャのパスが短ければ短いほど描画処理が軽くなる

以下の3つのピクチャがある場合(※全て同じ画像)

1. Picture/test01.png

2. p.png

3. P0000000000000000000000000000.png

Dataフォルダ直下にあり、ファイル名の最も短い『p.png』のピクチャの方が描画時に速く描画できる。

『p.png』と『P0000000000000000000000000000.png』

の1回の描画の処理負荷の違いは

『変数操作:CSelf0 = 0 + 0』コマンド9個分の違いがある。

処理負荷に違いがあるのは

ピクチャ表示コマンド時のみでピクチャ移動コマンドの場合は影響が無いと思われる。


DBのアクセス方法により処理負荷が変わる

DB操作にて以下のようにアクセス方法によって処理負荷が違う

<速い>

CDB[0:0:0],CDB[0:CSelf0:0]

<遅い>

CDB[CSelf0:0:0],CDB[0:0:CSelf0]

上記の違いが発生する原因は

タイプID及び項目IDに変数を指定すると

X番の変数呼出にて処理が実行されてしまうためと思われる。

変数指定をデータIDにのみ行うことで高速に処理できる。

処理負荷的には約3倍の違いがある。

※名前指定と数値指定は同じものとして考えて問題ない


ピクチャ表示とピクチャ移動の処理負荷

ピクチャ表示とピクチャ移動では移動の方が処理負荷が軽い。

既に表示しているピクチャに関してはピクチャ移動で処理してあげることによって描画負荷を軽くできる。


コモンイベント起動時に渡す引数は最大で5つまで渡せる
(数値入力、文字列入力)

通常コモンイベントに引数を渡す場合はウディタのコモンイベントエディタで設定を行うが、設定が行われていなくても引数渡しは可能である。

この仕様を使い、5つ目の引数を渡すことができる。

ウディタはエディタ上では引数を4つまでしか扱えないが、

内部的には5つまで対応している。

5つ目の引数を渡す場合はコモンイベント起動コマンドのイベントコードを改造する。

< 例 >

コモンイベント3に数値入力を5つ渡す(0,1,2,3,4)

WoditorEvCOMMAND_START

[210][7,0]<0>(500003,5,0,1,2,3,4)()

WoditorEvCOMMAND_END

コモンイベント3に文字列入力を5つ渡す(CSelf5,CSelf5,CSelf5,CSelf5,CSelf5)

WoditorEvCOMMAND_START

[210][7,0]<0>(500003,80,1600005,1600005,1600005,1600005,1600005)()

WoditorEvCOMMAND_END


変数で指定した引数有りコモンイベントを起動する方法

コモンイベントの『イベントの挿入』を使いコモンイベントを起動する際、コモンイベントの指定に『このコモンSelfXX』を使用すると変数で指定したコモンイベントを起動できるが、引数が渡せない。

引数を渡すようにするためにはイベントコードを改造する

以下は『このコモンSelf0』のコモンイベントを起動するイベントコードである。

WoditorEvCOMMAND_START

[210][2,0]<0>(1600000,0)()

WoditorEvCOMMAND_END

これに引数を渡すようにしたい場合は以下のように改造する。

(引数を3つ使い、CSelf1,CSelf2,CSelf3を渡す場合)

WoditorEvCOMMAND_START

[210][5,0]<0>(1600000,3,1600001,1600002,1600003)()

WoditorEvCOMMAND_END

▽解説

[2,0]の2に使用したい引数の個数分足しこむ

今回は3つ使用するので[5,0]

(1600000,0)の0のところに引数の数を入れる

今回は3つ使用するので(1600000,3,

(1600000,3,

に続き、渡したい変数や数値を引数分だけ記述する


ゲーム中にUDBに値を格納する

基本UDBのデータはゲーム中に書き換えることはできないが

書き換える方法が存在する。

UDBにアクセスする際に可変データベースのタイプIDでアクセスを行う。

例えばUDB[1:0:0]にデータを格納したい場合は

『DB操作』ではなく『変数操作』の『可変DB』を使用して

以下のように処理する

変数操作:CSelf0 = 1 - 100

変数操作:可変DB[CSelf0:0:0] = 0 + 0

これでUDB[1:0:0]のデータを書き換えれる。

▽アクセス先タイプIDから100を引くとなぜ書き換えれるの?

X番の変数呼出の番号を意識すると答えが見えてくる。

CDB[1:0:0]の呼出値は『1101000000』

UDB[1:0:0]の呼出値は『1001000000』

差は『100000000』

変数操作の可変DB操作はX番の変数呼出を使用してアクセスが行われる。

つまり変数操作でCDB[1:2:3]としての場合

呼出値は以下のように求められる。

CDBアクセスの基準呼出値 [1100000000]

 +

タイプID [1 * 1000000]

 +

データID [2 * 100]

 +

項目ID [3 * 1]

= 1101000203 → CDB[1:2:3]

上記の呼出値となる。

ここでタイプIDに-100を与えてみた場合

CDBアクセスの基準呼出値 [1100000000]

 +

タイプID [-99 * 1000000]

 +

データID [2 * 100]

 +

項目ID [3 * 1]

= 1001000203 → UDB[1:2:3]

となる。

これによってUDBにアクセスすることが可能になる。

UDBはCDBと違ってセーブデータの容量を食わないので

一時変数的な使い方をするならUDBに書き込む方が容量が増えなくて済むメリットがある。


実はDBは1タイプにつき10000データID以上使用できる(自己責任)

[※使用は自己責任、試すならバックアップは取っておこうね※]

X番の変数呼出を使用しないアクセス方法に限りデータID10000以上へのアクセスが可能。ただし必ずデータIDは使用する範囲分確保しておく必要がある。

10000以上のデータIDを確保する方法にはCSV読み込みを使用する。

CDBのタイプ0のデータ数を10001個以上にする場合

まずはデータ数10000個分を『データ数の設定』ボタンを使用して確保する。その後10000個分データをCSVで吐き出す。

データID9999を選択した状態でCSV読み込みを行い先ほど吐き出したCSVを読み込ませる。するとデータIDが0~19998まで確保できる。

この手順を使い任意のサイズまで拡張できる。

ただし、DB設定画面でそのタイプを選択する毎に重い読み込みが走ってしまうので、あまりにもたくさんのデータを用意するのは避けたほうが良い。

X番の変数呼出を使用しないアクセス方法については

DB操作のDB[数値:変数:数値]で使用するとよい。

(タイプID,項目IDに変数を使用するとX番の変数呼出になってしまうのでデータID10000以上にアクセスできない)


2階層下のピクチャを表示する

ピクチャ表示ではDataフォルダ内のフォルダから画像ファイルを選択するが、『Data/Picture/UI/hp_bar.png』のようにPictureフォルダの中にUIフォルダがあるような場合でも使用可能である。

ウディタ上で選択することはできないが、ピクチャ表示のパス入力欄に直接パスを入力することで表示が可能。

上記例の場合は以下のようにパスを入力すれば表示される

Picture/UI/hp_bar.png


Dataフォルダ外のピクチャを表示する

ピクチャ表示時のパスはDataフォルダからのパスを指定する必要があるが、

これは相対パスで処理されているので1つ上のフォルダに戻る『../』を使用すれば、Dataフォルダ外のピクチャを表示可能である
< 例 >
../Save/Test.png


拍手

ウディタツール開発用ライブラリ『WodiKs』のα版を公開します!
(Ver0.40)

WodiKs-Ver0.40[α版] ダウンロード



<< WodiKs とは >>
WodiKs はウディタツールの開発を手軽に行えることを
目的としたツール開発用ライブラリです。(C#で作られています)


◇ 現在実装されている主な機能 ◇
・ウディタが管理している各種ファイルの読み込み/書き込み
  ├ CommonEvent.dat
  ├ DataBase.dat / DataBase.project
  ├ CDataBase.dat / CDataBase.project
  └ SysDataBase.dat / SysDataBase.project

・各種データの取り扱い
  ├ コモンイベント
  ├ イベントコマンド
  └ データベース

以下のような物が手軽に作れるようになります。
(サンプルプロジェクトとして同梱しているものです。)

  ▲原寸大で開く

ライブラリの導入方法や使用方法等の詳細は
同梱されているマニュアルファイル『WodiKsGuide.chm』をご覧ください。

WodiKs-Ver0.40[α版] ダウンロード


拍手

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

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

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

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

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


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

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

-- ▼処理負荷比較 --




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

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

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

-- ▼処理負荷比較 --




[ 余談(興味ない人はスルーで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 がセットされています。
ここが一致する『ループここまで』を探索します。
つまりイベントコードを弄って本来は違うインデントのところで
対応した『ループここまで』コマンドを置くと
そこをループ終了地点と誤認させることができます。

拍手

WoditorOptimizer - Ver2.0.1
┗最新版公開日 : 2017/08/31

WoditorOptimizer - Ver1.00 -
┗旧バージョン : 2015/04/18

WECDeletor - Ver1.01 -
┗最新版公開日 : 2012/11/03
08 2017/09 10
S M T W T F S
1 2
3 4 5 6 7 8 9
10 11 12 13 14 15 16
17 18 19 20 21 22 23
24 25 26 27 28 29 30
HN:
K-Shin07
性別:
男性
趣味:
ゲーム製作
自己紹介:
趣味でゲームを作っています
プログラマーです

開発ツール・使用言語等
WOLF RPG エディター
・HSP
・C
・VB
・Java
・C++
・C++/CLI
・C#
・アセンブラ
・Haskell

・PHP
・Ruby

・WPF

・DirectX( 9.0c )
・PhysX( 3.X系 )

Mail
 k07.alpha.stella[あっとマーク]gmail.com
[02/26 たかねぇ]
[02/24 たかねぇ]
[06/07 たかねぇ]
[04/23 たかねぇ]
Copyright ©  -- α-Stella[R]_ブログ --  All Rights Reserved

Design by CriCri  /  Material by 妙の宴  /  Background by K-Shin07  /  powered by NINJA TOOLS / 忍者ブログ / [PR]