フレッシュ平瀬チャンネル

StageMajik あけました。

フレッシュ平瀬 — Fri, 25 Dec 2009 19:10:57 +0900

少し前の話になりますが、Embedded Technology 2009 (通称：ET 2009）にて、CRIの新製品「StageMajik」が展示されました。

StageMajikは、静止画や動画、３Ｄモデルを組み合わせて、シーン（※）を制作、再生するためのシステムです。ツールとランタイムライブラリを用意しています。

※シーン（Scene）とは、一定の場所の中での動作の一区切りをさす。
出典：Wikipedia

次の動画は、てんとう虫がとことこ歩いて、水を飲むシーンを StageMajik で作ってみたものです。ちなみに制作時間は、５分もかかっていません。

ここでは、てんとう虫の静止画と葉っぱの静止画を使用しています。葉っぱを動画に置き換えてもいいですし、てんとう虫を３Ｄモデルに置き換えることもできます。

このように静止画や動画、３Ｄモデルを配置してシーンを簡単に作り出すことができるのがStageMajikです。もちろん、ランタイムライブラリも用意しますので、各種ゲーム機や組み込み機器での再生もサポートします！

さて、先の「てんとう虫とことこ」の制作手順を簡単に説明します。

次の画像は、ＰＣ上で動作するシーン制作ツール「StageMajik Craft」のキャプチャ画像です。

まず使用する画像ファイルを画面中央の「スクリーンペイン」（キャプチャでは葉っぱとてんとう虫が表示されているエリア）にドロップします。この操作で使用する画像ファイルをStageMajikCraftに登録することができます。

次にてんとう虫をとことこさせます。画面下部の「タイムラインエディターペイン」（緑や青い棒、ピボット、位置などが表示されているエリア）で、とことこアニメを付けることができます。

StageMajikでは「キーフレーム」を用いてアニメーションを作成します。ようわ、「ある時間にどこにいるか」、「ある時間にどの向きか」、「ある時間にどのくらいの大きさか」などを指定してアニメーションさせます。３Ｄなら、「ある時間にどの向きか」は３Ｄ的に指定できますし、「ある時間にどういう光があたっているか」も指定できます。影を落とす、受けるなども指定できます。

今回の場合、特定のフレームごとに、その位置と回転角度を指定しています。たとえば、てんとう虫が最初、位置 (x, y) = (100, 200) にいて、１０秒後に (x, y) = (300, 600) の位置にいるとします。このとき、０秒と１０秒にキーフレームを打ち、それぞれの位置を指定します。そうすると、間の時間（１秒～９秒）は位置や回転角度が補間され、アニメーションができあがります。

このアニメーションを色んなオブジェクト（静止画や動画、３Ｄモデル）につけていくことで、シーンを作成できます。。

StageMajikは、以下のような特長があります。

画像素材、ムービー、3D素材を同時にオーサリング
- これまで個別のオーサリングが必要だった画像素材、ムービー、3D素材を一括で編集・再生できます。各種素材の移動や回転などの動きを時間軸上に設定するだけで、簡単にモーショングラフィックスデータが作成可能です。
- 映像素材にはムービーフォーマットとして「CRI Sofdec」を使用します。高画質なムービー再生を行えるだけでなく、ムービーと他の素材の合成表示が可能です。
- 3D素材はCRIの独自3Dフォーマットである「IG」を使用することで、これまでの映像作成ツールで扱うことの出来なかった3Dオブジェクトを画像やムービーと同じように扱うことができます。
- 複雑な3Dアニメーションをパラメータの増減だけで簡単に設定でき、扱いの難しい3D素材を簡単に使用することが可能です。
デザイナー完結型の制作環境。開発工数を大幅削減
- 素材の動作設定やデータといった複雑な情報をひとつにまとめた再生用ファイル（カットパック / リソースパックファイル）を出力します。再生用ファイルをランタイムで再生するだけでシーンの再生が可能です。

というアレで、長くなりましたが、StageMajikをよろしくお願いします。

あ、自分はツール開発に関わっています。

来年もよろしくお願いします。

以上

国際放送機器展: InterBEE 2009 に行ってきました

フレッシュ平瀬 — Tue, 24 Nov 2009 17:06:52 +0900

というアレで、11月の18日～20日に幕張メッセで国際放送機器展 InterBEE 2009 が開幕され、閉幕されました。私は、19日～20日にCRIのブース・・ではなく、メディアキャスト社さまのブースにて展示員をやっておりました。

ニュースリリースでもアナウンスしておりますが、「デジタル放送用リアルタイムHDエンコーダシステム」をメディアキャスト社と共同開発しております。このデジタル放送用リアルタイムHDエンコーダシステムの試作機を InterBEE 2009 で展示するにあたり、メディアキャスト社のブースで説明員をやることになったわけです。や、他社さんのブースに立つのは腰が疲れます。

このシステム、リアルタイム性やデジタル放送用途に使えることも特長のひとつですが、何よりの特長は、その価格帯。このシステムは、Windows PC ベースで組みあがっています。このため、これまで専用の高価なハードウェアが必要であった生中継業界（謎）に革新をもたらします。

現在、大手テレビ局ならば既に専用のハードウェアをお持ちでしょうが、地方のテレビ局などでは価格的に障壁があったかと思います。また、役所、図書館、学校などの館内放送などにも専用ハードウェアの導入は厳しかったと思います。ですが、PCベースです。安価に導入が可能です。校長先生の有り難いお話をHD/ハイビジョン品質（注：ハイビジョンはNHKさまの商標です）で放送できたりします。お顔の皺もくっきりです。

あ、そういえば、普通にビデオ入力にケーブル挿せばテレビに映るじゃないかって考えられるかと思いますが、今回のシステムでは、複数のテレビに同時に映るっていうのが重要です。校長先生の顔を電波に載せて、テレビに運べるっていうのが重要です。Koutyou To The Home ですね。

正直、自分が考えても適用先は思い浮かびませんが、テレビに映すことがこれまで難しかったものや、町おこしのためのローカル放送などなど、適用分野はまだまだあるかと思います。

メディアキャスト社ニュースリリースメディアキャストとＣＲＩ・ミドルウェア、デジタル放送用リアルタイムHDエンコーダを開発

Arrivederci

秒間 47 フレームでエンコードして、時間を節約。

フレッシュ平瀬 — Sun, 07 Jun 2009 14:56:16 +0900

Mi chiamo Tomoyuki. Sono giapponese.

というわけで、鞄もトリコローレに染まって、イタリア語修行中です。

イタリア語って、割と発音がラクチンで、アルファベット読みでいけちゃうので、人種のるつぼアメリカ英語よりは覚えやすい気がします。

というわけで、「Studiamo Italiano insieme !」という話題と・・・・

以前、「CEATEC 参加中です」@2008-09-30 でも書きましたが、「CRIWARE for SpursEngine」にちょこっと関わっていまして、最近、エンコード速度をさらに速くすべく、作業しておりました。

で、改善の結果、、以前は解像度 1920 x 1080 のビデオ素材を H.264 化するのに、秒間 30 フレーム程度だったエンコード速度を、秒間 47 フレームまで向上しました。

ただし、これビデオ素材が非圧縮データだと全然達成できません。。なんてったって、非圧縮データの場合、１フレーム当たりで 1920 x 1080 x 4 バイトのデータ量になり、47fps を実現しようとすると、秒間 372 MiB の転送レートがあるハードディスクが必要になってしまいますから・・・。最近噂の OCZ Technology Group さんの爆速 SSD だと大丈夫ですけど・・・・・、次は PCI Express バスの転送速度がボトルネックに・・・・

そんなわけで、エンコード速度が1.5倍ほどに向上した SpursCoder が間もなく登場します。

いま、しばらくお待ちください。

SpursCoderのページ

by フレッシュ？平瀬＠CRI

キビ、メビ、ギビ

フレッシュ平瀬 — Tue, 06 Jan 2009 09:49:11 +0900

あけまして、おめでとうございます。
2009年早々、変なタイトルで参ります。
よろしくお願いします。

最近、調べ物をしているときなどに「キビ」や「メビ」、「ギビ」という単位を目にするようになりました。何だろう、と思い調べてみると、どうやら「キロ」、「メガ」、「ギガ」とおおよそ同じ意味の単位だとわかりました。

「キロ」というと、一般的には「1000倍」を意味し、コンピュータ関係では「1024倍」を表すことがあります。ただしコンピュータ関係では、あくまで「表すことがある」だけで、必ずしも「1024倍」を意味しません。

そこで登場したのが「キビ」です。

「キビ」といえば、必ず「1024倍」つまり「2の10乗倍」を意味し、「メビ」なら「2の20乗倍」、「ギビ」なら「2の30乗倍」を意味します。更に大きい単位は「テビ」、「ペビ」、「エクスビ」、「ゼビ」、「ヨビ」と続きます。

例えば、ファイルサイズは「５００キビバイト！（500KiB）」とか「３ギビバイト！（3GiB）」などと表します。メモリ（ROM/RAM）なども同じです。

一方、音声データを圧縮する際のビットレートは、1024倍では表しませんので普通に「32kbps・・・」とか「160kbps」と表します。周波数や、ハードディスクの容量、DVDディスクの容量なども同じです。

最後になりましたが、「キビ」や「メビ」は、「2進接頭辞」と呼びます。（「キロ」や「メガ」は、「SI接頭辞」と呼びます。）

普段はSI接頭辞で会話する方も多いと思いますが、ここぞというときには声を大にして「キビ！」と言ってみてはどうでしょうか。

以上

ミドルウェアにしてミドルウェアにあらず。

フレッシュ平瀬 — Tue, 09 Dec 2008 09:28:41 +0900

CRIはミドルウェアを提供する会社ですが、提供するのは何もミドルウェアだけではありません。

ゲームに組み込むコンテンツ、圧縮しないと入りきらないですよね。そんなときは、とりあえず、CRI FileMajik。音に特化した圧縮ならCRI ADX、CRI Audio、救声主。ビデオに特化した圧縮ならCRI Sofdec（、と海外向けのCRI Movie）。

これらのミドルウェアをゲームに組み込んでいただくのがCRIの商売ですが、このミドルウェアの基本的なスタンスは「圧縮されたコンテンツの展開」です。

「じゃあ、圧縮は誰がやるの？」というと、先日発表しました「CRI SpursCorder」や「CRI Audio Craft」などのツール。

普段、CRIが発信するニュースにはならない、ミドルウェアといえばミドルウェアだが、ミドルウェアではないツール。今日は、そんな長い前置きを置いて、最近のCRIツールの核になりつつあるプロジェクトから、ひとつ私が開発中のコレ↓をご紹介します。

今までのCRI製品は、がっちがちにウィンドウのレイアウトが決まり切っていましたが、好きな位置に移動させたいですよね。というわけで、作りました。C# でガリガリ１から書き起こして、ウィンドウのレイアウトを変更できる、いわゆるドッキングビューを作りました。

その名は恥ずかしいですが、ま、所詮ツールの内部的な名前なので気にはしてないです。

まだまだフローティング表示もできませんし、タブウィンドウ化もできませんが、レイアウト変更も、レイアウトの保存と復元もできます。

そんなわけで、前置きの方が長かった気もしますが、このAwesome Dock、そう遠くない未来にお目見えするかと思います。

以上

CEATEC 参加中です

フレッシュ平瀬 — Tue, 30 Sep 2008 21:34:26 +0900

CEATEC JAPAN 2008が今日から5日間の予定で開催中です。
CRIも「CRIWARE for SpursEngine エンコード＆デコードライブラリ」と題して、
ブース「展示ホール8 8K15」にて展示中です。

ま、私自身は会社で留守番ですが。

こっそり。
実は、こっそり私も多少 CRIWARE for SpursEngine に関わりました。
私が担当したのは、SpursEngine を使ってビデオをエンコードするパート。
といっても、それ以外に何があるんだという感じですが、
ビデオのエンコードの他にも、オーディオエンコードや
ビデオとオーディオのマルチプレクス、デコード側もあります。
そんなこんなで、私が担当したのは、ほんのビデオエンコード部分だけでした。

久しぶりに、C/C++言語でコーディングしたもので
悪戦苦闘しましたが、何とか CEATEC に間に合って
ほっと一息つかぬ間に、次の仕事へシフトしています。

ま、それはさておき。
CEATEC JAPAN 2008 での CRI の様子はあまりウェブ媒体では語られてはいませんが、
実は、こっそり、インプレス様の PC Watch「【東芝編】ネットブックNB100を展示、SpursEngine搭載カードも」にて CRI のデモが写っています。

写真を拡大表示すると、意外に大きく写っているのがわかるかと思います。
ぜひぜひ、ご覧くださいませ。

こっそり(2)。
あ、ところで、CRIのポータルサイトがリニューアルされているのには、お気づきでしょうか。
見やすくなったポータルサイト、ぜひぜひご覧くださいませ。

こっそり(3)。
まったくもって、余談ですが、こっそりこっそり久しぶりの更新なのはさておきまして、
ソフトウェア開発技術者試験を受けたと報告しましたが、
とっくの昔の6月ごろに合否の発表がありました。
嬉し恥ずかしながらの、合格で、いつの間にやら報告が遅れてしまいましたが、
ことのついでに報告いたします。
ありがとうございました。

by フレッシュ？平瀬＠CRI

Take back the fresh!

フレッシュ平瀬 — Sat, 26 Apr 2008 02:44:50 +0900

「Take back the fresh!」というアレ（どれ？）で、
先日、こっそり資格試験「ソフトウェア開発技術者」を受けてきました。
（国家資格ですが、学生さんにも十分に取れる資格だと思います。）
（試験については、JITEC 情報処理推進機構さまへ、どうぞ。）
（実は前回の「基本情報処理技術者試験的ムービーファイルのファイルサイズ計算方法」は布石だったりします。）

当日は、朝8時半に現地入り（試験は9時半から）、
気合を入れて（ある横浜出身のフォークデュオの歌を聞きながら）自習。
9時半から「午前」試験開始、12時に終了
昼食は当然「カツ」サンド！
13時から「午後１」試験開始、15時に終了
15時半から「午後2」試験開始、16時半に終了
（そのまま（たまプラーザで）買い物へ突入・・！）

と、長丁場を戦い抜いてきました。

今回の試験内容に関して、以下のような印象を受けました。
▼午前
　問題の範囲が広くて・・・、自分の記憶力の性能限界が・ぁ・・。
▼午後１
　試験時間に比べて、問題が多くとってあるような印象。
　そしてシステム稼働率やシステムテストに関する問題が出ていて、意外。
　システムテストは面白かった。そういうテストもあるのねって感じで。
▼午後２
　午後1に比べて、簡単な問題に見えるのに・・・引っ掛けあり。
　何となく、この午後1の「ツンツン」っぷりに比べて、
　午後２の一見「デレデレ」、裏に「ツン」と澄ました印象。

で、今日、午前と午後の試験の解答が出てたので採点してみました。
※ちなみに試験は、午前、午後１、午後２、それぞれの結果で大よそ75%正解しないと合格にはなりません。

で
　れ
　　で
　　　れ
　で
　　れ
　　　で
　　　　れ

　　でん♪

===================
午前　：80問中54問正解（正答率：67.5％）
午後１：61問中48問正解（正答率：78%）
午後２：19問中19問正解（正答率：100%）
===================

お・・ぅ・・・っ・・・・・
しり上がり・・・・・・意味ない・・
午前を合格しないと、午後は採点されません！
・・・・・・・

午前が・・・・・・、触れないでください・・！
決して、見直し段階で修正したところばかり間違えたなんてことはありませんから！

午後１に関しては、ネットワーク技術とデータベース系でいくつか落として大よそ78%・・、ぎりぎり。
ポート番号の指定がわかってない！

午後２に関しては、アルゴリズムの問題でしたので満点。
でも見直ししてないと、少し間違えていたかもしれません（午前とは逆パターン）。

ま、まぁー、あのですね、皆様はこうならないように
頑張ってくださいね。
長くなるのもアレですし、夜も遅いですから。

それでは、皆様、よいゴールデンウィークを。

by フレッシュ？平瀬＠CRI

基本情報処理技術者試験的ムービーファイルのファイルサイズ計算方法

フレッシュ平瀬 — Mon, 18 Feb 2008 21:44:18 +0900

夜も更けてきましたが、いま、あるテスト用にムービーファイル（ビデオファイル）を作っています。作業は割と単純で、元々49秒のムービーがあって、そのムービーを4倍の長さにして196秒のムービーファイルを作っています。196秒・・・短いように思われますが、そのムービーのファイルサイズは約15GBにもなります。
というわけで、今夜は「基本情報処理技術者試験的ムービーファイルのファイルサイズ計算」です。（いたって簡単）

非圧縮のムービーファイルは、数学のノートの端っこに描いたパラパラ漫画のように何枚もの静止画が連なってできています。
もちろんファイル中には静止画だけではなく、ムービーの大きさ（解像度）や長さなどの情報もファイル中には存在しますが、静止画の大きさに比べたら僅かな大きさしかないので、とりあえず無視します。

今回のムービーファイルは、解像度が1280x720で、色深度は24 [bit]、フレームレートが30 [fps] です。
解像度はムービー中の静止画1枚1枚の大きさを表していて、幾つの点を使って静止画を表現しているのかを示しています。色深度というのは、さらにその1点1点において、色を表すのに何ビットを使って色を表現しているかを示しています。フレームレートは1秒間に何枚の静止画表示してムービーを表現するかを示しています。

今回のムービーファイルの場合、解像度と色深度をかけた値が1枚の静止画あたりのファイルサイズになり、さらにフレームレートをかけると、1秒当たりのファイルサイズが求まります。
そんなわけで今回のムービーファイルだと1秒間当たりのファイルサイズは、以下の式となります。

1280x720x24x30 [bit/sec] = 79 [MB/sec]

はい、そういうわけで1秒間に79MBにもなる49秒間のムービーですらファイルサイズは約4GBになり、さらに4倍にして196秒のムービーのファイルサイズは約15GBにもなるわけです。
196秒・・たったの3分です。3分で15GBも消費するので、並のハードディスクならすぐ一杯になってしまいます。

そこでファイルサイズを小さくするために、ムービーを圧縮します。圧縮は無駄なデータを省いたり、重複を削ったりしてファイルサイズをどんどん削っていく作業です。静止画や音声、ムービーなどの場合、人間にはわからない程度に元の絵や音を削ることで更にファイルサイズを小さくできます。

で、そんなノウハウを詰め込んだ、CRI Sofdecを使って先ほどの15GBのムービーを圧縮してみると・・・

706MB!

だいたい4.4%のサイズになりました。
というかでもこれ、元のムービーがかなり圧縮しやすいものだったので大分ファイルサイズが減ってしまいました。でも、ムービーの圧縮は上手くいけば、これほどの効果があるということです。
# ちなみに圧縮すると、多少ムービーが汚くなりますが、
# 今回の圧縮では画質を優先しています。

そんなわけで、基本情報処理技術者試験に出るかもしれない（本当か？）、ムービーのファイルサイズ計算方法と、圧縮の効果について書いてみました。

以上、よろしくお願いします。

.NET Framework ソースコードデバッグ

フレッシュ平瀬 — Thu, 17 Jan 2008 10:45:21 +0900

MSDNフォーラムの「Welcome To the Microsoft Reference Source Forums」によりますと、本日より、Microsoft Visual Studio 2008でデバッグ時に .NET Framework のソースコードを参照できるようになりました。

参照できるソースコードは以下のもの。

.NET Base Class Library
Windows Forms
Windows Presentation Framework
ASP.NET
ADO.NET
XML

（参照：http://weblogs.asp.net/scottgu/archive/2008/01/16/net-framework-library-source-code-now-available.aspx）

設定方法は、次の通り。

Visual Studio 2008のオプションの [デバッグ] - [全般] にて「'マイコードのみ' 設定を有効にする」のチェックを外す。
同じく [デバッグ] - [全般] にて「ソースサーバーサポートを有効にする」にチェックを入れる。
[デバッグ] - [シンボル] にある「シンボルファイル(.pdb)の場所」に「http://referencesource.microsoft.com/symbols」を追加する。
同じく [デバッグ] - [シンボル] の「シンボルサーバーからシンボルをキャッシュするディレクトリ」に任意のフォルダを指定する。

（参照：http://blogs.msdn.com/sburke/archive/2008/01/16/configuring-visual-studio-to-debug-net-framework-source-code.aspx）

これで、Form.csやControl.cs、Trace.csなどなどにアクセスすることができます。

この設定を行うと、初回デバッグ実行時にシンボルファイルとソースコードをダウンロードするものですから、Visual Studio 2008がフリーズしたように見えます。ま、一度ダウンロードしてしまえば、そんなに重たくはならないですが。

以上

救声主のエンコーダをバージョンアップしました。

フレッシュ平瀬 — Fri, 28 Dec 2007 18:37:44 +0900

本日、救声主エンコーダの新バージョンVer.1.10.00をリリースしました。
新しいエンコーダでは、とうとう「サイズ指定エンコード」ができるようになりました。

■サイズ指定エンコードとは？
「サイズ指定エンコード」では、音素材をエンコードする前にエンコード後の
ファイルサイズを指定してエンコードすることが可能です。
今まで、ROM容量きちきちに詰めるために、エンコードパラメータを
手動で選びなおしていた作業をある程度自動化することができます。

またサイズ指定エンコードの副産物として、エンコード後のファイルサイズ予測が
できるようになりました。これでエンコード前にある程度
エンコード後のROMサイズを知ることができます。

というわけで、より使いやすくなった救声主をよろしくお願いします。

以上

[ご参考] 就職活動タイムライン

フレッシュ平瀬 — Thu, 20 Dec 2007 13:52:36 +0900

そろそろ街にはリクルートスーツ姿の人が出没する季節です。
CRIチャンネルの１つ「リクルートチャンネル」も去年に続き、連載が始まっているようです。
というアレで、今日は私がどの時期に何をしていたかをまとめてみます。
何かの参考になれば幸いです。

就職活動を始めた時期は、遅くもなく、早くもなく、大手リクルートサイトがオープンし始めたときくらい（10月？）です。その時期は、SPI試験を受けてみたり、業界研究というやつをしてみたり、自己分析を受けたりしていました。また、名前を聞いたことのある企業さんのウェブサイトをチェックしたりもしていました。

あと、就職もしていないのに、転職サイトを眺めたりもしました（意外に面白い）。
ちなみに、修士の研究に目処がつき始めたのは、この頃。

初めて説明会に参加したのは、修士1年目の12月～2月ころだったと思います。たいていの説明会では、会社の概要や変遷だけでなく、業界自体のことも説明してくださいました。（ま、内定を出したはいいけど、入ってすぐやめられても困るから、ちゃんと説明するのだと思います。）
ちなみに、このときの研究状況は、まずまずで、ある１つのことさえ乗り越えれば論文かけるんじゃないかっていう頃（つめていくことは、いっぱいあったけど）。

次に試験ですが、説明会と同じタイミングで行うことが多く、12月～4月くらいまで試験を受けていたと思います。「試験」と一口に言っても、書類審査や筆記試験、口答試験やグループディスカッション、面接などなど様々な形態で行われます。

受けたのは、ソフトウェア・パッケージを開発・販売している会社2社くらいとハードウェアの会社1社、ゲーム開発会社が・・・６社くらい（たぶん）です。

で、就職先がCRIに決まったのが、忘れもしない2005年4月1日・・・・。
何の冗談かと思いました。エイプリルフールて・・・。

というわけで、駆け足ですが、私の就職活動タイムラインでした。
次回も何か、就職活動関連のことを書こうと思います。

以上

最近知ったデバッグ術～Win32 APIにブレークポイントを貼る

フレッシュ平瀬 — Thu, 22 Nov 2007 21:56:52 +0900

最近知ったデバッグ術、というアレで、今回もよろしくお願いします。

☆★☆★☆★☆★☆★☆★

いま、以下のようなコードを書いた。

#include "stdafx.h"
#include <windows.h>

int _tmain(int argc, _TCHAR* argv[])
{
    DWORD dwAccess             = GENERIC_READ;
    DWORD dwShare              = 0;
    SECURITY_ATTRIBUTES * psa  = NULL;
    DWORD dwCreateDisposition  = OPEN_EXISTING;
    DWORD dwFlagsAndAttributes = FILE_ATTRIBUTE_READONLY | FILE_FLAG_SEQUENTIAL_SCAN;
    HANDLE hTemplateFile       = NULL;
    HANDLE hFile               = NULL;

    hFile = CreateFileA("Test.cpp", dwAccess, dwShare, psa,
        dwCreateDisposition, dwFlagsAndAttributes, hTemplateFile);

    CloseHandle(hFile);

    return 0;
}

このコードで、Win32 APIのCreateFileA()にブレークポイントをはるにはどうするだろうというのが、お題。

上に示した程度のソースコードなら、デバッガでCreateFileA()のところに直接ブレークポイントを貼るだろう。これはいたってシンプルで、まともなやり方。

でも例えば、CreateFileA()がプロジェクト内に散らばってて、すべてにブレークポイントを貼りたいなら、どうするだろう。

こんなときは、少々荒業を使う。以下のように、CreateFileA()をラップする関数を作り、CreateFileA()自身はマクロで置き換えてしまう。

inline HANDLE MyCreateFile(LPCSTR lpFileName,DWORD dwDesiredAccess,DWORD dwShareMode,
        LPSECURITY_ATTRIBUTES lpSecurityAttributes,DWORD dwCreationDisposition,
        DWORD dwFlagsAndAttributes,HANDLE hTemplateFile)
{
    return CreateFileA(lpFileName, dwDesiredAccess, dwShareMode, lpSecurityAttributes,
        dwCreationDisposition, dwFlagsAndAttributes, hTemplateFile);
}
#define CreateFileA(arg1,arg2,arg3,arg4,arg5,arg6,arg7) MyCreateFile(arg1,arg2,arg3,arg4,arg5,arg6,arg7)

が、やはり荒っぽい。

2番の方法でも良いのだが、荒っぽさは拭えないし、ブレークポイントを貼るために専用のコードを書き足さなければならない点が、どうも落ち着かない。もちろん、はじめからCreateFileA()をラップしてソースコードを書いていれば問題ないのだが、他人が書いたコードをデバッグする際は、そうも言ってられない（ことがある）。

そこで最近覚えた、ハック。

まず、Visual Studioのツールオプションにある「デバッグ」「シンボル」を設定する。シンボルファイルの場所は「http://msdl.microsoft.com/download/symbols」に設定する。

次にブレークポイントを作成する。これはショートカット「Ctrl+B」、あるいは「Ctrl+Alt+B」でブレークポイントウィンドウを表示して、「新規作成」「関数でブレーク」によって作成する。関数の場所は「{,,kernel32.dll}_CreateFileA@28」に設定する。

これでブレークポイントウィンドウに赤丸のアイコンつきでブレークポイントができていれば、OK。

↑こんな感じ。

後は実行するだけ。

さて、ブレークポイントを作るときに設定した場所「{,,kernel32.dll}_CreateFileA@28」の前半はいいとして、後ろの「@28」ってどうやって決めればいいんでしょうか。これは、DeleteFileだと@14だったり、VirtualAllocだと@16だったりします。

こんなときはとりあえず、該当のWin32 APIがあるところまでデバッグ実行して、そこでブレークします。そのときに「デバッグ」メニューから「逆アセンブル」を表示すれば、アセンブラコード内にWin32APIの名前の後ろに「@##」って書いてあります。ここでいったんデバッガをとめて、ブレークポイントを作れば目的達成です。

そんなこんなで、以上が最近知ったデバッグ術でした。

継承すること。

フレッシュ平瀬 — Thu, 22 Nov 2007 20:53:31 +0900

オブジェクト指向プログラミングでいう「継承」は、どんなときに行うのだろう。というのが、月刊となりつつある「平瀬チャンネル」の11月のお題です。
それでは、よろしくお願いします。

　ウェブや書籍でみてみると、ふたつのクラスに「is-a」関係がある場合に継承を行うのが一般的なようだ。たとえば「A is a B」という関係が成り立っているなら、AクラスはBクラスを継承する。現実世界に例えるなら、「ハイブリッドカー is a 車」、言い換えるなら「ハイブリッドカーは車の一種」になる。このとき「ハイブリッドカー」は「車」を『継承』する。

　この「is-a」は、C++でクラスを継承するときの文法にも似ている。C++であるクラスBaseを継承してクラスHogeを定義する場合、次のように記述する。

class HybridCar : Car
{
};

　この文法は「クラスHybridCar is-a Car」と自然に読める（英語だけど）。

　よく聞くのは「has-a」の関係がある場合で、さっきの車の例でいうと車とカーナビの関係は「車 has-a カーナビ」となる。これをカーナビが車を継承したり、車がカーナビを継承したりはしない。
　機能面から言えば、車がカーナビの機能を継承して扱っても良いような気がする。だが、あくまで車がカーナビを「扱う」のであって、「車 is-a カーナビ」ではない。こんなときは、継承せずに車がカーナビを「持っている」ようにクラスを定義する。

class Car
{
    CarNavi navi;
};

基本的には、

「is-a」の関係が成り立つものに継承を適用する。
「has-a」のときには継承しない。

としておけば、コードが難読化することは少ないと思う。

というアレで。
みなさんも、クラスの継承をする際には、「is-a」であるかどうかをコーディングする前に一度確かめてみてはどうでしょうか。

以上

すごく気になるウェブデザイン

フレッシュ平瀬 — Thu, 25 Oct 2007 20:50:39 +0900

久しぶりの投稿です。
最近のウェブページは凄くこったものが多くて、ツールを作るうえで、その外観や操作感などは非常に勉強になります。今日は、そんなウェブページの中から幾つか、気になる３つのサイトさんを紹介したいなと思います。
よろしくお願いします。

■１． Tilt Viewer
次に紹介する「Flickr Related Tag Browser」も同じですが、Tilt ViewerはFlickrに登録されている写真を閲覧するウェブアプリです。見ていただくとわかりますが、あのマウスの操作感が堪らない感じです。
http://www.airtightinteractive.com/projects/tiltviewer/app/

■２． Flickr Related Tag Browser
さきほどのTilt Viewerと同様にFlickrの写真を閲覧するウェブアプリです。こちらは、キーワードを入力することで写真の検索ができるものです。面白い機能として、検索結果画面でマウスを画面ハシに移動させると
関連するキーワードが出てきて、そこからまた写真を検索できます。
http://www.airtightinteractive.com/projects/related_tag_browser/app/

■３．　スペースアルク
こちらは、ご存知の方も多いとは思いますが、英和・和英辞典のウェブアプリです。収録単語数もさることながら、少し前のアップデートで追加された機能が素晴らしいです。具体的には、検索結果の英単語にすべてリンクしてくれる「ワードリンク」とか間違って「differnce」なんて調べたときに、「もしかして、difference ？」と、正しいスペルを返してくれたり、過去形の動詞を調べたら、同時に現在形の動詞の候補もワードリンクしてくれたり、と、いろいろ便利さが際立っています。
http://www.alc.co.jp/

操作感がすごく気持ち良かったり、結果に対して何か提案してくれたり、必須ではないけれど、あると凄く嬉しいというのが最近のキーワードのような気がします。
冒頭にも少し触れましたが、こういった操作感とか提案とかはウェブに限らずツールでもゲームでも、人に触れてもらうものにはすべて通じるものなのかもしれません。あってもなくても、本質には関わらないけれど、あると凄い違う。ゲームなら売れ行きに左右する部分かもしれません。

そんなわけで、ツールやゲームを作ることにも通じる・・かもしれない、
素敵なサイトさんを紹介しました。

以上

それシネスタで。

フレッシュ平瀬 — Fri, 14 Sep 2007 11:35:50 +0900

本日『シネマスタジオ』が発表になりました。
そんなこんなで、今日はゲーム中のムービーについてです。
よろしくお願いします。

ゲーム中のムービーを使う場合、作業の流れはだいたい次の通りです。

素材を用意する。
エンコードする。
再生する。

ムービーを再生するときは秒間30枚とか60枚の絵をパラパラ漫画の要領で表示しますが、この1枚1枚が非圧縮の絵だとディスクメディアからの転送も追いつかないですし、システムメモリにも載り切りません。なのでエンコードしてデータを小さくしておくわけです。

ところがムービーのエンコードというと、DCT、量子化行列、GOP、フレーム間予測、動きベクトル・・・などなど難しい言葉が満載の作業です。ゲーム中でムービーを再生したいだけなのに、難しい概念を覚えて、ムービー再生システムを用意して・・・・というのでは余りに面倒です。
またエンコードしたものを再生するときにも、コマ落ちしないように気を配って、なおかつ次のシーンのコンテンツを裏読みして・・・・・って、本当に難しいです。
それにゲーム機が変わるたびに新しいムービー作成＆再生システムを用意して、システムのバグをつぶしていく・・・十全な状態を作り出すのはとてもツライものです。そして後々聞いてみたら他のプロジェクトチームが同じようなものを作っていたとかでは、その脱力感は計り知れません！　（いざ使ってみたらサポートしてくれないし・・・）

ということで、それCRIに任せてみてはどうでしょう。

本日リリースしましたミドルウェア『シネマスタジオ』（略してシネスタ）は、Wii向けのムービー作成＆再生システムです。シネスタでは、前述のエンコード作業もムービー再生も簡単に行えます。もちろんサポート体制も万全です（後述します）。詳しい特長は、セールスチーム「新製品！ Wiiに最適な高画質動画　『シネマスタジオ for Wii』」がわかりやすくまとまっていますので、ご覧ください。

・シネマスタジオ　製品紹介ページ
・シネマスタジオ　製品パンフレット（PDF）
・シネマスタジオ　ニュースリリース

またCRIではゲーム機だけに関わらず組み込み機器での
ムービー再生システム作成も行っていますので、お気軽にご相談ください。
　→お問い合わせは、こちらです。

ミドルウェアを使うとなると、金額面だけではなく、サポート体制も大きな関心事項になるかと思います。ところがCRIのサポートは基本的に金銭を請求することはありませんし、メールをいただければ1営業日以内に返事をお送りします。
サポートの状況についてはCRIインタビュー記事「まるで恋人関係のようなサポート体制？」が非常にわかりやすいです。また昨年USオフィスを設立したことで、1日20時間くらいのサポート体制ができています（USオフィスの状況はUSAさくらいチャンネルからお送りしています）。（たまに深夜でもサポートメールが飛び交うのはこういう理由です。）

さて、そんなこんなで新製品リリースに託けてCRIの仕事のひとつ、
ムービー作成＆再生についてご紹介しました。

それでは、よろしくお願いします。

以上

夏の暑さと電力消費量

フレッシュ平瀬 — Tue, 21 Aug 2007 08:11:00 +0900

夏の暑さが厳しい今日この頃、東京電力公式ページ調べによりますと、
　本日８月２１日は省エネしてください。
とのことです。

詳細は以下の通り。

http://www.tepco.co.jp/cc/press/07072002-j.html

　このニュースリリースによると、当初は、８月は6110万キロワットの予想電力消費に対して、6527万キロワットで挑もうとしていたそうです。
　しかし７月１６日に発生した新潟県中越沖地震によって数箇所の発電所が停止したため、電力供給力が726万キロワットほど不足し、それに対して対策として413万キロワットをかきあつめて供給力は6214万キロワットになったそうです。
　これによって余剰電力は104万キロワットとなったのですが・・・

http://www.tepco.co.jp/cc/press/07082005-j.html

　最近の猛暑/酷暑/炎暑のおかげで、ふたたび供給力不足が懸念されています。asahi.com “「２１日、電力需給逼迫の恐れ」　東電、緊急発電を準備” によると、平均気温が35度のときに消費される電力は6000万キロワット、36度のときには6170万キロワット、37度のときには6340万キロワットになるそうです。
　つまり最近の猛暑のせいで当初は予想していなかった平均気温になりそうで、平均気温が37度を越えた場合に供給力が不足してしまうことになるとのことです（地震がなければ大丈夫だったのですが・・）。
　そこで上記リンクのニュースリリース「省エネしてください」になるわけです。

というわけで、夏の暑さは厳しいですが、
今日くらいはクーラーの設定温度を1度節約して、
1時間早く退社するのはどうでしょうか。

以上、電力需給には無知な平瀬がお送りしました。

[C/C++] 文字が数字かどうか？

フレッシュ平瀬 — Fri, 10 Aug 2007 00:29:00 +0900

めっきりプログラミング１色に染まってしまったブログですが、
それはそれとて今日もとてとてプログラミングな話題をひとつ。
よろしくお願いします。

　「char型の変数cに入っている文字が、数字かどうか」を調べるには、普通次のようなコードを書くと思います。

if ('0' <= c && c <= '9') /* 数字だ！ */ ;

　これは非常に単純で、ASCIIコードのことさえ知っていれば書けます。もちろん、C言語などの標準ライブラリを使っても同等の効果が得られます。

if ( isdigit(c) ) /* 数字だ！ */ ;

で、この前見たコードは、こんな↓感じでした。（有名？？）

if ( (unsigned int)c - '0' < 10) /* 数字だ！ */ ;

　まぁ、はっきり言って上のように書き直したからといって、1秒だって1ミリ秒だって速くなるわけじゃないです。得られる効果は、ほんのわずかです。コードも見にくくなりますし、意図を読み取りにくいです。
　ですが、こんな些細な高速化を気にする気持ちとコメントでのケアを忘れないことが、プログラマへの一歩かな・・としみじみ思う夏休み前の今日この頃でした。

以上

Curiously Recurring Template Pattern

フレッシュ平瀬 — Mon, 06 Aug 2007 23:15:00 +0900

「Curiously Recurring Template Pattern」
というイディオムをご存知でしょうか？
というわけで今日は、この「Curiously Recurring Template Pattern」、
略して「CRTP」についてのお話です。
よろしくお願いします。

このイディオムは、あるクラステンプレートの継承時に、自分自身をテンプレートの型として渡すという何とも複雑怪奇な継承パターンのことです。実際のコードは以下のようになります。

template<typename ChildType>
class Base
{
public:
    Base() {}
    ~Base() {}
};

class Child : public Base<Child>
{
public:
    Child() {}
    ~Child() {}
};

こんな不思議な継承をする利点は、ただひとつ（だと思う）。
それは仮想関数の撲滅です。

　普通、継承関係を使ってインタフェースを規定しようとすると、どうしても仮想関数を使う必要が出てきます。インタフェースを規定するクラスは、インタフェースとなる関数が呼ばれると、実行時に呼び出す関数を決める必要があります。
　このとき仮想関数テーブルと呼ばれる関数テーブルを利用するのですが、この仮想関数テーブルを持つことで、1関数あたり1～2ワード分のメモリを消費するそうです。また仮想関数を持つことで、RTTI（Run-Time Type Information）のために40バイトほどメモリを消費するそうです(※The C++ Standards Committee - TR 18015:2006 C++ Performanceによる)。

　けれど、CRTPを適用すれば、仮想関数なしでインタフェースを規定でき、微妙にメモリ消費も抑えられます。ひょっとしたら、実行速度もほんの少し稼げる・・かもしれないです。

　仮想デストラクタを親クラスが使ってしまうとCRTPの利点がなくなってしまうので、仮想デストラクタは使えないです。なので、親クラスのポインタに子供クラスのインスタンスをnewして代入するような真似をすると、正常にメモリ解放できなくなってメモリリークしてしまいます（ので、親クラスのnew演算子を隠蔽しておくのが良い）。

　コードは読みにくくなるし、メモリリークの危険性もあるので「CRTPを使え」とは言いませんが、「こんなのもあるよ」という程度の情報として受け止めていただけると幸いです。

以上

遅延評価って何だ？

フレッシュ平瀬 — Mon, 23 Jul 2007 21:51:57 +0900

今日は「遅延評価」というものについて書いてみます。
まだ勉強中のため間違っている箇所があるかもしれないですが、
よろしくお願いします。

遅延評価は、最近のコンピュータ言語で出てきたテクニック(?)で、たとえばHaskellやD言語などで利用できます。「最近」と言っておきながら、いきなりアレですが、遅延評価自体は昔からあります。たとえば、こんな ↓ の。

if (p != NULL && *p == 10)

この場合「p != NULL」が先に評価され、「*p == 10」が後で評価されます。つまり「*p == 10」という式の評価は、その式の結果が必要になるまで、評価が遅らされるということです。

評価を遅らせるということは、結果として「必要なものしか評価しない」ことになります。必要なものしか評価（計算）しないということは、無駄な計算が発生せず実行速度を稼げるということになります。

「遅延評価といえばたらいまわし関数」というくらい、遅延評価にとって絶好のシンプルなサンプルがあります。たらいまわし関数は以下のようなものです。

int tarai(int x, int y, int z)

{

    if (x <= y) return y;

    return tarai(tarai(x-1, y, z), tarai(y-1, z, x), tarai(z-1, x, y));

}

見た目はシンプルなのですが、よく見ると再帰呼び出しが4つも・・・・、というC言語にしたら鬼のような関数です。x,y,zを1ずつ減らして、場所を変えてるあたりが「たらい」だそうです。

さて、この関数の引数に「x > y > z」となるような値を与えてやります。
たとえば「tarai(8, 2, 0);」や「tarai(20,10,0);」とかです。
が。
たらいまわし関数の怖いところは「tarai(8, 2, 0);」という何気ない小さな値でも7017回も関数コールされ、「tarai(20,10,0);」などは恐ろし過ぎて計算できないほど関数コールされます。うっかり「tarai(100,50,0);」なんてした日には、その日のうちに実行が終わるかどうかも怪しいです。

D言語での遅延評価は非常に簡単で、遅延評価させたい関数の引数を「lazy記憶域クラス」に指定するだけです（以下）。

int tarai(lazy int x, lazy int y, lazy int z)

{

    if (x <= y) return y;

    return tarai(tarai(x-1, y, z), tarai(y-1, z, x), tarai(z-1, x, y));

}

ほんとこれだけです。シンプル。

遅延評価がどれくらい効果があるかを評価するため、単純に遅延評価するときと、しないときの実行速度を比べます。結果は以下。

たらい引数：x=15,y=10,z=0

遅延評価なし： 87688 [msec]

遅延評価あり： 0 [msec] （早すぎて計測不能）

どちらもD言語で書いていますが、シャレにならないくらい時間差があります。遅延評価を用いた場合、「tarai(200,100,0);」でも266 [msec]でした。もはや勝負にならないくらい、遅延評価が優秀です。
なにもD言語だから遅いわけではなく、C言語で書いても言い訳できないくらいに遅いです（並列化も面倒ですし）。

遅延評価を使う場合、以下の最適化が行われます。

必要な式だけ計算する。
一度結果を求めた式は、その結果を使いまわす。

実のところ、1は2を含んでいます。「一度結果を求めた式」ということは、すなわち最初の結果を参照すればそれでいいということであり、つまり二度目の計算は「必要ない」ということです。この意味で、1は2を含んでいますが、あえて二つに分けています。

今回の「たらいまわし関数」の場合、たらい回す分だけ「2.一度結果を求めた式は、その結果を使いまわす。」が有効に働き、結果実行速度が飛躍的に加速したようです。
さて、今回の例では、あまりにも遅延評価に有利な立場のサンプルを用いて遅延評価の紹介を行いました。が、やはり時と場合によっては、マルチコアで並列化するよりもメタプログラミングでコンパイル時実行するよりも、アセンブラ化するよりも、遅延評価を使ってコーディングしたほうが有利な場面があります。
そんなときに、ふと思い出せるように・・・・、なれればいいなぁと思う今日この頃です。

以上

[C++] 不完全型と不透明ポインタ

フレッシュ平瀬 — Sun, 22 Jul 2007 16:40:12 +0900

中々、ブログを書く時間もとれないですが、いつも通りいきましょう。
本日は「不透明ポインタ」についてです。
よろしくお願いします。

　まず不完全型は、宣言だけあって定義のないクラスや構造体のことを指します。こんなの↓

 class MyClass;    // 宣言だけで実装がない。

　次に不透明ポインタは、不完全型へのポインタ変数を指します。こんなの↓

 class MyClass;    // 宣言だけで実装がない。
 MyClass * mc;    // 不透明ポインタ

　不完全型や不透明ポインタは、よくハードやOSといった環境に依存するコードを隠す目的で使われます。たとえば色んなハードやOS向けのライブラリを作る場合、ハードやOSに依存する部分は徹底的に隠蔽してクラスを設計する必要があります。
　そうしないとライブラリを使う人が、「あのOSでは、この関数。このハードではあの関数。」というような使い分けをしなければならなくなってしまいます。
　実際には、こんな↓感じでクラスを定義します。

 class Device;    // ハード依存のクラス（定義は別ソース）
 class System;   // OS依存のクラス（定義は別ソース）
 class MyLibrary
 {
 public:
    void InitDevice();
   void InitSystem();
 private:
    Device * device;
   System * system;
 };

　このようにハードやOSを抽象化することで、ライブラリ使用者は、ハードやOSとは無関係にこのライブラリを使用することができます。

　不完全型にはいくつか制限があります・・・というより、できないことの方が多いです。できることをまとめておきます。

不完全型へのポインタ変数を宣言、定義できる。
不完全型への参照変数を宣言、定義できる。
不完全型を戻り値の型とする関数を宣言できる。
不完全型を引数の型とする関数を宣言できる。

　ただし不完全型のオート変数は宣言も定義もできませんし、不完全型を戻り値あるいは引数の型に持つ関数は「定義」できません。つまり、こんな↓感じ。

    IncompleteClass * pValue; // OK
    IncompleteClass & rValue; // OK
    IncompleteClass Get(); // OK
    void Set(IncompleteClass value); // OK

    IncompleteClass aValue; // NG
    IncompleteClass Get2() // NG
    {
        return aValue;
    }
    void Set2(IncompleteClass value) // NG
    {
        aValue = value;
    }

　そんなこんなで、久々の更新は不完全型と不透明ポインタについてのご紹介でした。私が紹介するのもナニですが、すこしでも知識を共有できたなら幸いです。
　それではまたC++で逢いましょう。