とりあえず昨日悩んでいた goto の問題はなんとか使わずに済ませることが出来た。
てーか、while() ループの中で continue と break を使って無理矢理解決したのだから表面的に goto を使っていないだけかえって性質が悪いと言うべきかもしれない。
あのコードを読んで一目で何をしてるか理解できる人がいたら、それはきっとすごいひとなのだろうなぁ。コメントは何も入っていないし、予備知識としてヘッダ文字列がどのような形なのか持っていなければ絶対にあれは理解不能だと思う。
まあ、少しくらいはコメントを入れておいた方が親切なのかもしれないけど、あんなコードを読みたがる人は少ないだろうから気にすることはないか。
まあ、比較的素直なソースだからドキュメントといっしょに上から順に読んでいけば悩むことも無いだろう。（基本的にトップダウンな書き方だし）
と言う訳で、うんあれはあのままに公開してしまおう。
あの世界では自助努力が基本だし、ま、読みたい人には苦労してもらうことにしよう。
駄目だなぁ。本当にどうしたのだろう。最近日記の更新をサボリっぱなしだ。まあそれなりに忙しいしいのはあるけど、最近も約束をついうっかり忘れてしまうし。
あまり忙しくならないようにと予定を一応立てているつもりなのだが、それでもついついやらなければいけないことを忘れてしまう。
やっぱり元からいい加減な性格なのがいけないのかなぁ。
いまさら悔い改める気にもなれないし……。どうしよう。
久しぶりに秋葉原まで出かけた。まあ、散財しようにも元手が無いので出来ないのが悲しい点なのだが。
とりあえず新製品として IBM の DeskStar 25GP (IDE DMA/66 対応の 5400 rpm 25G) が幾つかの店で確認できたのが気になる点といったところだろうか。
これは IBM の GMR ヘッドを利用した第二世代 IDE ドライブで、既に幾つかの WEB ページで公開されているベンチマークでは 17M/sec を記録している（DMA/33 として接続時 HDBENCH 10M byte READ/WRITE の測定値）ので気になってはいるのだが、さすがに出たばかりの現在では８万円弱という手が出ない価格なので暫くは眺めているしかないのが悲しい点である。
とりあえずビデオキャプチャをメイン用途として考えている人間として G Byte 単位での WRITE 性能が気になるのだが、流石にそれを実行しているところは見つけていないし、買って試すわけにはいかないからなぁ。
DeskStar 16GP シリーズ (DTTA 35XXXX) で一世を風靡した IBM 製なのだから、今回のものでもやはりそれなりの静粛性と耐熱性を備えていることだろうと期待できるのだが……。
どちらかというと 22GXP シリーズ（7200 rpm モデル）の方が気になっていたりするのだよなぁ。（でも IBM は 7200 rpm モデルでは伝統的に安全性を求めて線記録密度を下げるからなぁ、劇的に速度が変わるわけじゃないんだよね）
まあ、どこからか G 単位での書きこみの安定性＆速度を求めるなら SCSI で RAID-0 を組めという声が聞こえて来るような気もするのだが……。
多分あっという間（おそらく３ヶ月〜半年程度）に現在の DTTA レベルまで値が動くだろうからそれを待つのが一番なんだろうなぁ。
で、物欲その二。
Canopus Power Capture Pro（アナログ M-JPEG ビデオキャプチャの最高峰）
これもやはり８万弱するため先立つものが無く、手を出せない。
こちらは競合他社が少ない＆市場が小さいため今後値が動く可能性も低く、ひょっとしたら学生の間は永遠に手に入らないかもしれない。
でも、HDD の転送速度向上には今のところ障害が多いし、やっぱりハードウェアでの動画圧縮機能が欲しくなるし、それならいっそ 640x480 も欲しくなってくるのだよね。
まあ一つクラスが低いものでも良いかと思うのだけど、それでもやっぱり５万はするのが……。
ああ、先立つものさえあれば……。
すこし暮し向きを節約することにしよう。うん。
最近遊んだ二つのゲーム。RISE の「RISE」と evolution の「Machine Maiden」
まあどちらもジャンルだけ見ればロボット AI 育成物で良くもまあこんな内容が似たものが発売日が一日しか違わない状態で出てきたものだと思うほどだけど、実際に遊んでみるとこれがなかなか味付けが違っていたりする。
「Machine Maiden」は古き良き育成ゲームの流れを汲み、パラメータ等の条件のみで最終職業が決定するというタイプのもの（途中発生するイベントなどもパラメータの変化としてしかエンディングには寄与しない）なのだが、「RISE」はパラメータはグッドエンドとバッドエンドのエンディングの振り分けにしか関与せず、途中でどのようなイベントに遭遇したかによってエンディングが変化するという形になっている。
最初に RISE からクリアした為かもしれないが、Machine Maiden のゲームシステムよりは RISE のそれのほうが好ましいと私は感じてしまった。
グラフィックは Machine Maiden の方が私の好みだし、個々のイベント自体に関しては RISE, Machine Maiden の双方とも甲乙つけがたいと感じる。ゲームのプログラムとしての安定性を比較すれば間違い無く Machine Maiden の方が（シナリオの整合性については別とする）上だろうし、声に関してもフルボイスで作られているだけ Machine Maiden に軍配が上がるだろう。
ただ、一つのゲームとして遊んでいると私は Machine Maiden にどうも違和感を感じてしまう。単調な作業と化してしまう（チップアニメーションすら無い）育成パート、突き放された世界観、イベントに一切遭遇しなくても到達可能な（いわゆる）トゥルーエンド。
良い部分も数多くあるのに、どうしてと考えてしまうほどにゲームとしてはつまらない。このゲームを楽しむにはバイナリエディタが必須だと考えるのは私が軟弱な為なのだろうか。（少なくとも RISE をやっているときはバイナリエディタは欲しいとは感じなかったが）
とりあえず、私が Machine Maiden を楽しむために必要としたデータを以下に示しておく。なお、使用したバイナリエディタは stirling である。
昨日の続き。
やっぱり Machine Maiden にあれほど違和感を感じるのは育成対象の部屋を訪れた際に発生する一連のイベントに対する嫌悪感なのだろうか。
まあ、秘してこそ花などと主張するつもりは無いのだけど、正直に告白するならば、やっぱりそれなりの順序というか手順を踏んで欲しかったということは確かにある。
それとも、違和感の原因はシナリオの意図が読めない事だろうか。
そういうモノとして最初から作られたのならば、こちらとしてもそれを否定する訳では無いのだから純粋に楽しむのだけど、他のイベントなどを見ているとどうもそういうものが作りたかったようには見えない。
何となく、こう言うのがあったら良いなと感じたイベントを前後の脈絡無く詰め込んでいるだけのようにも見えるし……。
借り物の言葉を並べた未消化なものをイベントとして提供しているようにも見えるし……。
シナリオさえもう少し練り込んでおけばもっと良いものに化けただろうに、なまじ絵が良いだけに悲しいことだよなぁ。
本日以降、四月までの発売日確定物からの私的注目作。
３月、１２日「リトル My メイド」・２５日「守り神様」・２６日「さよならの微笑み」
４月、８日「虚像庭園」・９日「終末の過ごし方」・同９日「略奪」・１６日「SEVEN」２３日「お兄ちゃんといっしょ」・同２３日「リップスティック・アドベンチャー」２８日「こみっくパーティ」
さて、どれを実際に購入するかが問題だ。
とてもじゃ無いが全部は試せない。ほぼ確定なのが「さよならの微笑み」・「終末の過ごし方」・「お兄ちゃんといっしょ」なのだが、これだけでもかなり財布的には厳しいからなぁ。
何かを追加するような余裕は無いのが非常に悲しかったりする。
あー、空から金でも降ってこないかと考えるのが間違ってるのかなぁ。
追記（あるいはメモ）
スペースや日本語コードなどを含んだボリュームラベルの CD を GEAR for UNIX でバックアップする場合。
とりあえず ISO トラックのイメージ（仮想イメージで良い）を適当なボリューム名で作成し、fugahoge.i01 を bvi や fb 等のバイナリエディタで書き換える。（力ずくな解決法だなぁ）
ビデオ録画の昨日放送分「彼氏彼女の事情」を見る。
２点。つまらない。見る価値なし。
以上感想。実際見事なまでに全ての条件が悪い方へ悪い方へと働いていくのを見るのは悲しいものがある。
見ている側としてはもう見るのを止めて春からの新番組に期待すれば良いのだけど、作ってる側の気分としてはこういう時どういうものなのだろう。
まあそれが判ったところで何ができるわけでも、何かが変わるわけでもないのだけど。
でも、現場で上からの指示で動くしかない人達の考えとか、見守ることしか出来ない原作者の意見とか、クライアントの訳の判らない制約に縛られる脚本書きの鬱憤とか、既に予算を使い果たされてから責任を押しつけられた監督の諦念とか（後半二つは噂に基づく憶測なので信用しないように）そういった本音が聞けると楽しいだろうにとやっぱり考えてしまう。
あー、どこかにこれ系の怪文書扱ってるサイトとか無いのかなぁ。そうすればテレビ放映分のあれはあれとして、また別の楽しみ方が出来るから覗いてみたいのだけど。
実際そんな楽しみ方でもしなきゃやってられない。
少し余裕（時間的・精神的な）が出来たので自宅の Linux のカーネルを 2.2.3 にバージョンアップしてみた。
ついでに ALSA も 0.3.0-per3 から pre4 にバージョンアップさせてみる。とりあえず TiMidity、mpg123 ともにリコンパイル無しで無事に動いてくれたようで安心した。
2.2.3 に上げた為か、それともコンパイル時のオプション設定を適切なものに変更した為かは不明だが、FUJITSU の MCB3064AP（IDE 接続内蔵型 640M MO バルク）を無事に IDE SCSI Emulation でリムーバブルメディアとして認識してくれるようになった。
VFAT フォーマットの 640M MO も大学の Solaris でフォーマットした 230M MO も無事に読めることを確認できたので有難い。（試してはいないが、Solaris フォーマットの MO へのデータ書き込みは ufs フォーマットへの書き込みをオフにしておいたので無理だろう）
とりあえず、カーネルのコンパイル時のオプション設定で関係ありそうなものとしては、CONFIG_BLK_DEV_IDE=y, CONFIG_BLK_DEV_IDESCSI=y, CONFIG_SCSI=y, CONFIG_BLK_DEV_SD=y, CONFIG_CHR_DEV_SG=y, CONFIG_UFS_FS=y の６つである。（恐いので試していないが、CONFIG_UFS_FS_WRITE=y に設定しておけば Solaris でフォーマットした MO に書き込みも可能になるだろう）
マウント時のコマンドラインは mount -t ufs -o ufstype=sun /dev/sda /mnt/mo でエラー無くマウントでき、中身を確認することが出来た。
これにはいろいろと嬉しい効能はあるが、何よりも嬉しいのはこれで mo に溜め込んでおいた ML からのメールを何時でも家で確認できるようになることだったりする。
他にも、これからはいちいち MO ドライブの電源が既に入っているか確認しながら空いている端末を探さなくても良いようになるということもかなり嬉しかったりするけれども、まあそれは二次的なことに過ぎない。
現在 C でのパターンマッチに挑戦中。
やっていて酔狂以外の何物でもない行為だとしみじみ実感している。まあ、一通り組みあがれば後は簡単なのだろうけれども、それでも途中まではちっとも動くものは出来あがらないし、何時になったら完成するのか見えてこないし、新しく問題点は湧いてくるし、やる気が失せることこの上ない。
本当にどうしてこんなやくざな言語が世の中に幅を利かせているのか理解に苦しむ。
まあ、Perl を覚えていればこんな苦労はしなくても済むのだろうけれども、まだ私の Perl の知識はプログラムを組めるほどの物ではなかったりするので……と食わず嫌いをしているからいけないのだよなぁ。
なまじ中途半端に C でプログラムを書ける程度の知識があるばっかりに他の言語を覚える気になかなかならないのだから、この害はかなり大きなものがある。
これが Fortran しか使えない状態だとしたら、あっさりとより沢山の機能が備わっている Perl とかに流れるだろうけれども、基本的に UNIX の世界で C で出来ない事というのは無かったりするからなぁ。
本当に業が深い。まあ、いずれは通らなきゃいけない道だと思ってあきらめて苦労することにしよう。（とかいってるうちに別の言語が一般的になったりしたら嫌だなぁ）
とりあえず、今回は今まで使用を避けてきた構造体を使わなければどうしようもなさそうなプログラムだし、良い勉強だと思って……。
人生ってなんだろう……。
人は何で生きてるんだろう……。
さて、勘の良い人ならもう気がついていますね。そうです、成績表が送られてきたのです。
え？ まだ判らない？
そうですね、明治大学の一般的な方法を知らなければ成績表が送られてきたからどうしたのだと言うかもしれませんね。
コスト削減の為かは知りませんが、明治大学では一般に、特に問題が無い限り成績表は送られてくる事はありません。
えーともう判りましたね。そうです。何か成績表が送られてくるような問題が発生したわけです。
そういうわけです。はい。これ以上は今のところ何も書く気にはなれません。それでは。
いつまでも落ち込んでいるわけにはいかないので、少しは前向きにソースをハックしたり、SGS-THOMSON nVIDIA RIVA 128 や Philips Semiconductors Inc. SAA7111A のデータシートを読んだりしているのだが……。
まあ、普通の行動じゃないとか言われるだろうということは判っているので置いておくとして、ASUS AGP-V3000/TV は随分ともったいない事をしているようだ。
SAA7111A は無圧縮 YUV 4:2:2 (16bit) でフルスクリーン（720X582）が取れるようなのに、RIVA 128 に接続して制御してるばかりに、CCIR-656 (8bit) でしか取りこめなくなっているらしい（データシートを読む限りでは）
しかし、RIVA 128 のデータシートを読んでいてもビデオポートをどうやって制御すれば良いのかが見えてこないのは困ったものだ。
とりあえず CCIR 656 と PCI、AGP に関しての資料を集めなければいけないらしい。RIVA 128 Programming Reference Manual というのもあるようだけど、なんだかこれは Windows 用に開発されたドライバの利用法のような気もするし……、TMP Design Guide はもっと違うものだろうし……。
いきなりこういうものに手を出したのが間違いだったのかなぁ。
袋小路に入るまではこのまま突っ走ってみる予定だけれども。