YU-RISお役立ち情報（非公式） @ ウィキ

YU-RIS使用のTIPS

最終更新：2011年02月24日 14:43

yu-ris

- view

だれでも歓迎！編集

YU-RIS使用のTIPS　上級編
大幅変更・加筆履歴コメント

YU-RIS使用のTIPS　上級編

　YU-RIS関係のスクリプトのテクニック・補足説明・注意点・設定などの情報。　なんかTIPSと言えない内容になってしまったかもしれません。
　処理速度やら何やら（？）のディープな使い方をしたい人のための情報です。もしかしたら、誰もいないかもしれませんが……

YU-RISスクリプト命令の使用で気をつけること

各レイヤーＩＤが保持している情報について。

　各レイヤーＩＤは下記情報（＝プロパティ）とデータ自身を持っています。命令のキーワードにより新しく設定されない限り、その値をキーワード値として参照します。（ただし、IDは除く）

ＣＧレイヤのプロパティ

　CGINFOコマンドで取得できる値に相当します。

サウンドレイヤのプロパティ

　SOUNDINFOコマンドで取得できる値に相当します。

最前面配置レイヤー一つしか実行できないため、レイヤーＩＤで管理していないMOVEとFLASHが保持している情報について。

　MOVEとFLASHはその性質上、同時に一つしか再生できません。また、常に、前面配置となります。

MOVIEのプロパティ

　MOVIEINFOコマンドで取得できる値に相当します。

マルチスクリプト（マルチタスク）とvolatile変数について。

　たとえシステム変数でなくても、グローバル変数（広域有効変数）はvolatile変数になる場合があります。
　例えば、タスクＡとタスクＢが存在した場合、タスクＢ内部でグローバル変数@gflt_OchameChanを常に書き換える処理があった時、タスクＡから見ればグローバル変数@gflt_OchameChanはvolatile変数ということになります。
　これは処理が大規模になるとバグに陥りやすい場合もあるので、これまた注意が必要です。

一部の命令にある、FILEキーワードを指定した時の注意事項

　一部の命令には、実行を行う「****[]」（例：CG[]）と、情報を取り出す「***INFO[]」（例：CGINFO[]）と、終了をする「***END[]」（例：CGEND[]）の形を取っているものがあります。
　これらを使用する時、実行を行う「****[]」（例：CG[]）で「FILE」キーワードを使用すると、メモリー確保とファイル読み込み動作が発生します。また、終了をする「***END[]」（例：CGEND[]）は、確保していたメモリーの解放動作が発生します。
　後半で書きますが、これらは処理速度に大きく響きますので、実行する場所に気を付けて下さい。

CG命令と画面更新について。

タスク数が多くなると、本当に表示が遅くなるか確認必要かもしれない
　ＣＧ命令はあくまでも、スクリプトエンジンに表示データの引渡しと画面更新要求をしているにすぎません。実際に画面更新をさせるには、スクリプトエンジンに一旦処理権を譲ってやる必要があります。それを行っているのが、WAIT命令です。
　また画面更新もタスクの一つです。よって、同時に常駐しているタスク数が多いと、順番にスクリプト実行権が切り替わる関係上、画面更新が遅くなりますので、注意して下さい。

TEXT命令のOUTPUTMODEキーワードについて。

　ERIS内部専用の、非公開キーワードです。そして、将来的に消える可能性もあります。

YU-RISにあるレイヤー機能、及びその扱いについて

YU-RISのタスクレイヤーの正体について。

　タスクレイヤーはタスク動作をするプログラムのまとまり（＝ルーチン）で、タスクレイヤーID名を付けて管理しています。
　「タスク」は、各タスクが実行される順番を設定できる機能（＝実行優先度設定）があるため、便宜上レイヤーを――タスク実行順番＝タスク階層というイメージで――使用しています。

YU-RISのレイヤーセットについて。

まだまだ理解不足、間違っている可能性もあり。確認必要です。
　これは、IDキーワードに対してレイヤーID名を指定する際の、拡張機能の様なものでしょう。
　それは、フォルダ管理方法（※）に酷似した管理方法でレイヤーは管理されています。　よってレイヤーセットの指定方法も、フォルダーの指定方法と非常に酷似しています。
　“カレント”という概念があるかどうかは不明につき調査必要あり。
　YUーRIS製作者様のペイントツール（恐らくフォトショップ？）では、「レイヤーセット」という呼び方になっており、その名称をYU-RISに採用しているのだと思われます。ちなみに、うちのツールは「レイヤーグループ」という名称になっています。
　レイヤーグループもそうですが、レイヤーセットにはレイヤーをぶら下げることが可能だし、次階層として新しいレイヤーセットをぶら下げることも可能です。そうやって、まるで“木の枝”のごとくレイヤーを連結管理（及び連動効果動作）することができます。

（※）専門用語で言うと“木構造”と呼ばれる管理方法です。

レイヤーセットの機能は、全てにあるわけではありません。

　これはペイントツールのレイヤー機能と同様の機能を、YU-RISが採用したわけです。よってこれが使用可能な命令は、ペイントツールのレイヤー機能の概念が存在する、CG命令系だけです。

【連結管理】YU-RISのレイヤーセットの指定方法について

残念ながら現在不明です。調査及び確認が必要です

【連動効果動作】YU-RISのレイヤーセットを使用することにより、得られる恩恵について

残念ながら現在不明です。調査及び確認が必要です

YU-RISスクリプトの実行を速く動作させるには

処理時間がかかる……画像描画やディスクアクセスはよく聞く話だけど、実はメモリー確保・解放も処理時間がかかるのです。

　YU-RISの内部構造によって状況は違います。恐らく確認必要かもしれません。
　一般的に、処理速度を下げる要因の一つに、

1.ディスクへのアクセス
　（最近は、NTFS圧縮・展開や、セキュリティチェックなどで少しずつ遅くなっています）
2.メモリーの確保や解放
　（最近は、セキュリティチェックが入ります。また、ハングアップ防止のWaitが入っている可能性があります）
3.画像の画面への描画
　（処理形態にもよりますが、一般的にチラつき現象を防ぐとかで処理速度を落とさないといけない――またはFPSを下げる？――とかあったりします）

　この三つが一番大きいのではないでしょうか。（音声は途中止めしたら問題ないと思うのですが…）
　簡単に言えば、画像は可能な限り小さめにし、ゲームスタート前の初期化後に上記1～2の二つを予め済ましておくしか手は無いでしょう。
　ただ1～2に関しては……いかんせんメモリー量は決まってるわけで、やり過ぎると「メモリー不足で起動できません」というWindows（だったと思いますが？）の叱責を食らってしまいます。
　その場合、高速性が必要なものとそうでないものに分類し、後者は不用になったら破棄して下さい。ただし、高速動作中は避けて下さい。

ローカル変数も時間がかかります。

　YU-RISにはローカル変数（局所変数）という変数が存在します。やはり局所的な存在なので、メモリーの確保や解放が発生します。
　よって、高速処理が要求されるプログラム領域内でのローカル変数宣言は避けて下さい。特に、ループ処理内でのローカル変数宣言は避けて下さい。
　一番無難なのはローカル変数は使わず、起動から終了までメモリーに残り続けるグローバル変数で済ます方法が無難です。
　ただし「メモリー不足で起動できません」の無き様、これも画像と同様に高速を要求する変数としない変数に分け、後者はタイミングを計りつつ不要な変数は一括解放するといいでしょう。

ループ処理の中で行う必要の無い演算や処理があれば、ループの外で行う様にして下さい。

　ループは連続処理ですから、組み方によっては大きなロスになります。
　ループ内の処理最適化は重要事項となりますので、処理が重いと考えられる物で、ループ外に置ける物があればそうして下さい。

ちょっと狙いすぎた（何気に無意味な処理の）プログラムですが、

　LOOP[SET=100]
　　　CG[ID=$(@A + @B) X=(@A + @B) * (@A + @B) + 2]
　　　WAIT[FRAME=1]
　LOOPEND[ ]

これは、

　@G = (@A + @B) * (@A + @B)
　$C_ID = $(@A + @B)
　LOOP[SET=100]
　　　CG[ID=$C_ID X=@G + 2]
　　　WAIT[FRAME=1]
　LOOPEND[ ]

となります。実際は、こんな単純には見つからないとは思いますが……(^^;

ループの中でGOSUBのルーチンコールを、できるだけ行わない様にして下さい。

　コールも一つの処理ですから、その処理が連続で発生するとかなりの時間ロスになります。

実数変数による演算も可能な限り行わないか、高速処理領域の外で予め済ませておいた方がよいでしょう。

YU-RISの演算方式、ソフト固定小数点か？　ソフト浮動小数点か？　コプロセッサー使用か？　（……でも、MMX使っていたら無理だっけ？）　確認が必要です。
　通常ソフトによる実数演算は処理時間がかかります。とりわけ数学関数系は時間がかかるので、可能なら高速処理の外で済ませておいて下さい。
　ゲーム系の場合あまり厳密で無くていいので、メモリーを食いますが配列変数によるテーブル検索を利用した演算方法（※）を検討してみて下さい。

（※）分かりやすく言えば、三角関数など値の範囲が決まっている関数は、配列変数を使って早見表を外部に作成し、高速処理内部でその表を使わせるという手法です。これだけでも結構速くなります。

YU-RIS確保メモリーを減らしたい

使用メモリー量について。

確認必要
　YU-RIS製作者様ではないため予想的な内容ではありますが、高速動作する以上この内容に間違いはないと思います。

スクリプトですが、内部的にパック解凍や暗号解除を行いながら全てメモリーに蓄積させていると思われます。ディスク上のファイルは暗号化されパックされているので、多分ですがメモリー上に展開されるスクリプトの総容量は、コンパイル直後のバイナリースクリプトファイルの総容量になると思います。
レイヤーもメモリー上に領域確保してそこに読み込まれた画像データや音声データの「ブロック」なので、やはりメモリーを消費する。
変数の総使用量

　ということで、この三つとexeファイルの総量に数メガほど加えたのがメモリー使用量に近い値となる……と、言いたい所ですが、「2」については、YU-RISスクリプトによるプログラムの作り方によって、確保と解放を繰り返す場合があります。
　よって、「2」はメモリー上にどのサイズのレイヤーが最大何個確保されるかので考えるのが自然でしょうね。
　それからもう一つ問題があります。それは次を見て下さい。

メモリー上の画像と音声のデータ形式について。

確認必要
　これもYU-RIS製作者様でないと分からない領域ではあります。そこで何が問題かと言うと、高速処理を行うためメモリー上に「画像はビットマップで格納している」「音声はWAV形式で格納している」可能性があると言うことです。高速化をしている様なので、恐らく間違いないと思われます。
　つまり、レイヤーを確保し過ぎると膨大なメモリーを消費してしまうと言うことです。
　だから、高速処理を要求する画像や音声、高速処理を要求しない画像や音声に分類し、高速処理を要求しない画像や音声は用済みになった解放するしかないでしょう。
　とは言っても、高速処理を要求するゲームの高速処理進行中は処理できないので、タイミングがかなり難しいかもしれませんが……

メモリーの確保・解放を頻繁に繰りかえす管理は程々にして下さい。できれば、一括で行って下さい。

　やり方によってはメモリー領域を汚す（＝使えないメモリー領域を増やしてしまう）可能性があるので、「やるなら程々に」という所でしょうか。
　できれば、一括でメモリー解放または一括でメモリー確保するのがベストでしょう。
　また前記の様に、メモリー確保・解放は処理に時間がかかるので、その辺りはご了承下さい。また、確認していませんが、メモリー確保・解放を頻繁に行うとハングアップしてしまう可能性もあります。