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系はどうしてころころインターフェースが変わるんだよ。どんどん使いにくくなっていくよ。ユーザが増えない一因のようにも思える。