OSTRACISM CO.
■ 開発日記 巻之十五

OSTRA / Takeshi Yoneki

Subject: 16 color ?
Date: Tue, 05 Nov 1996 18:41:37 +0900
From: Takeshi Yoneki

>>
>>AcerのVRAMが届いたから、1024*768で16色になりました(^^)。
>>

VRAM増やして16色? 16 bit colorでそ。^o^

Windows向けのtelnetだが、NT 4.0のtelnetはControl-Spaceがきちんと使える。
やっぱWindows95版のバグみたいね。
しかもNT 4.0のtelnetは設定が化けるのを除けばちゃんとWindows95でも動く!
たいしたもんだ。

Takeshi Yoneki

Subject: Today 19:00 To Horigon
Date: Wed, 06 Nov 1996 12:54:45 +0900
From: Takeshi Yoneki

なんでもいいが、ともかく今日19時に行くぞ。

例の本はなかなか面白い。まだ1冊目の途中だが無茶苦茶経歴が怪しいやつな
のね、著者は。
翻訳がお笑いな部分がたまにある。
tarを「ター」と書いてるな。わはははは。
UNIXのポータビリティを「携帯性」なんて訳してる。どはははははは。これは
「移植性」のことだぞ。

Takeshi Yoneki

注:
 例の本とは「テイクダウン」のことです。著者が本文中でハッカーという言葉の誤用に抗議する文を入れていますが、翻訳書の表紙には「若き天才日本人学者VS超大物ハッカー」とあります。このキャッチコピー考えた人は読んでませんね。

Subject: fumufumu
Date: Fri, 08 Nov 1996 10:44:30 +0900
From: Takeshi Yoneki

上司と合わないとねぇ。

私の場合は上には社長しかいなかったので、選択の余地は会社を辞めるしかな
かったわけだし、実際にそうしたんだしね。
昼休みに電灯を消すってのはただの節約イメージだと思ったぞ。バカバカしい。
マシンも真面目に揃ってなかったしね。なかなか問題は多かった。

現在はSONY並とまではいかないにせよメインとサブのマシンが用意されている
ので、開発環境自体は良くなった。あ、1台はペンティアムだからSONYにいた
頃よりは良くなってるな。メール環境はFreeBSDにWin95からtelnetで入って
muleでmh-eだ。ほぼいっしょだが、マシンがCISC NEWSより「確実に」速いっ
てとこが違うかな(^^)。メインマシンはNT 4.0βを使っています。

タイムカードやら休憩時間などいろいろと問題に思っていたのだけど、ソフト
ヴィジョンにはタイムカードはない。休息時間も勝手にバラバラにとっ
ている。それがソフトハウスとしてはあたりまえな気がするんだけど、変に
理創は意味もなくガチガチにしているんだな、こりゃ。給料高けりゃ文句もい
わないけどね。

ソフトヴィジョンでの人間関係はこれからこれから。

Takeshi Yoneki

Subject: Photo
Date: Tue, 12 Nov 1996 19:28:39 +0900
From: Takeshi Yoneki

あー、あー、業務連絡。
カボチャの写真忘れないでね(^^)。

Takeshi Yoneki

Subject: Re^2: I'm in SoftVision
Date: Thu, 14 Nov 1996 17:12:54 +0900
From: Takeshi Yoneki

>>おひさしぶーりーねー、まっちゃんですよ。
>>ヨネッキーさん元気?おねーちゃんも元気?
>>そのソフトなんちゃらっていう会社は何処にあるの?
>>あと、エッチなホームページアドレス知ってたら押しえてねぇ。

 どこにあるって、住所までつけたんだがなぁ。
 総武線で秋葉原から千葉寄りに1つのところにある浅草橋駅が最寄り。秋葉
原が近いってのがいいねぇ。
 ここの会社のホームページは
http://www.mmjp.or.jp/softvision/
なんだけど、見てもつまんないとは思うぞ。私が応募した募集案内もある。
村山さんがウチに遊びに来る計画を立ててるんで興味があったら連絡するとい
い。

Takeshi Yoneki

Subject: Re: SEIWA
Date: Tue, 26 Nov 1996 17:16:29 +0900
From: Takeshi Yoneki

>>誠和が倒産したそうだ。
>>あそこもツールばかりで、大きな商品がなかったからね...。

倒産してもホームページがまだ残ってる悲しさ。

Takeshi Yoneki

Subject: Re^32: Hello!!
Date: Wed, 27 Nov 1996 12:42:47 +0900
From: Takeshi Yoneki

>> |(ウワサ話)
>> |誠和の商品はメディアヴィジョンが引き継ぐそうな
>>
>>うう。。誠和の商品ってどんなの??

ええと、これは私宛てだとおもう。あと誠和システムズを知ってるのは新田さ
んくらいだな。
RAM Doubler(ラムダブラー)って聞いたことあるんじゃないかな。その日本
での代理店をやってたところ。あとはORGAI(鴎外)という名前のワープロを
出してた。これも開発元はスターなんとかという別会社。ORGAIの次のバージョ
ンを扱う代理店を探してたそうだけど、誠和ではもうダメと判断してたみたい
だ(これはお姉ちゃん情報、お姉ちゃんの会社にも話が来たそうな)。
その昔、Macintosh Plusに初めて付けた40MByte HDDが誠和システムズの扱っ
てた製品だった。IIcxに取り付けたDayStarの030-50MHzのアクセラレータも誠
和システムズを通していた。誠和システムズではIIcxのMPUを外す技術がない
もんだから、IIcxは単身米国までいってきたのでした。

Takeshi Yoneki

Subject: Re: Gohan!
Date: Thu, 28 Nov 1996 17:59:27 +0900
From: Takeshi Yoneki

>>
>>今日のご飯はブリです。塩焼きがいい? それともイタリア風に焼こうか?
>>

ぶりぶりぶぶりぶぶりぶり
ぶるぶりぶぶぶりぶりぶぶぶ
ぶっぶくぶりぶりぶっぶくぶ〜
ぶりぶりっ!

伊太利亜風って何かな? 縛り首したり折檻したり虐殺したりするのかなぁ。

Takeshi Yoneki

Subject: Re: HyperCraft
Date: Mon, 02 Dec 1996 17:36:44 +0900
From: Takeshi Yoneki

>>ハイパークラフトが今朝から全部閉店だそうだ。
>>こっちは売掛金と買掛金を調べてる。
>>今年はたいへんだぁ

閉店ってつぶれたってことかな? まじ。

Takeshi Yoneki

Subject: Re^64: Hello!!
Date: Tue, 03 Dec 1996 10:05:43 +0900
From: Takeshi Yoneki

>>
>>ってとこですか? 他に持っていくもの、ありますか?
>>時間はいかがいたしましょうか??
>>中村橋でしたっけ? 駅からは近いのですよね??
>>でも中村橋までがみんな遠いのかもしれない。
>>

「中村橋」でなく「都立家政」だから間違えないでね。鉄道は「西武新宿線」
だからね、「西武池袋線」ではないよ。私の行動半径の中心は新宿ですので。

新田さんはそろそろ引越しかな。

誠和システムズにつづいてハイパークラフトまで潰れちゃって、マック業界の
人たちには悲しい年の瀬だわさ。

Takeshi Yoneki

Subject: SEIWA
Date: Tue, 03 Dec 1996 10:56:41 +0900
From: Takeshi Yoneki

誠和の倒産はなんかしだいにすごい話になっている。犯罪すれすれなのではな
く犯罪そのものの可能性がでてきてるね。

http://www.softbank.co.jp/macweek/9612/n1202_seiwa.html

Takeshi Yoneki

Subject: enkai at Yonecky
Date: Mon, 09 Dec 1996 11:41:20 +0900
From: Takeshi Yoneki

>> 主に村山さん

そろそろ宴会の人数の決定・確認をお願いします。

>> その他

セガ・サターンを持っている人は使い慣れたコントローラを持ち込もう。
マルチタップは1つなので合計7個つながります。ウチには4つコントローラ
があるのであと3つまでです。ま、実際にゲームとして成り立つのは4人だろ
うからいらないんだけど、1つはジョイスティックなんでちとうるさい。
あ、もちろんボンバーマンの話です。

Takeshi Yoneki

Subject: Re^2: enkai at Yonecky
Date: Mon, 09 Dec 1996 12:15:17 +0900
From: Takeshi Yoneki

>> サターン用のパッド x 2
>> プレイステーション
>> PS用対戦ケーブル (TVは2台ある?)
>> RRR
>> あと最近買ったソフトのいくつか

対戦ケーブル使えるゲームあったかなぁ。ウチRRRないんだよなぁ。DOOMとか
あったら対戦も面白いだろうけど、これもPC/AT向けしか持ってないし。メタ
ルジャケットは対戦でも面白くなさそうだし。普通のリッジレーサーでは対戦
はないよね。RRR買うのが一番手っ取りはやいな(ひとに頼んであるんだが、
いっこうに来ない)。買うならDOOMでもいいのか。

PS持ち込むのは確かに覚悟がいるね。考えた方がいいよ。

Takeshi Yoneki

>>特にこの方法で会議室の一覧を作成すると、
>>實篤が順番に各会議室を開いていく
>>処理を行いますので、余計に遅くなります。
>>この処理がなくなるだけでもかなり
>>早くなると思います(メッセージのタイトル一覧は結構早いです)。

 遅いでしょうね。初期の實篤が当時の茄子Rに比べ高速に起動できるようになったあたりの実装と関係があります。實篤は負荷を起動時でなく会議室移動時にかけるように作られています。そのためforumを1つ決めてroomを番号でまわすと如実に遅くなります。
 roomを番号で決定するということはroomオブジェクトが決定しているという意味になりますので、そのroomのプロパティを完成させなくてはいけません。roomのnameプロパティ等会議室関連リソースの情報はforumオブジェクトが決定した時点で全部読み込まれているのですが、message countプロパティが非決定のままになっています。message countプロパティはmessageオブジェクトが決定しないと決まらない(ようするにmessageオブジェクトの数という内部的な変数そのものだから)ので発言インデックスリソース情報を読み込んでmessageオブジェクトを一揃い決定しています。
 使わないmessage countプロパティのために無駄に遅くなっているわけですので、ここらへんに「どうにかする」余地はありそうです。現在は会議室関連リソースに入っている発言数を信頼せず使っていないのですが、使うようにすべきかもしれません。また、room等にもselectメソッドを用意して、発言インデックスリソース情報を明示的に読み込むことも必要かなとも思います。現在は強制的に読み込んでいます。
 メッセージのタイトル一覧はroom決定時に発言インデックスリソース情報が既に読み込まれているので、AppleScriptのオーバーヘッドがあるにせよファイルアクセスがないぶんかなり高速なんだろうと思います。

>> set myList to title of every message of theRoom

 これが通るようにするのが一番良いのでしょうね。まだリストの実装のしかたは知らないのですが(^^;)。

1996.12.09

 伝聞だよ。
 某ショップから販売されていた、NIFTY Serveに登録されているフリーウエア・シェアウエアを収録してあるCD-ROMがあるのだが(Mac版とWindows版があり、Mac版には私の作品も収録されている)、ある日のこと某FWIN系の経営をしている某会社からクレームの連絡が入ったそうな。
 某ショップはきちんとNIFTY Serveとやりとりして企画を進めたので、弁護士を立てて詳しく電話で話を聞くとどうやら「アガリを分けろ」ということだったそうだ。
 私の作品の収録でFMACPROが何かを某ショップに請求したという話は聞いてないし、請求したとも思えない。ライブラリは単なる場であって「そこ」に作品があることにはそんなに意味があることではない。転載は対象がBBSでなくCD-ROMでも断ったことはほとんどなく(毎日コミュニケーションズの雑誌は除く)、最近はあまりタイムラグなしでベクターデザインのサイトに登録されていたりする。
 その某FWIN系がどういう権利の主張でアガリをカスめようとしたかは知らないが、もうそれじゃヤクザとどこが違うのか分からない。中村SHOWさんの書いた某FWIN系批判は半分眉唾だなぁと思っていたが、全く関係ないルートからこんな話がでてくるってことは、多くが事実なんだろうなぁ。
 「どういう権利の主張で」ってのをちょっと考えてみると、NIFTY Serveにおける「会議室での発言」にはNIFTY Serveに編集著作権があるそうだ。雑誌と同じように考えているそうな。だから、内容はいいとしても、NIFTY Serveに登録されている形態の発言のままではヨソに持っていけない。権利は一定パターンのヘッダ部分にあるからだ。
 だがライブラリに登録されているフリーウエア・シェアウエアについて考えると、この権利はあまり役に立たない。普通転載はダウンロード対象のアーカイブになるわけだから、NIFTY Serveの関わる余地は余りない。ましてやたかがフォーラムのシスオペの関わる余地なんて全くない。フォーラムのシスオペのできることは「ライブラリに登録しないこと」と「ライブラリの登録を削除すること」だけであり、フリーウエア・シェアウエアの作者のみが転載の可否および金品の請求を主張できる。金品の請求を主張といっても「サンプルCD-ROMください」って程度が普通なんだけどね。
 某ショップはきちんと各作品の作者に転載(収録)の許可を取ったわけだし(ウチにもメールのやりとりがありました)、NIFTY Serveという「名前」を出すことに関してもNIFTY Serveにきちんと話を通してたわけだから、その某FWIN系っていったい何考えてんだってことになるねぇ。ちなみに某FWIN系のキックバック(フォーラム経営者に払われる運営費で、課金に比例する)は億の単位だそうです。

1996.12.12

Subject: To Horigon From Yoneki
Date: Mon, 16 Dec 1996 11:21:07 +0900
From: Takeshi Yoneki

>>ほりごんへ

このクリスマス前の超混雑時期に、何の因果かほりけんへのプレゼントを買う
はめになった私であった。
新宿東口のヨドバシカメラはやたら混雑しており、PSもSSも飛ぶように売
れていた。N64は全く売れてない。ほとんど扱いは3DOと一緒。
そんなわけで
PS+対戦ケーブル+DOOM+クロックワークスを手に入れてきた。年末に取り
に来るように。
DOOMは対戦するには両方のマシンにソフトを入れなくてはいけないので2つ買っ
てきた。1つは私の分だぞ。
DOOMの移植性はかなり良い。ほぼPC互換機向けと同じ。いくらか簡略化されて
いる部分も目立つけど、マップは同じと考えてよい。家庭用ゲーム機ではCPU
は高速にできてもディスプレイの問題があるから単純にハイレゾ化できないん
だよね。
操作性はパッドを使うんでむしろ向上している。私はキーボードでゲームする
のは結局あんまり慣れていない。
しかし、同じ面の同じ場所で死んでしまうんだよなぁ。実力ないよな。

そんなわけで大晦日はDOOMを使ったPSのネットワーク接続の実験だ。ゲーム
で遊ぶんじゃないぞ、あくまで実験だからな、実験、実験。(^o^)

しかし、同じゲームがでてる場合、PSよりはSSの方が安いねぇ。

Takeshi Yoneki

Subject: Re: 8MB SIMM x2
Date: Wed, 18 Dec 1996 16:30:27 +0900
From: Takeshi Yoneki

>>
>>会社の赤塚さんが8MB SIMMが2枚余ってるから、5,000円くらいで売れるかなぁと言っている。サーバは今24MBでしょ? Linuxのを5,000円で32MBにして、Windowsのを40MBにする?
>>
>>SIMMは、もうマルさんからもらったんだっけ? よく覚えてない。

monadoは16+16+4+4=40MByte
alephは8+8+4+4=20MByte
増やすとすればalephを8*4で32MByteにすることになるかな。
マルさんからはまだ貰ってなかったはず、彼がメモリを買ったかどうかは知ら
ない。フライトシミュレータとジョイスティックなら買ったようだが。(^^;)

TwoTop価格で8MByte 60nsが\4,700となっている。\5000で2枚だとだいたい市
販の半額ってことかな。中古だともっと安いかもしれない。
Linuxサーバにメモリが足りないとは思ってないけどあればあるほど良い。
判断は任せる。

Takeshi Yoneki

Subject: FEP Keyboard Configration
Date: Fri, 20 Dec 1996 13:01:04 +0900
From: Takeshi Yoneki

Windows NT4.0では、SwapScanがないうえに、IMEのキーボードコンフィグレー
ションがレジストリに入ってしまったため、非常に扱いにくくなってるよね。
普段はVJE相当で使ってるんだけど、ATOK相当に変更すると、変換キーが日本
語モードのまま英文字直接入力とローマ字かな入力モードのトグルになると気
が付いた。それでレジストリをいじることにした。
レジストリは
"HKEY_USERS\.DEFAULT\Software\Microsoft\Ime\msime97\StyleList\VJE"

"key"
で、だいたい2KByte強あり、バイナリになっている。でも、基本的には
msime97.iniに近い。
ATOKの変換と無変換の値でVJEの変換と無変換を設定すると、変換と無変換は
ATOK相当と同じ動きをするようになった。
これで変換キーが入力モードトグルとして使える。

Takeshi Yoneki

 こんばんは。レポートありがとうございます。

>>「褌」を縦書き可能にしていただけませんか

 が主題ですので、これについて書きたいと思います。まず最初に期待を持たせてはいけませんのではっきり書きますと、縦書きの予定は全くありません。また、予定することもないと思います。
 Wzが縦書きを実装しているとは知りませんでした。1.0がコケまくった苦い経験からWindows(仕事)ではずっと秀丸を使っていますが、かなり意欲的な製品のようですね。
 私は本来文書(文章)作成にはエディタではなくワープロを使うべきだという考えを持っています。ワープロが特に長文の作成の役に立ちにくくなってきたのはこの数年のことです。初期のEGWordのような軽快さを持った使いやすいワープロが存在すれば私もエディタを作ったりしなかったでしょう。
 私にとってもエディタというのは妥協の産物です。エディタでの文書は最終生成物ではなく、入力のストレスを軽減するための方便にすぎません。特に私が現役で使っているマックは1989年の製品ですのでかなり速度的にきびしいものです(さすがに改造は入っています)。
 今年のWorld PC ExpoのUMAXブースで180MHzのPPC604マック互換機を触りましたが、最近の重いEGWordが往年の軽さで動作していました。
 結局、長文作成に耐え得る高機能環境を欲した場合、高速マシンを使うのが近道です。ORGAIは現在誠和システムズの問題で宙ぶらりんになっていますが、近いうちに別の代理店から扱われるようになるでしょう。素性はよい製品ですので、頑張って欲しいと思っています。
 縦書きは、高速マシンならまだしも、現在の私の環境で実現するにはあまりにも高負荷の機能となります。というのはマックには縦書きをサポートする機能がないからです。QuickDrawGXでは縦書きもサポートされるという噂を聞いたことがありますが、そもそもGXは高速マシン環境が前提です。基本的に負荷が高いのです。
 プログラミングには2つの立場があります。ひとつはパワーをひたすら消費するやりかたで機能を実現して、実用性はマシンの高速化を待つという豪勢な立場です。もうひとつは、マシンの性能に合わせチューニングされた機能を選んで実現する貧乏な立場です。
 どちらの立場も重要です。近年PC-UNIXが流行していますが、昔は重く感じたX-Windowが高速に動く程度にPCが高速化したということが流行の一因です。昔は資源をひたすら食うという意味でご法度だったEmacsも軽く動いてしまいます。
 しかし、マシンの高速性におんぶにだっこの「本来もっと速くてもいいのになぁ」というプロダクトも多いことは事実です(MS-WordとかMacWORDとか)。
 ようはバランスの問題なのですが、HUNDOSHI-EDITは1989年のマシンにチューニングされた比較的古めかしいプロダクトとして終ることになるでしょう。その先は別プロダクトになると思います。

>>現在 GripGrop は1バイト文字と2バイト文字を同一視
>>する機能がありません

 GripGropの機能の充実はこれからの課題です。
 GripGropを開発するまでは私も複数ファイルの検索にEdit7を使っていました。しかし、CodeWarriorの複数ファイル検索に触れ、Edit7はスピードが遅すぎると気づきました。GripGropの最初の課題は、とにかく高速な検索でした。Edit7の4〜5倍程度は高速になっているはずです。高機能な検索の重さがわかると思います。
 GripGropは合計数十メガバイトある数百個のファイルを検索対象にする私自身の要求を満たすために作られました。
 まあ、ともかく高機能化はこれからの課題です。スピードとの両立はかなり難しそうですね。

>>フォルダ指定と同時に検索が起
>>動する方が「直感的」

 「フォルダ指定」というのはダイアログでの指定でしょうか? だとすると「ファインダ上でのフォルダのドラッグ&ドロップ」とは無関係の話ですよね。このあたりがちょっとわかりません。

 まあ、ともかくご要望には添えそうにありません。他のツールやアプリを高速なマシンで活用することを勧めます。

1996.12.20

 マックユーザにとって苦悩の年末が誠和システムズの倒産と不穏な噂話で始まり、ハイパークラフトの倒産、AppleとBeの接近と続いたが、筒井康隆大先生の執筆再開とAppleによるNeXT買収は思いもよらぬクリスマスプレゼントだった。え? 筒井康隆とマックは関係ないって? ま、一応アップルのCMキャラクタになったくらいはマックユーザですから(^^;)。
 NeXTを初めて見たとき、マックのウィンドウが古臭く見えたものだった。「いつかはNeXT」は憧れのマシンに対する賛辞以外のなにものでもない。そういえばそもそもマックを買った直後から「いつかはNeXT」って思ってたんだよなぁ。
 マックのウィンドウの見た目を少しでもNeXTに近づけようとするINITもあった。今Copland風にするExtensionが流行ってるのと同じようにだ。結局Coplandは60年代に予測された30年後の世界と同じように、来なかった未来となってしまった。
 AT互換機で動かしているLinuxにもAfterStepというウィンドウマネージャを入れている。一応NeXTライクらしいのだが、多少ダサいのはしかたあるまい。
 マックとNeXTの融合は今まで夢見てきたことではあるけれど、いざ現実にはどうなるかは不安だ。Objective Cが、かつてのPascalのように開発の共通言語になるのであろうか? 独自にObject拡張したPascalのように、既存のC++を拡張してObjective C++のような言語を用意するのであろうか? 開発言語の流行としては孤立するのは得策ではない。ま、Metrowerksがなんとかしてくれるでそ。
 ともかく1ユーザとして、1ソフト開発者として、AppleによるNeXT買収を歓迎する。ジョブスのAppleへの帰還を歓迎する。
 これでBeBoxを買おうという意識はほぼなくなった。安心してPowerMacないしマック互換機を買うことができる。
 期待してるよ。

1996.12.24

Subject: Re: Color printer
Date: Thu, 26 Dec 1996 13:00:09 +0900
From: Takeshi Yoneki

 なるたけ早く帰って洗い物するように、ま、一応頭に入れてっと。

>>キヤノンのBJC-420JかアルプスのMD2010かMD2300がいいなぁと思ってるけど、アルプスのはMacとWindowsが別々の品番になってる。キヤノンのは、マッキントッシュにつなぐときはシリパラ変換ケーブルが必要だそうだ。

 どうやらアルプス電気MD-2300の方はとんでもなく奇麗みたいだね。熱制御
での連続階調表現だそうな。これまでのカラープリンタが全部旧世代品になる
だろうね。
 キヤノンBJC-420Jも奇麗だそうだが、薄めのインクを重ね合わせるそうで、
階調表現という点ではアルプスに負けるかもしれない。

 問題はWindowsとマックでの共用だ。アルプス電気MD-2300はJがWindowsのプ
リンタポート、Sがマックの「SCSI」だ。どう考えても共用は無理。
 キヤノンはマックとの接続に変換ケーブルが必要と書いてあるという程度に
はWindowsに問題無く接続できるはずだ。

 品質だとMD-2300で、接続性だとBJC-420Jだなぁ。
 どのみちWindowsで使うことはないとは思うけどね。

Takeshi Yoneki

Subject: Epson
Date: Thu, 26 Dec 1996 13:48:46 +0900
From: Takeshi Yoneki

 日経マック1月号ではエプソンのPM-700C(最新型カラリオ)の評価が高い。
 印刷の品質が高い上にランニングコストもダントツに安い。
 Windowsとマックのどちらのドライバも付属する。
 これできまりだな。
 昇華型のMD-2300Sはやはりランニングコストがかさむ。

Takeshi Yoneki

Subject: Map
Date: Thu, 26 Dec 1996 14:24:37 +0900
From: Takeshi Yoneki

>>(1)新米木邸はどうやって行けばいいんでしょうか?(交通機関)

最寄り駅は西武新宿線の都立家政
西武新宿(ペペ)からだいたい17分ってところか。

>>(2)VC++4.0で、Aダイアログクラスで入力したデータがm_Dataに
>>格納されるとします。 入力確認画面としてBダイアログを表示する時に
>>Aダイアログのメンバm_Dataを参照したいのですが、どのような
>>方法が一番エレガントでしょうか?
>>
>> 1. BクラスにAクラスを継承させる。
>> 2.Bクラス生成直後にBクラスメンバに代入する。
>> 3.m_Data(もしくはAクラス)をグロバールにする。
>> 4. Bクラス内でGetParentWnd()を使ってアドレスを獲得する。

普通は2.だろうな。データの量が多いときは構造体を作ってそのポインタを渡
して参照するという2.と3.の折衷がよかろう。構造体でなくてクラスのポイン
タでもいいわけだけどね。

>>(3) Windows95用のインストーラって作った事ありますか?

 ない。インストールシールドの説明を読もう。かなり簡単にできるみたいよ。
 私もそのうちやるハメになりそう。

Takeshi Yoneki

 引っ越し前後からあんまりゲームをするチャンスがなかったため、この冬一気に購買欲が爆発しました。以下最新でないものも含みますが、12月に手に入れたゲームです。

セクシーパロディウス(PS)
 ジョイスティック必須です。このシリーズは昔から好きです。
グラディウスデラックスパック(PS)
 移植性は良いですが、今さらであることも事実です。
サイドワインダーUSA(PS)
 最初の面で勝てません。私には向かないようです。エースコンバット2を待ちましょう。
リッジレーサーレボリューション(PS)
 初代リッジレーサーを1年以上やり続けただけあっていきなりエンディングでした。
レイジレーサー(PS)
 今ハマッてます。良いです。リッジレーサーがオモチャに見えちゃいます。ブレーキを使わないと勝てないってのが良いですね。
DOOM(PS)
 あれです。移植性は良いです。パソコンでゲームをやるのはあんまり好きじゃないんで、AT互換機ではあんまりやっていませんでした。でも同じ面の同じ場所で死にます。レベルを下げて再挑戦しています。やっぱ面白いですね。
ゼロ・ディバイド(PS)
 古い格闘ソフトを中古で買いましたが、なかなか渋いソフトです。でも私は格闘モノは下手なんで。
ヴァンダルハーツ(PS)
 SRPGです。後述のリグロードサーガが悲しい出来だったので買ってきました。まだ始めたばかりですが操作性も良く、血がドバー!っと出るのが驚きです。
リグロードサーガ(SS)
 SRPGです。中古で安かったんで買ってきましたが、なんとも好きになれません。もうちょっとやれば面白くなるのかなぁ。もしかしたら私はSRPGに向かないのかもしれない。
ナイツ(SS)
 非常に良いです。FCのマリオ、MDのソニック、PSのジャンピング・フラッシュに相当するSSの決定版アクションだと勝手に思っています。でもボスが強くて先に進めません。人工生命が減っていくとマジに悲しくなります。
クリスマスナイツ(SS)
 サターンの年末商戦のバンドルソフトですが、通販で手に入ります。12月25日まではクリスマスナイツ、以降はウィンターナイツ、正月にはハッピーニューイヤーナイツとタイトルが変化します。12月24日の夜にはトナカイが飛んでいました。人工生命の繁殖の様子が見れます。この機能はオリジナルナイツに欲しかった。
カオスコントロールリミックス(SS)
 リミックスじゃないやつは知りません。ガンコントローラを使ったシューティングです。なかなか出来は良いですが、二人だと案外あっけなく終わってしまいました。
3Dレミングス(SS)
 あれです(^^;)。軸が増えて数倍難しくなっています。サターン向けマウスが品切れになっているため、あんまりやってません。マウスを探すよりはPS版を買った方が早いかなとも思ってます。
パンツァードラグーン・ツヴァイ(SS)
 セガの王道の3Dシューティングです。出来は非常に良いです。昔、セガの3Dシューティングはあまりに大味だったんで嫌いだったんですが、マシンの能力が上がってゲーム性が納得できるものになりました。でも難しい。
バーチャコップ2(SS)
 例のヤツです。ガンシューティングの決定版です。やはり壮快感が違います。細かい動きが凝ってて楽しめます。スイカを撃つとそういう音がちゃんとするのは嬉しいですね。
サターンボンバーマン(SS)
 いつものあれです。ちっとも次世代っぽくありませんが、これはこれでいいのでしょう。先月ソニーの人達と家でパーティーをしたときに6人対戦しました。なかなか無茶です。

1997.01.03

 さて、1997年だ。昨年はいろいろと、本当にいろいろと何年分かの事件が一気に来てしまったが。今年はどうなるやら。

 とりあえず昔のマックデヴェジャとdevelopのCD-ROMを引っ張り出してきて實篤のドラッグ&ドロップ対応を始めた。サンプルが結構な量に見えたのでウンザリしていたが、マックデヴェジャの記事で原理的な部分を実装し、実践面の参考として使えると判り納得した。結局何らかのグローバル変数を使わないと実装できないようだ(refConを使って避けはしたが)。
 予想よりは楽に実装できた。ドラッグ&ドロップに対応してTEで始まるToolboxが増えているのは予想外だった。どうせならセレクトを保持したままキャレットを表示するというAPIも増やしてくれればいいのに。なんにせよTEGetHiliteRgn()は使える。ドラッグ中のキャレット表示はサンプルをそのまま使っている。
 ウィンドウ内のドラッグに対応したUndoの実装が新たに必要になった。

1997.01.07

Subject: NeXT
Date: Tue, 07 Jan 1997 10:59:30 +0900
From: Takeshi Yoneki

サブジェクトは日本語読めないんでその点よろしく。

Appleの次世代OSの最初のリリースはまんまNeXTSTEPになりそう。
ってことは今までのMacOSのアプリは全部動かなくなる。
System 7との互換性は98年に段階的に提供するそうな。System 7はNeXTSTEP上
でエミュレートされる形になるようだ。かなり思い切った方向転換だ。
マックの開発者はこれからObjective-Cを学習するハメになるわけだが、ここ
でつまづくとAppleは「昔そういうメーカがあったねぇ」という存在になっち
まう。難しいもんだ。

坂本龍一って矢沢永吉の物真似してたあいつか?(^o^)
やっとウニ組曲聞けるのね。

Takeshi Yoneki

Subject: Re: A Happy New Year!
Date: Tue, 07 Jan 1997 18:22:19 +0900
From: Takeshi Yoneki

>>久しぶりに、MAILを^NA*/8したら。。。
>>ヨネッキーさんのおうちの^NJ_0C(0のことなどなど。。
>>^NA*/8してなかったよ〜。。。ごめんなさい。。

みんな「^NA*/8」とか「^NJ_0C(0」とか読めてる?
私にはキャップエヌエーアスタリスクスラッシュハチとかにしか読めないんだ
が。何使ってメールした?
私のところはFreeBSDでMule+mh-eだ。

Takeshi Yoneki

Subject: Re^5: A Happy New Year Nights!
Date: Wed, 08 Jan 1997 16:51:49 +0900
From: Takeshi Yoneki

> しまどん
>>
>> mh-eのような emacs-lispで書かれた MIME拡張されたメーラです。
>> 僕も後輩がやはりmewを使ってて、移行した方がよいと言われてる
>> んだけど、面倒で...。
>>

 会社のsite-lispディレクトリにmew.elcが入ってました。見てみようと思っ
てcatしたら端末が完全に文字化け。これどういうコードで書いてあるんだろ
う。あ、まてよelcだからバイナリか。ソースあるかな。
> れいこおねえさま
>>今年はまだ、ぷよぷよで負け越しているので、完全なる攻略方法を
                        ~~~~~~~~~~~~~~
イヤミですか?(-_-#)
>>ついにpawmasvが狂ってしまったようなので、

 くるべきときがきたようですね。合掌。
 ごくろうさま > pawmasv

Takeshi Yoneki

注:
 「^NA*/8」は「チェック」、「^NJ_0C(0」は「パーティー」で、ともに半角カナであった。今時MIMEにも対応できないメーラを使っているのはどうもねぇ、ということでmewの話題になったのでした。

 ハンコック氏曰く「当社顧客のみなさんが,現在のプログラミングインタフェースとの別れを受け入れてくださるものと信じている」(MacWeek Online Japan 1997.1.7より)
 うひゃぁ。ついにこの発言がApple御本体からでてしまった。ボクらが今まで作ってきたソフトは、新OSに対応させたいならば完全に書き直せという意味だぁ。似た別のもの(例えばWin16とWin32)ではなく完全に違うAPIを使わなくてはいけない。
 Macintoshプログラムを作成する難しさはGUIプログラムの難しさであり、現在ではWindowsでのGUIプログラマも増えてはいるが難しさは同じだ。習得の障壁はなんといっても膨大なAPI群である。「何かを実現したいとき、どこにどの程度の機能が用意されているかを調べる」のが一番シンドい。ドラッグ&ドロップ実装で、TEの範囲選択リージョンを得るAPIはあるが、TEの範囲選択を保持したまま別にキャレットを表示するAPIは存在しないことが判った。指定レクタングル間でズームするAPIはあるが、TEで描画を遅延させるAPIはない。何を書く必要があり何を書く必要がないか調べるのが一番の手間だ。
 今は何気なく使っているstrlen()だが、Cの入門したてのときはその存在を知らず、strlen()と同じ動作をする関数を用意したりしていた。ライブラリやAPIなんて知らなければ使いようがない。
 新たにNeXTのAPIを学習するのはかなりの手間だと思う。それでもNeXTへの移行は歓迎せねばなるまい。念願の本物のOSなのだから。せめてObjective-C以外の選択肢もきちんと用意して欲しいというのは、世界中のマックプログラマの希望であろう。

1997.01.08

Subject: Re^2: GM Gakki
Date: Thu, 09 Jan 1997 17:35:09 +0900
From: Takeshi Yoneki

>>GM楽器図鑑 って何するものですか。
>>GM音源のがサポートしている楽器の実態がわかるとか・・・
>>オンドマルトノとかノバトロンとかもあるんでしょうか?

 オンドマルトノやノバトロンがGM音源にあるもんかぁ!
 名前の通りGM音源に入っている音色を中心に楽器の説明をする図鑑だ。音が
鳴る原理や音域の説明もある。シンセも何台か説明はあるけど音色は聞けない。
シモンズやTR-808は音色データもあったな。ヴァイオリンみたいな形のベース
もあったぞ。

Takeshi Yoneki

Saneatsu Lite 1.5 → 1.6の変更点

1.Drag and Drop対応。

2.Internet E-mail仮IDのINTxxxxx対応。

3.スクリプトでbbs、forum、roomのオブジェクトを得るときの動作で各オブジェクトの抱えるオブジェクトを常に有効(内部的にアタッチと表現している)にはしなくした。
 具体的にいうと、従来はあるroomをgetするとそのroomの抱えるmessageをアタッチ、すなわちIndexリソースを読み込んでいたが、messageオブジェクトをgetするまで遅延するように変更した。
tell application "Saneatsu Lite"
	tell current forum
		copy room count to theCount
		repeat with n from 1 to theCount
			get title of room n
		end repeat
	end tell
end tell
というスクリプトでスピードが以前より向上しています。

4.currentシリーズをtell文やof等で使えるようにした。ついでにselectionも同じ意味で使えるようにした。
tell application "Saneatsu Lite"
	tell selection of selection of selection of selection
		get title
	end tell
end tell
という怪しげな表現も通ります。


>>田中求之 (UVJ)さん

 上記3番関連の確認をお願いします。

>>Basukeさん

 上記4番関連の確認をお願いします。


開発フェーズは68K版なのでよろしく。

1997.01.13

Subject: Re: PTO2
Date: Mon, 13 Jan 1997 16:38:27 +0900
From: Takeshi Yoneki

>>その他のかなりの人が眠りについていたのは間違いないです

わははははははは。

 全く話は変わるが、S-760にマックのサウンドファイルであるAIFFを送ると
いうソフトがあると判明。早速手に入れて使ってみた。

 Samplifierというソフトで$20のシェアウエア。機能はいたって単純で、OMS
で設定したS-760にMIDIサウンドダンプスタンダード形式でサンプルデータを
送り付けるのみ。試しにGM楽器図鑑に添付されているAIFF(TR-808のクラップ)
を送ったら、きちんと受け取った。マックで鳴らす何倍も音が良い。
 S-760専用なので、サンプル名をAIFFのファイル名にしてくれる。ただしボ
リューム名は空なので自分で設定しなくてはいけない。ここは改善の余地あり。

 レジストはkagi.comを使うのでVISAがあればE-mailを送るだけ。翌日にはパ
スワードが送られてきてプロテクトもなくなった。

 私としてはOMSなしでSystem 6で動いて欲しいが、Classic IIを引退させる
方が良いのだろうとは思う。UMAXマシンでも買ってIIcxを音楽マシンにすべき
頃ではあろうな。

Takeshi Yoneki

Subject: To HORIGON
Date: Thu, 16 Jan 1997 10:33:31 +0900
From: Takeshi Yoneki

>>ほりごんへ

 例のベル9、この休日を潰してしまった。ともかく終了。元気の作ったソフ
トのくせにきちんと終われるってのはたいしたもんだ。元気もゲームバランス
の重要性に気が付いたのかな。
 そういうわけでゲームはバランスが命。システムは二の次。システム的にも
キリークに比べ非常に良くなった。システムは似ててもここまでゲーム性が変
化するもんなんだね。ともかくベル9はキリークのversion 3のようなもんだ
と思う。
 ともかく昨夜のうちに2度目の挑戦に入った。ようやく指もシステムに慣れ
てきた。多少キーコンフィグはしたが、やっぱ配列があまり良くない。上下視
線があることが操作の複雑さを招いてはいるんだろうな。
 ともかくゲームバランスが非常に良い。頑張ればなんとかなるってレベルが
一番。
 ゲームのケースには26面と書いてあるが、22面でラストであった。この
へんなんか思い当たるフシはない? 脇道なんてないよね。誤植かな。だとし
たらやたら迷惑な誤植だ。ラストのボスと戦いながら「まだ戦力を残しておか
ないとこの後進めないなぁ」と心配していた。

 もうそろそろキリークがいかにタコか判った頃かな?

Takeshi Yoneki

 ローランドのサイト(http://www.rolandcorp.com/)のライブラリにサンプリングマシンS-760のOSバージョン2.24が登録されている。バージョンアップされているとは全く思っていなかった。ずっと最初に付属していた1.0のままであった。たいして使っていたわけではないから困ってはいなかったが。
 アーカイブを展開するとクリエータが'DART'のファイルができた。何の説明書もない。'DART'とはなんであろう。たぶんイメージデータをフロッピーディスクに展開するツールなんだと思うが。
 再びローランドのサイトを覗くとDARTというツールがあるとわかった。まさしくフロッピーイメージをフロッピーディスクに展開するツールであった。やってみると物理的なフォーマットはDOSの1.44 M Byteだと表示された(論理フォーマットが違うからDOSからは見えない)。
 アップル純正のDiskCopyに似たツールだなぁと思ったらAppleのツールであった。こんなのあったんだねぇ。DiskCopyとの違いはDOSディスクのイメージファイル化もできるってことだろうか。
 S-760を新しいOSで起動するとバージョン番号がきちんと2.24と表示された。何が変化しているのか全く分からないが、ま、動けばいいか。
 もしかしたらどうしてもできなかったディスク間データコピーがきちんと動くかもしれない。今度実験してみよう。

 転職前の会社の同僚が「これは面白い」と言ってPSのゲームを持ってきた。
 あの元気株式会社の「ベルトロガー9」だった。「キリーク」のバージョン3みたいなものだ。「キリーク」があまりにゲーム性の低いソフトだったので、最初私は難色を示したのだが、やり進むにつれ、かなり改善されているとわかってきた。
 システム的にはジャンプが加わり自由度がかなり上がっている。フロアも広い部分が多く、シューティングで重要な「敵の弾を避ける」ことができるようになった。敵の攻撃のバリエーションも多い。印象としてかなり「DOOM」に近づいた。パズル性も高くなっている。
 はっきりいって出来は非常に良く、バランスもこなれており、面白いゲームに仕上がっているのだが、あの「キリーク」の「元気」が開発したってことで「絶対買うもんか」と思っている人も多いと思う。一度失った信用はなかなか取り戻せるものではない。
 「キリーク」を面白いと思った人には易しすぎるのかもしれないが、これくらいのバランスじゃないとゲームとして成り立たないだろうね。

1997.01.16

 セガのシャトルマウスが手に入らないということで抛っておいたSS版3Dレミングスを引っ張り出してきてやってみた。コントロールパッドでも操作性が悪いわけでもなく、マウスがなくてもちゃんとやれるゲームだとわかった。
 よくよく考えると、パソコンではマウス以外に確実にキーボードがあるが、ゲーム専用機ではマウスだけになるので、もしかしたら操作性に難がある可能性もある。
 3Dレミングスのコントロールは比較的大きなブロック単位であり、コントロールパッドでも十分な解像度になっているのであった。カーソル移動のスピードをリアルタイムに変化させるという方法がないので変だなとは思ったが、それが必要ないということだ。
 オリジナルのレミングスがほとんどドット単位に近いコントロールができたということが杞憂を生んでたわけだ。これでやっと3Dレミングスを進められる。そもそも私はオリジナルレミングスをSFCでやってたので、マウスである必然性はもともとない。COCO姉ちゃんはマウスにこだわってはいるが。
 以前に発見してた「セーブはできるがロードができない」という問題はサードパーティ製の連射コントローラが原因だと判明した。純正コントローラを使うと問題なくロードできる。何か互換性のない部分があるのだろう。ジョイスティックやアナログパッドでもチェックしておこう。
 3Dレミングスのチュートリアルはうざったいのだが、必ずやった方が良い。特に「バーチャルレミングス(レミングス視点でのコントロール)」はあんな風に明確に示されないと、どういう利点があるかなかなか解らない。あれは面白い機能だ。
 難点は面の達成評価画面やメニュー画面への移動に毎回CD-ROMアクセスが発生するところだ。そういったプログラムすら入らないくらいメモリがキツいのであろうか。面をキャンセル(自爆)してやり直すのに達成評価画面のためのCD-ROMアクセスが発生するのがかなりうざったい。なんとかならなかったのかなぁ。PS版の3Dレミングスも同じであろうか。
 もうひとつ難点。場所によってはカメラを後退させるのが非常に重い。しかたのないことなのかどうかは私にはわからない。

1997.01.17

Subject: GAME
Date: Thu, 23 Jan 1997 12:04:11 +0900
From: Takeshi Yoneki

 ドラクエ7おめでとうございます。いまだ任天堂が強気発言をしているのが凄い
ですね。2000年に耐えられる仕様のN64とか言っていますが、その頃にはPSも
バージョンアップしているでしょう(希望的観測)。

 それはさておき。
 最近のお勧めは「ベルトロガー9」です。「キリーク」を開発した元気株式会社の
ソフトですが、システムや面構成、そしてなにより難易度が非常にこなれています。
「キリーク」での反省が「ベルトロガー9」に活かされているようです。

 あと、いまコナミのSRPG「ヴァンダルハーツ」をやっているのですが、最初に
思ったほど悪いソフトでなく、結構楽しめます。戦略シミュレーションはスイスイ
勝ててもつまらなくなり、全然勝てなければゲームが成り立たなくなるため難易度
設定が非常に重要ですが、とりあえず私には程々です。

 そもそも私は「大戦略」等の戦略シミュレーションをやらないのですが
(PCエンジン版大戦略が何故か家にあるけど)、それはやはり複雑化した戦略
シミュレーションを好きになれないからです。何か面白そうな世界を一つ棄てている
ようで、残念でなりません。
 例外がハドソンの「ネクタリス」シリーズで、これは戦略シミュレーションを
複雑化する最大の要因である生産というコマンドをなくしています。おかげで
ゲームが詰め将棋的になり、比較的短い時間で楽しめるようになっています。
兵器のメリハリや絶妙な戦力差や配置などとことん練られています。
 今でもやはり一番好きなゲームに挙げます。シリーズというからには続編が
あるのですが、これが機種も背景もシナリオも兵器もタイトルも変えてでてきたので、
普通はシリーズとは言わないでしょう。でも発売当時は「あのネクタリスの面白さを
再び」のような口調の評が多かったように思います。続編「アースライト」の
システムは「ネクタリス」と同じですが、難易度が多少下げられています。

 そんなわけで私は、戦略シミュレーションもしくは戦略シミュレーション的な
ゲームにはどうしても「ネクタリス」を求めてしまう癖があります。
 「ヴァンダルハーツ」はさすがに「ネクタリス」ほど絶妙な詰め将棋という
ゲームではないため、私は物足りなさを感じるわけです。「ヴァンダルハーツ」が
悪いわけではなく、私が欲しがっているものではないというだけです。

 スクウェアの「フロントミッション」というSRPGがあるのですが、これが
非常につまらない。兵器のどれがどれに強いというループもなく、たとえ
あったとしても遠隔ミサイルが圧倒的に強いため、それを買い揃えれば戦略性も
ゲームバランスも何もかもなくなってしまいます。
 「フロントミッション」に比べれば「ヴァンダルハーツ」ははるかにマシで、
それは結局兵器を自分で選べないが故の詰め将棋的要素のおかげなのでしょう。
敵の思考ルーチン云々ももちろんあるでしょうが、自由度が高ければ面白いという
わけでもなさそうです。

 昔からスクウェアブランドのゲームは好きになれない。なんでだろう。

 「ヴァンダルハーツ」が終わったら「タクティクスオウガ」をやります。

Takeshi Yoneki

Subject: Re^2: GAME
Date: Fri, 24 Jan 1997 17:28:14 +0900
From: Takeshi Yoneki

>>
>> 任天堂の山内社長がいる限り、日本でのPSの優位は動かないでしょ
>> う。なにかあの人がいるおかげで、N64がおかしな戦略ばかりとっ
>> てる気がします。
>>
>># 関係ないですが、ちまたではSEGA-bandaiの話しで持ち切りのようですね。
>># バンダイも社長が、pippinなんぞに、うつつをぬかして会社を傾け
>># た口ですよね。
>># (バンダイの規模で300億の予定が50億の売り上げだったら、
>># 傾くわな、それは。社運かけてたし。いくら「たまごっち」を作
>># ってもおいつかないや。)
>>

 「任天堂がライバルだなんてゲーム屋風情の意識を持ってちゃあっという間
につぶされる」とCSKの会長が言ってますね。もはや視野に任天堂は存在しな
い?!
 まあ、セガとバンダイが組んでもあたしゃバンダイのゲームはやんないし、
セガの大味のソフトが好きってわけでもないし、影響ないなぁ。
 ちょっと前からセガのゲームにRPGって言葉が使われていると「RPGはバンダ
イの登録商標です」って書いてあったんだけど、セガとバンダイが近しい間柄
だったってことなんだね。うんうん。ソニーのゲームにはそんなことは一言も
書いてないからねぇ。
 にしてもいつのまにRPGが登録商標になってたの? バンダイにRPGって名前
の商品があるのかな?

 でもパンツァードラグーンとナイツは良い。

Takeshi Yoneki

Subject: Re^2: chain
Date: Fri, 24 Jan 1997 17:37:03 +0900
From: Takeshi Yoneki

>>●うちの父は、強風が吹いたり雨が降ったりすると、空に向かって、「バカヤロー!
>> ろくなもんじゃねえなー」と必ず叫びます。台風がきたときなど、そりゃあもう
>>

ラストの小話が尻切れトンボなのは原文がそうなのかな?
そりゃあもう何なんだろう。気になる気になる。
長編の方が短いってところも気になる気になる。

Takeshi Yoneki

Subject: To HORIGON
Date: Fri, 24 Jan 1997 17:56:56 +0900
From: Takeshi Yoneki

>>
>>「じゃんふ」はちかめいきゅうで「ざりがに」のおやだまみたいのにつつかれてさき
>>にすすめません。
>>3Dれみんぐす(りゃくして「3れみん」)はすでにかったんでしょうか。
>>とにかくこんしゅうまつは「きんど」のくりあにちゃれんじするぞぉっと。
>>

 ああ、あの蝦蟹ね。あれは案外強かった。精進精進。勝てば蟹鍋。
 キングスフィールド1は思ったほどボリュームないよ。そんなに気合を入れ
なくても大丈夫。

Takeshi Yoneki

 PSの戦闘国家というシミュレーションゲームを買ってきたが、こういったシミュレーションゲームに慣れていない私にはどうにも複雑すぎると感じた。そこで、先日存在を思い出したSUPER大戦略をやって、多少慣れて勘を身につけたら戦闘国家を始めようと考えた。
 PCエンジンCD-ROM2版(SUPER CD-ROM2ではない)のSUPER大戦略は、当時PC-98で大人気を誇った大戦略IだったかIIだったかIIIだったかの簡易版を8bit機であるPC-88シリーズ向けに移殖し、それをさらにMSXやPCエンジンに移殖したものである。システムソフトのコピーライトになっているが、メーカーはマイクロキャビンになっている。
 SUPER大戦略を購入したのははるか昔だが、実際にちゃんとやるのは始めてだ。なぜかというと、このゲームはCD-ROM2の持つバックアップRAMを全部消費してしまうのだ。他にもバックアップRAMを使うゲーム(Wizardry IVとか)をやっていた当時はやりようがなかったのであった。天の声を買うほどの思い入れもない。そもそもSUPER CD-ROM2の時代になってから中古で安く手に入れたので、まあ、どうでもよかったわけだ。ちょっとやってみてネクタリスほど面白くはないとわかっていたということもある。
 まず、UIがなってない。ボタンIとIIの役割をきちんと一貫させてほしかった。音楽もショボく、途中で変更できない上に効果音のみというオプションもない。完全な兵器データがマニュアルにもヘルプにもない。
 8bit機の能力は知っているので、いまさらグラフィックがどうしたとかスクロールがどうしたとかはいいません(スクロールは可能だとは思うが)。でも8bit機なりの誠意が欲しかった。ネクタリスはROMカードのゲームだけどちゃんと漢字を使っていたぞ。ネクタリスよりは前の時代のゲームだったかなぁ。たぶんCD-ROM2の初期の頃の製品だから急ぎで間に合わせたってやつかもしれないけどねぇ。
 音楽はしかたがないのでマシな組み合わせを選び(これがまた時間を食った、8と9がお勧め)、最初の面を攻略した。タコなUIでもやってると慣れてくるもので、時間は無茶苦茶かかったもののなんとか攻略できた。
 敵兵器の移動数を知る方法がないってのはどうにかならないもんかねぇ。一回敵兵力でゲームをやって全部生産してみろってことかなぁ。それじゃあんまりだよ、何のためのコンピュータか。
 次の面は最初ほど苦戦はしなかったもののやはり時間を食うことは変わりなかった。
 これでやらず嫌いだった大戦略もなんとかこなせることがわかり、現代戦シミュレーションの兵器の種類と用法もいくらかわかってきた。ただ私は全く本物の兵器には興味がなく、あくまで駒としての有効性という観点でしか見ていない。基本はネクタリスとそう変わったものではないともわかった。
 気になったのは間接攻撃の車両がないことと、首都でしか生産できないことだ。間接攻撃車両はたぶん簡易版だから削除したのかなとも思う。生産が首都に限るのは補給線の確保の重要性を認識させるためであろうか? しかし、遠くの前線の展開を予測しながら生産する兵器を決めるのはなかなか難しいものだ。対空車両は足りないか余るかどっちかなんだよねぇ。
 で、戦闘国家に戻る。
 いやはややはりこいつもUIが悪い。「他行動」なんてメニューの階層化をしないで、全部並べれば良いのに。音楽はSUPER大戦略より更に悪い。さいわい効果音のみというオプションがあるからいいものの、この音楽を消せなかったらそのままゴミ箱行きになったところだ。戦闘のグラフィックを見るかどうかを毎回選ぶのは面倒な上に、通常画面で再度戦闘をさせるのはなんだろうね。結果は同じだが何か変だぞ。
 どうやら戦闘国家は大戦略で不満だった部分を解消すべく作られたゲームのようだ。間接攻撃車両もあるし、生産を首都以外でもできる。この首都以外ってところが良し悪しで、ゲーム展開がかなりスピードアップされる。都市攻略の重みが断然違う。
 まだ最初の面しかしていないが、都市で生産と補充が可能なため、補給線の確保にさほど力を入れなくてすむ。補給線の重要性がかなり低下している。基地建設もその傾向に一役買っている。
 ほったらかしにした都市でも、敵が近づいてきてからその場で迎撃態勢を整えられる。なんとも緊迫感がない。
 また、自動迎撃システムと行動力システムのおかげで、一旦戦闘が始まるとどちらかが絶滅するまでガンガン進んでしまい、もはや援軍なんてものが成り立たなくなっている。詰め将棋的面白さはない。
 兵員輸送と占領周りの制限もあまり直感的ではない。何度もコマンドを間違えて再ロードをしなくてはいけなかった。そう、コマンドをキャンセルできなくなるタイミングが変だ。一旦移動したらそれは取り消せない。ゲームとしてのシビアさを追求したフリをしてるけど、自動迎撃システムと行動力システムとの整合性がとれないだけだよね。これはどう評価すべきかねぇ。ユーザの楽しむ試行錯誤は明確なキャンセルと共にあると思うんだが甘いか? 航空機の着陸・離陸も煩雑なだけだなぁ。
 結局SUPER大戦略の半分くらいの時間で最初の面が終了したろうか? 同じ面とは言えないので比較することに意味があるかどうかはわからないが、一旦敵が劣勢になったら、ボロボロっと一気に首都まで行けてしまったような感触だ。
 もう少しやってみないとわからないが、SUPER大戦略の方がゲームとしては面白いんじゃないかなぁ。時間がかかりすぎるという欠点はでかいけどね。

1997.02.03

 こんばんは、OSTRAです。
 オブジェクト比較アクセッサ周りの実装の問題があり、解決に時間がかかったため遅れましたが實篤のβ2です。テストをよろしくお願いします。

 β1からの変更点

1.bbs、forum、roomで含有エレメント数を得るという要求があってもそのオブジェクトがアクティブ(カレント)にならないバグを解消。
2.各クラスの持つプロパティがきちんとgetできるか全部チェック。幾つかgetできなかったもの及びβ1の変更でgetできなくなっていたものをgetできるようにした。
 setに関してはこれからのチェックの予定。
3.オブジェクト比較アクセッサに生データのデスクリプタが渡ってきたときに対処できるようにした。
 たぶん今までは
	if handle is "OSTRA" then
とは書けたが
	if "OSTRA" is handle then
とは書けなかったはず。
4.windowのプロパティにselectionを加え、選択されている文字列をgetできるようにした。
 これでもしかしたらNavigatorにURLを渡すなんてスクリプトが書けるのかな?

1997.02.03

 PSの戦闘国家も3面目となり、ようやくシステムに慣れてきた。何をしたら動作のキャンセルができなるなるかがようやく飲み込めてきたということだ。いまだにコマンド発行を間違えてしまい、ロードすることもある。
 序盤戦をうまく運び中盤戦を堪え忍ぶと、いつのまにやら戦力に大きな差が生じており、首都を叩き潰せるようになっている。都市攻略が重要ポイントで、序盤戦の一手は実に重い。2面目でかなり早い時期に戦力差がでたのだが、敵都市攻略に手間取った。生産を各都市でできるというシステムは即戦力となる生産が可能で、嘗めてかかると痛い目に遭う。
 それにしても音楽はどうにかならんもんかなぁ。誰が作ったか知らないけどマジに最低だよこれ。ゲーム音楽のこと全く解っていない上に、作曲能力に難があるのではと思う。明白な片手間仕事だったと確信している(本気でこんなもの作るようなら作曲家をやめたほうが世の為になる)。
 戦闘でユニットが全滅するパターンが多いように感じられる。似たような戦力のユニットが戦ってもどちらも大きな痛手を被るのだ。複数回戦闘ができることも関係しているだろう。SUPER大戦略では一つのユニットを潰すのに3ユニットくらいは平気で使っていたが、戦闘国家では少ないユニットで潰し合いをしてしまう傾向がある。あと、支援効果があまり感じられない。ないわけじゃないだろうが、全滅してしまったら支援効果も何も意味がない。
 いろいろと文句を並べてきた戦闘国家であるが、UIに難点があるもののシステム的にはしっかりしているため、音楽を消して(自分で別のCDを掛けて)楽しんでいる。展開が速いとはいえシミュレーションなので、根本的に時間食いなのはしかたあるまい。

1997.02.06

 COCO姉ちゃんに「何かあるんじゃないの」と言われていたHUNDOSHI-EDITのスクラップ周りのエラーチェック強化をした。といってもあまり有効とも思えない。エラーチェックはもともとやたらと入っているのであった。
 Eudora Pro Jと併用しているときに、HUNDOSHI-EDITでコピーしたテキストをEudora Pro Jにペーストして、再びHUNDOSHI-EDITを最前面にするためクリックするとHUNDOSHI-EDITがコケることがあるそうだ。
 問題があるとすればクリップボードのアップデート処理だ。HUNDOSHI-EDITは古めかしい方式だが、アクティブになっているとき常にスクラップのカウントをチェックしている。そして、カウントが変化していたらそれをすぐに反映させるようになっている。どうやらそこでコケているようだ。GetScrapでエラーが返らずにそのままコケているのではないかと思われる。
 InsideMacにおけるGetScrapの仕様は、最低限のサイズのハンドルを渡すと勝手に拡張してデータを格納するとある。どうもこれがヤバいのではないかと常々心配していた。実際にこれが問題点かどうかはわからないが、ハンドルサイズの拡張が安全なはずはなく、以前ときどき特定の環境で発生していた「バックスペースをすばやく押すとビープが鳴る」という件でその危険性は証明されている。以前のバックスペースの実装ではUndoバッファの拡張をハンドルサイズの拡張で行っていたのであった。
 結局残る安全対策はGetScrapをする以前に十分なサイズのハンドルを確保することだ。しかしスクラップのサイズを得るのにGetScrapしかないというのが気がかりで、しかもメモリの残りが厳しいときはメモリサイズを得るためのGetScrapでもコケることがある。
 完全に安全なスクラップ処理は夢だが、ともかく今回いくらかは自衛策を施しておいた。Eudora Pro Jがスクラップ周りで何をしているかは知らないが、どうせロクなコトじゃないことは現象から伺える。

 そのスクラップ対策強化版のソースをお姉ちゃんのPPC6100に入れてコンパイルを初めてから気が付いた。「あ、コンパイルが通らない、ああ、上書きしちゃった」。
 以前にPPC化を施したHUNDOSHI-EDITのソースに、それ以前からのソースを元にしたスクラップ対策強化版を上書きしてしまったのだ。あああ、結構苦労して変更を入れたのに。またやり直しだ。
 アップルイベントハンドラの引数がいつのまにか(たぶんUniversal化するときに)変更されていたことを前回の修正時に発見していたにもかかわらず、今回もヘッダを読んで再発見するまですっかり忘れていた。Toolbox Assistantに記載されている引数も古いままだ。こういった変更はなかなか発見しにくい。まさかと思うよねぇ。この変更はPascalだけのもので、Cでは結局ポインタなので同じですのでご安心を。また、68Kでは変更なしでも動いちゃうんだよね。

 で、ようやくHUNDOSHI-EDITでもUnixやDOSファイルの改行を自動的にコンバートすることに決めた。試験的に実装してみて、まあこんなもんかと思っている。漢字のコンバートは面倒だよなぁ。自動判定が難しいんだよなぁ。

1997.02.10

Subject: Re: STACK!
Date: Thu, 13 Feb 1997 14:28:11 +0900
From: Takeshi Yoneki

>>内部変数に使用する領域は通常どのくらいの大きさが限界なんでしょうか?
>>僕は現状512byte以上になるときにグローバル変数等に変更しますが・・・
>>スタックってどのぐらい積むとオーバーフローするんですか?

 今は昔の16ビット環境でMモデルだったりするとデータセグメントが64Kまで
という制限のため、4KByteとか8KByteのスタックでやりくりしてた。WinSock
なんて使ったら10KByteはスタックが必要だった。自分の使うスタックだけで
なく、WindowsAPIの先のほうのスタックを考慮に入れないといけなかったもん
だ。そんな義理はないぞ。

 んで、32bitとなった今、まさか8Kbyteてことはなかろうと調べてみた。
Developer Studioの
ビルド - 設定 - リンク - アウトプット
で、ヘルプを見ると良い。デフォルトは1MByteだそうな。8KByteでやりくりし
てたのはいったいなんだったの? 16bit Windowsの凶悪さがこれでわかるっ
てもんだ。80286がいかに脳梗塞だったか。

 そんなわけで、最近はUNIXプログラムと同じようにスタックを気にして書く
なんてことはあんまり必要なさそう。ま、古いパソコンプログラマの私は少な
いスタックの癖ってのから離れることはできなさそうだけどね。


>>クラフトワークのコンピューターワールドを買いました。
>>なんか全然ジャストインタイムじゃ無い感じですね、リズムが。
>>冷静に聴くと新たな解釈が生まれそうです。
>>Mac World Expoのテーマってどのアルバムに入ってるんでしたっけ??

 ジャストインタイムって実行時コンパイルか? クラフトワークは奏でなが
らそれぞれの環境にオプティマイズされるのであろうか? はいはいわかって
ます。ぜんぜんジャストじゃありまへん。でもルーズではけっしてない。

 Mac World Expoのテーマってなんだ?(最近TVはニュースステーションくら
いしか見てない)

Takeshi Yoneki

 LinuxやDOSとの共存で不便だったため、改行コードと漢字コードのコンバートを実装した。あ、HUNDOSHI-EDITのことだ。
 改行コードはとりあえず何がきても何にでも変換できる単純なアルゴリズムがあるのでワケない。これは以前MacMiNTで日本語フォントを使えるようにした、ええと名前を失念、人がバイナリに付属させていた汎用改行コード変換ツールのソースで読んだものだ(彼のオリジナルかどうかはわからない)。なかなか賢いアルゴリズムだと思った。
 最初はEUCからシフトJISへの変換を実装。これがきちんと動くとあとは力技。7ビットJISはエスケープシーケンスがあり、モードを持っているのでなかなか奇麗な書き方はできないが、どうにかした。
 普通は自動コンバートだろうが、コンバートするかどうかをユーザに問い合わせるというオプションも用意。これで大抵の日本語テキストはシームレスに読み書きできるようになった。とりあえず私の環境からはJeditは不要になった(そういえば実際には全く使ってなかったな、変換にはASL KConvertを使っていた)。ついでにEdit7も。
 今までPC Exchangeの.txt設定は、改行コードの自動認識があるというだけでEdit7になっていた(普通フロッピーでやり取りするファイルはDOSなので漢字コードの変換は必要ない)。しかしもう.txtはHUNDOSHI-EDITに変更した。
 久しぶりにHUNDOSHI-EDITに手を入れたついでに、他のアプリがオープンしたままのファイルも読めるように変更した。ファイルのロード時にパーミッションをリードオンリーにするように書き換えたのだ。CodeWarrior IDEは開いているファイルをオープンしたままにするようなので、気になっていたのだ。
 同様な変更をGripGropに対しても行ったが、HUNDOSHI-EDITよりはGripGropのほうが切実に必要だった。CodeWarrior IDEで開いているソースはGripGropにおける検索対象にならなかったのだ。
 HUNDOSHI-EDITのPPC対応も済んだので、これで久しぶりにアップできる見込みだ。とりあえずはプラグインのPPC化は先送りにしている。PPC版のHUNDOSHI-EDITでも68K版のプラグインが動くようにしたので、当面は問題無いだろう。

 Appleの新しいPM8600/200の筐体はどう見ても格好悪い。これで在庫が切れる前に安くなったPM8500/150を買う決心がついた。どうも最近売り上げランキングで上位にいるから変だなとは思っていたが30万円を切ってたとは予想外だ。

1997.02.17

Subject: PM8500/150
Date: Mon, 17 Feb 1997 14:20:36 +0900
From: Takeshi Yoneki

というわけで、日曜日にPowerMac8500/150がT-ZONEから届くことになりました。
現行バージョンのPM8500/150はもう市場から消えた模様で(ツートップの通販
では×になってた)、旧バージョンのPM8500/150だけど、まあいいや。CD-ROM
が4倍速だからちと問題だけどどうせDVDに入れ替えるからね(そのうち)。
	PM8500/150		248000
	DIMM 32MB * 2		36000
	Keyboard(パイオニア)	9800
家計簿に嗜好品でつけとこう(^^)。
17'モニタはこれからゆっくり選定だな。

Takeshi Yoneki

Subject: PM8500/150
Date: Mon, 17 Feb 1997 16:09:54 +0900
From: Takeshi Yoneki

 奇数の年はパソコンを買う年です。
 4年ぶりにマックを買いました。メインマシンの交代は6年ぶりです。いや
はやこの時代にひとつのマシンを6年使い続けるのはシンドかった(アクセラ
レータは入ってるけどね)。
 マックエキスポ終了日の翌日の日曜日に配達されるのはPowerMac8500/150で
す。UMAXのマシンを買おうかなぁと思っていましたが、このところPM8500/150
の値下がりが激しく、また新型タワーマックの筐体が「何コレ」ってくらい最
低だったため、在庫がなくならないうちに買いにでました。
 思えばPM8500は筐体の由来がIIcx→Q700→Q800→PM8100→PM8500となってお
り、現メインマシンの直系の子孫にあたります(PM7x00は傍系と勝手に決め付
けている(^^;))。
 ようするに私が格好いい筐体だと思っている最後のマックなわけです。この
機会を逃したらもうこの筐体のマックは(新品では)手に入らなくなるでしょ
う。それも買いに出た大きな理由です。
 もはや現行マシンのPM8500/150は在庫が切れてしまい、旧型のPM8500/150で
したが、ま、CD-ROMが4倍速なのはかまわないので即決しました(現行は8倍速)。
 T-ZONEでPPC604 150MHz / 32MB メモリ / 2MB VRAM / 2G HD で248000円。
いやはや発売当時の半額ですな、こりゃ。PM8500/180はまだ330000円くらいし
ます。
 で、我が家には96MBメモリを積んでやってきます。

Takeshi Yoneki

Subject: Brain
Date: Wed, 19 Feb 1997 14:53:40 +0900
From: Takeshi Yoneki

 bit(共立出版)の今月号(1997/2)に掲載されている「脳と情報環境-電子
メディアの人体への影響-」(仁科エミ)が面白いです。
 脳のα波圧力を測定する装置と100KHzを超える音の再生のできるオーディオ
装置を開発したそうで、それを使っていわゆるLP対CD論争の決着をつけてしま
いました。
 LPと20KHz以上をカットしたLPとCDで測定を行ったところ、20KHz以上をカッ
トしたLPとCDではα波圧力が減少したが、LPでは増加したとあります。これは
すなわちCDを聴いてもリラックスするどころかイライラさせられるということ
を示しており、非常に興味深い結果となっています。
 実験の精度をあげるため、もっとサンプル数を増やす必要はありますが、と
りあえずこれでCD神話はその科学的根拠を失ったといえます。オーディオマニ
アは自分に正直だっただけで、嘘をついていたわけではなかったのです。
 自然の持つ可聴領域を超える高周波の意義を実験できちんと提示したという
意味で画期的なんじゃないかと思いました。
 DVDはその容量を、長さを増やすことではなく可聴領域を超える高周波のた
めに使うべきなのかもしれません。
 CDで育った世代には音楽好きは少ないかもしれません。音楽を聴いて気持ち
良くなるという体験がLPで育った世代に比べ少ないでしょうから。

Takeshi Yoneki

Subject: Software DRAQUE
Date: Tue, 25 Feb 1997 15:02:15 +0900
From: Takeshi Yoneki

 質問には逆から答えよう。楽な順というか長さの逆順だな。

>>(その三)
>>
>>日曜日に練プ連副会長から電話があり「春会やらないの?」との質問あり。
>>会長殿は三月ぐらいのご予定はどうでしょうか?

いまのところ3月には何の予定も入っていない。
ヨキニハカラエ。

>>(その二)
>>
>>上記と関連するんですけれど、文字列で何かを初期化する場合
>>
>> char Msg[] = {"ErrorMessage!!"};
>>
>>こうやると"ErrorMessage!!"文字列分の領域が確保されると思います。
>>
>> char pMsg * = "ErrorMessage!!";
>>
>>こうやった場合"ErrorMessage!!"文字列分の領域が確保されたあと pMsg のメモリが獲得
>>され、アドレスが格納されるんでしょうか?。 上下の意味合いの違いがよく分かりません。
>>(雑誌のサンプルコードに下の記述方法をよく見かけるんですけど・・・)
>>

 上記2つの違いをノベルはNetWare。便宜的に上をア、下をイとする。ア
は文字列の領域のみを確保する方法。イは文字列の領域はモチロンだが、その
ポインタが実体として存在する方法。イの方法はアの方法に比べ(32bit機なら)
1文字列毎に4Byte余計にメモリを食う。
 余計にメモリを食うのになんで下の方法を良く見るのかというと、アの方法
ではメッセージを配列にはできないけど、イの方法は配列にできるなど、取り
扱いが楽になるからだ。これは問いの(その一)にも関係する。
 externでの参照も違う。
アは
extern char Msg[];
と書かなくてはいけない。
イはもちろん
extern char *pMsg;
となる。
 使うときの記述が同じだから、同じように扱えると思ったら大間違い。ポイ
ンタの実体があることとと配列の先頭のアドレスが参照できるってのは全然意
味が違うのであった。イのpMsgには代入できるがアのMsgには代入できないっ
てのが大きな違い。
 ポインタとアドレスの違いはCプログラマの優劣の分かれ目なんできちんと
理解しようね。「同じように扱える」は「本当は同じではない」ということだ
から。

>>
>>(その一)
>>
>>ロジック構築段階においての僕の疑問について師匠の意見を伺いたいのですが
>>よろしいでしょうか?。
>>
>>概要:何らかの処理を行っている時にエラーが発生した場合、特定の領域に
>> エラーコードを設定して、上位にエラーが発生している旨を通知する。
>> 上位層は通知を受けた後で、そのエラーコードを参照してメッセージ表示
>> を行う。エラーコードは順列値ではない。エラー原因によってエラーレベルを
>> 判断し、エラー表示方式を切り換えたい。(GetLaseError()のイメージ)
>>
>>僕の設計:エラー情報テーブルを以下の用に持つ
>>
>> struct ErrorInfo {
>> DWORD ErrorCode:
>> DWORD ErrorLevel:
>> char ErrorMsg[256];
>> }
>>
>> この構造体をエラーの数だけ構築し、それぞれの内容を
>> 各エラー項目に合わせた情報で初期化しておく。エラー発生時に上位層から
>> 渡されたエラーコードでテーブルを検索し、エラーレベル、エラーメッセージを獲得、
>> エラーメッセージを表示する。
>>
>>心配点:これって標準的な方法何でしょうか? エラーの数分テーブルを
>> 持てば改造は楽かもしれませんが、数が増えた場合問題無いんでしょうか?
>> 今まではエラーメッセージ等は#defineで定義していたので、メモリ領域とか
>> はあまり問題視していませんでした。今回はエラーコードに対応してメッセージ
>> を検索しなければならないので#defineが使用できません(ですよね???)
>> なので上記のような方法を考えたのですが、どうでしょうか?
>>
>>結構マジで悩んでいます。動けばいいというのであれば上記のもので問題ないんですが
>>どうも府に落ちません。エラーメッセージ表示処理の一般的な方法というものが
>>存在するのであればご享受できないでしょうか?
>>

 もう答えはわかっているね。
A
	struct ErrorInfo {
		DWORD  ErrorCode;
		DWORD  ErrorLevel;
		char   ErrorMsg[256];
	}
ではなく
B
	struct ErrorInfo {
		DWORD  ErrorCode;
		DWORD  ErrorLevel;
		char   *ErrorMsg;
	}
とすべきだろう。
MFCが使えるなら
C
	struct ErrorInfo {
		DWORD  ErrorCode;
		DWORD  ErrorLevel;
		CString ErrorMsg;
	}
でもよい。
 Aはメッセージひとつごとに必ず256バイトのエリアが必要となるが、エラー
メッセージなんて40バイト程度が相場。とてつもない無駄になる。配列にする
ときの制限としてサイズが固定されるのは(その二)を理解すればわかると思
う(不定長の配列はCの仕様にはない)。
 Bは不定長の配列が作れないという限界をポインタを使うことで解決したも
のだ。メッセージファイルから読むならmallocで結び付けてもよかろうし、ソー
スに書くなら普通に代入すれば良い。
 エラー表示関数を工夫して、エラーメッセージがNULLだったらコードとレベ
ルから簡単なメッセージを作って表示するようにすれば、ユーザレベルが見な
いはずのメッセージを省略できるし、そもそも、メッセージが完成していなく
てもプログラムとして確実にエラー表示できる。
 CStringはchar *に比べれば多少多くのメモリを消費するが、char[256]みた
いに馬鹿食いはしない。

 こんなもんかな。

Takeshi Yoneki

 PM8500への環境移行も済んで、次はHUNDOSHI-EDITのリリース向け仕上げだ。かなり久しぶりのアップだがさほどの変更があったわけではない。改行と漢字の自動コンバートをするようになった程度だ。
 かなり久しぶりにアバウトダイアログのレイアウトを変更し、プログラムでバージョンとリリース年月を表示するようにした。アバウトを見て68K版かPPC版かの判断をしたかったからだ。
 引用符プラグインの後藤さんに連絡を入れなくちゃいけないなぁ。

 褌満点音頭のデータをQuickTime2.5に合わせて調整した。ドラムスを中心に音色の大幅改定がなされているため、従来のデータではかなりバランスが崩れて再生される。シンバルの音がやたらとでかいのだ。これはQuickTime2.5の方のバランスが悪いんだと思うんだが、また改定するんだろうか。他環境向けのファイルを演奏させるとどうなんだろうね。ウチにはいわゆるGMデータ再生環境がない(あるのはGM以前の器材ばかり)んで聴き比べはできないのが残念。
 音そのものは以前に比べ格段に良くなった。根本的にショボいのはしかたないとしても、前のはあまりにあんまりだった。PM8500にAT互換機を買ったときに付いてきたスピーカを接続し、QuickTime2.5環境で演奏させるとかなりイケる。Master Tracks Pro 6は直接内蔵音源で演奏できるのでデータ調整も非常に楽だ。MoviePlayerを使って標準MIDIファイルをコンバートすると、オプションでQT2.0互換が設定できる。これでMIDIデータのプログラムナンバー(音色番号)をいちいちズラして保存する必要がなくなった。
 IIcxではそもそもまともに音がでなかった(処理が重過ぎて)。やはり速いマシンは良い。

 前回アップ時のアーカイブを参考にしようとMacLHaを使うとExtract指定で必ずコケる。_CalcMaskとかいう関数だ。よくよく調べると、アーカイブに含まれるフォルダ名と同じ名前のファイルがあった。これが原因となっていたようだ。あんまりチェックはしてないんだね。

 困ったことに、キャラベルのAV-1000HGをPM8500に接続すると、ディスクが回転しない。PM8500の電源を入れる以前に外付けのディスクが回転しないのだ。キャラベルに電話するが(非常につながりにくかった)こういった症例はないそうで、解決にはほど遠い。
 キャラベルでないディスクはちゃんと動作しているし、キャラベルのディスクも他のマックでは動作している。他のPM8500が存在すれば試験もできるんだがなぁ。お姉ちゃんに頼もうかな。
 ひとつ懸念材料がある。PM8500の内蔵ディスクは本来の製品構成ではない増設したものであろうということだ。旧型PM8500のディスクが2GBだったとは思えない。このSeagateディスクがキャラベルのディスクと喧嘩しているのではないかという可能性がある。そもそも内蔵用かどうかも怪しい。
 今アップル(株)のサイトを見たら、旧型PM8500のディスクは1.2GBまたは2GBとある。純正の可能性もあるってことか。ともかく内蔵ディスクを外しての実験が必要だな。
 私はSCSIでトラブらないマック買ったことないぞぉ。

1997.02.27

 PM8500の内蔵ディスクはアップルマーク付きの純正品であった。昨日はモニタ画面に変な点線が入ったし、どうも不良っぽいなぁ。

1997.02.28

「ホーム」へ戻る
「読まなくてもいいよ16(前編)」
OSTRACISM CO.
OSTRA / Takeshi Yoneki