■[と][NScripter] エフェクト自作 その2 01:23

エフェクト自作 - Atelier de Muguet 制作記録の補足とか。

プラグインのEffect()からスクリプトのコールバックを試したところ、見事に失敗しました。luasubの命令を含め、NScrExecWord()で組み込み命令以外を呼ぶと駄目のようです。

と思っていたのですが、もっと単純な話で、NSExec()の中でNSExec()を読んではいけないという原則の結果でした。ただし、厳密にはNSExec()を2回呼んでいる訳ではなく、1つは、NScripter本体がエクスポートしているNScrExecWord()という関数です。

つまり、

NScripterのエフェクト処理→プラグインのEffect()→NScrExecWord()→NScripterのコマンド

は、基本的に問題なく動作しますが、ここで、NScripterのコマンドがluasubで定義されたものであった場合、

NScripterのエフェクト処理→プラグインのEffect()→NScrExecWord()→NSCOM_*()→NSExec()

は認められない為、そのNSCOM_*()関数内でNSExec()が使えないということです。NSExec()が使えないのはNSLuaにおいて大きな制約でしょう。

これを更に厄介にさせているのが、プラグインからのスプライト確保を、NScrExecWord()によるlsp呼び出しで実現している事です。

exec_dll→NScrPlugInMain()→プラグインでスプライト確保する関数→NScrExecWord()→lsp

という流れになるのですが、この機能をLuaから利用しようとすると、

NSExec()→exec_dll→NScrPlugInMain()→プラグインでスプライト確保する関数→NScrExecWord()→lsp

となってしまうので誤動作するのです。そのために、 ドロップシャドウ - Atelier de Muguet 制作記録では、Lua用の関数を用意して、

プラグインのLuaインターフェイス→プラグインでスプライト確保する関数→NScrExecWord()→lsp

のように、exec_dllを呼ばない方法を用意しました。

このような煩雑な系を解消するためには、NSExec()の多重呼び出しに対応すること考えられます。しかし、設計上美しくないのは寧ろ、プラグインからlspを呼んでいる点だと思います。空のスプライトを確保する関数が、NScripter本体からエクスポートされれば良い訳ですが、そもそもこんなことをする需要があるのかというと、どうなんでしょうね。

そして、前回の記事を書いた後に、プラグインで画像を用意する手段として、NSDDLL()が用意されました。しかし、これはテクスチャのサイズをLua上で指定しなければならず、プラグインが直接確保することが出来ません。結果、NScrExecWord()やらNL_dostring()を使うか、Luaでラッピングする必要が出てきて、結局うんざりします。

なお、NSDDLL()を使えば、プラグインで画像を用意する為にlspを呼び出す必要が無いので、

NScripterのエフェクト処理→プラグインのEffect()→NScrExecWord()→NSCOM_*()→NSDCall()→プラグインでテクスチャを描画する関数

という流れが可能となり、自作エフェクトで出来ることが増えます。

ところが、自作エフェクトで肝心のエフェクト前後の画像を扱おうとすると、

オフスクリーンバッファ→プラグイン内のテンポラリバッファ*1→テクスチャ→NSD系命令用スクリーンバッファ→オフスクリーンバッファ

という何回コピーしているんだ、という状況が発生し得るのです。特に、演出メモ - 永字八法のようなことをやろうとすると、上の過程を毎ステップ実行しなくてはなりません。速度的には実用上問題ないレベルですが*2如何せん美しくないです。

やっぱり、自作エフェクトを含め、Luaによる凝った演出というのは、不可能でないにしても、現状のAPIでは無駄な労力が強いられる気がします。現状のNSD系命令はブレイクスルーの鍵だとは思いますが、ブレイクスルーには至っていないのではないかと。

ちなみに、個人的には、nspng.dllの横取りが一番融通が利くんじゃないかなぁ、と目論んでます。美しさで言えば最悪ですが。

あー、相変わらず機嫌が悪いです。