劇場版AIRのCMを見ました。劇場版なら、作画が死ぬ心配はあまりしなくていい *1 かな、というか、そもそも映画館では見ないし、DVD版でリテイクされるだろうから問題ない。気になることと言えば、あの長い話をどうやって2〜3時間で収めるのかなー、とか、声優陣が豪華だなー、とか。
bk1で土曜日に注文した、「24時間以内に発送」となっていた本が、水曜日に発送されて今日ようやく届きました。なんだ、「24時間以内に発送」されるのは「ご注文確認メール」だけか。
別に、急ぐものではないけども。
bk1とBooks.or.jpでもISBNから直接情報を取得できることがわかりました。ただ、amazonと比べると、どちらもHTMLがかなりアレで情報を取得しにくいため、利用価値は薄いですね。
ちなみに、HTMLからの情報取り出しには、Patraのヘッドラインセンサを使いました。
関係ないですが、「ヘッドラインセンサ」というと、「伺か」のあれとごっちゃになりそうなので、別の呼称にしたいですねー。ヘッドラインキャプターさくらとか。
なんか、すごい、雨。雷鳴は爆発音みたいだし。出かけなくて良かったなあ。
昼間、何気なくPCの電源を入れたら、ディスプレイの中央付近に横線が映るだけでBIOSの画面が出ません。ビデオカードがいかれたかな、と思って調べてみたら、いかれたのはディスプレイのほうでした。
前兆みたいなのはありました。数ヶ月前から、ときどき所謂VGAモード(640x480)にしたときに、妙に横長になってしまい、両端がはみ出てしまうという現象起こっていました。そんなときには物理的衝撃、具体的には、「なんでやねん」の要領で水平チョップを食らわせると直るのですが、今回ばかりは「なんでやねん」でも「んなあほな」でも直りません。
今となっては貴重な、水平周波数15kHzに対応した15インチCRTディスプレイです。学生の時分にアキバで購入し、キャリアカートに乗せてせっせと自宅まで持ち帰ったものです。保証書を見ると、購入日は1996年9月となっていますから、ちょうど8年間使っていたことになります。よくぞ今まで、これといった故障も無く動いてくれました。合掌。
いやいや、感慨にふけっている場合ではありません。ディスプレイが無いと何もできないではないか。そんなわけで、ディスプレイを買いにアキバへ。
どうせ買うなら液晶ディスプレイ、ということで、店を廻ってみたのですが…配置の関係からサイズは17インチ、LD、DVD、ゲーム用にS入力端子が必要、応答速度は16msより速いもの、となると、必然的に買うものは決まってしまいます。それがI-O DATAのLCD-TV173CBRです。液晶ディスプレイは多々あれど、私にとっては選択肢は無いも同然。
配送は無料でやってくれるそうなのですが、送ってもらっても平日日中は家にいないので、持ち帰ることにしました。結構重かったよ…
セットアップ後、ドット抜け簡易チェッカーをちょいちょいと作って *1 ドット抜けを確認したら、早速見つけてしまいました。右上の方に赤い点です。青地、黒地背景だとかなり目立ちます。すごく気になります。ドット抜け交換保証に加入してあるので、後日交換してもらいましょう。
ディスプレイを買う前に購入しておいたTHE お姉チャンバラをやってみました。各所で「惜しい！」と評されていますが、まさにその通り、非常に惜しいソフトです。2面クリア時点での私の不満点は次の通り。
最後のはご愛嬌ですが、これ以外は特に問題なし。むしろ、2100円（税込）でこの内容なら主婦も納得、お勧めのゲームです。暴走状態での居合い抜きで、数十体のゾンビを一撃の下に切り捨てる爽快感。たまりませんな。
しかし、やっぱり赤のドット抜けが気になるなー
3面でカプセル稼ぎをしたり、サバイバルモードで殺されてみたり。強くなったところで4面クリア。
ゾンビ警官、むかつくなあ。
THE お姉チャンバラって、チャンバラと言うよりは一方的な斬殺のような気がします。ちゃんちゃんばらばらしてないし。
とりあえずEASYをクリア。隠しコスチュームへの道は険しい。
置く場所が以下略。
お姉チャンバラ。未だにNORMALをクリアしてません。今日はカプセルを稼いだり、サバイバルで遊んだり、まったりと斬りまくってました。
妹服取得…もとい、VIOLENT制覇はいつの日か…
2.23β4でビルドしてみた。β3までの時とは違って、すんなりコンパイルが通る。数箇所の修正は必要だが。
例の DeeLibPNG.lib はバイナリで提供されていたので、リンクもばっちり…かと思いきや、LibJPEG2.libがなくて引っかかる。 IJG LibJPEG.lib を LibJPEG2.lib にリネームコピーして強引にリンカを通すも、今度はLibERINA.libが無いとおっしゃる。なんでだろー、ファイルはあるんだけどな。よくわからないので、また明日。明日できることは今日やらないのがモットー。
2.23β4でビルド。LibERINA.libリンクエラーは、src\core\environ\win32\bcb6\tvpwin32.cpp 中のUSELIBしてる部分で、LibERINA.libのパスが違うのが原因。修正したら無事LibERINA.libはリンクできたが、そもそもERIフォーマットを使わないのでTVP_SUPPORT_ERIをundefしてリメイク。
今度こそ、と思ったら、またもやリンカエラー。[リンカ エラー] 外部シンボル '******' が未解決（XXX.OBJ が参照）が60個くらい出た。boost::regexとかlibpng関連。ライブラリはリンクされてるはずなんだが…何故だ。
智美メール キター。
バリエーションとしては春香メールとか彩香メール とかいろいろあるようです。うちに来たのは２２歳でフリーター
なんだそうです。文体からして「春香メール」よりもSPAMな感じが強いです。まだまだですね。（何が）
まだ読んでませんが、ハインラインの「夏への扉」に出てくるアレこそが元祖メイドロボではないか、という疑惑が浮上しました。疑惑？
今度読んでみましょう。
W.Deeさんが貴重なリソースを提供してくださったおかげで、問題解決の糸口が見つかる。PNG、JPEG周りのリンクエラーは、おそらくバージョンの違いが原因だろう。libpngは1.0.6が手に入らなかったので1.0.16を使う。zlibは1.1系が手に入らなかったので…どうしよう。とりあえず頂いたライブラリ群から持ってくるか。バージョンを合わせてみたら、見事にリンカエラーが消えた。
残るはboost regex関係（かな？）。boostライブラリを再構築してみるも、相変わらず「re_detail::*** がない」と言ってくる。W.Deeさんの作ったboostライブラリをリンクさせれば、この部分は解決するんだが。何が違うんだろう。
レーベルに対応してみました。書籍ごとの項目が増えてきたので、表形式にも対応しました。量も増えてきたので、出力ファイルを分割したほうがいいですかね。
ついに吉里吉里ビルド完了。なんか、幸せ…
メモメモ。boost regex関係のリンカエラーは解決。boost regexのバージョンが違うのが原因だった。1.30系を使わないといけないようだ（1.31.0だとnamespace re_detail関係でリンクに失敗する）。
そういえば、1.30付近でregexが大きく変わった、というような話を聞いたことがあるような、ないような。関係ないか。
このほか、謎リンカエラー[リンカ エラー] Section ConstSeg defined in .def file is empty 等で途方にくれていたが、W.Deeさんに聞いたら即解決。thx!
PNG画像が読めないことに気付く（Layer.loadImagesでEAccessViolation）。JPEG, BMPはOK。PNGライブラリの作成方法、リンク方法がおかしかったようだ。作り直して解決。
そうそう、忘れないうちに、構築手順をおさらいしておこう。TODO。
…考えてみれば、TLG6があればPNG要らないかなー。性能差は歴然としてるし。PNGまわりの機能って、はずしても大丈夫かなあ。今度やってみよう。
Digital MarsC++ Compiler で吉里吉里付属のサンプルPluginを作ってみる。
DLLファイルはできた。吉里吉里Plugins.linkでリンクもできた。が、いざ関数をコールすると、そんな関数ないよん。
と言われてしまう。ガクッ。Bcc32で作ったDLLならちゃんと呼べるから、DMCでのコンパイル or リンク方法が悪いのかな。
真希メール キター。
構成や書き方が素人っぽく、文章も短いながらも、ついつい返信したくなるような文面になっています。前回の智美メールよりはよくできています。まあまあですね（何が）。
さて、次は何でしょうね。どきどき。
IRC:#うにっくす:*.jp でuzuraの発言を見ていたのですが、本当に良くできています。人間よりも鋭い突っ込みをしてきます。恐ろしいですね、これは。
メモメモ。レイヤ全体にグラデーションをかけるDLLプラグイン関数を作成。不透明対応。
iTJSDispatch2経由で何度もLayer.colorRect()をコールするのがちょっと嫌だったので、吉里吉里ソースを漁ってLayer.colorRect()の実装を探り、ほぼ同等の機能を実装してみる。core\visual\LayerBitmapIntf.cpp, LayerIntf.cpp, LayerBitmapIntf.h, LayerIntf.h, tvpgl.hあたりを見ると、Layer.colorRect()の不透明処理・アルファブレンドの実装には TVPAlphaBlend_o(), TVPConstColorAlphaBlend_d() が使われているようだ。嬉しいことに、これらは tp_stub.h に定義されている *1 。
左→右進行のグラデーションにはTVPAlphaBlend_o()を、上→下進行のグラデーションにはTVPConstColorAlphaBlend_d()を使ってみたが、なんとなくこれで大丈夫そう。不透明度処理に関してはLayer.colorRect()とほぼ同等のはず。
プロ野球選手会がストを決定したそうですが。
プロ野球に興味がないので、ストライキでもストリップでも勝手にやってくれ、と。番組が野球放送で潰れるときくらいしか、プロ野球など気にもしません。エマのアニメ化の方がよっぽど気になる。
makestub.plをいじってtp_stub.h, tp_stub.cppを高速化改造した…つもりだったが、生成されたDLLファイルがでかくなった上に、ちっとも速くならなかった。がっかり。
不透明度処理に関してはLayer.colorRect()とほぼ同等
…どころか全然違ってた。同等なのはdfAlphaだけだった。がくっ。描画クリップ領域を無視してるだとか、描画方式を無視してるだとか、その他いろいろ無視しているという、かなりトンデモな仕様。まあ、おいおい対応していくとしよう。
今日は今まで作ってきたグラフィック系関数を（中途半端に）不透明対応にしてみた。
あと、プラグインインターフェース部と実装部を分けた。
additive alphaや他の描画モードがどうなっているのか確かめるため、レイヤ関係のソースを漁る。読む。パクる。吉里吉里のソースをDLLプラグイン用としてそのまま持ってきたいところだが、そうすると痛い目に会いそうな予感がした、ていうか以前痛い目に会ったような気がするので、部分的にパクることにした。本家と実装がダブってしまうが、これは仕方がない。本家の変更にはできる範囲で追従するようにしよう。
…ComplexRectはそのまま持ってきても大丈夫っぽい。
Mozilla系はどうしてころころインターフェースが変わるんだよ。どんどん使いにくくなっていくよ。ユーザが増えない一因のようにも思える。
松屋のビビン丼はなかなか美味いです。うまトマハンバーグ定食以来のヒット作ですね、俺的に。豚めし *1 、デミたまハンバーグ定食 *2 、うまトマロールキャベツ定食 *3 と、いまいちな新商品が続き、食べるものが豚焼肉定食しかないという松屋暗黒時代にも、ようやく光明が見えてきました。がんばれ松屋。
dfAddAlphaにちょびっとだけ対応してみた。まだ実験フェーズだが。こうやって、ちょっとずつ機能を追加していく予定。これぞ牛歩戦術（違）
怪傑ズバットのDVDボックスを買ってきました。いろいろとキューが溜まっているので、観るのはだいぶ先になりそうです。
ジュリア集合描画プログラムを作ってみた。
複素数演算部（収束・発散判定）は高速化のためにC++で書いて、DLLプラグイン化。TJS配列オブジェクトとその他パラメータをプラグイン関数に渡してやると、配列オブジェクトに計算結果が格納される。格納された各値をカラーコード算出関数（TJS実装）に渡すとカラーコードが得られるので、これをレイヤの各点に対して setMainPixel() する。
レイヤサイズ640x480、複素座標領域 (-1,-1i) - (1,1i) の描画が約5秒。内訳は、収束発散判定が1秒未満、全点のカラーコード算出が約1秒、残り約3秒が setMainPixel() によるドット打ち。この結果は、だいたい予測の範疇かな、といったところ。
TJS実装の部分全てをC++実装にしてしまえば、確かに速くなる。しかし、カラーコード算出関数だけは、柔軟性を持たせるためにTJSで実装したい。色付けはフラクタル画像の大きなファクターなので、手軽に着色方法を変更できたほうが良い。
続きは明日。
TJSで定義した関数を、DLLプラグインから呼ぶ方法。
... iTJSDispatch2 * func = param[0]->AsObjectNoAddRef(); static tjs_uint32 hint = 0; tTJSVariant res; func->FuncCall(0, NULL, &hint, &res, 0, NULL, func); ...
とりあえず、これでOKっぽい。TJS関数が引数を要求するときは適宜変更。
setMainPixel() でドット打ちしていた部分を、C++で実装。オーバーヘッドがないので、速い速い。
ということは。
全ピクセルについて、TJS実装であるカラーコード算出関数を毎回呼び出すと、呼び出しオーバーヘッドのために少々時間がかかる。そこで、「ループ回数」→「カラーコード」とマッピングした、要素数256の unsigned int 配列を作成しておき、全ピクセルについてこのマップを適用するようにすれば、カラーコード算出関数を呼び出す回数が少なくて済む。30万回呼び出すのと、256回呼び出すのとではずいぶん違う。
これで、この部分はかなり速くなる。が、元々大して時間のかかる処理ではないため、体感速度はあまり変わらなかったりする。
演算〜描画まで約5秒かかっていたものが、カラーコード算出関数以外をC++で実装し直した結果、だいたい1秒前後に収まるようになった *1 。おおむね満足。
まとめてキュー消化中。
「起こし方その３」の謎を残したまま逝ってしまったエリノアさん。
エリノア… エリノアのいないMADLAX… エリノアのいないMADLAXなんて…
カラーコード算出関数を辞書配列にして、着色方法を簡単に切り替えられるようにした。お手軽。
対象の複素座標領域をマウスで指定できればいいなーとか、セーブ機能が欲しいなーとか、マンデルブロ集合も描けるといいなーとか、いろいろ欲しい機能はあるが、実装が面倒。ユーザインターフェースはKAGで作ろうか。
Mini-ITXマシン、BeSilentを修理に出してきました。メインボード交換になるでしょう、とのこと。もちろん、保証期間内なので無料です。
その足で覚醒plusをゲット。東方永夜抄が委託販売されているはずなんですが、入手できませんでした。まだ店に並んでないのか、売り切れていたのか、探し方が甘いのか。
今日もアキバ。アクメツ(9)と東方永夜抄ゲット。ちゃんと探せばあるじゃないか。
急に寒くなったせいか、風邪気味です。困った困った。
音楽は良い。CD-Rメディアの質は悪い。音楽用ソフトに、何故こんなメディアを…
CDプレイヤーで再生すると、音を取りこぼしてプツプツ途切れます。スピーカーで聞いているとわかりにくいのですが、ヘッドフォンで聞くと顕著に表れます。LD/DVDプレイヤーで再生するとそういったことは起こらないので、CDプレイヤーを疑ってもみましたが、他のCD-Rメディアでは起こりません。CD-ROMドライブに突っ込んでも認識しにくかったし、それ以前に見た目からして明らかに安物だし。
焼きなおさないとダメですね、これは。
交換を依頼していたディスプレイ、到着。MADLAX最終回で動作（？）確認。ああ、ドット抜けがないって素晴らしい。
イージー霧雨魔理沙でさっくりクリア。
嘘です。「どうにか」クリアです。イージーごときで4ミスもしているようでは（略）
例のCD-Rと格闘。アレンジ自体は良いものなので、何とか焼き直して「普通に」再生したいところ。そのためには、正常に取り込むところから始めないと。
まず、YAMAHAのCD-Rドライブで読んでみましたが、読み込みエラー出まくりです。もともとこのドライブは変なメディアには弱かったので、ある程度は仕方がないとしても、1曲分読んだだけでエラー数50ってのはちょっと…
次、松下製DVD-Rドライブ。CD読み込み機能はあまり充実してませんが、読み込みエラーはほとんどありませんでした。これはいけたか、と思いましたが、いざ聞いてみると所々に「ザッ」「ザッ」というノイズが乗ってました。だめです。
CD-R/ROMドライブは他にも数台ありますが、ダンボールの中にしまってあるので引っ張り出してくるのも面倒です。そんなわけで、早くも最終手段、DVDプレイヤー。今のところ、このメディアをまともに再生できるのは、こいつしかいません。光ケーブルで繋いで、STSRECで録音を仕掛けて就寝。焼くのは明日です。
…なんでこんな面倒くさいことをやってるんでしょう。
例のCD-Rです。
昨晩の仕掛けが終了していたので、出来上がったWAVEファイルを編集し、等倍速でじっくり焼き上げました。CDプレイヤーで試聴してみたところ、特に目立った欠点はないようです。これでやっと安心して聞くことができそうです。
