Hatena::Groupfatalemployeetraining

資材部の懲りない面々・あれこれブログ

「間違った社員教育」製品版委託頒布中!

2010-12-02

顔グラフィック+アニメ追加

3面

なんとか、顔グラフィック+目パチ口パクまでできました。

試作品(ダウンロード

よろしかったらお試しください。現時点で出来てる3面まで遊べます。(要 RaideresSphere 3rd / RaidersSphere 3rd 3D-Dive Edition)

あと、最初の最初に作ったひな型的ミッションをリメイクしたものも用意しました。RSE3.5でのミッション製作の参考になれば幸いです。(こちらには顔グラフィックライブラリは含みません)

(2011/6/3追記)「まったく君の会社ではいったいどんな社員教育を(略)」にて4面まで遊べるバージョンを公開しています。よろしかったらお試しください!

ひな型(ダウンロード)

スレッドの起動には、ミッション開始からの通算総起動数に制限がある

まず、RSEにおけるスレッドの基礎知識。

おそらくスレッドの同時起動数にも制約があるとは思うんですが、今回目パチ口パク作成でハマッたのは通算総起動数、つまりミッション開始から何回create_thread()を実行したか(途中で終了するしないに関わらず)、です。

当初、目パチ口パクは、ある表情絵の表示が始まったら、目パチ用スレッド口パクスレッドを起動し、別の表情・別のキャラ絵に切り替わったり、絵自体が消えたりしたらスレッドを終了する形で記述していました。毎回かならず終了しているので同時起動数は抑えられますし、アニメーションしないときには終了していますから、計算処理的にも負担が抑えられ、コード記述もシンプルになります。

しかし、すこし長めにプレイすると、エラーが発生。

関数コールの段数が深いかも、とか関数名が長いかも、とエラーメッセ-ジにあるので、多少調節してみましたが改善せず。

自己回帰呼び出しとかが発生していないかもチェックしてみましたが、それもありません。

もしやと思い、単純なテスト専用ミッション(目パチ・口パクもはずしたシンプルなもの)を用意し、2つテストを別々に行いました。

  1. ボタンを押すたびに自己再帰関数再帰回数制限付き)を呼び出して実行テストする。毎試行が終了するごとに再帰回数制限を多くしていく。
  2. ボタンを押すたびにスレッドを作成する。ただしスレッドは1フレーム以内に計算が終了(本編に影響しない引き算1回のみ)しスレッド自体もすぐに終了するもの。

1番は相当な数、再帰の回数を増やしてもエラーが出なかった(150回くらい?結局エラーを見ていないのでもっと大丈夫かも)のに対し、2番は74回でエラー発生。また、2番のテストで、スレッドからさらに別の関数を呼ぶなどするとエラー発生までの回数は少なくなります。

この試行から、

  • ミッション中で行えるcreate_thread()の回数には制限がある。起動したスレッドを終了するかしないかには全く関係がない。起動されるスレッドの構成(内部で別の関数をコールするなど)によって上限がより厳しくなる。

ことがわかりました。

これは正直なところ、(疑似だけども)マルチスレッドを謳う言語としては、リソースリークと言える深刻な問題仕様と思います。

(だって、現状の仕様と用意されてる関数だけ見てると、thread_idはintだからintの変数の上限値による同時起動数制限は受けそうだけど…終了しさえすれば大丈夫、って見えるじゃないですか。)

とはいえ、もともと過去のRSEは並列実行できるスレッド数に仕様上、上限があるものでしたから、内部動作的に上限がある前提で作られている部分が残っていてもおかしくはないとも思いますし、終了したスレッドについて逐一動的に痕跡を消すのがめんどくさい内部仕様になってるのかな、とも想像はできます。(並列実行する関数群をまとめて配列に積みっぱなしで、頭から最後までぐるりとひとループして疑似並列実行、exit_thread()されたやつは読み飛ばすようにフラグつけるだけ、とかなんですかね。双方向リストじゃないのかなー。)

とりあえず目に見えない上限があることを前提にしたコードに修正しました。(目パチを管理するスレッド口パクを管理するスレッドを用意し、グローバル変数で用意したフラグで目パチや口パクの動作開始を制御する。フラグが増えること、目パチ・口パク動作開始してからの時間測定を別途カウンタ変数を用意し管理する必要があること、などコードはかなり複雑になります。実は目パチ・口パク以外にも、メッセージイベントスレッドの自作ライブラリスレッド起動回数制限を考慮しない仕様だったので動作を変更。)

先日のget_pos()の子ユニットに対する挙動およびそれと関連すると思われる航空機ユニットの子ユニット化不可問題と併せて、本件もいずれ仕様が改善されることを期待します。

2011/6/4 追記:

SEC2011でこの点を話したところ、スレッドの起動回数上限問題は、電プロさんによると、想定外動作であるとのことです。いずれ修正されるはず。修正されたら、自前でスケジューリングしないで済むので楽になります。期待してます!

一方、航空機ユニットの子ユニット化不可問題は、公式掲示板でさしあたり無理という回答をいただきました。4thでこのあたりの内部仕様も組み直しで変わる可能性が高いので、4thになってどうなるかに期待ですね。

ゲスト



トラックバック - http://fatalemployeetraining.g.hatena.ne.jp/yumeno/20101202