ふむふむブログ fmfmBLOG

　
　
皆様こんにちは。
ジメジメと暑くなってきまして、天パーの私にとってはいろんな意味でイライラする季節となりましたが、皆様いかがお過ごしですか？
ふむふむソフトの飯島です。

私の大嫌いな言葉は「寝ぐせを生かしたスタイリング」です。
天パーの寝ぐせなめんな！！
　
　
それはさておき、フリーのFlash開発環境として「FlashDevelop」というものがあります。
インストール方法等は他のサイトに譲るとしまして、とにかく無料でFlashの開発環境が整ってしまう大変素晴らしいモノなのですが、弊社的にここ数カ月Flashから離れていたこともあって、しばらく触っていませんでした。
ということで、何となく久々に更新の確認をしてみたら、バージョンが3.2.1 RTMになっていました。
（私の手元にあったのは3.0.6-RTM）
　
　
このFlashDevelopは、ActionScript等、ソースコードのエディタとして大変素晴らしいものの、デバッグ機能と言えるものがほとんどなく、Adobeの本家Flashを使うか、trace等の出力に頼るしかなかったのですが（その出力を見られるだけでもありがたいのですが…）、久々にバージョンアップしたところ、「ブレークポイント＆ステップ実行＆ローカル変数の値参照」という、デバッグ機能が追加されていました！！イエーイ！！
また、プロファイラー機能なども追加されており、さらに強力な開発環境となったようです。

今までもfdbというFlex SDKに含まれるデバッグ機能を使ったプラグインなどが存在していたのですが、いかんせん安定性がイマイチで、本家の機能に含まれないかな～、と思っていたのですがついに実現されていたようです！！
（別に昨日今日されたわけじゃない、というのが本記事のダサいところですが）
これで色々と安心です！！
　
まだ試したばかりで、使い方や設定など、詳しい事は追ってレポートしたいとおもいますが、ざっと試した限りではブレークポイントもステップ実行もバッチリ動きましたので、Flash開発を行っている方は要チェックです！！

それでは失礼いたします。

皆様こんにちわ。
ふむふむソフト代表取締役の飯島です。

前回に引き続き、SilverlightのWriteableBitamap話です。

私がWriteableBitmapに興味を持ったきっかけですが、そもそもはFlashのBitmapDataをいじくっていて、その関連で知った「Adobe Alchemy」という技術とそのサンプルです。
（※ Alchemyとは、平たく言うと「FlashをC++で書いて速くなる」みたいな技術です。）

Flash 10, Massive amounts of 3D particles with Alchemy (source included). 翻訳
Flashのサンプルはコチラ

AlchemyとPixelBender（Silverlight3のピクセルシェーダーのもっと気の利いた版です）という記述を駆使して30万パーティクルを動かす、というサンプルを見て「こりゃスゲェ。私もAlchemyやってみるかな～。」と思い立ち、Cygwinを入れたりなんだりしていたわけですが、ようやく開発環境が整ったところで、今度はこんな記事を見つけてしまいました。

青柳 臣一 ブログ（総合）[Silverlight] Parallel で最適化してみる例

先のくるくる回るオウム貝みたいなアレをSilverlightに移植した人の記事です。
記事のメインは「Silverlightのマルチスレッド」についてがメインなのですが（これはこれで大変興味深い）、問題はそのリンク先にある「マルチスレッドに最適化してない（普通にC#だけで書いた）サンプルが十分速い」という事なのです。

問題のサンプル

つまり、Silverlightが持つ低レベルな描画や演算処理そのもののポテンシャルはかなりのものなのではないか、と思い、現在ごそごそと地味な実験を繰り返しているわけです。

今なお検証中ですので、また面白い実験結果が得られ次第、こちらのBlogで発表したいと思います。
もちろん大変偏った内容なのは言うまでもありませんが。

それでは失礼いたします。

皆様こんにちわ。
ふむふむソフト代表取締役の飯島です。

ひさびさに地味な研究結果を発表したいと思います。
今回はSilverlight3から搭載されたWriteableBitmapについてです。

WriteableBitmapとは簡単にいえば「書き換え可能なビットマップ」です。
WPFには以前から搭載されていたようですが、Silverlightにも3から搭載されました。

さて、このクラスを使うメリットは「ピクセルを直に触れる」ことにあります。
本来であれば、XAMLの高度な描画メソッドを使ってバリバリ描画していくのがSilverlightのあるべき姿なんでしょうが、ピクセルが触れるとなれば黙っていられないのがVGA（DOS）時代のPCゲームにヤラレちゃってた人間の性なのです。
私の場合、DirectDrawはもちろん、WinGの時からそうだったのですから仕方がありません。

話を戻しましょう。
このSilverlight3のWriteableBitmapは、ピクセルがint型の配列になっています（pixelsメンバ）。
（この時点でVGAの13hモードのVRAMを思いだして胸が熱くなります）
この配列のintの値は「ARGB（各8bit）」になっており、配列の長さが「ビットマップの幅×高さ」になっています。
ちゃんとαチャンネルの値を保持できる辺りも嬉しい限りです。

この配列に対して、シフト演算子でARGBの値を使ってint型を作って、「幅×y座標 + ｘ座標」みたいな感じでpixels配列にセットすればその部分のピクセルの色が変わる、というある種の方々には大変直観的な設計になっています。

が、タダの配列とはいえ、細々とアクセスをしていると「？」となるくらい遅くなる時がありました。
そこで、モノは試しで「ダブルバッファ」をやってみたのがこのサンプルです。

Silverlight3 + WriteableBitmapのダブルバッファサンプル
(※動作にはSilverlight3が必要です)

ソースコードはコチラ
(要Visual Studio 2008 + Silverlight3 SDK)

やっている事は「600×400ピクセルのWriteableBitmapに同じ色をセットする」という処理なのですが、二通りの方法でテストしています。
まず、通常（赤）と書いてある方が、ループでピクセル（赤）をセットする方法です。
そしてダブルバッファ（緑）という方が
・pixelsと同サイズのint型の配列を作る
・その配列に対して同じくint型のピクセル（緑）をセット
・配列の「CopyTo()」を使って、pixelsに一気にCopy
という手順を行っています。
どちらも画面更新（Invalidate()）のタイミングに違いはありません。

見た眼は死ぬほど地味（色は派手）ですので、興味が無い人には全くもってアピールのないサンプルですが、注目して頂きたいのはそれぞれの処理を行っている時のフレームレートです。

私の環境では、
・通常（赤）　： 150fps前後
・ダブルバッファ（緑） ： 180~190fps前後
となっています。
一見余計な手順を踏んでいる後者の方が、30～40fps（20～25%）ほど速いのです。

一応、弊社内の色々なPCで試してみましたが、大体
・緑の方が速い
・赤と緑で差が無い
というケースに分かれ、（本来そうなりそうなものなのですが）少なくとも緑の方が遅くなる、というケースは見受けられませんでした。
皆様の環境での差も教えて頂きたいところです。

なぜこのような差が発生するのか理由は不明ですが、「pixelsってアクセス時に何がしかのチェックロジックが走る」という事なのでしょうか…？
なんにせよ「やっておくと多少速くなる『かも』」なテクニックとして試して頂ければと思います。

なお、今回のサンプルコードでは、フレームレート処理部分にblog.sph62.net様の「SilverlightでFlash的なパーティクル（サンプル）」という記事からコードを拝借いたしました。

それでは失礼いたします。

皆様こんにちわ。
ふむふむソフト代表取締役の飯島です。

前回の更新からずいぶん時間が経ってしまいました。

ずいぶん前のエントリーでSilverlight2による疑似ブラーの実験をしました。

それなりに良い結果は得られたものの、やはり画像等の下準備が必要ですし実装も煩雑です。
「はやくホンマモンが実装されないかなぁ…」という気持ちが強かったのですが、ついにSilverlight3でピクセルエフェクトという形で実装されました。
「ピクセル処理と聞いたら黙っていられないタイプ」の私としましてはこれは放っておけません。

そんなわけで、以下のページなどを参考に、さっそく試してみました。

参考リンク
マイコミジャーナル
【コラム】The Silverlight Times (11) エフェクトによる実行時ピクセル変換

比較対象があった方が分かりやすいだろう、ということで、前回の「回るチズテクちゃん」と同じ素材＆ソースをもとに作ってみたのがこちらです。

(※動作にはSilverlight3.0 ランタイムのインストールが必要です)

上の方が、前回のまま（Silverlight2とか書いてますが、あくまでも使用している機能です）、下の方がSilverlight3でのBlurEffectを使った場合です。

やはりホンマモンはキレイですねー。
（中間のぼやけ具合のところ、などが顕著です）

ただ、CPUの負荷をみると、3.0のブラーの方が重いのが残念です。
もうちょっとなんとかなんねーかなー、という事で調査をしているのですが…、そもそもガウスぼかしって重いんですね。

参考リンク
t-pot ガウスフィルタ

確かに理屈で考えれば「周辺のピクセルをサンプリングして重みづけをして色を混ぜる」という事を全ピクセルに対して行うのですから、当然といえば当然ですね。

いずれにせよ「ピクセルシェーダー言語（HLSL）なんて触ることもないだろう」と思っていたのですが、Silverlightに搭載されたのであれば見過ごすわけには行きません。
今後も「ピクセル処理と聞いたら黙っていられないタイプ」（っていうか、単なる個人的な趣味）として色々と調査、実験をしていきたいと思います。

それでは失礼いたします。

弊社事務所のビルが外装工事中でうるさいですが、
皆様の事務所のビルはいかがでしょうか？
「CHIZTEK（チズテク） 手描き地図検索」の開発チームです。

Windows Live Galleryに登録したザ・スクラッチですが、
思いのほかDL数が伸びていて弊社一同驚きを隠せません。
もっとやれ。

さて今回は、地味な研究シリーズと銘打ちまして、
その第一弾として「影絵」をテーマに考えてみたいと思います。
（思い返せば、今まで取り上げたネタは十中八九地味なのですが…）

まず「よりもよってなぜ影絵なのか？」という事についてですが、
それはさておき早速サンプルを見て頂きましょう。

影絵 ― 銀光猫

(※動作にはSilverlight2.0が必要です)

いかがでしょうか？
手前味噌ながら、割と「マジの影絵」っぽく仕上がったのではないかと思います。

ポイントは
・ぼかしをうまく使う
・動きのゆらゆらした感じを出す
という2点に尽きるのではないかと思います。

まず「ぼかし」についてですが、これはPhotoShopで「そういう絵を用意した」というだけです。
レイヤーとガウスぼかしの使い方さえ分かっていれば何も特別なことはしていません。

次に「動きのゆらゆら感」についてですが、こちらはあえてSilverlightの
ストーリーボードは使わず、三角関数を使って、フレームレートベースの
アニメーションとしてコード側で制御しています。
位置を変えたり角度を変えたりする周期を微妙にずらして重ねることで、
「手で持ってる」ような表現ができるわけです。

作ってみたところ、期待以上の良好な結果が得られたと思いますので、
近いうちにこのテクニックを使って何か作ってみたいと思います。
（影絵が好きな人は）お楽しみに！