HyperCardのスピードアップ

 クロック周波数○ギガヘルツが普通に聞かれるようになっている今、この項目の意味は少なくなってきています。しかし、複雑な事をするにはHyperCardがスピード不足である事もまた事実。アニメーション能力でゲームボーイアドバンスにすら勝てません。  このページでは僕がこれまでに集めてきたハイパーカードゲームの高速化に関する情報を公開します。ただし、僕のマック上で速くなるかどうか判断しているので、本当に高速になるかどうかは保証できません。


テーマ1:HyperTalkの高速化

☆の項目はぜひやってみてほしいです。そうでない項目も一通り読んで、HyperCardがどのように動作するのかを理解しておいてほしいです。

☆他のカードのフィールドより開いているカードにあるフィールドのほうが速く、それよりもさらにglobal変数のほうが速いです。global変数とふつうの変数はあまり変わりません。スタックにデータを保存すべき時以外は、global変数を使うと速くなります。

☆だから、一つのスクリプト中で何度も同じフィールドからデータを読み込むよりは、一度だけ変数(あるいは、global変数)に格納して、処理にはその変数を用いたほうが速くなります。よく使うデータは変数に入れておきましょう。

☆char,item,word,lineのなかでは、charが最も速く、つぎにline,item,wordの順に速いです。2次元配列のような使い方をするなら、charとlineを使うようにしましょう。

・itemの区切り文字はset the itemDelimiter to spaceとすれば、スペースで区切ってある場合にwordを使うよりも速いitemを使えますが、HyperCard2.2と2.3で異なる動作をするので使わないほうが良いでしょう。 他の文字(半角の英数字か記号に限る)で区切ってあるならこの方法は非常に役にたちます。このときもnumber of items of 〜は使えます。

☆repeatで自作のハンドラを頻繁に呼び出すのは避けたいです。ハンドラ呼び出しはかなり重い処理です。特に行数が長い場合は時間が掛かるのですが、ハンドラ内の行数を少なくしたほうが読みやすくなって保守性が上がるので困ったものです。多数の場所から呼び出されるハンドラは仕方ないとして、1箇所からしか呼び出されない、頻繁に呼び出されるハンドラはひとつのハンドラにまとめる程度で妥協しましょう。

・char 1 to 10 of DATA とすれば、1文字目から10文字目までを扱えます。line等も同様です。スピードだけでなく、記述も簡単になるので重宝します。

☆ボタンやフィールド、カードなどを名前で指定するときはcd btn XXX とせず、cd btn "XXX"とする。ダブルクォートでくくると、それは文字列だとHyperCardは分かるのです。これでスクリプトも読みやすくなります。文字列を扱う場合はダブルクォートでくくるのが大原則です。

・true,false,Up,Downなどは予約語(HyperCardですでに定義されている)なので、ダブルクォートでくくらなくても速い。僕が作ったスタックで、わざわざダブルクォートでくくっているものもありますが、無意味でした。

・send mouseUp to cd btn 〜より、send "mouseUp" to cd btn 〜とダブルクォートでくくったほうがほんの少し速い。mouseUp等のメッセージ名は予約語ではないようです。だから、put 1 into mouseUpなんて事も出来ます。

・HyperCardで定義されている関数はticks()などと書かず、the ticksとする。ticks()とすると、命令はカード、バックグラウンド、スタック、ホームを通ってHyperCardに行きますが、the ticksとすれば、直接HyperCardに命令できます。その他、round of 3.5 なんて書き方でも同じ効果です。theやofがつくと直接HyperCardが扱うので速くなります。でも、the max(1,2,3)やmax of "1,2,3"というのは無理です。引数は1つまで。

・フィールドを不透明ボタンで隠すなんて事はせず、hideで隠しましょう。フィールドの内容を書き換える時の速さが違います。

・透明ボタンでset icon を使ってアイコンを真っ白にして見えなくする時間よりも、hideで消す時間のほうが短い。使わないボタンはガンガンhideしましょう。もちろん、本当にいらないボタンは削除してしまったほうがいいですよ。

・set width と set loc を使って、ボタンの移動と大きさの変更をするよりも、set rect で一度にやってしまった方が速い。

・同じように、set loc と show を使って、ボタンの移動と表示をするよりも、show cd btn 〜 at X,Y で一度にやってしまった方が速い。

・ボタンなどの指定は、数字(number)で指定するのが一番速い。IDで指定してもほぼ同じ。名前で指定すると少し遅くなります。ID指定が一番速いと言う話も聞くけど、うちの環境では数字(number)で指定するのが一番速いです。

・put で変数に入れるよりもget でitに入れた方が少し速いので、一時的にデータを読み込んでおくだけならgetを使うとよい。

・put DATA+1 into DATA よりもadd 1 to DATA のほうが少し速い。これは、変数の出てくる(変数を参照する)回数が少ないからです。

・他のカードのオブジェクトをたくさん使うなら、そのカードに移動してから使ったほうが少し速い。逆にいえば、少ないなら移動せずにget cd fld xx of cd "***"とすればいいです。カード移動時間はオブジェクト数に比例して遅くなるので多くの場合移動せずに使ったほうがいいと思います。

・PICTボタンは名前をかえただけでは描画されないので、lock/unlock screenやset locを使ったりしますが、set icon of cd btn XX to -1 としたほうが速いです。ただし、複数のPICTボタンを同時にかえる場合はlock/unlock screenを使うほうが速いでしょう。

・if XXX is true thenとするなら、if XXX thenと省略でき、速くなります。if XXX is false thenなら、if not XXX thenです。

・if XXX is "show" then show cd btn A
 else if XXX is "hide" then hide cd btn A
こんなスクリプトにするなら、一行にまとめて
 set visible of cd btn A to XXX is "show"
とできます。どうせなら、XXXはtrue/falseにしてしまい、
 set visible of cd btn A to XXX
としてしまえばいいのです。

・if [loc] is within [rect] then は遅いので、繰り返し使う場合は、if X > 0 and X < 10 and Y > 0 and Y < 8 then などとする。

・lock screenしたままカードを移動するような場合でも、openCard/closeCard等の命令が送られて、処理されます。openCard命令があるカードに移動してすぐ戻る場合などにはlock/unlock messagesを使って無駄な処理をしないようにします。

・ある変数の値が整数か文字かを調べる場合(通れるブロックかそうでないかの判定に使ったりしてます)、if XXX is a number thenとif XXX is a integer thenではintegerのほうが少しだけ速い。numberは小数かどうかまで判定するが、integerは整数かどうかだけを調べるため。

・マウスカーソルの位置を調べる時、横方向はitem 1 of the mouseLoc、縦方向はitem 2 of the mouseLocなんてしてる人がよくいますね。横方向ならthe mouseH、縦方向ならthe mouseVを使いましょう。ボタンやフィールドにもこういうのあったらもうちょっと速くなるのになぁ。left/top of cd btn XXXを使える時は使いましょう。

・スクリプトは変数名、コメント文なども含めて、なるべく少ない文字数(バイト数)で書くと、スクリプトを読み込む時間が少なくてすむので、速くなるというのはウソでした。すいません。

・(補足)掌田津耶乃著「応用HyperCard」(ASCII1995)によると、変数名を短くしたほうが速くなるとあります。田中求之氏の「HyperCardの散歩道」では変数名を短くしても速さは変わらないとあります。僕の実験では、変数名を短くしても高速化しないようです。

・the visible of cd btn 〜 や the random of 〜 などtheを付けても付けなくてもいいものでtheを省いても省かなくてもスピードは変わらないようです。容量を1バイトでも減らしたい方は省いたほうがいいかな?

・変数や数字をカッコで囲んでも速さは変わりません。カッコを使ったほうが見やすくなる場合はぜひ使いましょう。また、数字を"123"に囲むとむしろ低速化します。

・set loc of cd btn "A" to "100,200" よりset loc of cd btn "A" to 100,200としたほうが速い。同様にclick at x&","&y よりclick at x,yのほうが速くなります。""で括った場合はHyperCardが内部的にコンマで分割しているので遅くなります。

・ただし、if loc of cd btn "A" is 50,50 thenなんて書き方は出来ません。if loc of cd btn "A" is "50,50" thenと書きましょう。この場合、HyperCardが内部的にコンマで分割しているわけではないので遅くなっていませんし。

・if-then-else文はできるだけ行数を少なく書いたほうが速い。たとえば、
  if a=1 then
   put "わん!"
  else if a=2 then
   put "にゃん"
  else if a=3 then
   put "げこげこ"
  end if
 よりは
  if a=1 then put "わん!"
  else if a=2 then put "にゃん"
  else if a=3 then put "げこげこ"
 のほうが速く、さらに
  if a=1 then put "わん!" else if a=2 then put "にゃん" else if a=3 then put "げこげこ"
 だと最高に速いわけです。・・・最後の書き方見た事ないって?こんな書き方もできるんですよ。これだと見にくいので、見やすくするためにはソフトリターンを使います。ん、ソフトリターンはソフトクリームの仲間かって?"~"を使うと改行しているのに改行した事にならないのです。これがソフトリターン。
  if a=1 then put "わん!" ~
  else if a=2 then put "にゃん" ~
  else if a=3 then put "げこげこ"
でも、ここまで書いといて何ですけど、この方法はあんまり高速化しなかったりします。

・高速化を意識したスクリプトでも、長ったらしいスクリプトを書いてあったりします。例えば、
  put item i of Data into A
  put item i+1 of Data into B
  put A&B into C
なんてことをしている事があります。とことん高速化するなら
  put item i of Data & item i+1 of Data into C
とやってしまったほうが速いわけです。多少、分かりにくいスクリプトだと思うかも知れませんが。

・上のスクリプトは、さらに高速化できます。
  put item i to i+1 of Data into C
基本的に、スクリプトは簡潔にするほど速くなります。スクリプトの行数をできるだけ少なくする事に精を出してみるのも面白いですよ。

・さて、ここで問題です。下の3つのスクリプトでもっとも速く動作するのはどれでしょうか?
 1) set cursor to watch
 2) set cursor to "watch"
 3) set "cursor" to "watch"
もちろん、全て動作するスクリプトです。となると、「文字列はダブルクオートでくくると速い」と上で書いたので、3番だと思う方もいらっしゃるかもしれませんが、正解は、2番です!一番遅いのが3番でした。(HC2.2Lite,HC2.3Playerで確認。)どうも、HyperCardでは妙な処理をしているようです。lock screenとlock "screen"では前者のほうが速いのです。興味深い結果です。

・遅い、遅いといわれているis withinですが、少し速くする裏技があります。
 if x&","&y is within rect of cd btn 1よりも
 if "x,y" is within rect of cd btn 1のほうが速いのです。
もっと追求すると  if x&","&y is a&","&b&","&c&","&dよりも
 if "x,y" is within "a,b,c,d"のほうが速いのです。
不思議なことに、ダブルクオートで括った場合は文字列になるはずが、withinを使う場合だけ変数の中身を参照しています。
is withinは数値を扱うものですから、この方が便利といえば便利ですけど。ルール違反じゃないか?

・playでサウンドを鳴らす際、低速機種ではplayコマンド実行からサウンド再生までに若干「溜め」があります。これはサウンドデータをメモリに読み込んでいる時間なのですが、現在鳴らしているサウンドデータなら読み込む必要はないので、BGMのようにサウンドを繰り返し再生する場合、この解説スタックを参考にすると良いです。

・ボタンを最前面や最背面にする方法。set partNumber of cd btn "middle" to number of cd partsで最前面、set partNumber of cd btn "middle" to 1で最背面にできます

ここに書いてある内容は、1回の命令で1/1000秒しか変わらないような事も含まれています。しかし、これらを複数組み合わせて、何百回、何千回と繰り返すなら体感できるスピードの差となります。スピードが重要な部分ではぜひこれらのテクニックを使ってみて下さい。


テーマ2:画面表示の高速化

・背景に一枚絵を表示する場合、PICTボタンにするよりもピクチャにしたほうがボタンなどを動かしたときに高速に動きます。特に、PICTボタンが何重にも重なっていると、そのPICTボタンに重なる部分で画面表示の書き替えを伴う処理がとてつもなく遅くなります。

・画面に表示させる必要のないボタンやフィールドはできるだけhideしておきましょう。画面書き替えの処理時には、あるボタンが動かなくてもそのボタンと重なった部分の画面が書き換えられるときに遅くなります。hideしていても、PICTボタンやフィールドは遅くなる原因となります。使わないなら削除しましょう。

・PICTボタンを使う場合、PICTリソースの容量をできるだけ少なくしましょう。具体的には、クラリスワークスで白黒モードにしたり、小さなものならcicnリソースの白黒部分を使ったりします。PhotoShop使うのはダメらしいです。ColorItは白黒モードにすればOK。

・英数字しか使わないフィールドでは、1バイトフォントを使う設定にしましょう。ChicagoやGenevaなどです。フィールドを動かしてアニメーションさせたり、数値を頻繁に書き換える場合に処理速度が大きく変わります。

・フィールドと重なる部分の画面の書き替えがあるとき、それはそれはものすごく遅くなるので、フィールドとボタンが重ならないようにしましょう。ただし、フィールドの内容が空なら少しはましです。

・一つのカードにたくさんのオブジェクトがあればそれだけカード移動や画面の書き替えを伴う処理が遅くなります。100以上になると顕著です。hideしていれば少しましですが、やはりある程度は遅くなります。シカも、メモリを浪費して安定度も悪くなるらしいです。カード数も増えすぎると遅くなります。やり過ぎはよくない、何事も控えめに。

・ウィンドウサイズが大きくなるとメモリを喰うだけでなく、lock/unlock screenが遅くなります。lock/unlock screenを多用して高速なゲームを作る場合ウィンドウサイズをできるだけ小さくし、メッセージボックスもうまく活用しましょう。

・多数のボタンを同時に動かす(アイコンを変えたりする事も含む)場合、lock/unlock screenを使うと高速化します。PICTボタンの場合はもちろん、アイコンボタン、フィールドをたくさん動かす場合にも必須の技です。

・ボタンのオートハイライトはなるべくチェックしておきましょう。時々ボタンがハイライトしないので押したかどうか不安になり、もう一回押すと、次のカードのボタンが反応したりしてめちゃくちゃイライラしたりします。そうそう、マウスクリックが次のカードで反応するのを防止するためにカードを移動する時はマウスクリックのクリアも忘れずに。ぼくは、スクリプトにget the mouseclickの一文を置いてます。itの内容が変わってしまいますが、短いので気に入ってます。でも、if the mouseClick then(改行)end ifのほうが速いんですよね。

・HyperCardのカラー化を行うフリーのXCMDに「ColorizeHC」があります。これを使った後、カラー表示を行わせるには画面の書き換え処理が必要になるので、lock/unlock screenを使ったりしますが、スピードを重視するなら画面を書き換えるべき部分のみにボタンを移動あるいは表示させれば良いのです。ボタンは透明ボタンにすれば見えませんが、画面の書き換えはきっちり行われます。

・ColorizeHCでカラー画面を白くする時に"Dispose"を使わず、"Erase"を使いましょう。でも、"Dispose"命令を使わないとvisual effectが効かなくなるのでその場合を除きますが。"Dispose"と"Erase"そのものの速さは変わりませんが、その後カラー化命令("Add"とか)を使う時に"Erase"を使った後のほうが速くなります。また、"Erase"した後連続して"Add"でカラー化するなら"New"を使いましょう。"Dispose"命令はカラー描画情報をメモリから破棄してしまうものですので、カラー化する時にカラー描画情報がメモリ内になければ新たに作り直さなければなりません。そういうわけで、closeStack時には"Dispose"命令を忘れないように・・・。

・ColorizeHCでPICTを描画する際、ColorizeHC "Add"(PictのID),(描画するtopleftかrect)・・・とコマンドを打ちますが、「描画するtopleftかrect」は実はrectで指定したほうが速いです。32*32ドットのPICTをカード一面に並べるスクリプトで5%位の差がでました。

・フィールドに書かれた文字はフィールドの内容を書き換えたり、フィールドに重なるボタンを動かしたりすると、書き換えが起こります。この書き換え速度はフィールド内に書かれた文字数やフォントの大きさ、フォントの種類によって変わります。そして、意外にも「行を回りこませない」のチェックを付けておいたほうが速くなります。もちろん、その場合は行の回り込みが行われません。RPGやサウンドノベルなどでメッセージを1文字ずつつらつらと表示するような場合に使えますね。

・lock screen/unlock screenは画面の書き換えを起こさないようにするので画面処理を高速化できる可能性がありますが、逆にlock screen/unlock screen自体が画面処理でもあるわけです。しかも、ウィンドウ内の全てを書き直す相当重い処理です。lock screen/unlock screenを多用するカードにはなるべく不要なボタンやフィールドを置かないようにして高速化を図りましょう。


テーマ3:アルゴリズムの改善

 なんだかんだ言っても、一番重要なのがこれでしょう。HyperTalkだけでなく、CであれAppleScriptであれ効く技ですから。

・できるだけ少ない命令で処理すること。CPUに無意味なことをさせない。

・特にrepeatでくり返している内側を改善する。repeatで100回くり返している外側で10の高速化をするよりも、内側で1の高速化をするだけで100の高速化ができるほうが得。

・待ち時間内に先回り処理をしてしまいます。例えば、RPGの戦闘でダメージを0.5秒表示している間に、そいつが死んだかどうか、全滅したかどうかを処理しておきます。この方法を使うには、待つ処理をwait 30ではなくwait until the ticks >= LASTTICK+30 としなければいけません。(LASTTICKにはダメージ表示直前のthe ticksの値を入れておきます。)

・処理中にはなんらかの方法で処理中であることを示しましょう。カーソルをwatchにしたりbusyにするのが定番です。LUTIAのステージ構築はステータスバー表示です。ステータスバー表示なら処理がどこまで進んだか分かるのが長所です。処理中は画面を真っ黒にしたりするのも一案。レスポンスが悪ければ反応しているのかしていないのか分からず不安になります。

・逆に、処理中でなくユーザーがマウスを押したりするのを待っているのならカーソルをhand等にしましょう。実際の処理速度が遅い事よりもきちんと反応を返さないほうがよほど体感速度が遅く感じます。

・画面に見える処理をできるだけ早く行いましょう。クリック音を発生させるのにさえ低速マシンでは時間が掛かります。キー操作のRPGなどでは、リトル・パラルシリーズ((C)Image of the Forest)のようにその方向に動けるか動けないかに関わらず、キャラのアイコンを変えて反応を返します。人間の反射は0.1秒掛かるといわれていますから、0.1秒以内に反応を返しましょう。

・コメント文は入れたほうがいいでしょう。容量削減よりもバグを減らすほうが重要です。バグのないスクリプティングを心掛けましょう。もちろん、無駄なコメントは無駄でしかありませんが。

・似たようなスクリプトはコピー&ペーストで量産するのではなく、ひとつのスクリプトで処理できるようにしましょう。スクリプトの改善が楽になるので、作品をスムーズに作る事が出来ます。スピード面での改善ももちろん楽になります。

 いかにしてアルゴリズムを改善するかよく考えましょう。あまりアクロバティックなことをせず、なるべく短く、素直にやるのがいいと思います。素直なプログラムは改善しやすいです。あとから見て、「なんじゃこりゃ?」とうなってしまうスクリプトは本当に高速動作が必要な部分以外では使わないようにしましょう。


テーマ4:HyperCardの動作

 僕の経験上からHyperCardがいったいどういった処理をしているのかを考えてみました。間違っているところもあるでしょうけど。

・開いているカードのデータだけはメモリにあるようです。カードにあるフィールドの内容、カードピクチャ、カードのスクリプト、もしくはカードボタンスクリプトはメモリ内にあるので迅速に処理してくれます。開いているバックグラウンドとスタックのデータもメモリ内にあるはずです。だから、他のカードのデータを参照すると遅くなります。かといって、他のカードのデータをいじるためにわざわざカードの移動をすると、移動先のカードの内容全てをメモリに読み込むので逆に遅くなります。設計段階であるカードでのみ必要になるものはそのカードに置くようにします。

・画面の書き換えは縦2ドット横16ドットの長方形を単位として行われているようです。2×16=32bitコンピュータですからね。なんだか視覚効果もそれに束縛された動作になっています。丸い形の視覚効果はありません。カードピクチャはこの形式に最適な構造になっているので、処理に負担がかからないようです。フィールドやアイコン、PICTボタンは最適化されていないので遅くなります。

ここからは、良く知られていることや、受け売りです。

・一度実行されたスクリプトは、2回目からは速く実行できます。これは、1度目の実行時にスクリプトがコンパイル(Macが処理しやすいようにすること)されているのです。でも、メモリの割り当てが少なければ、コンパイルしたデータは消えてしまうらしいです。

・HyperCardはidle状態(スクリプトが何も実行されていない状態)になると、現在のスタックのデータをハードディスクに書き込みます。そのために一瞬動作が止まります。一つの解決方法として、set cantmodify to true で書き込みを阻止できますが、スタックの変更が保存されません。僕はrepeatで常にスクリプトを回しつづけてidle状態にしないという力技を使ってます。

・「スタックを閉じるときに、2度スタック整理を行えば良い」というのは誰が言い始めたのかよく分かりませんが、一度目のスタック整理ではスタック容量を減らし、2度目のスタック整理ではオブジェクトのデータを速く読み込めるように並べるらしいです。果たしてそうかな?

・AddColorでのカラー化の仕組み。CopyBits関数にパッチを当てています。出力先がカードウィンドウの場合、AddColorのカラーイメージと合成して出力します。CopyBits関数にパッチを当てる方法は、よく分かりませんが、カードウィンドウのグラフポートの設定が変わっているので、そのあたりが怪しいです。でも、ColorizeHCだと変わってないので、他のやり方もあるようです。


テーマ5:HyperCardの裏技的テクニック

 高速化とはあまり関係ないですが、一般的に知られていないが使えるテクニックを紹介します。上級者ならこれくらい知っておこう。

・PICTボタン:ボタンのiconを-1にしておくと、ボタンの名前と同じPICTが白黒2色で表示されます。iconを-1にするにはset icon of cd btn XXX to -1をメッセージボックスから打ち込みます。PICTはボタンのサイズまでの大きさだけ表示されます。また、hiliteは効かなくなるので注意。ボタンの名前を変えただけではPICTが表示されないので、set icon of cd btn XXX to -1をもう一度したり、lock screenをしてunlock screenをすれば表示されます。

・マスク付きPICTボタン:HyperCardの投げ縄ツールで丸い形のグラフィックを選択してコピーして、PICTボタンとして表示しても四角形で選択したように背景が不透明になります。しかし、クラリスワークス(アップルワークスでも同じはず)やResEditのcicnエディタで投げ縄ツールを使うと、きちんと丸い形で背景が不透明になります。この時クラリスワークスなら色数を白黒に、cicnエディタなら白黒の絵を書く部分でコピーして下さい。そうすると、PICTボタン表示時に容量が少なく高速に描画できます。この方法はRPGのモンスターのグラフィックを表示するのによく使います。

・マスク付きPICTボタン(追加):クラリスワークスやRsEditのcicnエディタではドーナツのように、中がくりぬいてある形を作るのは無理です。そこで、マスク付きPICTボタン専用のソフトを作りました。これさえあれば、自由自在なマスク形状のPICTを作ることが出来ます。しかも、PICTの容量が少なくて描画も速いのです。ソフトの入手先は▼こちら

・FONT:スタック内にFONTリソースがあれば、フィールドのフォントを自作フォントに変える事ができます。自作フォントといっても、表示させるのは文字でなくグラフィックにしてもいいのです。フォントはPICTより軽く、iconと違って一気に内容を変えられるという特徴があります。問題は、作るのが難しい事(ResEditかKatoh氏作のHCFontConvertor)とサイズに上限がある(127*127)ことです。「HyperCardでゲームを作ろう」(学研)についていたMakeFontというXCMDがあれば多少作りやすくなるのですが、この本は絶版となってしまい、容易に入手出来ません。FONTを使用する場合のエラーについては▼FONTについてを参照。

・ライブラリ:「start using stack スタックのファイルパス」でスタックをライブラリ化できます。スタックAでスタックBをライブラリ化すれば、スタックAからスタックBのリソース(アイコン、PICT、サウンド、FONT、XCMD、XFCN他)を利用でき、スタックBのスタックスクリプトを動作させられます。ライブラリを解除する時は、「stop using stack スタックのファイルパス」を使います。しかし、ライブラリは実際役に立つ場面はそう多くないかも知れません。

・pictureコマンド:これはHyperCardに標準で入っているXCMDです。PICTファイル、PICTリソース、クリップボードを別ウィンドウでカラー表示できます。待ち時間にピクチャを表示させるのにうってつけの機能です。使い方は、
picture [picture name/ID] , [source type] , [window style] , [visible] , [bit depth] , [palette]
source type = "file,resource,clipboard"
window style = "plain,zoom,document,windoid,roundRect,rect,dialog,shadow"
visible = "true,false"(ウィンドウを表示するかどうか)
bit depth = "0,1,2,4,8,16,32"(表示色数の設定、0ならバッファを使わずに転送する(※))
palette = "true,false"(ウィンドウを常に前面にするかどうか)
という感じでかなりややこしいです。set scale of window [picture name] to "-5,-4,-3,-2,-1,0,1,2,3,4,5"でズームイン/アウトできます。show/hide window [picture name] でピクチャウィンドウを表示させたり消したりできる。close window [picture name] でピクチャウィンドウを閉じて、メモリを解放します。set loc、set rect、set scrollも使えます。
(※)バッファを使わずに転送すると、バッファ分のメモリを消費しないのでメモリが少なくても使える。ただし、スクロールしたり、移動したりするとバッファがあればそのデータをすぐに転送できるが、バッファがないとPICTを書き直す事になり、スピードが遅くなったりちらつきが発生する。

・sendコマンド:send "mouseUp" to cd btn XXXのように使います。あるオブジェクトに対し命令を送ります。例えば、RPGの技1を発動する場合はsend "Action" to cd btn "技1"として使えば、スクリプトをボタン単位で管理できます。

・ColorizeHC:これはフリーウェアとして配付されているXCMDです。HyperCard製品版に付属のAddColorと違いスクリプトを全て自分で書かなければならないので使いにくいのですが、複雑な事をするならColorizeHCのほうがいいと思います。ColorizeHCにはカラーのエフェクトがないのが残念ですが・・・。説明は省略しますが、カラーデータのサイズはウィンドウサイズでなくカードサイズである事、"Copy"命令ですでに描いたカラーデータを使って描画できる事、"transparent"モードで白抜き描画できる事、細かいサイズで何度も描画するより大きなサイズで一気に描画したほうが速い事、アイコンやPICTボタンと違って拡大/縮小できる事、これらをうまく使えば相当凝った事が可能です。

・PgColorX:僕の開発したカラーXCMDです。高速な処理が可能で、しかも多機能です。白黒で頑張るよりこれを使ったほうが速いくらいです。回転、拡大縮小や多角形、点、線分、矩形、円、円弧の描画など。入手先は▼こちら

▲研究室入り口へ