Search this site:

Match case Regex search

Search Results from blog::楓

こまごまとした事

プロジェクトプロパティに基づき、グリッドのレイヤー数とサウンドバッファ数を決定するようにした。 グリッドの横の数をコマンド数+100になるようにした。 変更付加セルでクリックされた場合、その前に有効になっていた位置でメニューが表示されていたのを、表示されないようにした。 シーケンサーが閉じようとされた時、実際には閉じずに、非表示にするだけにした。 メインフォームのボタンからシーケンサーを表示できるようにした。 メインフォームも現在のシーンを保持していたので、そのプロパティを削除。 そのプロパティを参照していたDocModuleのメソッドも削除。 使われていないソースファイルがあったので削除。 シーケンサーが表示される時、ドキュメント(DocModule)に基づきシーンタブとグリッドの左端の項目が設定されるようにした。 これで、プロジェクト生成/保存部分までにやることは、少し大変なコマンド属性のメモリ上での保存とフォームへの反映のみになった。 ちょっとメモ。 コマンド属性を生成する時、レイヤー番号などもきちんと設定すること。 こういった細々とした事はここに書かずに、こまめにコミットしてそこにコメントとして書いたほうが良いかも。 それと、早めにWebSVNの設定をしてブラウザでコメントなどを見やすくしたほうが良さそう。...

Posted in blog::楓 on January 29, 2005 03:31 AM

シーン周りを整備

シーンの追加/削除/名前の変更が行えるようにした。 Enterキーでメニューを表示できるようにしようとしたら、メニュー項目決定のEnterで再びメニューが表示されてしまい、かなり使いづらい。なんか、前も同じ事やったような・・・。で、諦めた気がする。 でも、今回はいい方法を思い付いた。単に、Enterではなくスペースキーでメニューを表示させると言うだけのことだが。 で、そのように実装。 いい感じ。 直近でやることをメモ。 プロジェクトプロパティに基づき、レイヤー数を変更する。 コマンド属性のメモリ上での保存とフォームへの反映。 現在固定になっているグリッドの横の数をコマンド数に応じて追加する。 プロジェクトの生成/保存部分を作る。...

Posted in blog::楓 on January 29, 2005 03:04 AM

EAccessViolation例外

起動時にEAccessViolation例外が突然発生するようになった。 メンバを直接アクセスしていたのをプロパティ経由にして、参照を使うようにしたのか、ダイアログを追加したぐらいしかやっていないはず。 なんだ? バージョン管理しているので、戻そうかと思ったけど、また変更を加えるのは面倒なのでとりあえず、ダイアログを自動生成しないようにしてみる。 変わらず例外発生。 プロパティ経由を、メンバ直接アクセスに戻す。 例外が発生しなくなった。 プロパティ経由とメンバ直接アクセスは何か違うのだろうか? 読み出しの場合、プロパティは単にメソッドを呼び出し、その結果を使っていると思っていたのだが・・・ その読み出し用メソッドは単純に参照を返しているだけ。 よくわからないなぁ。 デバッガで追うと、初期化が完了していない値が返ってきているか、変なアドレスを参照しているみたい。 よくわからんな。...

Posted in blog::楓 on January 29, 2005 01:16 AM

機能追加&変更

変更項目 接続時のエラーメッセージを詳細に表示するように変更。 Alertウィンドウが自動的に消えないように変更。 ログイン時のレスポンスのリダイレクトURLを認識し、そのURLを読み込むように変更。 その時、boost::regexの正規表現でまたハマる。 <と>は別にエスケープしなくても良いようだ。と言うか、しないようにしないとヒットしない? 不必要なエスケープを減らしたらヒットするようになった。 チェックサイクルの時間をインターバルに変更。(以前は定期的に実行) 追加機能 チェックサイクルを1分、2分、3分、5分、10分、15分、20分、30分、1時間の中から選択できるように機能追加。 ソース上の変更 設定ウィンドウの各コントロールの設定を、前は呼び出し元が行っていたが、設定ウィンドウが表示される時に、自分で取得、設定を行うように変更。また、同時に設定ウィンドウのプロパティもなくす。...

Posted in blog::楓 on January 25, 2005 01:59 AM

Frameとのデータの受け渡し

パラメータを設定する箇所はFrameを使用しているが、そのFrameとのデータの受け渡しに初めは多重継承によって実現しようと考えていた。 そのFrameを切り替える元となるフォームは、各Frameを保持している。 そして、そのFrameのメソッドを介してデータを渡すようにしようとしていた。 そのため、単純に多重継承したのでは、そのインターフェイスとなるクラスのポインタも保持しなければならなくなる。 それを回避するために、Frame の派生クラスではなく、その親となるクラスで多重継承することにした。 次のような感じ。 class ITagProp class TPropFrame : public TFrame, public ITagProp class TUserFrame : TPropFrame こうすれば、TPropFrame を保持しておくだけで良い。 これでメイクも通りうまくいったかと思ったが、Frameのレイアウトなどを変更しようとしたら問題が発生した。 プロパティが取得できないとかなんとかエラーが出てしまった。 それでも、そのまま無視を選択したらフォームが表示されたのだが、メイクして動かそうとしたらエクセプション。 どうやら、この方法ではダメのようだ。 そこで、Tagプロパティを使って受け渡しをしようと思ったが、FrameにはOnShowなどがないので、Tagプロパティに値を設定しても、それを拾うタイミングがわからない。 良いメソッドがないかヘルプのTFrameを見る。 Dispatch! そうだ、普通にメッセージでやり取りすればいい。 Frameの切り替えを行う際、Dispatchをコールすることにした。 そして、独自のメッセージを作り、各Frameで受ける。 この方法でうまくいくかどうか実装してみた。 いい感じだ。 初めからこうするべきだったな。 なお、実際のDispatch 部分は、次のようにマクロで定義するようにした。 void __fastcall SetElement(...

Posted in blog::楓 on January 23, 2005 02:30 AM

とりあえず完成

実装した機能は以下の通り 新着メッセージ、新着コメントを定期的に確認。 確認サイクルは固定。 アラートウィンドウは一定期間で非表示に。 非表示になるまで時間は固定。 ログイン用メールアドレス、パスワードの設定。 タスクトレイへのアイコンの登録。 イマイチなアイコン。 要求システムは次のとおりのはず。 Internet Explorer 5.5 以降 Windows 2000 もしくはWindows Me 以降 とりあえず、XP と 2000 では動作確認している。 その他制限事項 IEを普段使っている場合、自動ログインが切れてしまう。IEは使わずにFirefox使ったほうが良いと思われ。 他に対応したいこと インストーラー マルチユーザー 新着日記、新着コミュニティー書き込み、新着レビューの確認。 確認サイクルの指定。 アラートウィンドウを自動的に非表示するかどうか。また、その時間。 自動的に非表示された場合、タスクバーのアイコンで未チェックかどうか明示。 アイコンがイマイチなので、何とかしたい。 確認の一時停止。(ユーザーの操作がない場合など) メッセージやコメントへのダイレクトリンクをアラートウィンドウに表示する。 それぐらいだったかな。...

Posted in blog::楓 on January 21, 2005 12:00 AM

perl でWin32 Inet

次のようにすれば、perlでWin32 Inetを使いmixiからログイン後のHTMLデータを取得できる。 use Win32::Internet; $email = 'your_addr@yourhost.ne.jp'; $password = 'your_password'; $next_url = '/home.pl'; $target_url = 'mixi.jp'; $target_object = 'login.pl'; $post_req = 'email=%EMAIL%&password=%PASSWORD%&next_url=%NEXT_URL%'; $success_login = 0; $INET = new Win32::Internet();    # WinInetのインスタンスを得る if( defined( $INET ) ) {     local $HTTP;     $INET->HTTP( $HTTP, $target_url );     if( defined( $HTTP ) ) {         $send_command = $post_req;         $send_command =~ s/%EMAIL%/$email/g;         $send_command =~ s/%PASSWORD%/$password/g;         $send_command =~ s/%NEXT_URL%/$next_url/g;         {             my $REQ;             my $params;             $params{"path"} = $target_object."?".$send_command;             $params{"flags"} = INTERNET_FLAG_RELOAD;             $params{"method"} = "POST";             $HTTP->OpenRequest( $REQ, \%params );             if( defined( $REQ ) ) {                 $REQ->SendRequest( $send_command )                 $file = $REQ->ReadEntireFile();                 $REQ->Close();                 @read_data = split( /\n/, $file );                 foreach( @read_data ) {                     chomp;                     if( /url=\/check.pl\?n=\%2Fhome.pl/ ) {                         $success_login = 1;                     }                 }             }         }         if( $success_login ) {...

Posted in blog::楓 on January 15, 2005 10:13 PM

カウンターの分散

全ページのカウンターが共通だとわかりづらいので、Topページとブログトップページ、その他のブログで分けることにした。 どこのアクセスが多いだろうか。...

Posted in blog::楓 on January 15, 2005 09:21 PM

libiconvを使おうとしたが

まず、libiconvをソースからmakeしようとしたが、うまくいかなかった。 で、バイナリのやつを使おうとしたけど、よくわからなかった。 で、いろいろと検索するとKaoriYa.netにiconv.dllをVCでビルドした物があったので、これを使うことにした。 そして、使ってみるが、文字列などによってうまくいくときといかない時がある。 iconv.cを見ると、その辺りはなんか面倒なことをしている。 この辺りでかなりiconvを使う気が減衰。 NKF32.DLLを使ってSHIFT_JISにした後、MultiByteToWideCharでUnicode(UTF-16)に変換しようかと思った。 だが、MultiByteToWideCharを使って、いきなりEUC-JPからUnicodeへ変換できない物かと考えて調べてみた。 調べるとEUC-JPのコードページは、51932 とある。キャラクタセットの認識および、Windowsコードページ一覧を参照のこと。 つまり、MultiByteToWideCharでコードページ 51932 を使えばうまくいくかと思ったが、変換できず。 文字コード掲示板の過去ログにもそのことが書いてあった。 ConvertINetMultiByteToUnicodeを使うしかない様子。 で、ConvertINetMultiByteToUnicodeを使おうとするが、MSDNに必要なヘッダーファイルの記述がない。 いろいろ調べてMLANG.IDLから、MLang.h だろうと思い、MLang.hをinclude。 しかし、リンク時にエラーになる。 DLLはmlang.dllだと記述されているので、検索し発見。 mlang.dll からC++Builder用のインポートライブラリを作る。 implib mlang.lib mlang.dll と、コマンドラインで入力すれば、mlang.libが出来るので、これをプロジェクトに追加。 メイクが通るようになった。 初めはうまく動かなかったが、キチンとリファレンス読んで書いたらうまく動くようになった。 その部分のコードは次のような感じ。 なお、エラー処理は省いている。 #define CP_EUCJP 51932 FILE *ifp, *ofp; ifp = fopen( "test.html",...

Posted in blog::楓 on January 14, 2005 04:27 PM

ImageMagickライブラリのビルド

ImageMagickを使えば、かなり多くのフォーマットに対応できるし、C++での使い方もPerlMagickのように簡単に見える。 また、ライセンスもApache-style licenseで、たぶんオープンもプロプラエタリにも使えるとある。 たぶんと書いてあるのは、リンクするライブラリが多いためだろう。 以上のようなことから、ImageMagickを使いたいと思い、ビルドしてみることにした。 バイナリのインストーラーもあるが、いろいろとインストールされてしまうので、必要な物のみスタティックなライブラリとしてビルドし、必要に応じてリンクするような形態にしたいため、ソースからビルドすることにした。 Install-windows.txtを見ながら進めた。 使用したのは、Windows Source 6.1.8-5で、VCは2003。 まずは、ImageMagick-6.1.8/VisualMagick/configure にあるVCのプロジェクトを開き、Releaseビルドでconfigure.exeをビルド。 出来たconfigure.exeをダブルクリックして起動するとダイアログが開く。 "次へ" をクリックした後、Build type setupでStatic Multi-threaded runtimesを選択。 Use X11 stubs to... のチェックははずした。 Build optionsはGenerate Visual Studio 7 formatにだけチェックが入った状態にし"次へ"をクリック。 次のパスの設定などはそのままにし、完了すると、VisualStaticMT.sln がImageMagick-6.1.8/VisualMagick に出来る。他にも各ライブラリのプロジェクトファイルが生成されたようだ。 VisualStaticMT.sln でVCを起動し、ビルド。 しばらく待てばImageMagick-6.1.8/VisualMagick/libにわんさかライブラリが出来る。 また、ImageMagick-6.1.8/VisualMagick/binに実行ファイルがいろいろと出来る。 Debug版、Release版はそれぞれ、途中のDBとRLの文字が異なるライブラリが生成される。 以上で必要なライブラリは生成されたはず。 次は、簡単なサンプルを作れるかどうか確認する。...

Posted in blog::楓 on January 13, 2005 04:37 PM

アクセスカウンタの設置場所

アクセスカウンタの設置場所をブログも対象となるようにした。 このページはほとんどブログなので、ブログも対象とした方が良いと思ったからだ。 また、検索すると自分のブログが出てくることも多い。 まあ、自分の興味があることをブログに書いていて、さらに似たようなことを検索するから自分のページが出てるくのは当たり前と言えば当たり前。 でも、ブログに書くエラーメッセージやソフトウェアの名前などは出来るだけ正確に書くように気を遣っている。 それは、自分が後から検索しやすいようにだけど、当然他の人も同じキーワードで検索することがあるだろう。 そして検索して見られるページはブログの1ページ。 そういったこともあるので、ブログもアクセスカウンタの対象とした。 その変更を行っていた時に気付いたけど、ブログを主体にしてしまってもいいかもしれないと思った。 テンプレートやCSSをいじれば、今のトップページのメニューのように表示させることも出来る。 また、各コンテンツもブログで書いた方が更新など楽だ。 各コンテンツは別ブログとして、テンプレートをいじって個別ページの見栄えを独立したページのように見せれば変に見えることはない。 いいアイデアだと思うけど、大幅な変更になるので実際に取り掛かるのは少し先だな。 今は構成などをもう少し詰めていこう。 とりあえず必要なのは、前述のようにログを残していくブログとコンテンツ用ブログの2つのブログ。 掲示板ページ。 ファイルを置いておく場所。 必要なのはそんなところか。 後、MTのバージョンアップも同時に行おう。 それと、旧ブログはリンクのために残しておいて、ブログページ移動のアナウンスを表示するようにしないとな。 出来たら更新作業が楽になりそうだ。...

Posted in blog::楓 on January 7, 2005 03:00 AM

MySQLの復旧

MySQLへアクセスできないので、いろいろと調べる。 まず、パスワードをなくしたい。 いろいろ調べて /etc/shadow にパスワードが保存されていることがわかった。 shadow のManページで意味を見る。 cryptで暗号化されたパスワードと思われるものが、mysqlユーザーには設定されていた。 PostgreSQLを真似て、パスワードを!!に変更。 で、再起動。 まだアクセスできない。 mysql とコンソールで入力した時に表示されるメッセージと、 ERROR 2002 (HY000): Can't connect to local MySQL server through socket 'ソケットファイル名' (111) を手がかりに、"Can't connect to local MySQL server through socket" で検索する。 このページがほぼそのままのことを書いている。 1番目にMySQLが起動していない可能性を指摘している。 ps axで見ると、mysqlはない。でも、ps ax...

Posted in blog::楓 on January 6, 2005 12:29 AM

MySQLのアップデート

Fedora Core 3では、MySQLは3.X系が入っているが、どうやらこの記事(MySQLの最新版でも静まらないライセンス方式への批判)に書いてあることが原因の様子。 それはともかく、4.0系が使いたいので、RPMをDLしてインストールすることにした。 で、MySQLのDLページを見ると4.1系がrecommendedになっている。 と言うことは、4.1系を使った方がいいのか? 前に書いたとおり、developmentパッケージを入れれば、MySQLは4.1.7系が入る。でも、どうせなら4.1.8を入れたい。 で、結局RPMをDLして、インストール。 rpm -Uvh MySQL-shared-compat-4.1.8-0.i386.rpm rpm -Uvh MySQL-server-4.1.8-0.i386.rpm rpm -Uvh MySQL-client-4.1.8-0.i386.rpm rpm -Uvh MySQL-bench-4.1.8-0.i386.rpm rpm -Uvh MySQL-devel-4.1.8-0.i386.rpm rpm -Uvh MySQL-Max-4.1.8-1.i386.rpm ってな感じ。 後から気付いたけど、これは、 rpm -Uvh MySQL-*.rpm とやってもいいみたい。 それと、最初入れる順番がまずかったのか、依存関係がどうとかでうまくいかなかった。いろいろと調べて、よくわからずにもう一度やったらうまくいった。 うーん・・・順番が違ったのかな。 あと、MySQL-shared-4.1.8-0.i386.rpm も入れたけど、その後に MySQL-shared-compat-4.1.8-0.i386.rpm を入れたら、表示されなくなっていたので、いらない様子。 たぶん、MySQL-shared-compat-4.1.8-0.i386.rpm は、3.23系と両方含んだものみたい。と言うか、DLページにはそんなようなことが書かれている。...

Posted in blog::楓 on January 5, 2005 10:49 PM

WebDAVフォルダの追加でまたハマる

SSL+パスワード付きのWebDAVフォルダを追加しようとしたら、すんなり行かずかなり悩んだ。 理由は、SELinuxのポリシーの設定と、許可するユーザーの設定ミス。 WebDAVポリシーは、以前Fedora Core 3 で WebDAV/Subversion を使おうを参考にして追加したが、今回新しいフォルダを追加しようとしていたので、設定の追加が必要になった。 詳しい設定方法は、前述のページを参照して欲しい。 で、ここにも一応備忘録としてメモ なお、httpd_dav_content_t の追加は前述のページを参照のこと。 /etc/selinux/targeted/src/policy/file_contexts/program/apache.fc の最後に新しく追加したポリシーを追加。 具体的には、 /home/dav(/.+)? system_u:object_r:httpd_dav_content_t ってな感じ。 太字部は、新しく追加したフォルダに合わせる。 で、コンソールで次のようにしてポリシーをmake。 # cd /etc/selinux/targeted/src/policy # make clean # make reload # restorecon -R /home/dav 書いていてふと気付く。 /home/webdav にポリシーを設定して、WebDAVを追加する時は必ずその下にフォルダを作り、そのフォルダにAlias を設定する。 そうすれば、毎度毎度ポリシーをいじらなくて済む。 で、設定変更。 うまくいった。...

Posted in blog::楓 on January 5, 2005 04:01 AM

MySQL

Fedora Core 3 に入っているMySQLのバージョンは3.23.58と少し古い。 せめて4.0系が欲しかったが、まあいいか。 たぶん、大丈夫だろう。 で、MySQLの設定を参考にパスワードの設定などを行う。 ただし、最後の mysql> set password for root@'%'=password('パスワード'); は、%ではなく、きちんとしたホスト名を入れないとうまくいかなかった。 で、次にphpMyAdminをインストール。 DLして、任意のディレクトリに展開した後、apacheの設定をいじって、そのディレクトリへはローカルからしかアクセスできないようにした。 そして、phpMyAdminのインストールを参考にして、設定を行った。 ただし、前述のページで変更する必要があると書いてある次の場所以外に $cfg['PmaAbsoluteUri'] = $cfg['Servers'][$i]['password'] = 次の、場所のlocalhostの部分をきちんとしたホスト名にする必要があった。 $cfg['Servers'][$i]['host'] = 'localhost'; 以上で、MySQLが使えるようになった。 でも、やっぱり4.0系が欲しいなぁ。 FC3でyumを使ってサインが入っていないdevelopmentパッケージをインストールするを参考に、アップデートできるパッケージを調べると、4.1系が表示される。 まあ、当たり前っすね。 で、普通にyumでやると、3.23.58になる。 うーむぅ。 RPMパッケージでやらないとダメなのか?...

Posted in blog::楓 on January 5, 2005 12:50 AM

再生できないMPEGファイルの調査

再生できないと言われたMPEGファイルを確認。 確かに再生できない。 エラーは、"これらのピンに共通するメディアの種類はありません。" だそうだ。 で、デバッガに各ピンがサポートするメディアの種類を出力するようにして、確認してみる。 問題のファイルの出力ピンのサブタイプはMPEG1Systemと出た。MPEG I Splitter はMPEG1System か MPEG1VideoCD、MPEG1Video、MPEG1Audio をサポートしている。 ( メジャータイプ、フォーマットは同一のため割愛 ) メディアタイプからするとつながるはずだが・・・ TMPGEncで問題のファイルを見てみる。 アスペクト比がその他(0.89)とか表示される。 何それ? メディアプレーヤーでファイルを再生し、プロパティを表示、ビデオコデックのあたりをクリックするとアスペクト比が表示される。 それで、アスペクト比を見てみると1.19:1・・・ 何でそんなに変なアスペクト比を設定しているの? 問題なく再生できるほうを見ると4:3になっている。 PCで再生させるのなら1:1の正方画素にするのが良いと思うが・・・ うーん。 こんな変なアスペクト比のファイルは再生できなくてもいいような・・・ 1:1になるように補正して表示しようとする段階で問題が生じそうな入力は、はじくようになっているのかな? でも、グラフ自動生成やメディアプレーヤーでは再生されている。 さて、どうする? 個人的には1.19:1とか言う変なアスペクト比のMPEGファイルは再生できなくても良いと思うが。 非サポートの方向でいこう。...

Posted in blog::楓 on December 26, 2004 09:48 PM

ムービーの栞への保存は厳しい?

レイヤー描画はピリオドイベントかセグメントループでシーンが遷移することを想定していた。 詳しく説明すると、ピリオドイベントは映画の字幕のように、ムービーに字幕を同期させたり、特定フレームでフラグによってムービーを分岐させたりするのに使用し、セグメントループは、選択肢やクリック待ちなどで、ムービーの指定範囲をループさせるのに使用し、クリックがあった時に、ループを解除するか、選択肢のときはループの終点のイベントでループの解除とムービーの遷移を行うような使用方法を考えて作っている。 上記のような用途に使うのなら、セーブポイントはシーン遷移後に置くことになる。 そして、栞がロードされた時、ムービーはそのシーンの開始フレームから開始されることを望む。 擬似スクリプトで表現するなら次のような感じ。 [ピリオド待ちorセグメントループ待ち] [ジャンプ] [ラベル] [ムービーのフレーム移動] って、再生しているムービーファイルとそのレイヤー、ループ状態を保存しておけば大丈夫か。 上記のように書いておけばロードされた時、移動させたいフレームに移動することになるし。...

Posted in blog::楓 on December 7, 2004 09:54 PM

続RAIDへのOSインストール

検索すると同様の症状に悩んでいる人を発見。 このページ。 上述のページではGIGABYTE GA-8ANXP-D Rev2.0だが、GIGABYTE GA-8I925X-G Rev2.0でも同じだと思われるので、同じように試す。 まず、Intelのドライバページから最新バージョンのドライバとフロッピー設定ユーティリティの両方をDL。 フロッピー設定ユーティリティを使ってFDを作る。 マニュアル通りに、インストール途中でF6を押す。 ドライバの入力を促された画面で、FDを入れEnter。 以下の4つが出てくる。 Intel(R) 82801FR SATA RAID Controller Intel(R) 82801FR SATA AHCI Controller Intel(R) 82801ER SATA RAID Controller Intel(R) 6300ESB SATA RAID Controller この内、一番上のIntel(R) 82801FR SATA RAID Controllerを選択。 後は、そのままインストールを続けると・・・ きた! 以前止まっていた場所を越えてインストールが進んだ。 GIGABYTEめぇー。 ま、なんにせよインストールが進んでよかった良かった。...

Posted in blog::楓 on December 7, 2004 01:12 AM

ムービーの状態をセーブ

別にやらなくてもいいかと思ったけど、やっぱりやった方が良さそうなので検討することに。 で、栞関係のことをDee氏に聞くと、 MainWindow.tjs内のinternalStoreFlags で、栞へ現在の状態を保存。 internalRestoreFlags はその逆を行っている。 とのこと。 場所はわかった。 でも、仕様を考えないといけない。 さて、どういうのがいいかなぁ。...

Posted in blog::楓 on December 7, 2004 12:48 AM

新PCのセットアップ

新PCも届き、組み立ても終わったので、コードをつないで電源ON。 なぜかCPUファンが回っていない。 なぜ? 一度電源を切り、ケーブルを確認。 問題なさそう。再度電源を入れたら、普通に回った。 なんだったんだろう? まあ、いいや。 で、BIOSの設定&RAIDボリュームの作成を行う。 作成が終わったら、インストールするOSのCDをMSDNの中から探す。 WinXP Pro SP1a。これだな。 SP2もあるけど、不評なのでやめておく。 で、プロダクトキーの取得方法を見る。 MSDNのサブスクリプションのページから取得するようだ。 Win2kまでは普通にCDに書かれているのに、WinXPは取得しないといけない。 面倒な話だ。 で、ログインしようとしたら.NET Passportになっていた。 いつの間にか統合されたようだ。 .NET Passportは以前メッセンジャーを使うために登録していたので、それを入力。 が、エラーメッセージが出てきた。 エラーメッセージは英語。いったんログアウトして、.NET PassportからMSDNのIDを追加をクリックするような内容のことが書かれている。 そのままログアウトしたら英語のページに飛んだ。 日本なので、日本語のページじゃないといけない気がしたから、日本語のページに戻ってそれらしきページを探す。 探してもないのでヘルプを見てみるが、.NET PassportにMSDNのIDを統合する方法がイマイチよくわからない。 もう一度エラーメッセージの画面を見てみる。 英語のページで手続きをする。 Fast Nameと書かれていたので、ローマ字で名前を入力したらエラーになった。 登録しているのと違うと書いているようだ。 漢字で入れてみる。 うまくいった! でも、なんか釈然としないものが・・・ Fast Nameとか書かれた英語ページなのに漢字で名前を入れる・・・ 違和感ありありだ。...

Posted in blog::楓 on December 7, 2004 12:29 AM

プレビューウィンドウ

プレビューウィンドウを作ろうと、フォームにTImageだけをのせたものを追加した。 そして、フォームのOnPaintでTImageのキャンパスのFillRectを呼び出すようにしたら、すごく重い。 こうやったらまずかったんだっけ? "TImage に含まれているグラフィックのペイントと更新は自動的に処理されます。・・・TImage 上で描画すると,永続的なイメージが作成されます。したがって,その中のイメージを再描画するための操作は何も必要ありません。" 再描画は勝手にやってくれるんですね。 だから、FillRectを呼ぶと、OnPaintが呼ばれて、またFillRect・・・と無限ループ。CPU負荷100%状態なわけか。 じゃあ、イメージのアップデートは別メソッドにしておかないと。 で、続きを作ろうと思ったけど、コマンドの処理などをやらないといけないので、各タグの属性のクラスが必要になるため、まだ出来ないことに気付いた。 なんでプレビューウィンドウは後回し。 描画はコマンドのクラスに任せる? でも、状態によって変わるものがあるのでそれはどうする? コマンドは状態にだけ変化を与えるようにして、描画はその状態を元に行えばいいのか。って、コマンドごとにクラスを持っているわけじゃなかった。 コマンドごとにクラスを持たせてもいいけど、それはちょっと・・・ でも、その方が柔軟になるか。 さて、どうするか。...

Posted in blog::楓 on December 2, 2004 10:44 PM

ノーマルモードとエキスパートモード

このツールにはノーマルモードとエキスパートモードを作ろうと考えている。 エキスパートモードは、今作っているインターフェイスで、細かく動作を設定できるというか、KAGスクリプトに近い形で細かい動作がわかる。 ノーマルモードはmacromedia Directorに近い形で、内部的なスクリプトの呼び出し順序などは自動的に決定され、UIで見た形に近い表示になるようになる。 一番初めは、単にExcelで書いた物をコンバートするような形を考えていたが、途中でそれをExcelから独立したツールにすることにした。 で、作っていたのだが、なんか見た目にわかりづらいと感じて、いろいろと考えた末、macromedia Directorのようなインターフェイスにすることにした。 で、上述のノーマルモードのみで行こうと考えていたわけだが、どのようにするかすごく悩んだ。 後、グループ分けなどいろいろと面倒なので、保留とした。 で、エキスパートモードが生まれた。 エキスパートモードはほとんどスクリプトそのままに近いけど、タグがカテゴライズされて、視覚的にもわかりやいので、これでいいと言うことにした。 と、ここまで書いたけど、そんなのはどうでも良くて、ノーマルモードを実現するために必要な要素を思い付いたから、メモしておこうと思ってこのログを書いた。 つまり、上の文章は要らない。 じゃ、書くなよって感じだが、まあ・・・ いいじゃん。 で、その要素だが、単にタグの中には時間を経過させるものとそうでないものがある。ってだけのこと。 Directorの場合、横軸はフレームで、何fpsにするかを指定して、アニメーションを作る。 でも、KAGの場合はそうではない。時間を進めるタグがなければ、時間は進まない。(ムービーやアニメーションなどは勝手に進むけど、言いたいのはそう言うことではない。) つまり、横軸のコマが進むのは、時間を経過させるタグが出現した時だ。 言い換えれば、同一の時間軸に存在するのは、時間を経過させるタグに囲まれた間と言うことになる。 これは、いいひらめきだ! と思ったけど、そんなでもないか。 後、悩んでいるのは横軸をなんと呼ぶか。 どうでもいいと言えば、いいけど、名前によってわかりやすさが違ってくるし、場合によっては誤解を生じてしまう。 うーん・・・ フレームとかでいいかな? 意味的には大丈夫だと思うけど、一般的にどうとらえられるかは・・・ 大丈夫かな。 ・・・ ヘルプなどで上述したような概念の説明を最初に持ってくれば、問題ないでしょう。 とりあえず、横軸はフレームと呼ぶことにしよう。...

Posted in blog::楓 on December 2, 2004 03:27 AM

状態を調べなければならない?

どのレイヤーに対する操作かわかりやすいように、セルに色を塗る機能を追加した。 現段階では細かい判定はしておらず、単純にそのコマンドがどのグループに属するかだけを見ている。 しかし、最終的にはどのレイヤーに対する操作かなども判定する予定だ。 そこで、問題に気付いた。 ビデオは再生したいレイヤーを事前に指定するが、それはつまり、過去のコマンドを検索しなければならいなことを意味する。 しまった。 再描画が発生するたびに、コマンドによっては各列で状態を判定しなければならない。 重いか? そんなことはないか。 PCでメモリ上にある物に対して操作するのなら余裕だろう。 組込用の数十とか数百MHzで動いているCPUじゃないし。 ま、重かったら、重かった時に考えよう。 それに、状態の判定などは、プレビューウィンドウを付けようと思ったらどのみち必要になる。 で、次は・・・ 各コマンドの属性を保持するためのクラスを量産かぁ。 各コマンドのUIとこのクラス、そして、それぞれを結びつける作業。 数が多いだけにここはしんどいな。...

Posted in blog::楓 on December 2, 2004 02:59 AM

C++Builderのイベント

Builderでイベントを実行中に割り当てようとして、ふと疑問に思った。 サンプルでは何気なく、クラスのメンバ関数を代入しているが、C++でそんなことは出来ないんじゃなかったっけ? つまり、次のような文だが、 Event1 = Class1->fun; このようには出来なかった気がする。この場合は、 Event1 = Class1::fun; としなければならず、Event1の定義を見ると関数ポインタのようなので、Class1::funはstaticなメンバ関数でなければならないはず。 でも、不思議なことにBuilderでは普通に出来ている。 変だなぁと思ってよく見ると、__closureというキーワードが間に入っている。 ヘルプを見ると、これはBuilder独自の拡張のようで、クロージャと呼ばれる物らしい。 で、いい感じにthisポインタを取得して、そのメンバ関数をコールしてくれるようだ。 なるほどね。 独自拡張だったのか。...

Posted in blog::楓 on December 1, 2004 01:14 AM

メニュー項目の動的追加

Excelからコードを吐くようにして、それによってメニューの文字列や属するグループを判別し、メニューを動的に追加するようにした。 メニューは、表示前に前回の物を全部消してから、新たに追加するようにした。 速度を少し懸念していたが、全然余裕だった。 まあ、最近のPCがその程度で重いわけないか。 せいぜい150個とかだし。 少し操作してみたが、なんかイマイチ。 メニューの並び順も工夫した方が良い気がする。というか、しないと使い勝手悪そう。 そこで、ダブルクリックでメニューを表示するのではなく、シングルクリックで表示するようにした。 うざいかなと思っていたが、意外と軽快でいい感じ。 よし、シングルクリックで表示にしよう。 メニューの並び順は、今後Excel表で調整することにする。 コード自動生成で、enum値が変わることになるが、そのことには依存していないはず。 今後も依存しないように記述しないと。 って、依存することなんてないかな?...

Posted in blog::楓 on November 30, 2004 11:55 PM

フォームの切り替え

ポップアップメニューで、コマンドが選択された時、どのようにして上部のフォームを切り替えるか? クリックされた時のハンドラで、切り替えてしまってもかまわないが、そうはせずに、指定されたコマンドクラスを初期化して、ドキュメントに設定。 ドキュメントから再描画を促された時に、上部のフォームを切り替えると共に、グリッド部のフィルも行う。 と言うのが、良いだろうか? 重いかな? いいや、やってみよう。 でも、その前にタグごとのクラスを大量に作らないと。...

Posted in blog::楓 on November 29, 2004 02:32 AM

Xファイルが持つ情報

少し調べてみたのでメモ。 Xファイルは、回転、スケール、位置、行列の複数のキーによるアニメーションが可能。 アニメーションはフレームに設定される。 フレームは親子関係構造を持ち、行列とメッシュを持つことが出来る。 スキンウェイト情報は関連するフレームと、その影響を受ける頂点を持つ。 つまり、Xファイルを使うば、ボーンアニメーションと単に物体が動くアニメーションが可能。 ライトやカメラ、モーフは含まれない。 ただし、独自のデータ型が定義出来るので、それによって補うことは可能。...

Posted in blog::楓 on November 27, 2004 10:55 PM

クラス図を書く

とりあえず、ゲームのクラス図を書いてみる。 結構いろいろと詰めないといけなさそうだなぁ。 TJSスクリプトで少し書いてみる。 すべてTJSスクリプトで書くのは速度的にちょっと不安だけど、プロトタイプとしてはいいかも。 速度的に問題なければ、そのままでもいいし。...

Posted in blog::楓 on November 27, 2004 10:14 PM

C++ Builderでメニューハンドラを共通化

メニューがクリックされた時のイベントハンドラは共通にしたい。 しかし、前回はどのメニューが押されたのか判別する手段がわからずに、似たようなメソッドを大量に作ってしまっていた。 メソッドの中身は、 SetActiveTag(TAGTYPE_cancelautomode); をコールするのみで、引数の定数値が違うだけだった。 面倒だから置換でコードを生成するというアホさだった。明らかにメンテナンス性が悪い。 で、今回は注意深くヘルプを読んだ。 するとint Tagプロパティがあった。 ヘルプには"Tag は,あらかじめ定義された意味のあるプロパティではありません。Tag プロパティは,開発時の利便性のために提供されます。追加の整数値を格納したり,コンポーネント参照またはポインタなどの 32 ビット値に型キャストできます。"と書かれている。 たぶん、今回のような用途に使うんだろう。 これを使えばすべてのメソッドを共通に出来、中身は、 SetActiveTag(reinterpret_cast(Sender)->Tag); とすればいいはずだ。 タグのグループ分けはマスクにして、配列を作り、その配列の全要素とorをとって真となった要素をメニューに追加。 同時に、メニュー文字列も配列にしておけばいい。 って言うか、そう言う作り方が当たり前だろう。 前のはどう考えてもアホだった。まあ、この文章の方法のようにしたいと思っていたが出来なかったので、苦渋の選択をしたのだが。 ま、なんにせよ、これでメニューはさっくり出来る。...

Posted in blog::楓 on November 25, 2004 11:58 PM

分類した後また悩む

すべてのタグを分類したのだが、その後インターフェイスをどのようにするかかなり悩んだ。 わかりやすくするためには、1列に1コマンドでは限界がある。 しかし、わかりやすいインターフェイスにするには分類したタグをさらに分類したり、インターフェイスを考えていかなければならない。 本来ならここでじっくり検討して行くべきなのかもしれないが、ちょっと疲れてきた。 とにかく一通り実装したい。 なんで、面倒なことは考えずに、選択したグループによって違うメニューが出るだけのものを作ろうと考えた。 とにかく完成させてからインターフェイスを再考する。 それで行こう。 前は、ポップアップメニューをちまちまGUIで作っていたが、今回は動的に作ってしまおう。前回はちょっと無謀だった。 コマンドの多さをあんまり考慮していなかった。 さくっと行こう。...

Posted in blog::楓 on November 25, 2004 11:35 PM

分類に悩む

各タグの分類にかなり悩む。 KAGのドキュメントでは、すでに分類がなされているが、今回のツールの性質からしてそのまま適用するのは少し違う気がした。 そこで、違う分類項目を考えたわけだが、すごく悩んだ。 結局、制作者が操作する対象物に着目して分類することにした。 たぶん、これがわかりやすいのではないかと思う。 で、項目は次のようにすることにした。 ・ 画像レイヤー ・ メッセージレイヤー ・ オーバーレイ (ムービー/Flash) ・ システムグラフィック (Windowなど) ・ 効果音 ・ BGM ・ プログレス/ウェイト ・ レスポンシビリティ ・ セーブ/ロード ・ スクリプト/変数 ・ システム さて、これは吉と出るか凶と出るか。...

Posted in blog::楓 on November 23, 2004 09:20 PM

データ構造はどうする?

DirectorのスコアライクなUIにすることは決めた。 では、内部のデータ構造はどうする? 見た目通りに2次元配列で持つことも可能だが、現在のまま単なる1つのリストとして持つことも可能だ。 リストの場合は、コマンドによって分類され、適切な場所のセルが塗られる。 リストにするか? でも、その場合セル状のUIからの操作を反映する場合、前方向、もしくは後方向にリストを検索しなければならない。 検索と言っても、マッチする条件は明確なわけだから、それほど問題にならないか。 2次元配列も1次元配列の各位置への参照を持っているようなものだ。 とりあえず、リストで作ってみよう。 2次元配列の方が何かと問題発生しそうだし。...

Posted in blog::楓 on November 23, 2004 01:20 PM

やるなCyberBB

昨日Bフレッツの電話がNTTからあったが、今日はCyberBBから電話があった。 「昨日NTTから電話があったと思いますが、工事日はいつになりましたか? ユーザー登録の書類はもう送ってしまっていいですか?」 と言う内容だ。 でも、ブログに書いた通り、まず本人確認書類の郵送が必要だ。で、そのことを伝えるとまた電話するとのこと。 なんか、やる気が感じられる。 今のところ好感触だ。 掲示板などで調べて選んだのだが、いい感じだ。 今後も期待が持てる。...

Posted in blog::楓 on November 16, 2004 12:03 AM

スクリプトで保存することの意味は?

スクリプトによって変更された状態を、任意の位置で取得できるようにする予定だが、この場合、スクリプトで書くコマンドを保存した場合、毎回解析しなければならない。 少ない内はよいが、長くなってくるとこの解析の時間は無視できなくなる。 やはり、スクリプトではなく、構造体などで保存した方が良いだろうか? そもそもなぜスクリプトを使おうとしたのか? まず1つは吉里吉里/KAGで制作する場合にスクリプトが使われているから、そのままの流れで使用することにした。 たぶん、これが一番大きいのではないだろうか? 潜在的にそれしかないと思ってしまっていた。 もう1つは、スクリプトでの入力になれた人は、スクリプトで入力した方が速いと考えたからだ。 プログラマはスクリプトを直接書いていく方が断然速いと考えていた。 そして、いくつかの入力支援などを加えることで、単なるテキストエディタよりも速く制作できることを目指していた。 しかし、果たしてそれは真実だろうか? 確かにスクリプトでの入力は、一般的なGUIなどを使って、マウスで入力していくスタイルと比べれば速い。 でも、キーボートとマウスに適切に役割を分担させた場合は? キーボートとマウスはそれぞれ特性が異なる。 片方で実現しやすいことがもう片方では手間がかかることもある。 つまり、インターフェイスを工夫することでスクリプトでの入力よりも高速に制作できるようになる可能性がある。 スクリプトは最終出力段階のみとし、途中ではなくそう。...

Posted in blog::楓 on November 12, 2004 01:09 AM

ゲートウェイ用マシン

余っているマシンを思い出した。 現時点では手元にないのだが、近日中に手に入る。 以前、兄にあげたマシンだ。 兄が新しいマシンを購入したので、もういらなくなったとだいぶ前に聞いていた。 それでその時処分するかどうか聞かれたのだが、とっておいてもらうことにした。 それが今回奏功した。 初期にあまりお金を使いたくない。 これで、結構費用を抑えてそれなりのネットワーク環境が出来そうだ。...

Posted in blog::楓 on November 11, 2004 11:59 PM

TCP/IPを基礎から

TCP/IPの基礎を学ぶため、マスタリングTCP/IP 入門編 第3版を読み始めた。 この本の第1版も持っているが、その本には落丁があった。 第1版を購入したのは確か学生時代。 読んでいると白紙のページ。一気に読む気が失せて、読むのを止めた記憶がある。 その後は、雑誌やネットで断片的にTCP/IPを学んでいた。 しかし、もう一度基礎からと思い、第3版を半年ほど前に購入。 しばらくほったらかしにしていた。 で、最近サーバーの構築を本格的に検討し始めたので読むことにした。 初めのほうのネットワークの歴史は何度も読んでいるのでとばす。 ネットワークの基礎的な部分を読んでいると衝撃的な事実が! TCP/IPとOSIは異なると言うのだ。 確か、第1版の時はOSIの一部的な扱いでTCP/IPが説明されていたはずだ。 記憶違いなのだろうか? それとも、意味が変わってきたのだろうか? 現在、TCP/IPは単にTCPプロトコルとIPプロトコルを指すのではなく、インターネットプロトコルスイーツを指すらしい。 OSI参照モデルの7層のようなものがあるらしい。 ただし、TCP/IPモデルは7層ではなく、5層になっている。 また、それがさらに3つに大別されている。 いつの間にそんなことに。いや、初めからそうだったのだろうか? なんにしても新しい発見だ。 読み進めているとデータリンクの章に来た。 ここで今日はやめようと思ったが、この章にはATMの説明があるようだったので、ATMのところだけ先に読むことにした。 普通にネットをやっていたらATMなどと言う用語は銀行のATMなど以外では目にしない。 でも、専用線などについて調べているとATMと言う語に出会う。 それで気になっていた。 EthernetやPPPみたいなものだとなんとなくはわかっていたが、もう少し詳細が知りたかったのだ。 で、読んだ。 ふーん。 終了。 それほどメリットは感じられなかった。...

Posted in blog::楓 on November 11, 2004 11:58 PM

属性設定用UI

コマンドメニューで残っていた分を追加。メニューだけでも面倒なのに、UIとなると・・・ UIはいくつかは使い回せたり、属性なしも結構あるからだいぶマシかもしれないけど。 属性設定用のUIを作っていく。やっと10個分だ。 このUIとグリッド部、ドキュメント部とのハンドリングについて考える。 以前も何か考えていたなぁと思い、クラス図を見るとやっぱり考えていた。 しかし、そのときはModel/Observerを知らなかったので、単なるクラスとして考えていた。 なので、再考中。 基本的なやりとりは、スクリプトを介すことで汎用的なインターフェイスにしようと思ったが、UIのいくつかは共通化している。 共通化しているUIは単なる有効/無効、ファイル選択だけを属性に持つものだ。 共通化しているUIで異なるスクリプトになるのもある。 クラスを受け渡し!この文章を書いていて気付いた。 文書化は告知や報告など以外に思考の整理としてなかなか役立つ。 誰かに何かを説明しようとしたら当然理路整然としていなければならない。頭の中では筋が通っていると思いこんでいるものは意外と多い。 文章化すればこのような矛盾に気付く。 また、なぜか新しいアイデアなどが思い付くこともある。 人に説明しようとすることはいろいろと役立つことが多い。 話がそれてしまったので元に戻そう。 グリッドと属性設定UIとのやりとりはクラスを受け渡す方法にしよう。 パラメタを持つクラスは1つのクラスから派生させれば、インターフェイスは共通化できる。 ドキュメントの方とはどうするか? 同じような方法をとっても良いが・・・ バケツリレーのような方法でやろう。 つまり、属性設定UI→グリッド→ドキュメントといった具合に受け渡していく。 属性設定UI、グリッド間はクラスでやりとり、グリッド、ドキュメント間はスクリプトとしよう。 グリッドは直接スクリプトを編集することも出来るようにするのでその方が都合がよい。 構造を考えていくと、グリッドがドキュメントへのアクセスを一手に引き受ける形になりそうだな。 I/Oは限定されている方がやりやすい。...

Posted in blog::楓 on October 31, 2004 11:50 PM

Bフレッツ+プロバイダの申し込み

Bフレッツ+プロバイダの申し込みを昨夜行った。 現在は書類が送られてくるのを待っている状態だ。 それでプロバイダは固定IPがもらえるところにしたのだが、そのサービスはとりあえず2005年6月までのようだ。(初めは2004年12月までとしていたようだが、延長されていた) 調べたところによると、IPv6切り替えがあるためどこも似たような状況らしい。 先行き不透明。 ややこしい時期に始めてしまった。 でも、IPv4でIPv6をトンネリングするサービスもあるようなので、いろいろと実験は出来そうだ。 将来的に切り替わる予定なのだから早めに準備を進めておくに越したことはない。 とは言っても、すでに出遅れている気もするが。。。 前調べたときは、普及価格帯でIPv6が使えるルーターはまだ出ていなかったと思うが、今ならあるのだろうか? それよりも、既成製品は諦めてLinuxでルーターマシンを組んだ方が良いだろうか? 自由度で言えばLinuxに軍配が上がるが、手軽さではやはり既成のルーターだろうなぁ。 しばらく、IPv6 Magazineなどを読み漁るか?って、休刊してるし。...

Posted in blog::楓 on October 31, 2004 11:49 PM

Model/Observerの実装

Model/Observerを実装した。 各タグの属性設定用ダイアログを作る。 数が多いので大変だ。 まだ、5個ぐらいしかできていない。 グリッドのOnRowMovedイベントが来ない? optionのgoRowMovingをtrueにしているのに。 他に何かしないといけないことがあるのだろうか? よくわからなかったので、OnSelectCellで代用することにした。 ARowとプロパティのRowが異なっていたら処理するようにした。 これで、現在の行のタグに応じてダイアログ表示が切り替わるようになった。 最終行のコマンドを設定したら行が増加するようにした。 command列の時、Enter orダブルクリックでコマンド選択メニューを表示するようにした。 ドキュメントの方で状態を持った方がスッキリする気がしてきた。 Boarlandのサイトにあるコンポーネントは、ドキュメントを変更した時に、表示を更新するようになっている。 Modelはデータモジュールに置くように説明されている。 で、その通りにした。 このような構造にすると言うことは、データモジュールにドキュメント変更用のメソッドを持たせ、そのメソッド経由でデータを変更し、それと同時に表示更新を行うことだと考えられる。 つまり、データの変更は必ず、データモジュールのメソッド経由で行われることになる。 しかし、現在はフォームの方でカレントコマンドの参照を持ち、それを直接変更している。 そうした方が都合がよいことが多いと考えたためだ。 あー・・・うーん。 フォームでカレントコマンドへの参照を持つのは、別に問題なさそうだ。 列が移動するなどのコマンド確定動作が行われた時に、データモジュール側に通知すればいいだけか。 シーンはどうする? シーンの切り替わりも一元管理したい。 もう一組Model/Observerを追加すればいいのか! 一度、同期して変更を加えたいものをリストアップした方が良いかもしれないなぁ。 でも、今のところは上記の2つだけかな。...

Posted in blog::楓 on October 30, 2004 11:50 PM

ドキュメント管理部

とりあえず、昨日決めた通りstd::listをラップしたようなクラスを作成。 前回アクセスしたイテレーターを保持しておくのと、要素を位置で取得できるようにした。 各コマンドはどのように保持しよう? 各コマンドごとにクラスを作り、保持するのではも良いが、スクリプトをそのまま保持し、毎回動的にパースするほうがいいかな? ダイアログでの入力も、スクリプトでの直接入力も受け付けるようにしたいので、パーサーはどのみち必要になる。 毎回解釈するようにしよう。 パーサーはflexのみで十分かな? TJSのを作るとなると、bison(yacc)を使った方が良い気もするが・・・ とりあえず、flexのみで予約語どべーって並べて、力業で作ることにしよう。 でも、表示の更新はどうしよう? グリッドをすべて書き換えるのはさすがに厳しい気もするが・・・ 更新したウィンドウを覚えておき、それによって振り分けるか? 挿入処理があった時はどうする? 全部書き換えてしまうのが楽で、間違いも少ないが・・・ いいや、全部書き換えでやってみよう。 ダメならダメで考えよう。...

Posted in blog::楓 on October 28, 2004 11:54 PM

ドキュメント管理部の状態

ドキュメント管理部分は状態を持つかどうか。 ドキュメントは逐一更新されるので、必然的に状態を持っていることになるが、その状態ではなく、アクティブなタグ(以下、コマンドと呼ぶ)を認識するかどうかだ。 UIは、エクセルのようなセルとタブを持っている。 各行は一つのコマンドと対応し、タグはシーンごとに作ることにする。 その関係上、アクティブなシーンとコマンドが存在することになる。 当然、ドキュメント管理部は状態を持たない方がスッキリする。 UI側が更新時に毎回位置を指定すれば事足りる。 気になるのは、やはり処理速度だ。 ドキュメント管理部分は挿入や削除などに備え、リストで管理することにしようと思っている。 リストの場合ノードが多くなればなるほど、後ろになればなるほどアクセスが遅くなる。 つまり、コマンドが多くなった時、処理が重くなることになる。 うーん、ま、いっか。 シーンを分ければ何とかなるし、重くなった時はリスト自体が前回アクセスされたノードを保持するようにすれば、解決できそうだ。 よし、ドキュメント管理部分は状態を持たない方向にしよう。 その方がスッキリする。 リストは初めstd::listで行く予定だったが、TListは配列アクセスが出来て楽そうだ。 そこで、TListに気持ちが傾いたのだが、前回アクセスされたノードを保持する機能を持たせることを考えると、よくわからないTListよりも、std::listの方が良い気がしてきた。 やはり、std::listでやってみるかな。...

Posted in blog::楓 on October 27, 2004 05:24 PM

ボタン絵結合ツール

吉里吉里のボタン絵には通常、押下、選択の3つを横に並べたものが必要だ。 単純に横にくっつけると言うのは、プログラムでは簡単だが、普通のペイントツールを使うとかなり面倒だ。(単純に並べるだけなのに、ドットがずれないかどうかに神経を使う) ペイントツールでこのような機能を持ったものが存在するかもしれないが、知らないので作ることにした。 仕様は、 フォルダをD&Dすればその中にあるBitmapをすべてくっける。 くっつける時のルールは"名前.bmp", "名前_d.bmp", "名前_s.bmp"と言う名前のファイルを一組として、横にくっつくていく。 くっつけられた画像は、D&Dされたフォルダの下にbuttonフォルダを作り、その中へ"名前.bmp"というファイル名で出力する。 とする。 で、なにげにC++Builderでボタンとテキストボックスをくっつけて、D&Dのハンドラ書いて、FindFirstで"*.bmp"を列挙するところまで作った。 そして、くっつける処理はGDI+でも使ってみようと思い、ヘッダーをインクルードするとエラーが山のように出てくる。 あらら。 すごく行き当たりばったりだが、C#で.Net Frameworkを使い作る方向に変更。 少しC#に興味があったからだ。 で、まずはフォームにボタンやエディットボックスを置く。 でも、これはC++Builderに近いなぁ。 これは意外といいかも。 そして、D&Dの処理を調べる。 テキストをD&Dするサンプルがすぐに見つかったので、それを適当に改造して、フォームに対するドロップを処理するようにしようとするが、よくわからない。 そもそも、C#でプログラムを一度も組んだことがないので、文法などもよくわかっていない。 Cを半音上げたものだから、C#って聞いていたので、Cと似たようなものかなぁと思っていたのだが、それほどすんなりとは行かないようだ。 コードの一部に波線が引かれていたので、カーソルを置くとツールチップで説明が出たが、よくわからない。 C#独特の記法のようだ。 C#入門ぐらいは読まないとダメかな。 今やるのはちょっと面倒臭いなぁと思って、どうしようと考えていたらImageMagick(PerlMagick)を使うことを思い付く。 PerlMagickは使ったことがないけど、これなら簡単に出来そうな気がした。(根拠なし) で、ImageMagickのページのAPI->PerlMagickを読んで適当に作ってみる。(このページの日本語訳ないかなぁ?) 少し悩むが、意外とあっさり出来た。 次のコードで、'b_fast.bmp', 'b_fast_d.bmp', 'b_fast_s.bmp'の3つファイルを横にくっつけて、x.pngという名前で出力する。 use Image::Magick; $image = Image::Magick->new; $x =...

Posted in blog::楓 on October 12, 2004 12:14 AM

クラス図を書く

クラス図を書いてみた。 やはり、各ビューを同期させるには、どこかで一元管理した方が作りやすい。 そして、そこへデータの格納や、各ビューへの反映処理を入れることにする。 Doc-Viewアーキテクチャのような感じだ。 でも、Builderはこれをサポートしていないが、確かHPにその回答が書いてあったはず。 見てみると・・・ なるほど、非ビジュアルコンポーネントとして実装するわけね。 これはなかなかよい方法だな。 この方法で実装しよう。 クラス図も書き換えないとな。...

Posted in blog::楓 on October 11, 2004 12:02 AM

プロセスが残る問題への対処

以前、プロセスが残る問題の対処を行ったが、あれで完璧というわけではなかった。 まだ、タイミングによってプロセスが残ってしまうことが判明。 調査すると、DoRenderSample 内でフィルタグラフのIMediaSeeking を使用する箇所で返ってこなくなってしまうようだ。 フィルタグラフはマルチスレッドで動作しており、Stop がコールされても、タイミングによっては、DoRenderSample がコールされてしまうようだ。と言うか、ほとんどの場合、DoRenderSample がコールされてしまう。 そして、その中でフィルタグラフのIMediaSeeking を使うわけだが、すでにdelete中のため、何らかの理由でIMediaSeeking のメソッドがリターンしないようになってしまうようだ。(内部がどのようになっているかわからないので正確な理由は不明。) そもそも、この時点では単にStopへステートの遷移中なのだから、IMediaSeeking のメソッドぐらい使えても良さそうなものだが、使えない。もしかしたら、デッドロックが発生しているという可能性もある。 レンダーフィルタは下記のようないくつかのクリティカルセクションを使用して動作しているが、それらの取得順序の違いによって・・・ いや、その可能性は低いか。 ・m_InterfaceLock フィルタ状態のロック。 ・m_RendererLock ストリーミングのロック。 それよりも、フラグの問題かもしれない。レンダーフィルタがもつフィルタは多い。っていうか、内部動作のシーケンス図クレーって感じだ。 BaseClassesはソースが公開されているので、CBaseRenderer などのシーケンス図を書こうと思えば書ける。でも、フィルタグラフのところは不明なので書けない。(もしかしてどこかにあるのかな?) まあ、結局のところよくわからないのでいろいろと試したが、変なところでフリーズしたりしてうまく行かなかった。 なので、方法を変更することにした。 その方法は次の通り ストリーミング開始時にコールされるメソッド内でフィルタグラフのIMediaSeeking を使用して、開始フレームを記録する。 レンダリング前にコールされるメソッド内で、自身のフィルタのIMediaSeeking を使用してストリーミングタイムを取得し、記録している開始フレームを加算したものを現在のフレームとみなし、メディアサンプルにメディアタイムとして設定する。もし、自身のIMediaSeeking が使用できない場合は、ストリーミングが開始されてからレンダリングしたフレーム数とドロップしたフレーム数を加算する。ただし、ドロップしたフレーム数はより上位のフィルタでドロップされたものまではわからないので、若干精度が劣る。 そして、DoRenderSample 内でメディアサンプルからメディアタイムを取得し、それを現在のフレームとして使用する。 以上のような処理に変更すると、プロセスが残る問題はなくなった。 ただし、現在のフレーム番号の精度は少し落ちているものと思われる。 この対処でも、完全にこの問題に対処できたとは限らない。 もし、CBaseRenderer::OnStartStreaming が別スレッドコールされてしまうと、同じような問題が発生する可能性がある。しかし、CBaseRenderer::OnStartStreaming を可能な限り追ったところ、CBaseRenderer::Run からコールされているようだ。これが同じスレッドなら・・・ そうだ、GetCurrentThreadId...

Posted in blog::楓 on October 6, 2004 03:05 PM

ストリーム タイムを追う

時間について少し整理する 基準タイム 基準タイムは、基準クロックから返される絶対タイムである。 ストリーム タイム ストリーム タイムは、グラフが最後に実行を開始したときを基準に定義される。 ・グラフが実行しているときは、ストリーム タイムは、基準タイムから開始タイムを差し引いた値に等しい。 ・グラフがポーズしているときは、ストリーム タイムはポーズされたときのストリーム タイムに留まる。 ・グラフが停止しているときは、ストリーム タイムはゼロである。 ・シーク処理後には、ストリーム タイムはゼロにリセットされる。 タイム スタンプ(サンプルタイム) タイム スタンプは、ストリーム タイムで示されるサンプルの開始タイムと終了タイムを定義する。タイム スタンプは、プレゼンテーション時間と呼ばれることもある。 メディア タイム メディア タイムは、シーク可能なメディア内のサンプルの本来の位置 (たとえばディスク上のファイル) を指定する。ビデオの場合、メディア タイムはフレーム番号を表す。 シーク処理後には、ストリーム タイムはゼロにリセットされるって、あかんやん。 でも、IMediaSeeking::GetCurrentPosition を使えば正しい位置が返ってくる。 だから、IMediaSeeking::GetCurrentPosition を使えればいいのだが・・・ 調べるとちょうどいいのがあった。 CBaseRenderer::GetMediaPositionInterface フィルタの IMediaPosition および...

Posted in blog::楓 on October 4, 2004 01:49 PM

IMediaSeeking::SetPositions の怪

IMediaSeeking::SetPositionsでシークした際、その移動先が0フレームでなくても、CBaseRenderer::GetSampleTimesで返ってくる位置は0からになっている様子。 そのせいで、途中のフレームにジャンプさせるとうまく行かないようだ。 でも、そしたら・・・ なんかおかしい。 ここはもっと調査しないといけないなぁ。...

Posted in blog::楓 on October 4, 2004 12:50 AM

BRender.axの内包

BRender から必要なソースをコピーし、CBaseControlVideo を継承し作成したクラスを削除、IBasicVideo インターフェイスを取得できないようにする。 代わりにIRendererBufferVideo インターフェイスを作成し、それを継承するようにし、IBasicVideo が提供していたメソッドを実装する。 krlmovie 側では基底クラスでIBasicVideo のメソッドをラップし、IBasicVideo を使用している箇所から分離、そのメソッドを継承側でオーバーライドしてIRendererBufferVideo インターフェイスのメソッドをコールするようにする。 以上のようにすることで、IBasicVideo インターフェイスがなくても動くようにした。 これでクラスファクトリがどうとか言う問題はなくなる。 また、追加されたメソッドはインターフェイスを別にしたので、コードもなかなかスッキリした。 BRender.ax をアンインストールし、動作確認。 以前と同じように動作した。 これでBRender.axは必要なくなった。 にしても、次の2つは紛らわしい。 typedef LONGLONG REFERENCE_TIME; typedef double REFTIME; REFERENCE_TIMEは100ナノ秒単位、REFTIMEは普通に実数で時間を保持している。 次は特定の環境でMPEG再生がうまく行かない問題の対処だな。 フィルターをつなぎ合わせるメソッドは作ってあるので、ひたすらクエリーして接続していくだけのはず。...

Posted in blog::楓 on October 2, 2004 07:41 PM

ボタン絵ジェネレーター

ボタンの絵をパラメタを設定するだけで生成することが出来るツールを作成。 これで、さくさくボタンが作れるが、このツールを作るのにかかった時間を考えると・・・ 普通に絵を作った方が断然速かった。 まあ、今後もっといっぱい作ることになったら、活躍してくれるでしょう。 たぶん。 そのときにはもっと機能追加が必要な気がするけど。...

Posted in blog::楓 on September 28, 2004 03:58 PM

吉里吉里へのマージ

Dee氏に、リリースした時に吉里吉里へのマージなどしていただけるのでしょうか? と聞いたところ、 "そうですね、安定したものでkaedeさんの了承を得られればしたいと思います"と言う回答を頂けた。 安定したらっすね。(笑 BRenderは、いろいろと苦労した分かなり安定しているはず。 後は他の部分のテストだな。 その前に、追加したメソッド群をまとめておかないと。...

Posted in blog::楓 on September 23, 2004 01:57 PM

インストーラーでタイムスタンプ忘れ

BRenderインストーラーでタイムスタンプをきちんとつけるのを忘れてた。 そのせいで、インストールした日付のファイルが出来てしまう。 そのうち直さないと。...

Posted in blog::楓 on September 22, 2004 12:28 PM

画像結合ツールの開発 その1

ヤフオクに出品するものの写真の結合をやりながら思う、面倒くせー。 これは明らかに自動化できる作業だ。 で、画像結合ツールを作ると思い立ち、作業に取りかかった。 今回はめずらしくGUIで作る。 いつもは、Perlとかでさっさとやってしまうのに。 まあ、気まぐれだ。 そして、C++Builderを起動してぺこぺこやる。 C++Builderはあまり慣れていないので、少々手こずるけど、GUIアプリを作るのはすごく楽だ。 とりあえず、DrawGridに画像をD&Dして結合するようなIFにしようと思い、DrawGridをいじる。 でも、エクスプローラーからファイルをD&D出来ない。 ドラッグ&ドロップ用のイベントを書いてもうまくできない。 セル同士のドラッグ&ドロップが出来るようになっただけだ。 調べてみると::DragAcceptFiles( Handle, TRUE );とやって、WM_DROPFILESメッセージを処理するようにしないといけないらしい。 メッセージ処理用メソッドを作るにはBEGIN_MESSAGE_MAPを使うらしい。 なんか、MFCみたいだ。 でも、調べてみると、このマクロは単にDispatchに展開されるだけのようだ。 マクロだとデバッグ時にいろいろと面倒なこともあるので、Dispatchは自分でオーバーライドすることにした。 そして、DragAcceptFilesにDrawGridのハンドルを渡しメイク。 カーソルが変わった。 D&D出来るようだ。 で、ドロップ。 ・・・ WM_DROPFILESのハンドラに来ない。 なぜ? って、DrawGridのDispatchにWM_DROPFILESハンドラを書かないといけないんじゃないか。 普通にメインのフォームのやつに書いていた。 DrawGridを継承するコンポーネントを作る。 きちんとWM_DROPFILESハンドラに来るようなった。 次に画像データの保持だが、面倒なのでvectorで10*10決め打ちで作ることにした。ま、ツールだしね。 std::vector > m_Cells; こんな感じ。 そして値初期化の時にm_Cells.reserve(10)とやって作る。当然2次元なので2次元目もreserveし、NULLで初期化。 画像はTJPEGImageで保持させた。 そして、メイクしてインストールしようとしたら、"パッケージ'vcljpg60'にもユニット'Jconsts'が含まれるためパッケージ'dclusr60'は読み込めません。"と出た。 なんだ、コンポーネントでTJPEGImageを使うのはまずいのか?...

Posted in blog::楓 on September 19, 2004 10:09 PM

Visioを注文

以前からシーケンス図や状態遷移図を描きたいなぁと思っていて、IIOSSなどを使ってみたりしていたのだが、作図に限って言えば、Visioは使いやすい。 シーケンス図の編集は泣きそうになるのだが、その以外はいい。 で、最近お金が入ったので昨日Amazonで注文してしまった。 Vision Standard 2003 と Visio Professional 2003 Version/Product Upgrade だ。 なんでこんな構成になっているのかよくわからないが、Professionalを買うよりも安いので、まあいい。 到着予定は、1個が19日~21日、1個が22日~25日の予定だ。 なぜか分割発送を選んでしまった。 しかも、先に届くのはProduct Upgrade の方。 なんだかなぁと言う状況だ。 それはともかく、ビデオの再生でいろいろと機能追加して、複雑になってきているので、状態遷移図やシーケンス図で整理できるようになって、いい感じだ。 本当は先に図を描いておいた方がいいんだけど、Visioがなかったから仕方ない。 これからは先に描くだろうし。 状態遷移図とか描くのもなかなか楽しいしね。...

Posted in blog::楓 on September 18, 2004 06:27 AM

イベント発生の仕様

イベント発生の仕様はどのようにしたらよいだろう? 基本的には特定のフレームをセットしたら、再生中にそのフレームに来たら、periodイベントを投げるというものだが、問題はドロップフレームが発生する可能性があると言うことだ つまり、if( curFrame == eventFrame ) ではなく、if( curFrame >= eventFrame ) としなければならないわけだが、そんなことをしてしまうと、指定フレーム以降毎フレームイベントを投げてしまう。 それならということで、フラグをもうけて1度しか投げないようにすれば良いかというと、そしたら、ループ中にイベントが発生するように設定したら、1回しか投げられなくて、期待したのと違うという事態にもなる。 じゃあ、指定したフレームより前のフレームに移動したらフラグを解除して・・・ と考えていったわけだが、ふと、利用する時はどのようなものが使いやすいか、と言うことについて考えてみた。 そして、そのフレームを通過した時、1回だけしか投げないと言う仕様にしてしまった方がスッキリするのではないかと思った。 たとえば、イベントを投げるとeventFrame=-1;などとして、イベントを投げるフレームを忘れてしまうわけだ。フラグも要らない。 ループなどでは何度も設定しないといけないわけだが、そう言う仕様だと言うことにすれば問題ないだろうし、ループ中で何度も投げることは少ないだろう。 ただ、問題点として、再生中のフレームより小さいフレーム番号にイベントを設定すると、設定した次のフレームにイベントが投げられてしまう。これはちょっと不便だ。 なら、ドロップフレームは10フレームまで考慮し、それよりフレーム番号が大きい場合は無視するように・・・ そしたら、取りこぼしが怖いなぁ。 設定した時のフレームの前後関係を保持し、現在のフレーム番号の方が大きい場合は、イベントが発生しないようにし、設定されているフレームよりも小さいフレーム番号へ移動した時にこの発生しないようにしたものを解除すると言うのが妥当だろうか。 ちょっと複雑になってしまったけど、仕方ないかな。 とりあえず、そんな感じにするか。...

Posted in blog::楓 on September 18, 2004 05:57 AM

現在のフレーム番号の取得

様々な場所でIMediaSampleからメディアタイムを得ようとするが、得ることは出来ず。 やはりデコーダーはメディアタイムを設定していないようだ。 ということは、レンダーは即座にレンダリングすることになる。 しかし、CBaseRenderer::Receiveがコールされてから実際にレンダリングされるまでには、一度イベント待ちがある。 つまり、このイベント待ちの直後の時間が、そのフレームの時間に近い。 そして、CBaseRendererでは、イベント待ちの後にOnWaitEnd がコールされるようになっているので、これをオーバーライドすれば、目的の時間に最も近い時間が得られるはずだ。 また、OnWaitStartと言うメソッドもある。 何となく、気になったので、この2つのメソッドを通過する時間をOutputDebugString でデバッガへ出力。すると、明らかにイベント待ちをしたような時間差がある。 イベントってレンダラー自身がIMediaSampleからメディアタイムを得て、IReferenceClock::AdviseTimeを使用し、そこからイベントが送られてくるのを待つんじゃなかったっけ? 調べると、やはりCBaseRenderer::ScheduleSample でスケジューリングされていた。 その中では、GetSampleTimesがコールされていて、そこから得た時間を元にスケジューリングしているようだ。 しかし、GetSampleTimesの中では、IMediaSample::GetTimeを使って時間を得ている。 以前、IMediaSample::GetTimeを直接コールしても、時間を得ることが出来なかったのだが・・・ なぜか出来ている。 あれ?っと思い、GetSampleTimes をコールしたら、時間を取得できた。 さらに、ありぃ?と思い、IMediaSample::GetTimeを直接コールしてみたら、またしても時間を取得できた。 なぜ? 私は幻を見たのだろうか? そんなことはないはずだが・・・ でも、100nsec単位の時間が返ってきている。確か、ビデオではフレーム番号がメディアタイムのはずだが。 GetSampleTimes はタイム スタンプを取得するとある。 って、あああぁぁぁぁぁぁぁぁ。 IMediaSample::GetTimeとIMediaSample::GetMediaTimeって、メソッド違うじゃないか! IMediaSample::GetMediaTimeにしたら、やっぱり取得できなかった。 と言うことは、IMediaSample::GetTimeからフレーム番号に変換すれば何とかなりそうだ。 ここは意外と盲点かも。って、俺がアホなだけかな。 ちなみに、IMediaSeeking::SetTimeFormat( &TIME_FORMAT_FRAME )と設定しても、IMediaSample::GetMediaTimeでメディアタイムを得ることは出来なかった。...

Posted in blog::楓 on September 13, 2004 10:55 PM

BRenderの拡張をしようとする

BRenderは画面更新時にEC_UPDATEイベントを送るが、そのとき同時に、何フレーム目かを送れるように変更しようとした。 IMediaSampleに問い合わせれば、フレーム番号が取得できるはずだから、簡単に出来ると思っていたのだが・・・ 取得しようとしたら、"このサンプルにはメディア タイムがセットされていない。"って、返ってきた。 どうしよう。 これはまた大変そうだ。 他の方法をとるかなぁ。 まずは調査だ。...

Posted in blog::楓 on September 10, 2004 11:47 PM

BRenderインストーラの作成

BRenderインストーラを作成した。 面倒なのでVCでMFCを使って組んだ。 MFCを使ってと言っても、書いたコードのほとんどはAPIコールだが。 にしても、面倒臭い。 基本的には、リソースに入れたファイルをシステムディレクトリに書き込んで、その書き込んだBRender.axをロードして、登録する関数ポインタを得て、それをコールするだけなのだが、きちんとエラーの処理などをしているのでコードがかなり多くなってしまっている。まあ、当然のことなのだが。 でも、これでBRender.axの公開にだいぶ近づいた。 後はドキュメントを書くだけ。面倒だけど。 そして、その次はレイヤー描画だ。 なんとか、来週ぐらいに一度リリース出来ると良いのだが・・・ まとまった時間がとれれば可能かな?...

Posted in blog::楓 on September 9, 2004 01:46 AM

レイヤーへの描画サンプル

サンプルを置こうと思ったけど、いろいろいじっていたらちょっとまずい部分を発見したので、とりあえずやめにした。 まあ、激しいエラーが出て大慌ててでアプリ強制終了させると言うことがあったんですが。 原因は、フレームの更新部分にあったようで、レイヤーにnull設定したら、フレームの更新のたびにエラーが出て、毎秒30個エラーボックスが出るという悲惨なことに。 で、とりあえず画面イメージだけ。クリックすれば実寸になります。 どうしても、早く見たいって言う人がいたら言って下さい。 あげますんで。 でも、今のところ動作無保証です。 何があっても知りません。 まあ、他のアプリと同時に起動させていなければ大丈夫でしょう。 と言っても、その内リリースされると思うから別に今じゃなくてもいいんですけどね。...

Posted in blog::楓 on September 8, 2004 07:18 PM

リリースに向けて

まずはCOMコンポーネントを公開に向けて利用方法などの資料整理だな。 ムービー拡張を組み込んだ吉里吉里は、いろいろとやらないといけないことが残っているので、まずはそれを片づけないと。 それと、ブログを整理してDirectShowの解説ドキュメントも書いておきたいな。 ブログのままだとぐちゃぐちゃだし。というか、1から読まないとよくわからない状態。 吉里吉里でムービーの上に文字が表示されているサンプルって、早く見たいって人はいるのだろうか? たぶん、リリースまでにはまだ時間がかかりそうだからこんな感じだ!って、置いておくのも良いかもしれない。 でも、その前にDee氏に一言断っておいた方がいいな。 一度またIRCに行こう。 さて、ここからが面倒臭い作業だが、リリースに向けてがんばらねば。...

Posted in blog::楓 on September 8, 2004 02:05 AM

レイヤーへの描画、長かった・・・

ついにレイヤーにムービーが表示された。 テキストがムービーの上に出ている。 やったー。 でも、同時にいくつか問題が。。。 とりあえず解決したものとして、初めループ出来なかったのが直せた。 ただし、これでいいのかどうかは謎だ。 どういうことかというと、ループの終点でperiodイベントを送っているが、periodを送ったすぐ後で、playを送っている。 これはステータスをplayに戻すためだ。 単にStatusへplayを設定すればいいだけかもしれないが、とりあえずこのような実装にした。 ここはもう少し調査する必要がありそうだ。 もう一つは、ムービー開始点で一瞬ちらつくと言うことだ。 これは、ムービーが開始され、1フレーム目を描画し終わる前に画面が描画されてしまうために発生してしまう。 どうしてそうなるかと言うと、現在、描画後画像をレイヤーにアサインするような作りになっているのだが、初めは何も描画されていない真っ白な画像がレイヤーにアサインされている。 つまり、そのレイヤーを表示にした瞬間、この白い画像が描画されてしまう。 そして、1フレーム目が描画され、アサインされた瞬間に普通の絵が出る。 とりあえず、内部的にムービーの1フレーム目が描画され、アサインする時に表示にするようにしたが、本来は表示前にreadyか何かのメソッドを準備し、1フレーム目をレンダリングしレイヤーにその画像をアサインするようにした方が良いだろう。 そうすれば、表示にした時、1フレーム目が表示されるので特に問題ない。 しかし、そうすると1フレーム目が2回表示されて・・・というか、ダブルバッファリングだから表示が1フレーム遅れるのは仕方ないか。 ま、この辺りはもう少し考えて改善することにしよう。 何はともあれ表示されるようになったので、ちょっとこれで遊ぶぞーぅ。...

Posted in blog::楓 on September 7, 2004 09:11 PM

DLLへ公開メソッドの追加

tGetVideoOverlayObjectと同じ機能を持った構造体渡しバージョンを作った。 そして、元のtGetVideoOverlayObjectは、mode引数を削除し、従来のままの関数とした。 で、ビルド&実行。 うまくいった! 引数が7個とかになるとまずいのだろうか? 引数の制約でもあるのか? でも、別にスタック渡しなら問題なさそうな気もするが・・・ よくわからないけどいいや、解決したし。 詳しく追ってもいいけど、そんなに引数が多い関数は滅多に作らないだろう。 ま、後で気が向いたら詳しく追おう。 そして、いよいよレイヤー描画の動作確認だ。 でもその前にTJSスクリプト書かないと。...

Posted in blog::楓 on September 7, 2004 07:28 PM

レイヤー描画を組み込んでビルド

レイヤー描画関連の機能を組み込んでビルド。 動作確認をしたら、なぜかDLL内の関数に渡される引数の一つがおかしなことに。 呼び出し方法も指定しているし・・・ 引数が多いのが原因?というか、そう言うことってあるのか? よくわからない。 BCBとVCでデバッグできないかなぁ。 BCBでデバッグ中だと、VCからそのプロセスにアタッチできなかった。 VCがBCBで吐いたコードのデバッグ情報を読み込んでくれれば楽なのだが・・・ VCのデバッガの方がいいし。 出来るかなぁ? やっぱり、よくわからない。 もう一個メソッドをDLLから出してみるかなぁ。...

Posted in blog::楓 on September 7, 2004 06:42 AM

Lightflowのファイル

Lightflowのシーンは独自のファイルフォーマットがあるようだ。 それも、アスキー形式とバイナリ形式がある。 シーンプロキシをLfASCIISceneProxyにすれば、指定したストリームにアスキー形式でシーンを出力してくれる。 当然、そのファイルをレンダリングさせたり、そのファイルからシーンを構築できたりする。 つまり、I/Fがなくても直接このスクリプトを書けばレンダリングさせることが出来る。でも、それはかなり面倒くさい。やっぱり、I/Fは必要だ。 アレ?ということはこの発見は意味ないか。 ま、ネットワークレンダリングの時に役立つぐらいかな。 でも、なぜか少しI/Fのイメージがわいた。...

Posted in blog::楓 on September 6, 2004 06:42 PM

レイヤー描画ビデオクラスの作成

オーバーレイとレイヤー描画の共通基底クラスへオーバーレイのIBasicVideoインターフェイスを移す。 共通基底クラスの純粋仮想関数を何もせずにリターンするように実装する。 これで、共通基底クラスの純粋仮想関数はなくなった。 まあ、それぞれのクラスで実装しないものを、何もしない関数として上位に実装しただけだが。 レイヤー描画ビデオクラスをコーディング。 まだ、ビルドしていないがとりあえずコーディング終了。 後は、生成部分でのクラス生成分けと、レンダーフィルターからの描画更新イベントに対応すれば、とりあえずはレイヤーに描画できるようになるはず。 CLSID_BufferRendererは手書きで定義したが、IDLにcoclassを記述して、MIDLに生成させた方が良いかもしれない。 ビルドしたところ、問題なかったのでそのままにした。...

Posted in blog::楓 on September 6, 2004 02:56 AM

ムービーレイヤー描画の制約

諸般の事情により、ムービーレイヤーはムービーの画像サイズを変更できないことにしたので、LayerVideoが持つBitmapはムービーのサイズと同一です。 描画対象レイヤーはそのBitmapと同一サイズである必要があります。 なので、レイヤーサイズがムービーのサイズを異なる場合、強制的にレイヤーサイズを変更してしまいます。(いいのかなぁ) ムービーサイズとレイヤーサイズにはご注意を。 ムービーの画像サイズを変更出来るようにすれば、この問題は解消されるのだけれども、それは後で考えよう。...

Posted in blog::楓 on September 5, 2004 05:09 PM

LightflowのI/Fをまとめる

Lightflowの各パラメータをクラスにまとめる。早く、I/F作って、ごりごりレンダリングさせてー。まあ、まずはLightwaveのデータをレンダリングできるようにしよう。で、サーフェイスとかパラメタいろいろいじって楽しむんだー。(子供のように楽しげに話す) かっけーって言うようなものを作るっすよー。  でも、どんなI/Fにするかが問題だな。まずはファイル喰わせてレンダリングするようなのを作りたいと思っているけど、その次はパラメタいじってレンダリングしてって言う作業を手軽に出来るGUIが欲しくなってくるかも。最終目標はシーンをごりごりいじれるツールだな。後ネットワークレンダリングも。あー、わくわくしてくる。  後、Yさんに教えてもらったのだがXSIがかなり安くなったとか。一番安いのは8万円弱。ちょっと買ってみたい気もする。でも先立つものが。。。お金入ったらまず豪速新PCを買いたいしなぁ...

Posted in blog::楓 on September 4, 2004 06:40 PM

終了時アクセス違反の調査

IGraphBuilderを最後にリリースしているのだが、どうやらこの部分でアクセス違反が起きているらしい。 なぜか、すでにリリースされてしまっているようだ。 集成の問題か! もらったー! やはり、集成の問題だった。 CBaseVideoRendererを継承したレンダーのコンストラクタで、CBaseControlVideoを継承したクラスをメンバに持っているので、CBaseControlVideo::CBaseControlVideo( NAME("Video properties"), pUnk, phr, &m_InterfaceLock, this ) と言うように初期化していた。 しかし、本来はCBaseControlVideo::CBaseControlVideo( NAME("Video properties"), GetOwner(), phr, &m_InterfaceLock, this ) と初期化しなければならない。 コンストラクタで渡されるpUnkは集成された所有者オブジェクトへのポインタと説明されている。 そして、pUnkがどこから渡されるかと言えばクラスファクトリだ。 さらに追うと利用者がCoCreateInstanceから渡たすものだ。 で、CoCreateInstanceではNULLと指定していた。集成なしということだ。 つまり、最初のように初期化すると集成なしとされる。 これがどういうことになるかというと、リリースした時メンバ変数をdeleteしようとしてしまう。 ま、おかしくなって当然ですな。 そして、本来は2番目の初期化方法のようにGetOwner()によって、集成もとのオブジェクトのポインタを得るわけだ。 そうすれば、参照カウンタは集成元のオブジェクトのものが使われるようになり、解放時もオーナーが解放されるようになる。 これで、万事O.K.と言うわけだ。 集成の説明 (間違っているかも) 複数のインターフェイスを1つのクラスに持たせる場合、多重継承が使われるが、多重継承を使いたくない場合というのは往々にしてある。 そんなとき、よくメンバにそのクラスを持ってしまうと言う方法がとられる。 そして、そのクラスが保持するインターフェイスが要求された時、そのメンバのポインタを返すことで要求を満たす。 これが集成である。 しかし、COMの場合、すべてのインターフェイスは参照カウンタを保持する。そして、参照カウンタが0になった時、そのオブジェクトはdeleteされる。...

Posted in blog::楓 on September 4, 2004 02:06 PM

フィルタの修正

インターフェイスを追加しようとして、いろいろと入らないことが判明し、処理の書き換えを行った。 そのおかげでだいぶコードがすっきりした。 次はプレーヤー側の修正だ。 でも、そっちは結構大がかりかも。...

Posted in blog::楓 on September 2, 2004 09:49 PM

インターフェイスの変更(?)

レンダーからイベントを送るため、IMediaEventSinkをセットするメソッドを追加したいと思い、IDLファイルにメソッドを追記し、IMediaEventSink型を使うために、import "axextend.idl";を追加する。 と、やっていてふと気付く、フィルタはイベントを送るんだから、IMediaEventSinkははじめから持っているんじゃないかと。 調べると・・・あった。 CBaseFilter.m_pSinkだ。 IMediaEventSinkを設定する関数は無駄だったんですね。 で、作っていた物を書き換えて動作確認する。 問題なく動いた。 IMediaEventSink関連の処理は全くの無駄だった。(涙 無駄な処理を削除していくのもまた悲しい。 それはともかく、MediaTypeを取得する物もインターフェイスへ追加しようと思ったが、フィルターではなく、ピンの方のIPin::ConnectionMediaTypeで取得できることがわかったので、やめる。 まあ、これ関連の処理も全くの無駄だったんだけど、これはこれで処理は短くなっていたので良しとしよう。書き換えないといけないけど。 で、結局インターフェイスはそのままでいいことになった。...

Posted in blog::楓 on September 2, 2004 09:32 PM

IRendererBufferAcces関連仕様

Set系は、基本的にフィルタグラフを作ってから、再生を開始するまでに行うようにする。 再生中の呼び出しは動作保証されない。 再生が開始された時に、Setが呼ばれていない場合は、TBufferRendererが自分でメモリを割り当てる。 特にメモリを渡す必要がない場合はこの方法を使用する。 TBufferRendererが確保したメモリをGetし、そのメモリを再度Setしてはいけない。TBufferRendererは、Setによってメモリが設定されると、自分で確保したメモリは解放するので、不正アクセスが発生してしまう。 当然、TBufferRendererが確保したメモリをGetし、そのメモリを解放するなどという暴挙に出てはいけない。 buffにNULLを入れて呼び出すと、sizeに要求されているサイズが返ってくる。 TBufferRendererはフレームが更新された時、EC_UPDATEを投げる。利用者はEC_UPDATEを受け取ったら、GetFrontBufferし描画などの処理を行う。...

Posted in blog::楓 on September 1, 2004 01:03 AM

多重継承

COMの場合、1つのクラスに複数のインターフェイスを持たせるのが一般的なようだが、そのためには多重継承をしなければならない。 しかし、すべてのインターフェイスはIUnknownを継承する。 つまり、QueryInterfaceやAddRedなどのメソッドがかぶってしまう。 おいおいどうするんだ?それってやばくないのか?と思っていたが、実は全然問題ないようだ。 そもそもCOMもそれを期待している節があるようだ。 多重継承を行った場合、基底クラスごとに仮想関数テーブルが作られる。 そして、共通の関数は両方のテーブルで同じ物を指す。 つまり、何の問題もないのだ。 ただし、複数の仮想関数テーブルが作られる関係上、キャストは慎重に行わなければいけない。 QueryInterfaceで返すインターフェイスは、要求された型に一度きちんとキャストする必要がある。 そうしなければ、仮想関数テーブルが別物になってしまい、うまく動作しなくなる。 また、仮想関数テーブルが違うと言うことは、ポインタが異なる。 つまり、同じクラスが持っているインターフェイスでも、QueryInterfaceで返ってきたインターフェイス同士を比較してはいけない。 まあ、利用者側としては、同じクラスかどうかなどわからないし、それを期待した実装はしてはいけないので、さして問題はない。 どうしても、比較したい場合は、そのインターフェイスにQueryInterfaceでIUnknownを要求し、そのIUnknownインターフェイスのポインタを比較するようにしないといけないようだ。と言っても、使わないけどね。 ここの説明は、C++がどのようにクラスを実現しているか、メモリ構造がどうなっているかを知っていないとかなりわからないかも。 まあ、C++のクラスのメモリ構造を知ってて、多重継承はどうなの?って説明だからなんだけど。 それと、図があった方がもっとわかりやすいっすね。 自分用の備忘録としてはこれで十分なんだけど。...

Posted in blog::楓 on August 31, 2004 10:46 PM

IBasicVideoの実装

サンプルを見ながらクラスを作成。 CBaseControlVideo::NonDelegatingQueryInterfaceとCBaseControlVideo::GetVideoFormatさえ作れば、目的を達成できるが、他にいろいろ純粋仮想関数があるので、それも実装しないといけない。 ほとんどはE_NOTIMPLエラーを返すだけだが。 とりあえずは、今までグローバルにあったMediaTypeをBufferRendererに保存するように変更。動作確認。 IBasicVideoをサポートするクラスを作成し、追加したらクラスファクトリ系のグローバル変数が必要だと言われる。 つまり、CBaseControlVideoを継承したクラスを作ると Textures error LNK2001: 外部シンボル ""class CFactoryTemplate * g_Templates" (?g_Templates@@3PAVCFactoryTemplate@@A)" は未解決です。 Textures error LNK2001: 外部シンボル ""int g_cTemplates" (?g_cTemplates@@3HA)" は未解決です。 などが出るようだ。 CBaseControlVideoを継承したクラスを持ったフィルタを作ると、IBasicVideoがフィルタグラフから使われる(検索される)ようになるわけで、そしたらフィルタが登録されていないといけないと言うわけだろうか。 これは、どんどん本格的なフィルタになっていく・・・。と言うか、クラスファクトリを実装してレジストリの登録とかをやったら、もう普通のフィルタです。 でも、そうなると独自メソッドはインターフェイスとして実装しないといけないことになって・・・。 ちょっと大変です。 しかも、レジストリへ登録とかになってくると、インストーラがどうとか言うことになって・・・ IBasicVideoはもういいか。 とりあえずは、LayerDrawとOverlay別々の処理にしておいて、将来的にきちんとしたフィルタとして実装する? と言っても、かなり近い将来になりそうだけど。 とりあえず、その方針にして、両方を平行で進めることにしよう。 よし、ローカルの実験用リポジトリをブランチだ。...

Posted in blog::楓 on August 27, 2004 10:34 PM

modeにいて

modeはopen前に設定されていた物を有効とすることにした。 それは、open時のクラス生成時に生成するクラスを振り分けることにしたからだ。 OverlayとLayerDrawの共通部を基底クラスにし、それを継承してOverlayとLayerDrawの各クラスを作ることにした。 動的再接続を使用して2つを切り替えるのは少々厳しそうだから諦めることにした。MPEG SplitterかDecoderのどちらか忘れた(あるいは両方)が、再接続に必要なインターフェイスを備えていないので、再接続しようとしたらかなり面倒だ。 メモ デフォルトのフィルターなどもCOMだから、包含することで独自に機能拡張することも可能だ。 つまり、デフォルトのオーバーレイをラップして機能拡張が出来る・・・調べてみるとやりたいことは無理そうだ。 メモ2 フィルタグラフはIReferenceClock を使用して同期をとるようだ。 IReferenceClockではセマフォを使って同期をとるようだ。 DirectXのヘルプ"DirectShow のタイムとクロック"の項を読むとよいようだ。 時間は100ナノ秒単位。 10,000,000 = 1秒。 でも、返される値は意味がない。それは、基準クロックに依存するから。つまり、100ナノ秒単位できちんと増加するわけではない。 制御しづらそう。サウンドがある場合は、サウンドフィルタのクロックに同期化されるんだろうなぁ。 IMediaSample::GetMediaTimeを使えば、そのサンプルのフレーム番号がわかる。 IBasicVideo::get_AvgTimePerFrameを使えば、100ナノ秒単位のフレームレートが得られる。 IVideoFrameStep を使えばコマ送りが出来る。...

Posted in blog::楓 on August 23, 2004 11:57 PM

メソッドとプロパティの追加

TJS2 基本的な使い方のネイティブクラスの項を読む。 以前も一度読んだのだが、また頭がこんがらがる。 クラス、インスタンス、オブジェクトと言う言葉が出てくるが、これらの言葉は状況によって取り方が変わる。それに、C++の方かTJSの方かがすぐに判断できなくて、さらにこんがらがる。 まあ、よく読めばわかるんだけど。。。 もう一度読んだらまた???ってなりそうだ。 それはさておき、とりあえず、Overlayにメソッドとプロパティを追加。 VideoOvlIntf.cppですな。 他のをコピペしてただ書き換えるだけ。単純作業だ。 マクロが少し気になるが、たぶん登録処理だろう。 で、メイク。 すんなりいった。 じゃ、次は実際の処理の記述ですな。 でも、I/FにはすでにPause()が入っているけど、実装されていない。 なぜだろう? ま、考えても仕方ない。追加していこう。 でも、その前にテスト用のTJSスクリプトを書いておいた方がいいかな。...

Posted in blog::楓 on August 23, 2004 06:57 PM

オーバーレイの対応

レンダーがデフォルトの物でいいので、グラフ作成部分がすごい簡略化された。 で、再生! ・・・ ウィンドウが4つ出来た!! やったね!っておい。 オーナーウィンドウや位置を設定しとかないといけないようだ。 設定すると問題なく表示できた。 これでとりあえず目標は達成だな。 次は吉里吉里への組み込みだ。 でも、その前にどのような構成にするか検討しないと。 なんとなく、KAGのソースを見てみる。 ウィンドウがムービーオブジェクトを持っているんすね。 KAGの方の改造はそれほど大変ではなさそうだ。 そして、ふと気付く。 KAGに構文を追加しようと思ったらパーサーをいじらなければならないのではと。 でも、ほとんど予約語追加と対応する処理を記述するだけとかで出来るんじゃないかなぁと期待を抱く。 何となく見た感じだとbisonは使っているけど、flexは使っていないような感じだったけど・・・ ま、その辺は追々だな。 初めはKAGでTJS直打ちすれば済むし。...

Posted in blog::楓 on August 20, 2004 09:28 PM

フィルタグラフの複数生成

ヘルプを見ていると、どうもフィルタグラフは複数存在していても良いようだ。 それなら、初めに複数のフィルタグラフを生成しておき、順番に再生していけばうまくいきそうだ。 で、早速試す。 うまくつながっているけど、完璧につながっているかどうかはわからないなぁ。 そこで、アニメのOPを5秒ずつに分けた3つのムービーを準備し、再生してみた。 が、やっぱりつなぎ目で音がとぎれるし、絵も一瞬ぼやける。しかし、MPEGなんだから、その絵が完璧に一致しないのは仕方ないだろうと思う。 問題は音だが・・・やっぱり一瞬とぎれてしまうよなぁ。 完全に繋ごうと思ったら、ソースフィルタからデコーダーへ流れるデータをとぎれないようにしないといけない。 そうするとソースフィルタを工夫しないといけないのだろうか? そもそもそこまで必要かどうかと言う問題がある。 ムービーをつなげて作る場合、シーンが切り替わるところにムービーの接続点を持ってくるだろう。そうすれば、たいして違和感なく表示される。 また、バックに音楽を流す場合は、ムービーとは別に音楽を流せば何とかなるのではないだろうか。 つまり、完全につながっていなくても大丈夫な気がする。 ま、作り手の工夫次第っすね。...

Posted in blog::楓 on August 20, 2004 09:10 PM

ソースフィルタの動的再接続

ヘルプの動的再接続のソースを参考に、と言うかほとんどそのまま実装してみる。 が、いきなりQueryInterfaceでインターフェイスがないと返ってきて終了。 何ーぃ。 まあ、サンプルはソースフィルタではなく、途中のエフェクトフィルタだったので若干異なるのかもしれない。 でも、このIPinFlowControlがないと動的再接続が出来ないのだが・・・ ヘルプを読むと次のように書かれている ---以下引用 フィルタ開発者へ : 動的な再接続をサポートするパーサー フィルタとキャプチャ フィルタでは、その出力ピン上でこのインターフェイスをサポートしなければならない。通常、その他のタイプのフィルタでは、このインターフェイスを実装する必要はない。 ---引用終わり ソースフィルタはサポートしていなくても良いと言うことだろうか? そもそも、ソースフィルタを差し替えるには他の方法があるような気がしてならない。 さてどうしたものか。 基本的にソースフィルタを差し替えたい場面はムービーの終点になる。 つまり、すでにストリームにはデータは流れていないはずだ。 なら、そのままはずしてしまえばよいのではないだろうか? とはいうものの、やっぱり危険な香りがするので、IMediaControl::Stop()を事前に呼び出し、フィルタを停止状態にしておくことにする。 しかし、この場合ムービーのつなぎ目に隙間が生じてしまう可能性がある。 まあ、隙間が出来たら、ソースフィルタのみを停止し、つなぎかえれば何とかなるのではないだろうか。そのときはそのときにいろいろと考えよう。 で、IMediaControl::Stop()を呼び、IPinFlowControl::Block()は呼ばずにIGraphConfig::Reconnectを実行してみたのだが、入力ピンがIPinConnectionをサポートしていないと返ってきて終了。 ・・・ なんですとー。 まあ、毎度のことなんだけど・・・ よし、自分でDisconnectを呼んで、その後また自分で繋ごう。 で、やってみたらなんかうまく再生されない。 GraphEditで見てみると・・・ めためたです。(涙 本来は次のようにきれいにつながっています。 でも、よく見てみると、スプリッターから先がぶった切れているだけのようだ。 なら面倒だが、再度繋げば大丈夫なんだろうか? でも、そうすると一から構築するのと大差ない気がするのだが・・・ さてどうした物か。 とりあえず、どの辺りでぶった切れているのか調べると、ソースフィルタをDisconnectした後にすでに切れてしまっているようだ。 うーん・・・ 明日考えよう。...

Posted in blog::楓 on August 19, 2004 08:48 PM

接続しているピンの取得

接続しているピンを取得するには、IPin::QueryInternalConnectionsではなくIPin::ConnectedToを使えばいいようだ。 QueryInternalConnectionsはインプリメントされていない場合があるが、ConnectedToにはそのようなエラーは定義されていない。 たぶん下位の部分で実装されているのだろう。 これで、スプリッターのピンの問題は解決した。 次はソースフィルタを差し替えれば、次のムービーが再生されるはず。...

Posted in blog::楓 on August 19, 2004 07:54 PM

C++ビルダでフォーム表示の切り替え

C++ビルダでフォームの同じ位置に異なるダイアログのようなコントロールの固まりを切り替えながら使用する方法を調べる。 ページコントロールを使えば、タブによって切り替えられるが、タブが表示されてしまうのはちょっとかっこわるい。 そこで、同じ位置にパネルを配置し、その各パネルを表示/非表示することで、とりあえずは切り替えられることがわかった。 しかし、フォームの編集が出来ない。 各パネルないにフレームを配置し、そのフレームを編集することで、各コントロールを編集することは出来るが・・・どうもしっくり来ない。 もっと良い方法はない物だろうか? 出来れば、動的に割り当てられるとかなり良いのだが。。。 とりあえず次のようにすればいいようだ。 m_Frame = new TFrame1(this); m_Frame->Parent = MyPanel; m_Frame->Align = alClient; m_Frame->Show(); まず、フレームを生成する時にオーナーをFormにする。 Parentに位置を決めるためのパネルを設定する。 アライメントをクライアント領域に設定する。(アライメントはフレームの方で設定しておけば問題ないようだ) で、表示する。 後はいらなくなったら非表示にして削除する。 そして、各フレームの各コントロールの状態を保持する構造体でも作ってデータを設定/取得出来れば万事O.K.だ。...

Posted in blog::楓 on August 18, 2004 05:59 PM

ソースの整理2

エクセプションクラスは組み込めた。 そのおかげで例外処理部がきれいになった。 ユーティリティー的なのは全部CPlayerに入れてしまうことにした。 そして、MPEG依存部分 ( フィルタ名を直指定で検索している箇所がある ) をなくしていく。 しかし、ソースの整理と同時にやると面倒なことになる可能性があるので、とりあえずは従来の処理を有効にしておく。#if #else #endifで分けておく。(リファクタリング時に機能追加しないのは基本らしいし) ソース整理はもう少しかかりそうだ。 ビルドして動かす間でしばらくかかるので、時々中だるみする。 やっぱり、細かくやっていった方がいいな。...

Posted in blog::楓 on August 17, 2004 10:29 PM

CComPtrの代入時の振る舞い

COMのインターフェイスを管理する時はATLのCComPtrを使うと楽だ。 ソースはatlcomcli.hにある。 で、代入時の振る舞いがちょっと気になったので調べてみた。 中ではAtlComPtrAssignが呼ばれている。 その中を見ると次のような感じ。 if (pp == NULL)    return NULL; if (lp != NULL)    lp->AddRef(); if (*pp)    (*pp)->Release(); *pp = lp; return lp; やっぱ代入元もAddRefされてるんすね。 と言うことは、呼び出し元管理のインターフェイスは代入後Release呼んどいた方が良さそうだ。...

Posted in blog::楓 on August 17, 2004 02:16 PM

連続再生について

今日はとあるイベントに行った後、アキバへ行ったりしていたので進捗がないが、昨日考えたことをここに記しておく。 遅延なく連続再生するためにメモリ上にデータを置こうと思っていたが、そんなことをしなくても、ディスクに一度アクセスすればキャッシュがきいてほとんどの場合遅延なく読み込めるのではないかと思う。NT系のディスクキャッシュは強力だし。 で、それより問題になると思われるのはグラフの再構築だ。 もし一から構築しなおすと、完全につながらないのではないかと考えられる。 何となくだが、グラフの構築はそこそこ時間のかかる処理のように見える。 そこで、どうするか? だ。 簡単に思い付くのはフィルタグラフを複数作っておくという物だが・・・ 複数作っても大丈夫なのだろうか? また、うまく切り替えられるのだろうか? 次善の策としてはソースフィルタの差し替えだ。 すべてを作り直すのではなく、次のムービーのソースフィルタのみを事前に準備しておき、切り替え時にその部分のみつなぎかえると言う方法だ。 どっちにしても、ソースコードを整理しないといけないので、どちらを選択してもいいのだが、ソースフィルタの差し替えで済むのならそれが一番なので、まずは差し替えを試してみることにする。...

Posted in blog::楓 on August 15, 2004 10:09 PM

ソースフィルタの変更

asyncio.h/.cppとasyncrdr.h/.cppをそのままコピーしてきて、吉里吉里のCIStreamReaderとCIStreamProxyを別ファイルに分離して、それをインクルード。 VC.NET 2003でビルドするとasyncio.cppでビルドエラーが。 単に型チェックが厳しくなっただけのようだ。 asyncio.cppの422行目のCreateThreadへ渡す関数ポインタを(LPTHREAD_START_ROUTINE)にキャストしたらビルドが通る。たぶん、これで大丈夫だろう(あまりこういうことはしない方がいいけど)。 ビルドが通ることを確認したので、ソースフィルタを変更する。 と言っても、AddFilterでCIStreamReaderをグラフに追加し、その出力ピンとレンダーをつなぐだけ。 IStreamはとりあえずSHCreateStreamOnFileでお手軽に生成。 でも、SHCreateStreamOnFileに渡すファイル名はなぜかマルチバイト文字セット。 仕方なく、WideCharToMultiByteで変換する。 なんで、ワイド文字列(Unicode)じゃないのだろうか? シェル系はワイド文字列が多かったはずだが・・・あれ?逆だったかな? まあ、いいか。どっちでも。面倒だけど。 で、前回と同じように再生されることを確認。 なんか、かなりあっさりと出来た。 次はいよいよメモリからの再生。 でも、そんなに難しくはなさそう。 IStreamを継承したクラスを作って、ぽんっと渡せば済みそうだし。...

Posted in blog::楓 on August 14, 2004 07:25 PM

Asyncサンプル

メモリから読み込む場合、このサンプルがほとんどそのままっぽい。 Base部分は吉里吉里と同じ? とりあえず、memfileのソースを読むが、やっぱり簡単そうだ。 でも、BaseやFilterを見ると・・・って、いつものようになるのだろうか? Filterを軽く見た感じではそうでもなさそうだ。 Baseがいろいろとやってくれているのだろう。 でも、Baseのソースを見ると・・・いろいろとややこしそうなことをしている。 面倒だなぁ。 Baseはあんまり見ずに、そのまま流用でいいかな。 吉里吉里ソースを見直すとIStreamを渡すようになっている。 つまり、メモリ用のIStreamのなんかを作ればいけるのか? ファイル用のIStreamはSHCreateStreamOnFileをコールするだけでいけるようだ。 でも、COMってどうやって作るんだっけ? すっかり忘れてしまった。...

Posted in blog::楓 on August 13, 2004 09:23 PM

マルチメディア ストリーミング

IDirectDrawMediaSampleAllocatorのことについて調べていて、 IDirectDrawMediaStreamを発見する。 どうやら、IDirectDrawMediaSampleAllocatorを使うには、IDirectDrawMediaStreamを使わなければならいなような雰囲気だ。 しかし、IDirectDrawMediaStreamはインターフェイス一覧にない。 なぜだ? うーん、MicrosoftのDirectDrawをなくしたいと言う思惑だろうか? まあ、使用禁止インターフェイス一覧になかったら気にせずに使おう。 そして、IDirectDrawMediaStreamの項を見ているとマルチメディア ストリーミングへのリンクがあった。 マルチメディア ストリーミング? そんなのあったっけ?と思ったら、ヘルプ付録にあった。 うーん・・・普通のところに書いていて欲しかった。 まあ、とにかくマルチメディア ストリーミングの項を読まねば。 ・・・ 例によって例のごとくよくわからない。 いや、よくわからないと言うか、今回のような構成で使用できるのかどうかがわからない。 マルチメディア ストリーミングはどうやらファイルを与えて、任意のサンプルを得るための仕組みのようだ。 つまり、適当につなげて・・・と言うような用途には利用できないのかもしれない。 マルチメディア ストリーミングの入力はファイルかモニカを使用するようだ。 モニカについてはよくわかっていない。 調べた結果、オーバーレイかマルチメディア ストリーミングを使用しないとDirectDrawへ直接書き込めなさそうだ。 しかし、MPEG-1 ビデオ デコーダ フィルタの > このフィルタは、DirectDraw サーフェスへのデコードも可能である。 と言う一文がかなり気になる。 何らかの方法でDirectDraw サーフェスへ直接書き込めそうなのだが・・・ とりあえずは、そのことを気にとめておいて、メモリ上からの再生とオーバーレイの切り替えを先にやろう。 オーバーレイ、マルチメディア ストリーミング、モニカはその過程でわかっていくだろう。 メモ...

Posted in blog::楓 on August 13, 2004 09:40 AM

DirectDrawSurfaceへの描画方法の調査

ビデオレンダリングフィルタを使えば、DirectDrawSurfaceに描画出来るようだが、そうしてしまうと、描画タイミングを得る方法がわからない。 あるのかもしれないが、調べた限りではわからなかった。 IDirectDrawMediaSampleAllocatorとIDirectDrawMediaSampleを使えば、デコーダーにDirectDrawSurfaceへ直接描画させられそうであるが、これはどうすればいいのだろうか? どのメディアタイプで接続すれば良いのかがわからない。 アロケーターに呼び出しがかかるのは、レンダー接続時のCheckMediaType呼び出しより後だったはず。 つまり、その時点で受け入れるメディアタイプをどうするかが問題だ。 いや、他ので実験してみればよいのか。 いけるかも。...

Posted in blog::楓 on August 12, 2004 07:09 PM

高速化への実験

今までのことを整理していてふと気付く。 DirectDraw Surfaceを使えばさらに高速化できるのではないかと。 とは言っても、直接使うことは出来ない。 吉里吉里の仕様上、最終的にはメモリ上にイメージがなくてはならない。 しかし、これは最終的にメモリ上にあれば良いと言うことでもある。 つまり、DirectShowにDirectDraw Surfaceへレンダリングさせ、それを再びメモリへコピーしてこようという作戦だ。 明らかに非効率的な方法のように感じるが、これによって少しCPU負荷が下がる可能性がある。 最近のグラフィックスカードはMPEG再生支援機能という物がだいたい搭載されている。 MPEGのデコードは前フレームとの差分や逆離散コサイン変換などがあり結構重い処理だ。 そして、MPEG再生支援機能とは動き補償やIDCTなどをさすようだ。 当然、MPEGムービーは入力データ量よりも出力データ量のほうが遙かに大きくなる。 あくまで推測だが、、MPEG再生支援機能によって、この少ないデータ量をグラフィックスカードへ送り、グラフィックスカード内で伸張されるのではないかと考えられる。(このようになっていればかなり効率が良い) つまり、CPUの処理量とメモリコピーの量がかなり軽減されるわけだ。(推測だけど) しかし、この後でVRAMからメインメモリへのコピーを行わなければならない。 当然これは負荷がかかる。しかも、その後またメインメモリからVRAMへのコピーが発生する。 結局のところハードウェアによってなくなった分とVRAMからメインメモリへのコピーでどちらが重いかと言うことになる。 うーん、微妙ですね。 たいして速くならない気もする。 まあ、興味があるのでちょっとやってみようって感じですね。...

Posted in blog::楓 on August 10, 2004 08:22 AM

ソースの整理とイベント化

上下反転の実験用コードの削除と、連続再生用に少しだけコードを整理する。 Texture3Dでは再描画がメッセージではなく、メッセージループでメッセージがないときに描画&Sleepと言う構成だったので、レンダーのDoRenderSampleがコールされ、サンプルが得られた時点でIMediaEventSinkインターフェイスを使ってメッセージを送信するように変更した。( メッセージはOnRenderEndで送る方が良いかも ) なお、定義済みのイベントではそのような目的の物はなかったので、独自に定義した。 ヘルプに独自定義に関する文章は見つからなかったが、DirectShowのイベントが定義してあるEvcode.hにEC_USERが定義してあったので、たぶんこれを使ってユーザーイベントを定義することになっているのだろうと勝手に解釈し、#define EC_UPDATE (EC_USER+1)と定義した。(ウィンドウメッセージにもWM_USERって言うのがあるし) よく調べるとDirectX8.1の英語ヘルプのには次のように書かれていた。 Filters can define custom events with event codes in the range EC_USER and higher. どうやら、上記のような使い方で問題ないようだ。...

Posted in blog::楓 on August 9, 2004 04:38 PM

ピンとアロケーターの実装

参考ソースを今まで作ってきた物にあうように若干修正して(ほとんどそのまま、でも、オーバーライドした関数は単にスルーようにした)、ビルド。 デバッガで動きを追ってみる。 次は、アロケーターがDirect Draw Surfaceを返すように改造だ。 いよいよ核心ですな。 でも、CMemAllocatorではなく、CBaseAllocatorを継承した方がよい気がするなぁ・・・ メモリは確保せず、持っているサーフェイスのポインタを渡すだけだし。 でも、要求されたサイズがサーフェイスのサイズを上回っていたらどうするか・・・ エラーにするか、それともメモリ確保をして、多段コピーするようにするか。 デコーダーに渡す時に丸める処理を入れるから、上回ることはそんなに多くないだろうし、エラーにしても他のアロケーターが使われるだけだろうから、たいして問題はないでしょう。まあ、そのときは多段コピーで性能が落ちるけど致し方ない。...

Posted in blog::楓 on August 7, 2004 08:36 AM

さくっと分離

レンダーを別ファイルに分離して、ソースの整理を行って、ビルドが通った。 グローバル変数はそのまま。 やっぱめんどうだし、そんなに多くないから今はいいやって感じで。 で、次はアロケーターとピンですね。...

Posted in blog::楓 on August 7, 2004 07:50 AM

開発日誌って・・・

開発日誌の増加量が半端ではない。 このまま行くとどうなってしまうのだろうか? 再利用性なんてあったもんじゃない。 最後にカテゴライズしてインデックスを作ればそこそこ後で見返すのも楽になるだろうか? それよりも心配なのは、もっと時間のかかる物の開発を始めた時である。 その時はどうするのだろうか・・・ うーん・・・その時はその時ですね。 ああ、いいかげん。...

Posted in blog::楓 on August 5, 2004 09:06 AM

Texture3D(改)をメインに

サンプルのTexture3Dを改良していった方が簡単だと思い、その方向で行くことにした。 DirectDrawでいろいろやったのは何だったんだろうと言う考えが、頭をよぎるが気にしないことにする。 で、まずは必要のない3D関連の処理を取り、TextureをSurfaceにする。 デコーダーの出力形式をRGB32にするのは以外と簡単で、CheckMediaType内で受け入れる形式をRGB32にすれば、RGB32で出力してくれるようになった。 それと、MPEGファイル名が直値だったのをプログラムの実行ディレクトリ+ファイル名(直値)とした。 とりあえず、これでだいたい準備は整ったかな。 ヘルプも読んでだいたい理解したので、次はピンとアロケーターの作成だな。...

Posted in blog::楓 on August 4, 2004 09:50 PM

DirectShow 実験プログラム第1段階 - 2

かなり長くなってしまったので分離する。 なんか計画性は皆無だな。 メモ 超高速描画の謎--以前読んだ気もする・・・ DirectShowを扱う部分のコードを吉里吉里のからコピペして、改良していく。 とその前に、コメントとルールを決めておくことにした。 基本的にはDoxygenで自動的にドキュメント(関数リファレンス)を吐かせたいから、Doxygenの書き方には従う。 で、後は項目や細かい書き方だな。 以前、会社で作ったものを参考にしながら、自分の書きたいように作り直す。(こうゆう規約を作るのは、自分が多かったなぁ・・・) ヘッダーコメントは//スタイルよりも/**/の方が書く量が減るし、書き始めが左に少しずれるので/**/を使うことにした。 そんな感じでだいたい決めた。 そのうち内規として上げておこう。 で、早速コーディングだと意気込んで。 まずはプロジェクトにDirectShowに必要なライブラリなどを加える。 そして、コーディング・・・よくわからない。 ヘルプとサンプル、ソースコードを何度も見直す。 そのうち何とかわかってきた。 とりあえずここにある程度まとめる。 吉里吉里のコードIStream周りを追う。深い。止める。 今回は、ファイルが独立しているので、IFileSourceFilterですませることにした。 ここでふと、Texture3Dを改良したプログラムで音が鳴っていなかったことに気付く。 そこで、GraphEditでシミュレートしようと思うが、独自に拡張したフィルタを追加する方法がわからない。GraphEditのヘルプを見ればいいんだろうが面倒だなぁと思っていると、実行中プロセスのフィルタグラフを見る方法があると書かれている。 そのためには、実行中オブジェクト テーブル (ROT)にプログラムで登録する必要があるらしい。 ここってハッと気付く、Texture3DのソースでなんとかROTと言う関数があって、よくわからない処理をしていたことを。 そう言うことだったのか。 今後は、DirectShowのプログラムを書くときは、デバッグ用にROTへの登録処理を書くことにする。 ちょっと話がそれたが、Texture3Dではそのままでグラフを見ることが出来るようなので、GraphEditで見る。 サウンドの出力がない。 とりあえず、練習用にこれにサウンドの出力を追加してみるか。 まず、DirectSoundのフィルターがなんかよくわからなかったので、IAMDirectSoundかな?と思い、おもむろにグラフビルダーにQueryInterfaceしてみる。後で気付くが、これははっきり言ってアホな行為です。 たぶん、IAMDirectSoundはフィルターではありません。DirectSoundフィルタのインターフェイスの一つです。 しかも、IGraphBuilderにQueryInterfaceしても見つからないと思われる。 まあ、このあたりのことはさらに理解が深まったときに書くとして、結果としてどうやったかを書きます。 CoCreateInstanceでCLSID_DSoundRenderを使い、DirectSoundフィルターを生成します。 フィルタグラフにDirectSoundフィルタを追加します。 MPEG-I Stream SplitterフィルタをフィルタグラフにFindFilterByNameで見つけます。...

Posted in blog::楓 on August 3, 2004 07:00 AM

DirectShowっていったい・・・

私は馬鹿なのだろうか? DirectShowのヘルプとサンプルを見ると何となくわかったような気になる。 でも、コーディングの時になると、やっぱりわからない。 たぶん、それでもほぼ期待した動作をするコードを書くことは出来るだろう。 何かが引っかかる。 グラフビルダーにムービーファイルを渡すと、最も基本的な構成でフィルタグラフを構築してくれる。 自分で構築したいときは、AddFilterを使ってフィルタを追加し、ピンを接続する。 でも、ピンの接続先は指定しない。勝手につないでくれる。 よくヘルプを見るとメディアタイプを指定することで、グラフビルダは正しい位置にフィルタを挿入できるとある。 GraphEditを少しいじってみて、ヘルプを読み直す。 ああ・・・、了解了解。 よく見ると接続先を指定している。 もう少し実験すれば確証が得られそうだ。 Texture3Dサンプルの場合 まず自作のCTextureRendererをグラフビルダーにAddFilterで追加している。 次にグラフビルダーのAddSourceFilterをコールすることで、ファイルを渡されたグラフビルダーがメディアを理解し、残りのフィルタグラフを自動的に構築するようにしている。この時点ですべてつながっているのではないかと思われるが、サンプルを見た感じでは、つながっていないようだ。 そして、CTextureRendererの入力ピンをCTextureRendererからFindPinで取得、ソースフィルタの出力ピンをソースフィルタからFindPinで取得し、その2つのピンをグラフビルダーのConnectでつなげている。Connectは必要であれば、間に適切なフィルタを挿入する。 つまり、グラフビルダーがどこまで自動的に構築できるかをよく認識し、自動的に出来ない部分を手動でつないでやる。と言うことのようだ。 IGraphBuilderとIFilterGraphで、フィルタグラフへのフィルタ追加&グラフ構築ができる手は限られている。 IFilterGraphはAddFilterとConnectDirectの2つ。 IGraphBuilderはConnect、Render、RenderFileとAddSourceFilterだ。 ちょっとメモ メリット値 モニカ 続く・・・...

Posted in blog::楓 on August 2, 2004 05:29 PM

IRC チャンネルでのチャンネルの作り方

IRCでは、参加者が一人もいないチャンネルは自動的に消滅します。 逆に、それまで存在しなかったチャンネル名を入力すると自動的にチャンネルが作られます。 例えば、チャンネル名を『#gはいうおvhせ』などと適当に打って入室してみましょう。 すると、勝手に『gはいうおvhせ』というチャンネルが出来上がります。 当然、他の人が『gはいうおvhせ』に参加して普通に話す事も出来ます。 つまり、自分独自の部屋名を入力するだけで誰でも簡単にチャンネルを作る事が出来るのです。 ----------- そうだったのか。 知らなかった。 つまり、PC立ち上げっぱなしにして、ログインしておけば、そのチャンネルは維持されるわけか。...

Posted in blog::楓 on August 2, 2004 05:43 AM

DirectShow 実験プログラム第1段階

とりあえずは、以前自分が作ったDirectDrawのプログラムと吉里吉里のソースとDirectShowを使った動画再生とフレームビットマップ取得方法のサンプルソースを参考に作る。 まずは、VCでプロジェクトを作って、draw.libをリンクに加え、Direct Drawの初期化部分を作る。 でも、なんでVCはあんなにAboutダイアログ好きなのだろう。私は、ほとんどの場合使わないのだが。。。 コーディングしながらふと気付く。DirectX5ぐらいのヘルプはないだろうか? VC.NETのヘルプを見ても、そのあたりの関数は消えている。MSDNを入れれば復活するかなぁ。 そうだ、Cマガの付録から探せばいいんだ。 で、探すとあった。 DX5.2とDX7のヘルプとサンプルソースを入れる。 でも、DX5.2の日本語ヘルプはなくて、なぜかDX3のが入っていた。 まあ、DX7のヘルプがメインになるだろうから大丈夫だろう。 サンプルなどを見ていて思い出してきた。 このころはCOM丸出しだったんだった。 DX7使うにはdxguid.libも必要な様子。 フルスクリーンじゃないとバックバッファ使えないんだった。(本当にそうだったかなぁ?) とりあえずは、DirectDrawを初期化してから、オフスクリーンバッファのポインタを取得して、そこへ書き込むまでは出来た。 予想外に手こずるなぁ。 DXMediaSDKのヘルプも必要そうなのでコピーしておく。 でも、英語版しかなかった。 まあ、それはともかく次はDirectShowだ。 上述のページによると・・・ streams.hとそれに必要なライブラリがサンプルのディレクトリ内にあり、ビルドするにはSDK内のdxsdk\samples\Multimedia\DirectShow\BaseClassesをINCLUDEディレクトリに追加し、 baseclasses.dswをビルドして得られるstrmbase.libとstrmbasd.libをリンクできるようにしておかなければならない。 ・・・とある。 本当なの?と言うか、これ使ってしまっていいの? 後、吉里吉里は固めたファイル内からムービーを読み込むためにMicrosoftから提供されているasyncio.h/.cppとasyncrdr.h/.cppを使っているとか。 吉里吉里のkrmovieのプロジェクトを見てみると、strmbasd.libをリンクしていた。 それに、streams.hもインクルードしている。 やっぱり、必要なようだ。 よくヘルプを見ると、8以前のバージョンでは上記ライブラリはバイナリで提供されていたようだ。 DirectShowについて再びいろいろと調べる。少し理解が深まった。 そして、出来れば、吉里吉里の実装に近い形態で作りたいと思い、コードを追う。 IDirectDrawSurfaceが取得できれば・・・と思って、いろいろと調べるがよくわからず。と言うか、取得方法がない気がする。 結局、Dee氏に質問することにした。 結論はメモリへのポインタとして取得することしかできないとのこと。 まあ、DirectDrawだけだと自由度が低いし、Lock遅いって言うし、そう言う実装になりそうだなぁ。 ---それといろいろと聞いたのでメモ 聞いたときのバージョンは吉里吉里2 2.22 rev.2/...

Posted in blog::楓 on August 1, 2004 07:10 AM

バージョン管理システムについてのメモ

使ったことがあるものと、これから使おうとしているものを比較してみる。 ただ、使ったことがあるものは少々バージョンが古かったりするので、現在のものとは違うかもしれない。 後、あんまり詳しく比較はしない。 と言うか、最もよく使う、チェックイン、チェックアウト、ロック、ロック解除ぐらいしか比較していない。 Visual SourceSafe 6.0 チェックアウト&ロック、チェックイン&ロック解除を持つ。 チェックアウトするとロックがかかり、チェックインするとロックが解除される。 チェックアウト以外に取得というものがあり、ソースはこれで取ってくる。 取得したソースは読み取り専用属性が付く。 編集する際はチェックアウトする。すると、ソースの読み取り専用属性が解除され、リポジトリ上のソースはロックされる。 編集が終わったらチェックインする。すると、ソースに読み取り専用属性が再び付き、ロックが解除される。 読み取り専用属性はローカルで簡単に解除できるけど、そんなことをしてもあんまり意味がないのでしない。 説明を読んでわかる通り、小規模開発向け。 でも、作りがシンプルな分使いやすい。 チェックアウト&ロックをした人と管理者が休むと作業が止まってしまうこともある。あんまりないけど、その時はとりあえず叫ぶ。 ただ、マージがほとんど発生しないので、精神的に良い。 マージは非生産的な作業の雰囲気を漂わせている上に、かなりの集中力がいるので、ファイル数が多いと相当辛い。 StarTeam 4.2 チェックイン、チェックアウト、ロック、ロック解除を持つ。 チェックイン、チェックアウトとロック、ロック解除が独立している。 当然、ロックしていないと、他の人が同じソースをチェックインして、マージが発生することがある。 ただし、生産性を下げないためにロックはあまりしない。 そのためマージ作業に遭遇するが、それは諦めるしかない。 もし、他の人が同じファイルをいじっているのを発見したら、出来るだけ早くmakeが通る状態にしてチェックインするのが吉。 そうすればマージ作業から逃れられる。チェックインは早い者勝ちなのだ。とにかく細かく早くリリースしよう。 ただ、焦って致命的なバグを入れてしまわないようにしよう。そんなことをしたら、かなり非難されてしまう。それと、チェックインを急いでいるのは出来るだけ周りに悟らないようにしよう。何食わぬ顔をしながら、素早くコーディングするのだ。 また、周りがどのような作業をしていて、どのファイルをさわっているかに常に気をつけておこう。同じファイルをいじる時期は出来たらずらしたい。かち合う場合はとにかく素早くコーディングだ! また、ロック機構があるので、担当者に休まれたら叫ぶという状況は発生しうる。 なんか、いいとこなしのような印象を与えてしまうかもしれないが、実際はそんなことはない。 いろいろと機能盛りだくさんだし、それほど悪くはないシステムだ。 にしても、StarTeamってBorlandだったのか。違ったような気がしたが。 そもそも私が使っていたのは4.2とだいぶ古かったので、変わってしまったのかもしれない。 Subversion, CVS コミット(チェックイン)、チェックアウトを持つ。 まだ使ったことはないので、よく知らない。 ただ、ロック機構がないので担当者不在で叫ぶことはない。...

Posted in blog::楓 on August 1, 2004 05:57 AM

DirectShowで実験-サンプルのビルド

実際に実験を行ってから、少し時間が経ってしまったが、メモしておくのを忘れていたので、ここに追加しておく。 まず、やりたいことはオーバーレイを使わずにDirectShowを使ってビデオを再生することだ。 オーバーレイは以前に一度、DirectX7かその辺りの時に、何となく遊んでみたことがある。とは言っても、そのころのことはほとんど忘れてしまった。 そんな感じなので、とりあえずは良さそうなサンプルをDirectX8.1 SDKの中からか探してみる。(DirectX9でもいいのだが、入れてあったのが8.1だったので、そのままにした) いろいろと見てみたところTexture3Dが一番近そうだ。 Texture3Dはムービーをテクスチャとして使うサンプルだ。 とりあえず、MovTexture3Dと言うフォルダを作り、そこにこの中身をコピーする。 プロジェクトはVC++6の物のようだ。 気にせずダブルクリックしてVC++.NET 2003を立ち上げる。 プロジェクトを変換するかとどうか聞かれたので、すべて変換する。 何はともあれビルド。 > Textures fatal error LNK1104: コンパイラは、ファイル 'libci.lib' を開くことができません。 と出て、失敗。 旧プロジェクトから変換した時、よく出るエラーだ。 LIBCIをリンクしないようにして、再度ビルド。 > Textures error LNK2001: 外部シンボル "_CLSID_FilterGraph" は未解決です。 > ・・・ なんか、リンク時にいっぱいないと言われる。 いろいろと調べたところstrmiids.libを追加する必要があるようだ。 で、追加したらうまくいった。 そうそう忘れていた。 上記のこと以外に、XSDK/samples/Multimedia/DirectShow/BaseClassesをビルドしてライブラリを作っておく必要がある。 これを忘れているとさらにエラーが出たはず。 以上で、とりあえずビルドが通ったので、改良にかかる。...

Posted in blog::楓 on July 29, 2004 05:07 PM

こういう仕様にしましょう

----以下、W.Dee氏の返答から引用 もし吉里吉里本体に手を加えられるならば、VideOverlayにレイヤへの画像出力機構を持たせるようになるのかな、とか思っています。 VideoOverlay のなんらかのプロパティにレイヤオブジェクトを指定するとそのオブジェクトに動画が出力されるようになると。 いわゆる「オーバーレイ」では無くなるので VideoOverlay という名前とはちょっと乖離してしまいますが、レイヤの指定領域にビデオを勝手に表示する(結果もともとレイヤのそこの領域にあった画像は上書きされる)という意味ではオーバーレイという意味があり、名前はこのままでかまわないとも思います。 ----以上、引用終わり W.Dee氏の考えに沿う形にしよう。 より詳細な仕様は、もうちょっと調査してから決めることにする。...

Posted in blog::楓 on July 29, 2004 01:05 AM

プラグインのライセンスに関して

いずれlicense.txtに追加されることになりそうですが、念のためここにメモしておく。 ------以下、引用 license.txtの「● オープンソース」のにある「ここで流用とは、このソフトウェアの一部が他のソフトウェアに組み込まれること」(tp_stub.h / tp_stub.cpp が他のソフトウェアに組み込まれること)に該当しますが、プラグインについては特にそこで求められているような「このソフトウェアに含まれるソースを使用している旨をドキュメント等に表記することか、あるいは、このソフトウェアの作者に配布を行う旨を事前に連絡し確認をとることの、どちらかあるいは両方」は求めない方向で行こうかな、と思います。 ただし、tp_stub.h や tp_stub.cpp 以外の 吉里吉里のソースコードを流用する場合は別です。 ライセンスに補足が必要ですね。入れておこうとおもいます。 ただプラグインをGPLも適用可能なライセンスにしておかないと、吉里吉里のライセンスとしてGPLが選択されたときにその吉里吉里とはリンクできないことになりますのでご注意ください。 もっともGPLを選択可能にするのは強制ではありませんし、プラグインのソースを公開することでさえ強制ではありません。 # 吉里吉里のライセンスとしてGPLが選択された事例は未だ見かけた事はありませんが...

Posted in blog::楓 on July 28, 2004 11:23 PM

クラスプラグインは可能?

ソースやTJS2のドキュメントを見ていて気付いたのだが、関数プラグインだけではなくて、クラスプラグインも作れるのではないだろうか? 関数プラグインはtTJSDispatchを継承して作る。 実際の処理はFuncCallをオーバーライドする。 そして、それをバリリアント型に変換する。 iTJSDispatch2かそれから派生したグローバルオブジェクトを取得し、そのメンバ関数のPropSetを使い、バリリアント型に変換したクラスを登録する。 そうすることで、グローバルな関数として使えることになるようだ。 そして、ここからはソースやドキュメントからの予想。 PropSetは字句を登録しているのではないだろうか? 登録した字句をnewするとiTJSDispatch2のCreateNewがコールされる。 生成されたオブジェクトのメソッドをコールするとiTJSDispatch2のFuncCallがmembernameを伴ってコールされる。 と言うことは、クラスプラグインも何とかなるのではないだろうか? ただ、組み込みクラスは継承図の構成が異なっているのが気になる。 ファクトリーパターンやプロキシのような作りになっていると言うことだろうか? やはり、もう少しコードを追わないと可能かどうかわからないなぁ。 クラスプラグインが使えるのなら、関数をまとめたクラスをTJSで作ると言うことはしなくても良くなる。 当然、その方が自然だし、処理も軽くなるだろう。 ソースを追ってもいいが、聞いた方が早いか。...

Posted in blog::楓 on July 28, 2004 02:05 PM

構成

拡張方法としては、次の2つが考えられる。 ・本体に変更を加える ・プラグインを作る しかし、W.Dee氏は定期的に本体の拡張をされているようなので、あまり本体に変更を加えたくない。 そうなるとプラグインとなるのだが、今回のような用途の物はあまり想定されていないようだ。 吉里吉里で使えるプラグインの種類は次の3つ。 ・Susie Plug-in (画像読み込みとアーカイブアクセス) ・WaveSoundBufferで再生可能な形式を拡張するためのプラグイン ・そのほかの吉里吉里専用のプラグイン そして、そのほかの吉里吉里専用のプラグインは次の2つにわかれている様子。 ・トランジション用 ・関数追加用 以上のことから考えると、 プラグインで提供する。 プラグインはTJS関数追加プラグイン。 となりそうだ。 後は、利便性を考えて、TJSでクラスを作り、KAGプラグインとして提供するとなるだろうか。 なんか、Cで組まれたライブラリのラッパークラスを作るような感じだなぁ。 組込型に比べれば少し重いかもしれないが、たぶん大丈夫でしょ。(根拠なし)...

Posted in blog::楓 on July 26, 2004 05:33 PM

2004/07/26

少し前にSQLiteと言うものを知った。 SQLiteはRDBのような使い方をする用途ではBerkeley DBに取って代わろうとしているとかしていないとか書いていた記憶がある。( 残念ながらそのページのURLはメモするのを忘れていた ) で、調査することに。 パブリックドメインで、自由にコピー、変更、出版、使用、コンパイル、販売、オリジナルSQLiteのコードの配布がバイナリ、ソースコード問わず、どのような用途でも、商用、非商用関係なくできるようだ。 詳しくはこの文章を呼んで下さい。 注意!!上記解説は私のつたない英語力で読解した物なので、当てにしないで下さい。 この解説を元に損害を被っても私はいっさい責任を負いません。 この文再び登場。 すごい。すばらしい。 なんて崇高な思想なんだろう。 しかも、SQL文が使える。まあ、そのせいで動作はBerkeley DBよりは遅いことが予想されるが、ベンチマークを見る限りでは、MySQLと同じか少し速い、PostgreSQLより圧倒的に速い。 速度的な問題は実際にアプリに組み込んで使ってみないことには何とも言えないが、たぶん大丈夫だろう。(根拠なし) 簡単にコマンドラインのプログラムをいじってみたが、いい感じだ。 普通のRDBMSのような感じで使える。 しかも、データはファイルに直接書かれる。 クライアント・サーバ形式ではない。 ああ、素敵だ。 もう、SQLiteに決めた。(即決!惚れた!) 現時点ではバージョンの問題があるようだ。 2.8系と3.0系。 3.0系は次のバージョンで安定版になるだろうと書かれている。 どうするかなぁ・・・ 3.0系にするか。 BLOBをきちんとサポートしているし、UTF-8、UTF-16もサポートしているし。 何より新しい方がいい。 全く持っていい加減だが、気にしない気にしない。 結果 データ保存部分はSQLite V3.0系にする。 ラッパーとしてこれが有用かも。...

Posted in blog::楓 on July 26, 2004 04:52 AM

2004/07/12

Berkeley DBのライセンスをチェック。 オープンソース形式なら無料、ソースを公開しない場合は有料です。って事らしい。 オープンソース形式とは、GPLとBSDを含むopensource.orgで記載されている条件を満たした物らしい。 オープンソースライセンスは@ITによる解説文やGNUによる解説文がわかりやすそう。 次に添付されていたライセンス文を読む。 Berkeley DBのソース配布予定はないので、バイナリ形式の項を読む。 バイナリ形式で配布する場合は、上述のコピーライトの複写、この条件リストと以下の免責条項を配布物に付属するドキュメントもしくは他に付属する配布物に添付すること。 免責条項の欄はまだ読んでいない。 注意!!上記解説は私のつたない英語力で読解した物なので、当てにしないで下さい。 この解説を元に損害を被っても私はいっさい責任を負いません。 と、一応書いておこう。 で、どうするかだが、派生物の定義が微妙だ。 Berkeley DBのDLLを使用したソフトウェアは派生物になるかどうか。 GPLの場合、リンクするソフトウェアは派生物とされているが、LGPLの場合は、派生物ではないとなっている。 Berkeley DBのライセンスはどうなのだろう?これはかなり詳しく追いかけていかないとわからない問題だ。 とは言っても、このアグリゲーターはフリーで良い物が見つからなかったので、作ろうと思った物だ。 なので、オープンソースにしてしまっても問題ない。 とりあえず、オープンソースで行くことにしよう。 しかし、今後Berkeley DBを使ったソフトウェアを開発する時はどうするか? オープンソースではなくプロプライエタリなモデルを採用したい場合だ。 うーーん、購入すればよいか。 その他発見したBerkeley DBに関するリンク Berkeley DB と mmap UNIX DBM掲示板 等を発見。 他にもいろいろと読んでみたが、良さそうなドキュメントは見つからず。 AmazonでもBerkeley DBの書籍を探すが見つからず。 やはり、添付ドキュメントとサンプルソース見ながらゴリゴリしかなさそうだ。 でも、当たり前と言えば当たり前だが組込型のデータベースはBerkeley...

Posted in blog::楓 on July 12, 2004 04:08 PM

2004/07/09

ニュースの各記事を保存するのに独自のデータ形式を設計して、読み込み書き込みライブラリを作って・・・というのは、ちょっと現実的ではない。 だいいち面倒臭すぎる。 XMLを使って保存することも考えたが、こういうことは明らかにRDBMSの方が向いている。 たぶん、XMLでやってしまうと、記事が多くなってきた時、読み込みが遅くて嫌になるだろう。 そんなこんなでRDBMSを使うことを決めたが、まだ何を使うか決めていない。 とりあえず、MySQLかなぁと思ったが、そんなことしたら一般配布が困難になってしまう。 別にいいかと思いつつBCCでMySQLにアクセスする方法などを調べてみる。 データベース操作実験と言うページがよさげであった ( MySQLではないが ) 。 その後、直接プログラムに組み込めるDBがあるのではないかと気づき、調べたところいくつか見つかった。 そのような用途ではDBM, NDBM, GDBMなどが有名なようだ。 しかし、最近はBerkeley DBがよく使われているような感じだ(自信なさげ)。 このブログもBerkeley DBを使っている。 と言うことで、Berkeley DBを使おうと決めるが、使い方など全く知らないので、調査したところ、Berkeley DB で遊ぼう!と言うページが良さそうな情報を提供していた。 RSSを扱うのに特化したライブラリやコンポーネントがないか探すが見つからず。 Xerces-C++を使って作るか。...

Posted in blog::楓 on July 9, 2004 06:05 AM