第17版公開

だいぶ遅くなったが、ようやく「主筆」第17版を公開しておいた。　本当ならもう少しテストをしてから公開するようにしたかったのだが、あまりにもやる気がなくて、かつ、できれば年内に公開しておきたかったから、とうとう公開してしまった。

今のところ、配布用パッケージはリリース用にビルドすると自動的に生成されるようにしてある。要はMakefileにパッケージ生成から圧縮・md5の署名の生成までを行うスクリプトを記述してあるのだ。だが、それは実行バイナリに対するものだけでああって、ソースコードの配布用のファイルは生成してくれない。毎回必ずソースコードも配布している現状を考えれば、上記の対処は片手落ちだといわざるを得ない。ソースコードの配布用の圧縮ファイルまで自動生成してくれるスクリプトを、どこかのタイミングで作成した方が良さそうだ。

配布用ファイルのmd5の署名は、上に書いたとおりMakefile内で自動生成している。そしてそのために、署名を生成するためのプログラムを作成して、署名時にそれをコンパイルして実行するようになっている。

md5のソースコードはRFCの何番だったか忘れたが、公開されている。今まで俺はそれをそのまま流用して使用していたのだが、ソースコードを配布することを考えると、著作権的に問題があるのではないかと思い、使うのをやめた。

とは言っても、自分でmd5のアルゴリズムを実装するのもあほらしいから、そこまではやらなかった。結局、Solarisがmd5のAPI関数を提供していたから、それを使うようにしただけだ。手抜きなのも甚だしいが、まぁいいだろう。

第16版から第17版にかけて、約200KB程度容量が増えているが、これは別に、その分だけ機能が増えたと言うわけでもない。確かにいくつか機能を追加しはしたものの、圧縮した状態で200KBも増えるような追加はしていない。容量が増加した原因は、添付しているアイコンが増えたことと、より強力に最適化を行うようにしたことだ。

Sun studio 11には、binoptという実行バイナリの最適化を行うツールが添付されている。今まではそんなものの存在を知らなかったから使わないでいたのだが、せっかく付いてくるのなら使っておこうかという事で、採用することにした。そしたら実行バイナリの容量が多少増えてしまったようだ。だがまぁいいだろう。

古い話になるが、第15版から第16版にかけて、配布ファイルの容量が約1MBも増加しているのだが、この原因は配布形式の変更にある。今までは、インストーラーをShellスクリプトで自前で記述していたのだが、それをパッケージに変更した。

パッケージにしたからと言って、直接的に容量が増加する原因にはなり得ない。だがしかし、パッケージにすると、中のドキュメントがインストールするまで参照できなくなってしまうという問題がある。そのため、ドキュメント（pdfファイル3つ）は、パッケージ内に含めるのと同時に、圧縮ファイル中にも重複して持たせるようにしている。そのため、容量が極端に大きくなってしまった。

だから、実を言うと配布ファイル2MB中の約75%程度がドキュメントだったりもする。配布するファイルの形式や構造を何とか工夫して、ドキュメントを重複して持たなくてもいいようにできれば、容量はだいぶ削減できるのだが。

気力

「主筆」第17版を公開しようと思って、ドキュメントを整備してパッケージを作成するまではやってみた。だが、そこから先を進める気力が出ない。

プログラムを作成し終わった後、リリースまでにしなければならない作業には、以下のようなものがある。

1. ドキュメントの作成


2. 配布パッケージの作成


3. Webサイトの更新


4. リリース

どれも大した作業ではないように思われるが、実際やってみるとそれぞれ相当な工数を要する。

ドキュメントの作成には大変な労力を要することは今更言うまでもない。また、Webサイトの更新も、本質的にはドキュメントの作成と同じであって、それ相当に労力がかかる。

意外と負荷が大きいのはパッケージの作成だ。Solarisの配布パッケージの作成自体はmakeで自動化できる。だが、パッケージの内容を更新するのが大変なのだ。

パッケージの作成に含まれる作業には、配布するリソースファイルやその他のデータの準備、配布先フォルダの決定、パッケージ作成用のPrototypeファイルなどの作成、パッケージ作成用のコマンドの作成、makeファイルの作成、圧縮などがある。

そういったものを一つずつこなしていき、パッケージを作成した後には、正しくパッケージができているか否かテストしなければならない。

特にパッケージのテストは、最も欠かすことができない作業の一つであると同時に、最も手が抜かれやすい作業でもある。プログラミングも含めた開発工程全般から見れば、パッケージの作成に要する期間は短い。そのため何となく軽視しがちだ。だが、この作業に由来するバグは思いの外多いし、また、パッケージの作成で失敗した場合は、リリースされたソフトがまったく動かないとか、そもそもインストールできないとか、そういった致命的なものになりがちで非常に目立つ。だから、パッケージのテストは重要である。

また、パッケージ作成後にパッケージのテストだけを行うというのは、常識的に言っておかしい。普通に考えれば、この時点で総合テストを行うことになるだろう。

つまり、できたばかりのソフトをインストールして、実際に使ってみて、最後にアンインストールするまでを通してテストするのだ。それでようやく完成したと言うことができる。

配布するものができてWebページも作成したら、ようやく一般に公開することができる。だが、ここで気を抜いてはいけない。人間というのはよくしたもので、隙あらば間違いを犯すようにできているらしい。

ファイルの移動やコピーなどといった作業は、普段いくらでもやっているような作業であるはずなのに、なぜかソフトのリリースの時に限って間違えるのだ。リリースしなければならない新しいバージョンのファイルを古い奴で上書きしてしまったり、違うところにおいてしまったり、ファイル名を間違えたり、ありとあらゆる間違いが起こりうる。

だからここでもテストが必要である。つまり、リリースしたファイルが正しくダウンロードできることを確認して、なおかつ、ダウンロードしたファイルの内容が正しいことを確認しなければならない。

そこまでやって、ようやくリリースが完了するのである。

その行程を考えると、作業を進める気力が失せる。そもそもいったい何でこんなことをしているのか。これをやって一体何のメリットがあるのか。

プログラムの作成は、まだそれ自体に面白みがあるからいいようなものだが、この辺の作業はまさに雑用意外の何者でもないし、本当につまらない。

いくら物好きな俺でも嫌気がさす。

ドキュメントの書き方

「主筆」第17版の公開に向けて、ドキュメントの整備を行っている。ところで、このドキュメントはどういった体裁にするのが良いのだろうか。他のマニュアルなどを参照しながら、自分なりに考えてみた。

１．表紙

主筆のマニュアルの表紙はSunのマニュアルを模倣している。右上にロゴをおいて、ページの中程に右揃えで表題を書き、下線を引いてある。

格好のいい絵でも描ければいいのだろうが、何分俺にはそういった才能がないので、できる限りシンプルなものにしておいた。

２．目次

今のところ、ページ数はそれ程多くないため、目次の体裁については余り考えていない。とりあえず書いてあるだけだ。

３．分類

さして長くないとはいえ、十数ページに渡ってだらだらと文章で書きつづるわけにも行かないから、ある程度の単位で区切らなければならない。

とりあえず俺は、大分類を「１」「２」「３」……、中分類を「１．１」「１．２」「１．３」……、小分類を「１．１．１」「１．１．２」「１．１．３」……、とする章立ての方式をとっている。

他のマニュアルを見た場合、大分類以外には明示的に番号を振っていない物もあるようだ。また、マニュアルが長くなってきた場合、上記の方式だけでは分類仕切れなくなってくるのだが、その場合にはマニュアル自体を複数に分けたり、あるいは大分類の上にさらに「１」「２」「３」……という区切りを設けるなどして対処している物もあるようだ。

４．大分類

一つの大分類の始まりで改ページするか否か。

大概のマニュアルでは改ページしているようだ。さらに物によっては、大分類の区切りに白紙のページを設けているものもあるようだ。

また、多くのマニュアルでは、大分類の始まり（大分類のタイトルの後）に、その大分類では何の説明をしているのかを、短い文章で記述しているようだ。

大分類のタイトルのページを一個独立で用意するか、あるいはタイトル（と短い説明）の直後に改ページしないで中分類のタイトルを続けるかは、物によるようだ。だが、どうやら長大なマニュアルでは、大分類のタイトルのページを用意する（つまり改ページする）方式を取っている様な気がする。

５．中分類・小分類

中分類・小分類の区切りで改ページすることは余りないようだ。

６．インデント

これが一番難しい。

他のマニュアルを参照すると、下記のような方針でインデントを行っていることが多いようだ。
インデント無し
・大分類のタイトル
インデント1段
・中分類のタイトル
・中分類の本文（中分類に関する説明書きなど）
・小分類のタイトル
・本文
インデント2段
・何らかの特殊な説明書き

本文中に箇条書きが出てくる場合にも、通常は本文と同じレベルのインデントにしているようだ。俺は箇条書きは一段下げたくなるのだが、どうもそれは間違っているようだ。

また、中分類と小分類のタイトルが同じレベルにくるので、インデント以外の方法で区別できるようにしてやる必要がある。文字の大きさを変えるのが一般的だが、それ以外の方式も組み合わせて使われるようだ。多いのは、中分類と小分類のタイトルの右側に何らかのアイコンを配置する方法だ。

これは、文字の大きさの違いだけだと区別が付きにくいからだ。実際、10.5ポイントと12ポイント程度の違いだと、本文中に紛れて区別が付かない。だから、かなりはっきり判るようにしてあげなければならない。


図や表の入れ方にもいろいろと工夫すべき点があるのだろうが、とりあえず以上の工夫ぐらいは取り入れて、多少なりとも読みやすいマニュアルになるよう努力しておこう。

Jsvzの更新

何となく「主筆」をいじる気がしなかったから、Jsvzを更新してみた。

まず、プレイヤーが攻撃しているときに、敵が攻撃するときの音が再生されない問題を解決しておいた。

Jsvzでは、音声データは細切れにしてリストに格納し、リストの先頭の方から順番に再生していくようにしている。これは、WindowsAPIのwaveOutWriteの制約によるものである。

ある程度の長さの音声データをwaveOutWriteで再生しようとした場合、その再生中のデータは途中で変更することができない。そのため、プレイヤーの攻撃や敵の攻撃、敵の崩壊などといったイベントが複数重なった場合は、あらかじめ音が重なった状態の音声データを合成して、その音声データをwaveOutWriteで再生するようにしてあげなければならない。だから細切れにして再生する必要がある。

ポトが再生されない問題は、再生するデータをリストに追加する処理に原因があった。リストの先頭の方には再生中のデータがあり、その後ろに未再生のデータが並ぶ。そういう状態で音声データを新たに追加しようとしたとき、リストの先頭のデータに対しても、音を重ね合わせる処理を実施していた。

ところが、再生中のデータに対して変更を加えたところで、実際に再生すされる音には変化は生じない。そのため、結果として再生するデータの先頭部分が再生されなくなっていた。また、再生しようとする音が短い場合には、全く再生されなくなっていた。

だから、再生中のデータに対する音の重ね合わせ処理を実施しないようにすることで、確実に音が再生されるようにしておいた。

また、バグ対策以外にもいくつか仕様変更も行った。

一番大きく変更されたのは、敵の攻撃方法だ。今までは、プレイヤーがいる方に向かって一つずつ弾を撃つだけだったが、それを、ある程度まとめて撃つように変更した。また、敵が撃った複数の弾が一点に重なっていても仕方がないので、ある程度ばらけるようにしておいた。

世の中のシューティングゲームというものを思い浮かべるに、どうやら敵は、プレイヤーに対して的確に攻撃を加えてはいけないようだ。敵はプレイヤーがいる方向に向かって、無駄弾を大量に撃ちまくるようにしなければいけないようだ。

どうしてそれが良いのかは行く判らないが、どうやらそういうものらしい。だから俺も、そういう「業界標準」に合わせておくことにした。

そしてそれに合わせて、ステージの構成も変更しておいた。何せ、弾の数を増やしたため難易度が大幅に上がってしまったのだ。だから敵の数を大幅に減らしておくことにした。そもそも、敵の数が多いと処理が重くなる。処理速度維持のためにも、簡略化は必須だった。

だが、これだけの労力をかけて物を作ったとしても、ほとんど報われることはないようだ。vectorでの順位も、順調に下がり続けている。Webサイトのアクセス数には目立った変化はない。

やはり俺には、こういう方面に対する才能は無いのだろうか。

CDEでの背景画像の設定

CDEで背景画像を設定することを考えてみる。

背景画像は${HOME}/.dt/backdropsに格納したxpm形式のファイルが使用される。だから、背景に設定したい画像を何とかしてXPM形式に変換して、然るべきディレクトリに格納してあげれば、背景として使用することができるようになる。

問題はここで使用するXPM形式である。通常XPM形式は256色であると言われるし、俺も最近までそう思っていた。だが、XPM形式のファイルフォーマットを考えれば、必ずしも256色に限定されないことに気が付いた。

XPM形式のファイルフォーマットは、下記のようになっている。

/* XPM */
static char * 名前[] = {
/* width height ncolors cpp [x_hot y_hot] */
"幅 高さ 色数 1ピクセル当たりの文字数 x位置 y位置",
"カラーテーブル1",
・・・
"カラーテーブルn",
/* pixels */
"画像データ1",
・・・
"画像データn"}

カラーテーブルの部分は、
"文字列 <TAB> c #色",
となっており、画像データの部分は、カラーテーブル中の"文字列"の値を使用して、各ピクセルの色のインデックスを指定するようになっている。

つまり、XPM形式はインデックスカラーを使用するフォーマットであるということだ。だがしかし、1ピクセルを表現するのに使用する"文字列"の長さを長くしてあげれば、必ずしも256色である必要はないということだ。極端なことを言えば、24bitカラーの画像を減色せずに、直接XPM形式に変換することもできるというわけだ。

そういうことで、やってみた。

上でも書いたが、通常XPM形式のファイルを出力するソフトは、256色で出力する仕様になっている。だから俺は、ビットマップファイルを読み込みXPMを出力するプログラムを作ってみた。とは言っても、XPM形式のフォーマットは単純だし、ビットマップ形式のファイルを読み込むプログラムは、すでに作り込んだやつを持っているので、さして時間はかからなかった。（そんなことをしなくとも、GIMPなどでは色数の多いXPMファイルを出力することができるようだが。）

それで、生成したXPMファイルをSolarisで開いてみた。が、いかんせんファイルを開くのに時間がかかってしまい、到底背景画像としては使用に耐えないことが判明した。

まぁ、当然といえば当然の結果だろう。なにせ24bitカラーの画像を直接XPMに変換したのだから、使用されている全ての色をカラーテーブルに登録して、その色を参照するという形になっている。それでは開くのにも時間がかかるというものだ。

ならばということで、色数をある程度落としてからXPM形式に変換してみることにしてみた。だが、256色に変換したのでは今までと全く同じになってしまうので、もっと色数を多めにしてみることにした。

しかし、ちゃんと探したわけではないのだが、中途半端に1024色や4096色などに変換できるツールというのは、余り無いようだ。だからこれも自分で作ることにした。元々作ってあった減色プログラムを転用して、任意の色数に変換できるよう拡張しただけだから、これにもさして時間はかからなかった。

著作権の問題があるため、変換した画像を公開するわけにはいかないのだが、しかし、かなり良い結果が得られた。実用的な時間範囲内で開くことができ、なおかつ256色よりもは画質の高い絵が得られた。

俺の今の環境はFire v250（CPU:Ultra SPARC IIIi 1GHz × 2、メモリ:1GB、G/B:XVR-100）で、1280×1024の画像であれば、1024色や2048色程度なら普通に開くことができる。しかし、それ以上となると厳しいようだ。

また、これは絵の内容にも依るのだろうが、俺が背景に設定したい絵では1024色程度であれば画質的には十分で、4096色だと原画とほぼ区別が付かないようになる。だから最終的には2048色に落として背景として使っておくことにした。

しかし、いくら背景にこだわったところで、一文の価値にもなりはしないのだが、まぁいいだろう。

スクロールバー

しばらく前に書いたが、今俺は通信制の大学とか言うものをやっている。これ自体にはそれ程意味はないのだろうが、長期的計画に基づく活動の一つとして取り組んでいる。

大学を卒業するには、スクーリングなる方式での単位をいくつか取らなければならないらしい。そしてそれを取るためには、現地に行って授業を受けてこなければならないらしい。そういうことで、12月中に3日ばかり授業を受けに行くことに決めた。

行くと決めたのはいいが、一体どこに行けばいいのか。簡単な地図は与えられてはいるのだが、当日の朝にそれだけを頼りに現地に赴くのはあまりに危険すぎる。道に迷って遅刻でもしたら目も当てられない。そういうことで、今の内に経路と所要時間・必要経費について調べておこうと思い、実地で行ってみた。まぁ行ってみただけで、そのまま何もしないで帰ってきただけなのだが。

しかし、本題はそのことではない。今ここに書くべき事は、行き帰りの電車の中で考えたことだ。

電車の中で、手持ちの本を読み終えてしまい暇になったから、主筆の今後の開発方針について考えてみた。とりあえず、前に書いたように「主筆マネージャ（仮題）」の作ってみるのも良いだろうし、あるいは、通信基盤を整備するのも良いだろう。だが、それをやるには大分時間がかかりそうだ。

もうそろそろ第17版を公開しようかどうか考えている状況下では、そういった大物に手を付けるほどの気力はない。だが、何となく現状のままで第17版とするのは、何か気が引ける。他に何か手を加えられるところはないだろうか？

そんなことを考えていたら、ふっと思い出した。よく考えてみれば、スクロールバーの挙動が奇妙なまま放置されていたのだ。それを早いうちに対処しなければならない。以前。とりあえずそれっぽく動くようにしておいて、細かいところは後で修正しようと思ってずっとなおし忘れていたのだ。

具体的には、スクロールバーのPageUp(PageLeft)とPageDown(PageRight)の挙動だ。

通常スクロールバーは、ツマミの部分以外の所をクリックすると、クリックした方向に1ページ移動するようになっている。ところが、主筆ではそうはなっていない。

Motifのスクロールバーは、どこにどういう操作が加えられたらどういう動きになるのかを全て自前で記述しなければならない。ところが、そのインターフェースがどうにも理解しづらく、理想通りの動きをさせようとすると、標準エラー出力にエラーメッセージが表示されるのだ。

意味不明なメッセージがでるのは気分が悪いため、うまくいかないところは適当にごまかしてしまってお茶を濁してあるのだ。だから微妙に挙動がおかしいことになっている。

明白なバグをいつまでも放置しておくわけにはいかない。このバグは、第17版を公開するまでには修正するようにしよう。