◆ - Sugar Snow - ◆

  

日曜日に１日かけてオセロ……もといリバーシを作ってみました。



ふとした気紛れです。

ある程度できたところで動かしてみたところ、
まあそれなりに動いてくれました、2P対戦の場合は。
（１度だけですが、最後まで対戦しました）

コンピューターとの対戦は全然ダメです。
とにかく処理が遅いのです。
コンピューター同士の対戦なんてさせたら、いつ終わるの？って感じです。

なんかそんな気はしていました。


これは PC 版を先に作ってから移植しています。
C++ で作ったものを LSL に作り変えてあります。

LSL にはポインタも参照も無いので、配列を扱うとコピーが発生してしまいます。
まあそもそも配列が存在しないのですが。
一応 list があるので、配列の代用として使用できます。

int 配列であれば、具体的にはこんな感じになります。

arr = llListReplaceList(arr, [ 5 ], 0, 0);  // arr[0] = 5;
n = llList2Integer(arr, 0);                 // n = arr[0];

もちろんこれは代入ではなく、新しいlistを作成することになるので
無駄がとても多い処理です。


また、関数の引数として渡す場合もすべて値渡しになります。
値渡しなので list のコピーが発生します。
関数で処理をしたら結果を返してもらわないといけません。
もちろん戻り値として返すことになります。
やはりここでも list のコピーが発生します。

そんな処理がたくさんありました。

手の先読み処理では関数を再帰呼び出ししているので、
何度も何度も list のコピーが行われます。
盤面（list）へアクセスしまくっているので、もうコピーしまくりです。

なので原因は（調べていませんが）list のコピーのような気がします。


とりあえず、関数の引数へは list を渡さないように直しました。

少し変わった気がします。
代入の方は別の方法に変えますか……。
別に list 使わずにもできますし

先読み量減らすと、ちょっと弱すぎでした。
定石入れて、、も処理が速くなるとは限りませんね。。

アルゴリズム最適化しますか？
地味な高速化手法でも取り入れますか？


そうですね、また今度にします。
  

パーティクルって連続で発生させようとすると出ないことがあるみたいです。

パーティクルの設定を一定時間で消えるようにしているため、
出ないというより切り替わらないといった方が正しいかもしれません。

簡単に書くとこういうことをした場合です。

list rule1 = [...];
list rule2 = [...];
list rule3 = [...];
llParticleSystem(rule1);
llParticleSystem(rule2);
llParticleSystem(rule3);

環境設定の描画距離や最大パーティクル数の設定は問題ないはずです。

１つ目は確実に描画されます。
２つ目以降は時々しか描画されません。

こんなスクリプトでプリムを連打してみても時々同じようになります。

touch_start(integer total_number) {
    llOwnerSay("touch");
    llParticleSystem([...]);
}

間隔を0.2秒以上空けると描画される可能性が高くなるみたいです。
なのでそういうことなのかもしれません。
回避策はあるので諦めます。。
パーティクルの細かい制御にはコツがいりそうです。

  

何故かスクリプトの左下にある実行中のチェックが
勝手に外れることがあります。

↓これです。普段使う人は少ないと思うので一応画像付けておきます。

これが外れるということは
スクリプトが停止してしまうことになります。

原因を調べている内に
テレポートをする度にチェックが外れていることがわかりました。

これが起きるようになったのは
16KBのヒープ制限回避のためにある関数を別のスクリプトへ移した頃からだと思います。

その関数が呼ばれている状態でテレポートをすると発生するみたいです。
恐らく100%に近い確率で発生します。

おかげで最近テレポートばかりしています。

読めない英語のサイトも調べてみましたが、全然原因が見つかりません（んにゃあ……読めません。
エラーは何も出ていませんし、起きるようなところもありません。
この関数が少し重い（速くて１秒弱掛かる）せいかとも思いましたが、
それまで動いていたものなので関係ないはずです。
そうなると、リンクメッセージが関連しているのではないかと思う訳です。

一応、処理の不特定の場所でログが止まるので
何かに強制停止されているみたいです。


まず、llMessageLinked()を呼ぶ間隔に対して
処理が追いついていないのは確実でしたので呼ぶ回数を減らすことにしました。
若干ですが、発生頻度は下がりました。
逆にこれで動いているのが不思議でした。
（確かメッセージキューってオーバーするとエラーが出るのでは？
　もし、無視されるのであれば、まあ動きますか……）

link_message()内ではllSetTimerEvent()だけを呼び、
timer()内で例の関数を呼ぶようにしたら更に下がりました。

ですが、それは単純に例の関数の呼ばれる回数が減ったからかもしれません。
その関数内の何れかの関数がSIM切り替え時に終了していないと、
エラーも吐かずに落ちてしまうのかもしれません。

もうわかりません！

とりあえず、放置決定です。

仕事じゃあるまいし、ここに時間を掛けたくもないので
前の方法に戻して起きなければ諦めようか考え中です。


気持ち悪いですけど。。。