m作戦。
zオーダーの管理方法がわかってきた。container.add(component,
..., 0)とやると前に出る。なおcomponentはすでにcontainerに入っているものでも、二重登録にならずにちゃんと動く。
しかしこの方法には欠陥があった。
このアプレット（IE専用。あしからず）の左上にある2枚のカードのあいだで、ポインタを左右に動かしてみてほしい。画面が激しくちらつくはずだ。
これは2つの原因による。ひとつは、コンポーネントをaddしなおすことで、コンポーネントのあるエリアが強制的にバックグラウンドカラーで塗りつぶされるためである。まずバックグラウンドカラーで塗られ、それから図柄を描画するので、ちらつきが生じる。update()をオーバーライドしてもこの動作は止められない。
もうひとつの原因は、コンポーネントをaddしなおすときの、InvalidateRect相当のメカニズムが馬鹿で、2つのIndalidateされた場所の両方を含む矩形をInvalidateしてしまうためである。このため、中央の大きなカードと、左上の小さなカードのあいだの空間がちらつくことになる。
以上、JavaのGUIがなぜあれほど重いか、その一端をお見せできたと思う。
WindowsのGUIが速いのは、ネイティブ環境のせいばかりではない。こういう小さなところで、実にせせこましい工夫をコツコツと重ねているからでもある。MSは、少なくとも昔は、ほんのわずかの高速化のためにも血と涙と汗とバグを惜しまない会社だったのだ。
ちなみに上のアプレットだが、ブラウザのサイズを変えてリロードしてみてほしい。
アキバのエロゲー屋の店頭デモで、汚らしくリスケーリングされた画像を見るたびに、ウェーブレット圧縮の世界を、JPEG2000独裁の到来を、解像度フリーの実現を祈る私である。
m作戦。
・カードゲーム用のレイアウトマネージャとコンポーネントを作る、もしくはどこかから調達する
・drawImageの嫌な挙動（いくらThread.yield()しても、イメージのロードが終わらない場合がある）を解決する
あるクラスファイルを食わせると、KJC Suiteの1.5Bの逆アセンブラが落ちる。java.lang.ArrayIndexOutOfBoundsExceptionだから明らかなバグだ。
そこでKJC Suiteを2.1Aにしたところ、まったく動かなくなった。ちなみにSun
JDK1.4。GNU getOptのバグらしい。
花札のこいこいに似た同人カードゲーム、「モエモエ」のJava版を作ることになった。本作戦をm作戦と命名する。
こいこいと違う部分は3つ。
1. カードやイベント等の名称
私はこいこいを知らないので、名称はモエモエのもので記述する。
名称の足りない部分をここで補っておく。
・カードを配ってからあがる（あるいは流れる）までを「セット」とする。
・相手と自分が手札を切って積札をめくるまでを「ターン」とする。
2. 役
こいこいより役ができやすいらしい。
3. 1点差で勝っても10点差で勝っても効用は同じ
この意味は重い。
相手も自分も親番を使い切っていて、相手にリードされている、という状況を考えてみよう。たとえ1萌の役でも、相手に役を作られたら即死する。逆に、第1セットで1萌の役ができても、あがる馬鹿はいない。
この状況を、次の関数Rαで表現する。
今から始まるセット（まだカードは配られていない状態）で親を持つプレイヤーをαとし、子を持つプレイヤーをβとする。αの残り親番数をx、βの残り親番数をyとする。ルールによりx
≦ 6、y ≦ 6である。αの萌数とβの萌数の差をzとする。αがゲームに勝つ確率を、Rα(x,
y, z)とする。
x = y = 0はルール上ありえないセットだが、話を簡単にするために、Rα(0,
0, z)を定義する。z ＞ 0のときRα = 1、z ＜
0のときRα = 0とする。
関数Rαの性質はいろいろあるが、簡単にわかることを書くのは面倒なので省略する。
Rαが決まってこそ、役ができたときの対応を決定できる。相手にあがらせる危険を冒しても続行を宣言するのはなぜか？ そのほうがゲームに勝てる確率が上がるからである。
あがるか続行かを決定するときの、自分の手札の萌数をpとする。次に自分に役ができるまでのあいだに相手に役ができる確率をrh、そのときの相手の手札の萌数の期待値をEhとする。次に自分に役ができたときの、自分の手札の萌数の期待値をEsとする。続行したときの自分の勝率をRc、あがったときのをReとすると、
・Re = Rα(x, y, z + p)
・Rc ≒ (1 - Rα(y, x, - z + Eh))
× rh ＋ Rα(x, y, z + Es) ×
(1 - rh)
となる。Rc ＞ Reのとき続行である。
下の式の右辺をRca1とする。Rca1はRcの近似になっている。次に相手か自分に役ができたときには必ずあがる、と仮定しているぶんRcと異なっている。次に役ができたときにあがるか否かまで考えると、事実上計算が不可能になるので、さまざまな条件に場合分けして考える。たとえば、1萌の役を無視できる条件と、そうでない条件がある。
Rcのよりよい近似こそ、すべての要である。こいこいというゲームが、続行の宣言「こいこい」の名で呼ばれているのもむべなるかなだ。
役ができる確率rや、萌数の期待値Eについての議論は後日。
exeをDLL化して、血反吐を吐いた。起動時にまったく意味不明のランタイムエラーを出して落ちる。
結論からいえば、STLのmapが原因である。VC++6のSTLは殺人的に地獄的なので、こういう意味不明の事態が生じる。
というわけでSTLportにした。Platform SDKをインストールしている正しいMS者は、ここを参照。
PCカメラ、連動電源タップ、Wake On Lanを使って、メカトロ用の遠隔デバッグ環境を整えた。
40kmのかなたにある機械が動く、動きが見える！ アニキ、これがADSLの力なのか！