« January 2000 | Main | March 2000 »

日曜アニメアワー

タイムレンジャーもクウガもどれみも見のがす。ダメダメじゃん。代わりに(っていうか、漠然と子供達の見るTVを見ていたのだが)デジモンアドベンチャーとぐるぐるタウンはなまる君と御存知!月光仮面君を見る。面白い。月光仮面君、しばらく見ないうちにサタンの爪一派は味方になってるし、宇宙人のヒロイン登場しているし。あんがい美味しい展開かも。
そういえば土曜の朝ってのもちょっと変。こないだまでやってた、仙界伝封神演義は、いくら何でも土曜の朝じゃなく、夕方かゴールデンにやるべきでしょ。ジャンプマンガなのに………そんなことやってるから、早々に終わっちゃうんだよ。んで、今やってるモンキーマジック、昔、ビットザキューピットってアニメがありましたが、まだ諦めてなかったんだ、あの手法。見づらいよねえ。ちょっとだけ今回思ったのは、天界が悟空捕まえるために、あからさまに卑怯な手を使う(仲間を人質に取る)って展開はちょっとないんじゃない?これじゃお釈迦様も天界の味方できないって。次回やっと釈迦の手のひら脱出エピソードをやるらしい。展開の遅さがちと気になる所。

| | Comments (5) | TrackBack (0)

今日の落書き

天気: 晴れ
観測場所: 相模原

ロールロックマンDASHまわりの、投稿イラストコーナーに投稿すべく、ロールちゃんを描く。
目が死んでいる………
DASH2楽しみだなあ。世間的にはもはやPS2だけど。

| | Comments (6) | TrackBack (0)

HNS

どうういわけかdi.cgiが、1974年1月1日を返す。つまり時刻取得に思いきり失敗しているらしい。不思議な事にコマンドラインから実行すれば正しい更新時刻を返す。普通ならディレクトリのパーミッション違いだと思うのだが、di.cgiが読もうとしているディレクトリは第三者読み込み及び実行/検索パーミッションがついている。何が悪いんだ。
細かく動作を追ってみると

@a= <$diarydir/$year/d*.hnf>

みたいな行で、@aに何も入っていない事が判明する。ファイル名のワイルドカード展開がこけてるのか?これってperlの普通の使い方だよなあ。コマンドラインから実行するとちゃんと動くんだし。これを試しに、
my $file;
my @a = ();
opendir(DIR, "$diarydir/$year");
while ($file = readdir(DIR)) {
	push (@a, "$diarydir/$year/$file") if $file =~ /\.hnf$/;
}
closedir DIR;
などとすると、ちゃんと動作する。不思議だ。何が起こってるんだ?どうやらclear_cache.cgiでキャッシュクリアされないのもこの辺があやしそう。あ、はい、すいません。MLに入ります。ふむふむ、nobodyがデフォルトですか。ところで、うちの環境、cgiの実行オーナーはよく見たら'www'でした。ううむ、インストール後に手動で行わなければならかった事は
  • .htaccessの、第三者読み込み権限をつける
  • lib以下のすべてのディレクトリに第三者読み込み、及び実行権限をつける
  • lib以下のすべてのperlモジュールに第三者読み込み権限をつける
  • 日記ディレクトリの下の、confに第三者読み込み実行権限をつける
  • conf以下の各txtファイルに第三者読み込み権限をつける
といったあたりです。

| | Comments (1) | TrackBack (0)

ダーウィンの晩年

(http://www.geocities.co.jp/HeartLand-Namiki/3294/science4.html#appendixC)
ダーウィンは死の床で進化論を間違いだったと悔いた、という話は創造論者の主張でよく聞く。もちろん、たとえダーウインが進化論を撤回しても進化論が否定された事にはならないのだが、事実はどうなのかと思い、調べてみた。で、これが答え。
(http://www.ediacara.org/hope.html)


 ダーウィンの死後しばらくして、マサチューセッツ州ノースフィールドの福音伝道者ドワイト・ライマン・ムーディが創設した学校で若者たちの集会があり、ホープ夫人が講演した。死の床にあるダーウィンを自分は見舞ったのだと夫人は主張した。ダーウィンは「ヘブル人への手紙」を読んでいるところで、その地元の日曜学校の生徒たちが庭園の四阿で歌ってくれるよう頼んだという。そして「進化論なんか発表しなければ良かったと、どれほど思っていることか」と告白したそうである。夫人によると彼は言葉を続け、「自分は至福の神々しい予期を熱心に味わっている状態であって、イエス・キリストと御救いのことを人々に語りたいから」聴衆を集めてほしいと夫人に依頼したということである。
 ムーディの激励のもとで、ホープ夫人の話はボストンのウォッチマン・イグザミナー紙に掲載された。物語は広まり、くだんの主張は1955年10月の「リフォーメーション・レビュー」や1957年2月の「スコットランド自由教会月報」にも再掲された。ダーウィンの物語をでっち上げようとする企てはすでに真相を暴かれていたが、それはまずダーウィンの娘ヘンリエッタによるもので、この企てが1922年に蒸し返されたときのことだった。「私は死の最期を看取りました」と彼女は1922年2月23日付のクリスチャン紙に寄稿している。「ホープ夫人は父の死に際に立ち会っていませんし、父を見舞ったこともありません。父はホープ夫人にあったことすらないはずですが、いずれにせよ彼女は父の思想や信条にいささかたりとも影響を及ぼしていないと思います。父は末期の時も、それ以前も自分の科学的知見を決して肯んじませんでした。父の転向の話は米国内で捏造されたものだろうと思いますが……話全体が事実無根です」

(この翻訳は竹岡啓氏によるものです。)

………まあ、こんなとこだと思ったよ。1922年には否定されてるのに、ほとぼりがさめたころに何度も復活するんだね、このての話は。誰か、Talk.Origin.FAQの翻訳とかやらないかしらん。なかなか整理されていて分りやすいと思うけど。

2001年2/28追加Excite Japanの翻訳サービスが結構いけるのでダーウインの話を機械翻訳で見られるようにしてみました。
Exite翻訳

2005年10/9修正
自分で不完全な翻訳をしていた部分を、クトゥルーMLの竹岡啓氏に送っていただいた翻訳に差し替えました。

| | Comments (905) | TrackBack (3)

GIF特許

ううむ、この問題、考え出すときりがないですね。すると結局GIFなんぞ使わずPNGってのも態度としては正しいか。hns作って配付してるチームからしたら、このへんでぶつぶつ「pngなんてつかえねーもんにしやがって、抗議運動様かい?けっ」(いやそんなにヤな言い方はしてないつもりだけど)とか書かれたら怒るかもなあ。僕が配布元だったらやっぱりPNGにしちゃうかもだなあ。

このページでは、ライセンシー全部が載っているわけではないので、よくわからないが、Appleはどうなんだ?これが大問題かも。
問題になったMicrosoftのライセンスだが、あれは要するに企業単位でどんと一括のライセンス料払って、IEなど個々のプロダクトの配布ごとにライセンス料かからないようになっているのだろうな。で、プロダクトそのものに限定されるライセンスではないので、適用範囲を明確にしないとまずいという事情があって、配布プログラムやAPIを使ったサードパーティまで拡大されないという事を表明したのだろう。それは分かる。Microsoftとしてはそこで責任範囲を決めてるわけで。サードパーティは個別にライセンスを取る。これは別に間違ってはいない。ただ、フリーソフトウエアはなんであれ、LZWを使ったGIFを生成する事も表示する事も一切不可能だと言う事だ。ここから、フリーソフトウエアのPNGへの流れが必然的に起こる。いいも悪いもなくGIFは使えないのだから。
してみると、NetscapeがMozillaベースのブラウザを無料で配付する場合は、おそらくMicrosoftのような一括ライセンスの元で行うから問題はないだろうな。ただ、Mozillaそのものの配布と使用という問題は残る。現在もM13/M14を試験的に使う事はライセンス違反になるのか。オープンソースである以上、誰でも自由にダウンロードして試す事ができる。

それはさておき、リーガルなツールで作成した画像そのものを配付する行為は問題ないはず。なぜならUNISYSの特許はLZWの圧縮と展開にかかるものだから。Webサイトライセンスは、オンデマンドで画像を生成するような状況を考えて作られたものであって、対象はやはり画像生成のためのソフトウエアであると思う。
ライセンスは、企業製のブラウザではあまり問題にならないので、GIFを追放する動機にはならない。バックワード・コンパチビリティを考えれば、サポートを急に外すわけにはいかないのだし。ましてや、PNGは単にデータを圧縮するものではなく、リッチな規格であるため、きちんとサポートしようとすれば開発コストが相対的に大きくなるだろう。
GIFは、256色以内であれば劣化無しで利用できる事、アニメーションができること、透過をサポートしているといった特徴がある。一方PNGは、GIFのできることはおおむねできて、その上フルカラー、半透明マスク、デバイス非依存で正確な色再現が可能といった特徴がある。ただし、GIFの最大の弱点であり、それゆえにJPEGがGIFと同じくらいメジャーになった原因であるフルカラーのサポートはまた、ファイルサイズの肥大という効果をもたらす。もちろん、同じ色数ではPNGの方がGIFより圧縮率が高いと言われており、この場合は問題にならないが、24bitカラーなどの画像を可逆圧縮すると、あからさまに大きくなってしまい、JPEGのような非可逆圧縮の圧倒的有利が目立ってしまう。要するにフルカラーではJPEG、256色以下ではGIFで十分、積極的に新しいフォーマットを採用する理由はないわけだ。
ただし、時代の流れとして、PNGが表示可能な環境はゆっくりと増えている。Netscape Communicatorも不完全ではあるが表示できないわけではない。NetscapeがIEに破れて、開発が大幅にスピードダウンした事が不幸の元であると思う。本来ならとっくにPNGの透過もサポートされていたはずではないだろうか。ブラウザがサポートすれば、便利なフォーマットはあっという間に広がる。初期のMosaicではGIFしかインライン表示できなかったが、NetscapeがJPEGをサポートして、一気にフルカラーでかつ軽い、このフォーマットは広まった。おそらく、あと一年もすれば、PNGを表示する上での不具合はおおむね解消されると思う。

| | Comments (1) | TrackBack (1)

Macの話

MacOS9壊れた

なんか近頃調子悪いな−と思って以たら、なんかの拍子に起動しなくなった。CD-ROMから起動するも、メニューバーが表示されたところでストップ。あ、そうだ、MacOS9はDHCPに不具合があって、一部ダイアルアップルータ−との組み合わせで無限ループになっちゃうんだっけ。OSのアップデーかけて解決したつもりになってたけど、それがこけてもとのCD-ROMから起動する時は当然もとの不具合が出るんだよなあ。解決法は本体からイーサケーブルを引っこ抜いた状態で起動する事。 試しにCD-ROMから起動した状態で、いかれた方のSystemファイルをダブルクリックしてみる。通常はフォルダのように開いてキーボードリソース等が表示されるのだが、エラーが出て開かない。どうやらリソースフォークが壊れたみたいだ。多分Systemファイルだけ正常な物と入れ換えれば大丈夫だと思う。で、ふつうインストーラでOSをインストールするわけだが、インストールに必要な空きがないし、時間もかかる(通常15〜30分)ので、どうしようと考えた。「はっ」今CDから立ち上がっているということは、CD-ROMにはまっとうなSystem環境が構築されているわけだ(いや、「はっ」とかそんとき気づいたわけじゃなくて、前から知ってたけどさ)。つまりここからSystemファイルをコピーすれば、秒単位で復旧か!! 甘かったね。そうして再起動かけたら、起動途中で、「オリジナルのCDからでないと起動できません」と出てストップ。なんだよもう。確か昔はそれでも動いたぞ(経験あるんじゃん)。 しょうがないなあと思って、とりあえず主にPhotoshopのスクラッチ用に使っていて、多少は余裕があるディスクにインストールしてから、必要なファイルをもとのシステムフォルダにコピーしようと試みる。とにかくSystemとFinder位があればいいので、MacOS 基本の中をさらにカスタムインストールで最低限に減らしてインストール。おかげで数分で終わった。さて、Systemと、System Resourcesと、Finderをもとのものと入れ替えコピー(壊れてるのはSystemファイルだけみたいだが、一応最低限関連している物は一緒にコピーした方がいいかなあと思って)する。再起動。今度はうまく立ち上がる。さて、MacOS 9から導入された、自動アップデートの問題がある。インストール後、確か2回ほどこいつを使ってアップデートを行っているはずだが、今CDからインストールしたてのSystemに戻してしまったので、アップデートをかましてみると、案の定以前行ったアップデートが必要と出た。「今すぐアップデート」をクリックしてしばし待つ。コンポーネントをダウンロードして、インストールが始まるが、「選択されたコンポーネントのうち、インストールされなかった物があります」とか出てストップ。なにい?? 「このMacintoshについて」を見ると、OSのバージョンはJ1-9.0、アップデートに成功すればJ3-9.0になるはず。だめじゃん。どうやらOSのコンポーネントのいくつかが古く、いくつかが新しい物になっているので、アップデートプログラムが矛盾を起こして停止したらしい。役にたたねー。 こうなったらしょうがない。CD-ROMのインストーラを再び起動して、今度は完全なOSをインストールする。そのうえで、入れ代わっては困る物を注意深く避けながらSystemフォルダの中身をほとんど入れ替える。これでOSのコンポーネントのほとんどは、「古い」ものになった。これでアップデートをかけると、やっとまともに進んだ。 いやー、人間姑息な事をやると、かえって手間が増える見本みたいな事をやってしまった。 あ、ついでにうっかりQuickTime関連の機能拡張一式も古い物になっちゃったので、QuickTime4.1へのアップデートも再度行う必要があった事を追記しておく。ううむ、ちゃんと動くSystemのバックアップは取っておくべきだなあ。 あ、一応MacOSの名誉のために書いておくと、僕は趣味のソフト開発で、頻繁にOSをクラッシュさせているので、通常の環境よりはOSになんらかのダメージをあたえがちである。それとともに、現状のMacOSは、まだまだ堅牢なOSとは言えないので、ユーザープロセスのバグから、OS自体にダメージを与えやすいのも事実。System関連のリソースフォークは開きっぱなしで、アプリケーションから見たリソースと言う物は、まるでオブジェクト階層のように繋がっていて、指定したリソースファイルに目的のモノが見つからなければSystemまでのぼっていって、ユーザープロセスが、適当な書類のリソースをいじるつもりで、うっかりSystemのリソースを書き換える事さえ起こり得る。これをきちんと阻止する機構は存在せず、アプリケーションプログラマの安全設計にまかされている。

マンガApple物語

近頃密かに話題のマンガ。MacFanに連載されている。内容はまあ、タイトル見れば分かる類いのものだが、なんつーか凄い。ジョブズやスカリーといったキャラクターが、微妙にアメコミ風で、でもアメコミにもなりきれないタッチで描かれる。ほとんどのコマの人物が、どっかで見たようなポーズで不自然にセリフを喋っている。おそらく様々な写真資料のポーズをそのまま引き写している絵が多いのだろう。このての人たちはインタビューに答えているか、講演している写真が多いわけで、なんかそういうポーズばっかりなのだ。第四回では、華やかにデビューしたマックがさっぱり売れず、てこ入れ策も裏目に出てもうだめー、ってところから、DTP、HyperCardの成功、そしてNewton登場等で盛りかえして来たというところを扱っている。そして最後のページの直前、どう見ても西新宿っぽい高層ビルの中で、池上遼一描く所の影の総理のごとく、ソファに身体埋めたシルエットの男が登場、「このMacの成功を冷静にじっと見つめている男がいた」のナレーションが入り、男はコーラらしき缶のプルタブを「プシュ」とあけ、グビッとひとくち(ペプシコ−ラ出身のスカリー/Appleを飲むと言う暗示か)。ページをめくると、最終の大ゴマで、暗黒拳法にしかみえない妙なポーズをとる男(背景に稲妻付き)の大アップに、ナレーションで「ウィリアム・ヘンリー・ゲイツIII世! 世界最大のソフト会社マイクロソフト社の会長」「通称ビル・ゲイツである!!」 このコマで確信した。作者はわざとやっている!! このコマのゲイツも、よくみればなにかの発表会で身ぶり手ぶり熱心なデモンストレーションを行っている最中なのだろうと思う絵であり、そういうキャプションがついていればさしておかしくないのだが、前段から、のコーラをのみ、クルっとこちらを振り向いた直後のコマとしてはとてつもなく異常なポーズなんである。「ほあああ〜〜〜」とかいう気合いが聞こえてきそうだ。これはぜひMacユーザー以外の人にも見てほしい。面白すぎる。

| | Comments (0) | TrackBack (0)

日記


HNS

新しいベータ版が出ていたので入れ替える。またパーミッション設定で苦しむ。CGIがnobody権限で動作する環境をデフォルトにしてもらうことはできないだろうか………
ところで、うちの環境だと、Makefile中のコメント(#で始まる)が、どうも行頭にないと誤動作するみたいだ。hnsのMakefileでは、何ケ所かインデントしてコメントつけてる行があるがここでエラーになってしまう。なんかそれも変な話だが、コメント行の頭の空白を削除してインストールできた。

Mozzila

えーと、Mozillaで見ると、この日記、変な所がある。IMGコマンドでアライメントを指定した場合、行揃え設定がクリアされないので、画像の横に付けた文章が短い場合、次の話題が直下についてしまう。つまり、前の話題の画像を回り込んで次の話題が表示されてしまう。という事。うーむ、文章で書くと分かりづらいなあ。<IMG SRC="foo" ARIGN="left">とやったあとで、アライメントを戻さない事に問題があるのは確かなので、なんとか考えてみる。僕が使っているThemeファイルh、デフォルトのjapaneseをベースに改造したjuansというもの。基本的にはjapaneseの記述を踏襲している。そこで、
package HNS::Hnf::Command::NEW;
package HNS::Hnf::Command::LNEW;
package HNS::Hnf::Command::SUB;
package HNS::Hnf::Command::LSUB;
のそれぞれについて、
$EndTemplate = "<br clear='all'></div><!-- end of SUB -->\n";
などと周り込みクリアのタグを埋め込む。clear='all'みたいにシングルクオートで囲むのは個人的には気持ち悪いのだが、qqで囲むとかエスケープするのも面倒なのでこれでいいか。
この方法だと、一つのセクション内に複数の画像を配置する場合に問題が起きるが、とりあえずよしとする。で、ふと気づいたのだが、これまたどういうわけか、うちの環境だとhnsのキャッシュがclear_cache.cgiでクリアされない。これもパーミッション関係かなあ、やだなあ。正常にクリアされたかのような表示をするが、ディレクトリには残っており、Themeの変更もうまく反映されていない。手動で消そうにもパーミッションが違っていてダメ。とりあえず、いままでの日記を改めてアップロードしなおして強制的にキャッシュを再構築させる。
clear_cache.cgiの問題、ひょっとしてcache/2000ディレクトリの読み出しパーミッションかしらん。これ、ユーザーが変更できないし。キャッシュ構築周りでdir作ってパーミッション設定しているあたりを書き換えないと無理かな?あのー、自分のマシンでrootやってる人とかならいいんだろうけど、プロバイダの一ユーザーで、CGIがnobodyで動くような環境でHNS使っている人もそれなりにいると思うんだけど、皆さん全く苦労無しで使えているのでしょうか。うう………なんか僕が間違っているのかなあ。ふと思ったが、Make Installするシェルスクリプト書いて、cgiとしてブラウザから実行すればいいのか?するとnobody権限でインストールされ、nobody権限で実行されて問題は解決?しかしそれだと今度は手動で細かい設定いじる時などもnobody権限で行わないといけなくなったりしそうだ。少なくとも、必要なファイルの書き込みパーミッションをONにするCGIを用意して、変更したいファイルを扱う時はそれを実行してからviなりで変更する必要が出てくるか。ううむ……ねえ、僕やっぱりなんか間違ってる??

GIF問題

ええUNISYSの特許関連のアレです。hns付属のgifの多くが問題ありってんで、pngに変更になりました。しかし、実用的にはまだまだpngの透過も完全にサポートされたブラウザ少なかったりして、いまいちなんですよ。ネスケ4.7で見て回っても、醜い白縁ついてるし。この場合、間抜け臭いけどライセンス受けてないツールで作成したgifを、きちんとライセンス受けたツールでまたgifにコンバートするというのが正しい方法だと思うのです。UNISYSへの抗議と言うのであれば、きちんとそれをうたって行うべきではないかしらん。pngがよいフォーマットである事は認めるにやぶさかでないけど。よいものが必ずしも勝利しないのはこの業界の常識(笑)。ちなみに、この日記で使っている画像は、ほとんど僕作成のモノに取り替えてるので、URL表記用の丸印位しか関係ないけどね(僕が作っているgifはおおむねPhotoshopとGraphicConverterで作っている)。さて、hnsユーザーである僕がUNISYSのライセンス受けたツールでGIF画像作って使う事は抗議運動に打撃を与える唾棄すべき行動でしょうか。資本家に搾取される立場に安住して反革命の走狗となる無知蒙昧なるブタでしょうか。
「ブタか?ブタはブタ小屋へ行け」(ケンシロウ)
UNISYSの特許自体の正統性はさておき、その行使の仕方に問題があるのはまぎれもない事実ある。Windowsでは、IEのレンダリングエンジンが公開されており、これがデフォルトでOSに組み込まれているものだから、これを利用したオルタナティブなブラウザソフトなども存在する。これらは基本的にGIFをなにも特別な事をしなくても表示できるわけであるが(というより、選択的にGIFを表示しない事はできないか、難しいらしい)、マイクロソフトが、「マイクロソフトはUNISYSのライセンスを受けているが、このライセンスは、Windowsの付属ソフトやAPIを使う、サードパーティ製ソフトにまで適用される物ではない」と発表したため大騒ぎ。IEのエンジンを使ったソフトは個別にUNISYSとライセンス交渉しなければならなくなった。で、フリーウエアの場合はなにしろ配付すればその数に応じて作者が持ち出しで金払わなければならないのだ。というわけで、これらのソフトは当然次々公開中止。さらに、Windows2000でファイル選択のためのダイアログ(コモンダイアログでしたっけ?)を使うと、ファイルのプレビューを表示する機能があって、これがgifを表示できてしまう。これもWindowsのAPIを使うのであって、これを使わず自前でファイル選択ダイアログをインプリメントする事は無駄な上にGUIの統一と言う点で問題である。しかし、これを使うと自動的にUNISYS特許に抵触するということになり、ひいては、Windows用ソフトでファイルを選択するものはすべて個別にUNISYSにお金払わなければいけないという事になる。厳密に考えると、ライセンス料金を含めたシェアウエアは可能だが、Windows上でフリーウエアを作成、配付する事は事実上できなくなるというほど、影響の大きい事件なのだ。
さて、この事件、Macユーザーにとっても決して対岸の火事ではない。Appleは実の所いまだこの特許に関する立場を明らかにしていない。ファイル選択ダイアログではデフォルトで画像のプレビューは可能である。まあ、プレビューしないようにするのも可能だが。もともと画像を表示するプログラムはほとんど追加無しでGIFもひょうじできたし、MacOS9ではHTMLレンダリングエンジンのAPIが公開され、アプリケーションから使えるようになった。さてMacからもフリーウエアが消えると言う自体になるのかどうか………
ところで、オープンソースで開発されているMozillaはどうなんだろう。Mozzilla.orgとしてUNISYSにライセンス料を払うのか?それともAOLが?だいたいAOL(Netscape)が主体となっても、ブラウザを無料で配付すれば一本あたりいくらでUNISYSに金払わなければいけないわけで、いっそ普及させたくない代物になってしまうだろう。
けちくさい事言わず、ソフトの代金の何%という形のライセンスにすれば良いのに。そうすればフリーウエアは無料で配付できるし、web上にあるGIFデータがリーガルかどうか悩んだりしなくてすむ。そもそもフリーウエアから金とれるわけがない(金払うなら配布をやめてしまうから)ので、無料のものはライセンスも無料でいいと思うのだが。無茶でしょうか?

| | Comments (12) | TrackBack (0)

アニメ

モンコレ

ぐわあ、昨日の夕方寝ててモンコレナイト見のがした!!ダメダメじゃん。 サークルカット こんなのも用意してるのに(^^;

ナウシカ

ナウシカを見た事ない人を見つけた。いや見た事ない人はいっぱいいると思うけど。惜しかったなあ、ついこないだTVでやってたのに。あ、ちなみに、映画「風の谷のナウシカ」の中で、あの主題歌は一切流れません。主題歌があった事を知ってる人の方が今や少ないかも。とある知人は宮崎アニメのベストは「ラピュタ」だと言います。僕は「魔女宅」かなあ。

| | Comments (0) | TrackBack (0)

Rogueの歴史


もう飽きたと思うが、rogueの話。
rogueとの初めての出会いは、今はなきASCII-NETであった。ちなみに当時のASCII-NETでの僕のIDはASC08452である。それはさておき、初期のASCII-NETでは、login後のプロンプトからrogueと打てばrogueが遊べたのだ。ついでに、なにかとホームディレクトリにcoreを吐いていた(^^;。
ASCII-NETはVAX上の4.2BSDで動いていたと思う。おそらくあれはオリジナル版のrogueではないかと思うのだ。暗い部屋もあった気がするし。で、当時の感想としては、正直言って、「なんだこりゃ」って感じであった。ただ、通信ソフトの画面上で座標を操作してキャラクタが動くと言う事に感心したのは覚えている。当時の事だから、300〜1200bpsの速度で、かなりのたくた動いていたはずだ。
さて、現在フリーで出回っているrogueは、ほとんどTim Stoehrによる「Rogue Clone II」をベースにした物だ。Tim Stoehrは、BSD版のRogue 5.3のソースコードを入手する事ができず、自分でほぼ同じ動作をするゲームを作ってしまったらしい。オリジナルのソースは紛失したとも言われているが、現在その開発史をWeb上で読む事ができる。興味深い事に、初期のMacにRogueを移植したと書かれている。これは「Dungeon of Doom」の事だろうか。オリジナルの開発者達は会社を作り、各種パソコン版のRogueを販売するも、あまり当たらなかったらしい。そして、ここからリンクされているDoom では、PC Rogue のソースを(GIF画像で)見る事ができる(太田さん、ここにありますぜ)。BSD版関係者が作った会社のもので、オリジナル版の直系と言っていいだろう。
もうひとつ、Rogueバリエーションの一つで、UltraRogueというのがある。Rogueをもとに、AT&T/ベル研で開発されたAdvanced Rogue(これは最初のroguelikeゲームだそうな)をもとにして開発されたもの。現在SCOのサイトからソースがダウンロードできる。キャラクターのクラスがあったり、店(ノミの市)があったり、アーティファクトがあったり、このへんで現代のroguelikeゲームの要素が出来上がりつつあるようだ。なかなか興味深い。
ところで、今時のインターネットプロバイダの多くは、telnetによるshellの利用を許してはいないが、winではこれができるし、nethackが遊べたりする。ちょっとASCII-NETを思い出すな。
まあ、winでシェルアカウントを持っていれば、ccやgccが使えるので、自分のホームディレクトリでrogueとか適当にコンパイルして遊ぶ事は可能なのだが、システム側で用意して遊ばせるところがちょっと微笑ましいような気がする。そもそも、電話回線繋いだままnethackふつうやらないよなあ。自分のパソコンでできるし、rogueやnethackをオンラインでやるってのは、スコアを他人と競えると言う楽しみはあるのだが………

| | Comments (156) | TrackBack (1)

MacWorld Expo Tokyo

そろそろなんか発表されてるころだろうか。ううむ、1月のSFで新機種発表がなかったから、今回どーんと発表されると言う噂がたちまくってるけど、世界的な発表があるんだったら、基調講演を生中継しないはずはないと思うのだがどうだろうか。日本発の大規模ストリーミング中継は色々難しいかもしんないけど。
ま、とりあえずこの日記は結果が出てからサーバーに送ろう。
と書いてひと休みしたら、発表されてたみたい。ハードウエアは、まあ順当な所、PowerBookはAirMac対応、FireWire搭載など、iBookはメモリ/HD増量で値段据え置き+グラファイトのスペシャルエディション登場。G4は400〜500にスピードアップ、というか、当初のスペックに戻るって感じ。興味深いのはむしろMacOS Xに添付されるヒラギノ6書体かしらん。OpenType、17000文字搭載で、明朝、ゴシックそれなりに使えそうなバリエーションで揃っている。

| | Comments (0) | TrackBack (0)

Rogue


どうもrogueの動作が遅い。自動移動などで、時々いらつく程度に遅い。これではPPCネイティブ化した意味がない。実際68k版と動作速度が変わらない気がする。PPCProfかましてみたら、かなりの部分DrawTextに食われている。API呼び出しがCPUタイムのほとんどをくっているわけで、これでは68k版(エミュレーション)との差も出ないはずだ。つまりこちらの責任ではなく、MacOSのAPIが遅いのだ。と言いたい所だが、アンチエイリアステキストの描画なんて、どうやったって遅いのは当たり前。無駄にDrawTextを呼ばないようにするべきなわけで、MacCursesのコードを調べると、wrefreshの度に全画面描きなおしてる。まあ動作として間違ってはいないが、無駄だ。特にrogueだけに使うなら、あまりいろんな状況を考えなくても良いので、表示行数分の真偽値フラグ配列を用意し、文字追加などのたびに「この行はアップデートが必要だよ」という印をつけ、wrefreshの時には、その印がついてる行だけ描画するようにする。
真に無駄を省くなら、文字単位でダーティかどうか判断し、最小限の描画で済ませるという方法も考えられるが、DrawTextは小数点幅の文字を制御するため、一文字ずつ描画する場合と、一行描画する場合で幅が若干異なってしまう。行単位のフラグで十分速くなったので、これでよしとするか。
というか、すでにちと速すぎる。これでは移動途中を表示しない設定とあまり変わらない。移動中のキャラクターがジャンプ移動しているように飛び飛びに見える事を考えると、どうやらモニターのリフレッシュレート以上の速度で画面を描き換えているようだ。うちはPowerMac 7600にG3/266を挿しているが、おそらく今どきのマシンはCPUクロックのみならず、バススピードもビデオカードも高速化しているから、どれもこれの倍速いだろう。そうなると、移動途中の表示を切った状態と変わらない事になる。一般的なモニターとビデオカードの組み合わせなら、どれでも60Hz以上のリフレッシュレートだから、60fpsにしておけば、移動中のキャラクターは完全に表示されるはずだ。前回表示してから1/60程度経たないうちは次の描画を行わないようにした方がいいような気がする。60fpsだと、横一杯移動するのに約1.3秒かかる計算になるか、うーん、悩ましい。ま、いいか。ウエイト入れとこう。ここに置いておくので、Macユーザーでrogueやりたいひとはもって行って下さい。

| | Comments (0) | TrackBack (1)

Rogue


ソースをメッセージ分離版rogueに変更。これでMacでもLeafRogueができたりするわけさ。ところで、メッセージ分離版は起動時にコマンドラインでデータファイルを指定する事になっているが、当然Macにはコマンドラインがないので、他の方法を取らなければならない。最初はrogue本体と同じディレクトリにデフォルトのメッセージファイルを置いておいて、とりあえずそれを読ませ、初期設定ダイアログで変更可能にするというインターフェースで作ってみたが、これだと、もしアプリケーションだけを別の場所に移動したりすると起動すらできないことになる。また、初期設定ファイルにメッセージファイルのエイリアスを保存させるようにしたので、間違って関係ないテキストファイルを指定してしまった場合、エラーで落ちて、初期設定ファイルを削除しないと二度と動かないということになる。色々悩んだ挙げ句、デフォルトのメッセージファイルをアプリケーションのリソースフォークに格納して、指定したメッセージファイルに問題があったらデフォルトメッセージを読み込んで起動するように改造。
前に書いたセーブファイルのIDの件、Macの機能で実現は可能なのだが、問題はボリュームを超えての「ファイルの移動」ができないこと、およびHFS系のファイルシステムでないとファイルIDが有効でないということ。最初に保存したディスクと別のボリュームにセーブファイルを動かすと、コピーを作った事になり、そのファイルから起動できなくなってしまう(同じボリューム内での移動はOK)。セーブファイルの厳しさをそこまでつくりこまなくてもいいと思い、やはりやめることにする。ところで、UNIXでは例えばmvコマンドでボリューム跨いでもきちんと移動になるが、この際、rogueのセーブファイルはきちんと同一のファイルとして扱われるのだろうか。確かUNIX用の処理では、inode番号を使っていたが。

調子にのって、rogueをCarbonアプリケーションにしてみる。いろいろ書き換えなければならない所も多いが、なんとか動作する。しかし、どうも根本的な問題がある。
CarbonはMacOS APIをMacOS Xで使えるようにするものだ。これに添ってアプリケーションを作れば、MacOS Xのメモリ保護、プリエンプティブマルチタスクなどの恩恵を受ける事ができる。おまけに、MacOSでもMacOS Xでも一つのバイナリで動作するアプリケーションができる。ただし、CarbonがサポートするのはMacOS APIのみであり、ANSI Cの標準ライブラリなどは含まれない。もともとMacOS X にはBSD互換レイヤーがあり、ネイティブに標準ライブラリが使用できる。MacOSの場合には、OSにStdCLibという標準ライブラリが組み込まれていて、これに動的にリンクすることで、不完全ながら標準関数が使える。当然、rogueみたいな移植モノではStdCLibに依存した移植を行うわけで、アプリケーションからStdCLibへのリンクは外せない。
MacOSでCarbonアプリケーションを開発する時は、CarbonLibを動的にリンクする。この共有ライブラリは、MacOS上でCarbonアプリケーションを動かすためのモノだが、これを使う場合、クラシックなMacOS アプリケーションを作る時にリンクする基本的な共有ライブラリ(InterfaceLibなど)の機能をCarbonLibが内蔵しているので、それらはリンクせずCarbonLibだけをリンクする事になる。この段階で、MacOS XのBSD/POSIX互換レイヤーを呼び出すライブラリをリンクする事はできない。もし、そのためのstubファイルが用意されていても、それではMacOS上では実行できないOS X専用バイナリになってしまうだろう。可能なのはStdCLibをリンクする事だが、これはMacOS組み込みなので、MacOS Xでは使用できない。おそらく起動しようとすれば共有ライブラリのロードに失敗してエラーを出すだろう。
バイナリ互換を保ちながらMacOS/MacOS Xでの標準ライブラリを使用するには、共有ライブラリそのものであるStdCLibをアプリケーションと同じフォルダに入れて、一緒に配付するという方法が考えられる。現在、静的ライブラリのStdCLibは配付されておらず、共有ライブラリ版のみであるため、通常のPPCLinkでアプリケーションに直接組み込む事はできないが、Carbon環境がClassicと同様、アプリケーション直下などの共有ライブラリを自動的にサーチして使用する仕組みであるなら、これは動作する可能性が高い。アプリケーションとライブラリという、分割ファイルになるのが気に入らないが、これはOS X御得意のパッケージにしてしまうという手もある。
もっとも、このStdCLib共有ライブラリについては、Carbon互換ではないので使うなとドキュメントされているという凄い問題があるのだが………

| | Comments (0) | TrackBack (0)

Rogue


Mac版jrogueのPPCネイティブ & カラー化に取り組んでいる。
jrogue
これこれ、この色、昔PC98版をやったときの色だよ。うふふ。ついでにMacOS 9のマルチユーザーに対応して、ログイン名をきちんと取り出すようにする。他のユーザーのセーブファイルではプレイできないようにするのだ。Rogueって、セーブファイルの扱い厳しいよね。セーブから再開したら、そのファイルは自動的に消えてしまうし、他人のファイルでは遊べない、さらに、ファイルをバックアップするとダメ。データに改造加えてもダメ。ただ、今回は、昔使っていたThink C付属のUNIX互換ライブラリが使えないので、ファイルIDを判断する部分を無効にしてしまった。というわけで、今の状態ではセーブファイルをコピーして、何度でもやりなおしができてしまう。これ、どうしようかなあ。きちんと自分でそのへん判断する関数作るべきか?
しかし、これやりだすと、セーブファイルを置く場所も問題になるなあ。制限付ユーザーでは、アプリケーションのあるフォルダでは保存できないかもしれないから、デフォルトでユーザーの書類フォルダにリダイレクトするようにすべきか?fopen系の関数にこれやらすのは結構面倒。MacOS 9に含まれるStdClLibではFSSpec使う代替関数が用意されてるけど、MacOS 9限定にするとか、StdCLibのshLibつけるとかはしたくないし……

さて、フォントメニューは前からあるけど、簡単にやっているので、インストールされてるフォント全部表示してしまう。本来等幅フォントのみにすべきだと思うけど、FONDリソースのフラグで等幅かどうかチェックすると、通常の日本語等幅フォントはほぼすべて等幅でないというフラグになっている。1Byte部分と2Byte部分の幅が違うからかしらん。で、CharWidthで' 'と'W'の幅をチェックして同じだったら等幅とみなすという処理を加えたら、フォントメニュー構築にむちゃくちゃ時間かかっちゃうので断念。
あと、ゲームのオプション設定をMacっぽくGUIで行って、初期設定フォルダに置くようにしないとなあ。この部分はあきらかに面倒なので前にやったときも放置していた部分。
ところで、カラーの黒地白文字で12Pt程度だと、モニター解像度が高い場合、非常にみにくい。しかし、24Pt位にして、アピアランスコントロールパネルで、なめらかな文字で表示する設定にすると、なかなかいいかんじである。小さいサイズの時と、大きいサイズの時では、きれいに見えるフォントも変わってくる。昔の画面の雰囲気を味わうためにはビットマップのASLFont+を拡大して使うのもわるくないが、20ポイントあたりからきちんとアウトラインをきれいにラスタライズするようになった「等幅ゴシック」も捨てがたい。W7位の等幅明朝体があれば、それもいいと思うが、うちにあるフォントでは、等幅明朝とリュウミンライト−KL−等幅といった、細い書体しかないので、ちと見づらい。ただし、これらの書体を使う場合、ゲームオーバー時の墓石表示が化ける(\をバックスラッシュとして表示できないため)。もちろん\が円記号なのはJISのコードでは正しいので、ASLFont+eのように、コードの左半分をASCII互換にしてあるフォントを使うというのはいかにも対処療法っぽくて気持ちが悪い。このゲームの中では、基本的にバックスラッシュが表示される事を期待して使われているので、表示部分にフックして、書体を一時的に、勝手に切り替えるべきか……っつーか、それ、まともにやったら表示遅くなって多分だめ。QuickDrawの低レベルフックを使う手はあるけど、そこまでやると複雑になるしなあ。
と思ったら、実はMacOS用の日本語フォントでは、0x80にバックスラッシュが割り当てられている事を発見!、これならもとのメッセージの文字列リテラルを書き換えるだけでOK、スピードは一切犠牲にならない。0x5Cにバックスラッシュを割り当ててるASLFont+eの場合、0x80に円記号を置いているのでこれを使われるとやはり化けてしまうが、この場合は、eなしのASLFontが使えるので問題は少ないと思う。

| | Comments (0) | TrackBack (0)

Mozilla

ううむ、Mozillaで見ると、hnsで画像を貼付けた部分のレイアウトが崩れる。これはMozillaが厳密なHTML解釈をするということかしらん?

| | Comments (0) | TrackBack (0)

デジカメ


おお、ついに出るのか、スーパーCCDハニカム。300万画素時代がようやく幕をあけようかと言う時に、一気に432万画素。すごいぜスーパーCCDハニカム。要するに画素を八角形にして蜂の巣状に並べたわけなんだけど、これで解像度、感度ともに大幅アップってところがコロンブスの卵なんだよね。発表されたとたん、他社の開発部門は軒並み「やられた」と思ったんじゃなかろうか。値段は12万8千円とちょっと高めだが、ニコンの新製品が同じくらいの値段で予告されてるから、画素数で考えると御得感がある。デジカメの値段、全体にスペック競争とともに上がってるしね。というか、この技術を使って、100万〜200万画素クラスの、むちゃくちゃ安いカメラ作ってくれない物か。
とりあえず、コンパクトタイプのFinePix4700Zを出して、次は一眼レフタイプの610万画素だそうだ。こちらは多分プロ用の価格がつくと思うので、今はいいや。でも、こっちは記憶メディアにこれも去年話題になったIBM製「500円玉サイズハードディスク」を使えるところがポイント。さすがに610万画素となると、スマートメディアでは厳しくなってくるよね。432万画素でも、64MBで77枚と景気よく表現されてるが、つまり8MBだと10枚入るかどうかってとこだね。

| | Comments (5) | TrackBack (0)

« January 2000 | Main | March 2000 »