fkiss Extenstions Tech-Know

fkissにおいて実装されてる拡張機能について，
もっとマシなドキュメントが欲しいという声もありますんで，
ちょっとここでコメントしときます．

fkissでは，次のKISSの仕様に制式採用されるといいなーという機能の
研究のために実験的に独自の拡張機能を実装しています．
それは，ほっぺたをクリックしたらウィンクしたりとか，
胸をクリックしたら「いやーん！」としゃべったりとかする機能です．

ところが，fkissではこれらの機能を実現するために
必要最小限の機能しか準備していません．
それは，
なにかが起ったら，なにかをする．
ということを，
KISSのcnfのなかに記述しておき，
fkissはそれを実行するというもので実現しています．

「なにかが起ったら」というのをfkissではイベントと呼びますが，
これは，例えば胸のセルをクリックした等
「なにかをする」ための条件です．

「なにかをする」というのをfkissではアクションを呼びますが，
例えば「いやーん！」という音声を再生する等の
KISSのローダーが実行する機能のことです．

つまり，
ある条件が成立したら（イベントの発生），ある処理（アクション）を実行する．
ということをcnfに記述することによって，
胸をクリックしたら「いやーん！」としゃべったりとかする機能を実現しています．
例えば，
胸をクリックしたら「いやーん！」としゃべらせるためには，
;@press("mune.cel")	sound("iyaan.au")
と記述します．
これは，"mune.cel"の上でマウスのボタンが押されたときに
"iyaan.au"という音声データのファイルを再生するというものです．

もっとも，前述のとおり必要最小限の機能しか用意していないので，
イベントは，
	あるセルの上でマウスのボタンを押した．
	そのボタンを離した．
アクションは，
	音声データを再生する．
	あるセルを表示する．
	あるセルを消す．
などの非常に原始的なことしか指定できません．

例えば，cel_0.celの上でマウスの左ボタンが押されたときに
cel_a.celを表示したければ，
;@press("cel_0.cel")
;@	map("cel_a.cel")
というように記述することになります．

さすがにこれだけでは，あまり高度なことができないので，
タイマーという機構を用意してあります．
これは，
アクションとして，今から何から何秒後に何番のアラームが鳴る．
イベントとして，何番のアラームが鳴ったのを条件とする．
というものです．

例えば，
cel_0.celの上でマウスの左ボタンが押されたら，
cel_a.celとcel_b.celを1秒毎に交互に表示したい場合には，

;@press("cel_0.cel")		; cel_0.celの上でボタンが押されたら次の処理
;@	alarm(1, 1)		; チャンネル1のタイマーを1ミリ秒後にセット
;				; 0ミリ秒後というのはfkissでは許されない
;				; (alarm(1, 0)はタイマー1のクリア)
;@alarm(1)
;@	map("cel_a.cel")	; "cel_a.cel"を表示して
;@	unmap("cel_b.cel")	; "cel_b.cel"を非表示状態にする
;@	timer(2, 1000)		; 1000ミリ秒(つまり1秒)後にタイマー2を設定
;@alarm(2)
;@	unmap("cel_a.cel")	; "cel_a.cel"を非表示状態にして
;@	map("cel_b.cel")	; "cel_b.cel"を表示する
;@	timer(1, 1000)		; 1000ミリ秒(つまり1秒)後にタイマー1を設定

と記述することになるというわけです．
たかが，1秒毎にセルを切り換えるだけにもこれだけの記述が必要なわけで，
本来このような記述をデータ製作者に要求するのはこくなことだとは承知してます．
もっとはるかに解りやすい記述方法にすべきであることは明白なのですが，
fkissのイベント拡張機能は，あくまで次期KISSに必要な機能の洗いだしをする
という目的がありますので，このような処理形べったりの記述となっています．

また，けっこう誤解されているフシがあるのですが，
timer(ch, n)というのは，
すくなくとも nミリ秒後以降にチャンネルchのアラームを鳴らすということであり，
ほんとにチャンネルchのアラームでの処理が実行されるのは，
(処理系によりますが)，これよりかなり遅延してのことだということです．

前述の例をとると，
"cel_a.cal"を表示状態にするのに1500ミリ秒(1.5秒)かかるとすれば，
その次のalarm(2)の実行は，それから少なくとも1500ミリ秒以降になります．
こういった遅延の少ないシステムの上でデータを作る場合は問題ありませんが，
遅延の多いシステム上でデータを作成する場合には，
この遅延があるものとしたデータを作成してしまう可能性があり，
そのようなデータを遅延の少ないシステムで再生した場合には，
あっというまに処理が過ぎてしまって，まともなアニメーションにならない．
といった結果をもたらすことになります．

こういった問題に対する明確な回答は残念ながら今のとこありません．
できるかぎり，遅延の少ないシステムでデータを作成していただくか，
もしくはローダがどの程度タイマーが遅延してるのかをレポートして，
その値を参考にデータを作ってもらうしかすべがありません．
これは，もし遅いシステムを使ってるひとは
自分の意図する結果を見ることができないということになりますが，
こればっかりは人知の及ぶ範囲ではないのでご容赦ください．
(16色しか表示できないシステムで，256色のKISSデータを作成する
 というような状況とあい通じるものがあるかもしれません)

と，まあこういったことがfkissでの独自の拡張機能を使う点で
注意すべきことです．
冷静に考えると，それなりに意味のある機能(だけ？)が準備されているので，
いろいろ面白いことができると思います．
各人，トライしてみてくださいね．

なお，この仕様は納得いかん！とか，
オイラならこんなふうにするにゃん！とか
実際にデータを作ってみるといろいろと希望要望等出てくると思うので，
そんなときには，私宛かKISSin' BBSに苦言を吐いてもらえれば
次期KISSの仕様決定の参考になると思いますんで
よろしくお願いいたします．

なお，このドキュメントはパブリクドメインです．
かってに転載でもなんでもしていただいて結構です．

P.S.
上記の例は，実際に試してはおりません．
あくまで参考です．
実際の動作例について質問等ありましたら
遠慮せず聞いてくださいね．

                                        UHD98984@pcvan.or.jp
                                                        yav