|
Quick Links
Categories
XML/RSS Feed
Statistics
Total entries in this blog:
Total entries in this category: Published On: 10 09, 2005 11:45 午前 |
1033 : Max Tips(007) : 赤松正行------------------------------------------------------------------------
DSPマガジン 2005.01.19 No.1033 ------------------------------------------------------------------------ そろそろ新春気分も抜けた頃ですが、2005年最初のDSPマガジンの配信です。どうぞ今年もよろしくお願いします（って今年も続くのか〜ってのは去年も書いたなぁ〜笑）。ともあれ、今回はMax Tipsの7回目、まずはJitterでの映像処理に関して処理速度と全画面表示に関するテクニックを解説します。久々にサンプル・パッチも書いてみました。そして、あまり話題にならないうちに(?)ディスコンしちゃいましたが、近々さらに強力になって復活予定のビジュアル・ツールを紹介し、グラフィックス・カードでオーディオ処理を行う話題も取り上げます。 ・フレームレイトを上げろ ・フルスクリーンを考える ・PixelShoxって知ってる？ ・オーディオもGPUで ------------------------------------------------------------------------ Max Tips(007) 赤松正行 ■フレームレイトを上げろ Jitterの悩みの種は処理が重くってフレームレイトが下がっちゃうことですね。10fpsくらいしか出なくって、カクカクとした映像でイヤになるってことがあります。これを解決するには基本的にはアルゴリズムを突き詰めるしかないのですが、ちょっとした設定で処理速度が上がることもあります。 その代表選手がウィンドウ表示を行うjit.windowの設定。noaccelはグラフィクス・カードのハードウェア・アクセラレーションをオフにするアトリビュートで、デフォルトではオフになっています。オフをオフと言うことはオンなわけで、アクセラレーションを行っています。しかし、OpenGLを使わずにビデオ映像を処理しているとか、2Dグラフィックスを生成しているといった場合には、この設定はかえって邪魔なんです。2D処理だけならハードウェア・アクセラレーションをオフにするほうが高速に表示されます。アクセラレーションをオフにするほうが速いっていうのも変な感じですけどね。 もうひとつ重要なのはdoublebufferというアトリビュートで、これはオフスクリーン・バッファを使って描画するもの。デフォルトではオンになっています。オフスクリーンとは目には見えない裏側で描画を行って、それを表側に転送するという手法で、チラツキを防ぐために役立つ場合があります。しかし、処理によっては単なる二度手間ですので、オフちゃってもいいでしょう。さらにsyncというアトリビュートもあります。これは描画をVBL（垂直同期信号）に合わせて行うもので、デフォルトはオンです。これもチラツキ防止にグッドなんですが、足枷をはめるようなものなので、怒濤のフレーム攻撃には不要です。ただし、sync設定はnoaccelがオフの時だけ有効です。 それではノイズを表示するだけの簡単なサンプル・パッチで試してみましょう。「1-window settings.pat」を開いてみてください。このパッチでjit.windowにアトリビュート設定のメッセージを送ってみます。最高のフレームレイトを叩き出したのは「noaccel 1, doublebuffer 0」の場合で、PowerBook G4/1.33GHzでは220fps程度になりました。最低は「noaccel 0, doublebuffer 0, sync 1」の場合で30fpsです。その差7倍以上ですね。まぁ、表示するまでの処理の負荷や映像の見え方にもよるので単純な比較はできませんが、jit.windowの設定だけでも随分とフレームレイトが違うわけです。 ------------------------------------------------------------------------ ■フルスクリーンを考える パフォーマンスやインスタレーションでは映像をフルスクリーンで表示したい場合が多いですよね。このためには、jit.windowにfullscreen 1メッセージを送るだけです。メニューバーも消したい場合はfsmenubarというアトリビュートを0にしておけばOKです。これもサンプル・パッチを用意しましたので、「2-fullscreen.pat」を開いて、数字キーの「1」を押してみてください。もう一度「1」キーを押せば元に戻ります。 ところで、多くの場合、映像の縦横比が4:3だったり16:9だったりしますが、スクリーン自体はそうでないかもしれません。そのような場合に単純にfullscreen 1とすると映像が横や縦に伸びちゃってカッコ悪いです。そこで、映像の比率を保ったまま、できるだけ大きなサイズで表示することを考えてみましょう。サンプル・パッチでは数字キーの「2」を押した場合がそれで、必要な処理は「propotional-fullscreen」サブ・パッチで行っています。 「propotional-fullscreen」サブ・パッチでは、jit.displaysにcurrentstate 0を送って、メイン・スクリーンのサイズを求めます。このサイズから4:3になる最大サイズと中央に表示できる位置を求めて、jit.windowにsizeメッセージとposメッセージを送っています。これで比率を保ったフルスクリーン表示ができます。ただし、元に戻すことを考えて、先にgetrectメッセージをjit.windowに送って、現在の表示矩形を得ておきます。フルスクリーン解除になった場合は、その矩形を使ってウィンドウを表示をするわけですね。以上は、サブ・パッチの中央部分です。 この処理ではfsmenubarアトリビュートによるメニューバーの消去ができないので、自前でメニューバーの表示をコントロールします。これはサブ・パッチの左側にあるMaxへのメッセージ送信で、;max hidemenubarならメニューバー消去、;max showmenubarならメニューバー表示となります。 また、スクリーンが4:3でない場合は余白が生じて、背後のウィンドウやデスクトップが見えてしまいます。そこで、もうひとつウィンドウを作ってフルスクリーン表示した後、映像のウィンドウを上に重ねて表示すれば良いでしょう。サブ・パッチの右側ですね。right-to-leftって知っていますよね？ なお、ここでは背景ウィンドウを黒くするために、黒い1ピクセルの画像（マトリックス）を表示しています。 さらに考えると、これまでのフルスクリーンは映像を拡大表示しているわけで、そのためにCPU（あるいはGPU）パワーを使っています。これは場合によっては無駄以外のナニモノでもありません。映像が640×480ピクセルなら、スクリーン自体を640×480ピクセルにしちゃえば良いと思いませんか？ というわけで、スクリーン・リサイズをするのが「screen-resize」サブ・パッチで、数字キーの「3」を押せば動作します。 具体的にはjit.displaysでスクリーンのサイズを変えることができますが、実際にはgetmodeメッセージを送って対応している全モードを求め、その中から指定することになります。getmodeで得られる情報は、ディスプレイ（スクリーン）のID番号、モードのインデックス番号、横ピクセル数、縦ピクセル数、カラー解像度、リフレッシュ・レイト、そして拡張表示の状態からなるリストです。このうち拡張表示であれば「stretched」、そうでない場合は空のシンボルとなり、これ以外は数値で表されます。サブパッチでは、横640ピクセル、縦480ピクセル、カラー解像度32ビットで拡張表示でない、という条件でインデックス番号をgateから通過させ、その番号のsetmodeメッセージをjit.displaysに送ることで、スクリーン・サイズを変えています。また、あらかじめsnapshotメッセージを送って現在のスクリーンの状態をjit.displaysに記憶させ、resetメッセージで元の状態に戻しています。 なお、サンプル・パッチでは、数字キーの「4」で、noaccelを切り替えるようにしています。前段の話とは違って、フルスクリーン表示では、noaccelをオフ、つまりアクセラレーションをオンにしたほうが、高速に表示される場合も多いかもしれませんね。このあたりはケース・バイ・ケースですので、いろいろと試してみてください。また、OpenGL描画を行う場合は、jit.windowのFSAA（フルスクリーン・アンチ・エイリアス）アトリビュートの設定で描画結果や描画速度が異なりますので、これも試してみてください。 ------------------------------------------------------------------------ ■PixelShoxって知ってる？ あまり詳しく書くとアレなんですが、虎OSの石英作曲家がなかなか出来が良くって、もしかしたらJitterを凌ぎかねない開発ツールになるかもって予感がしています。で、そのオリジンがPixelShox Studioです。Motionのリアルタイム版＋Jitterの機能集約版とでもいった雰囲気でしょうか（ちょっと違うかな）？ プログラミングはアナログのモジュール・シンセみたいな雰囲気でパッチングします。うにょっと曲がるパッチコードもいい感じ。パッチは階層化（サブパッチ化）できるんですが、これが視覚や操作として分かりにくいのがちょっと難点でした。 クールなモーション・グラフィックスが結構簡単に作れちゃうので、VJ系の人の話題になったのかも。オーディオやMIDIの入出力もバッチリで、マウスやキーボードも使えるので、インタラクティブな処理も簡単に作れますね。映像処理はすべてOpenGLで行われるので、ハードウェア・アクセラレーションがばっちり効きます。そのようなわけで、PixelShoxは虎OSに迎え入れられたんでしょうね。 PixelShox Studioはフリーウェアで、以下のサイトからダウンロードすることができます。このアプリケーション自体は最早開発終了なのですが、最終バージョンでも結構機能は充実していますし、未来を垣間見るには十分なインパクトがあります。近い将来に、これがOSに統合されてGPUベースで動くのですから、かなり凄いことになりそうでしょ？ PixelShox Studioホームページ： http://www.pol-online.net/pixelshox_technology/ ------------------------------------------------------------------------ ■オーディオもGPUで PixelShoxというかGPUで思い出したんだけど、GPUでオーディオ処理を行うBionicFXというプロジェクトがありますね。CPUの高速化は頭打ちになりつつあるものの、GPUはどんどん高速化してるんで、こういった動きが顕著になってきてるんでしょうね。昔のマルチメディア・コプロセッサみたいですが、ビデオカードでオーディオ処理という発想が素敵です。リバーブとかリシンセシスとかまっとうな用途じゃなくって、マッドな使い方を考えてみたいところです。とは言え、まだパブリック・ベータもまだのようなので、首を長くして待ちましょう。 BionicFXホームページ： http://www.bionicfx.com/ ------------------------------------------------------------------------ 今回紹介したサンプル・パッチは、以下のリンクをクリックしてダウンロードできます。 TIPS007files.sit ------------------------------------------------------------------------ メルマガの発行確認や購読中止は、DSPマガジンWEBサイトをご覧ください。 http://dspmag.iamas.ac.jp/ ------------------------------------------------------------------------ Copyright(C)2003-2005 DSP Magazine. All Rights Reserved. 転送・転載禁止 ------------------------------------------------------------------------ |