IDCT は LLM を使っているけど、 ANN も試してみた。
2%ぐらい速くなるが、誤差が大きいせいか汚い。
補間があればもう少しましだろうか？
ANN は使わないことにする。

ブロックが単色かどうかの判定は、AC 係数すべてを調べる必要があると思っていたが、よく考えればハフマン復号化の時にわかることに気付いた。
JPEG では、係数行列の残りが全て 0 の時終端記号が入る。
つまり、デコーダ内部の AC 係数の書き込み終端位置を覚えておけば、AC係数の要素数がわかる。
AC 係数がなくて DC 係数のみの場合、DC 係数値を 8 で割った値が色になる。
これを利用して輝度と色差の両方が DC 係数のみの場合、1度だけ色変換の計算を行って、後は全てその色をコピーすればよい。
1ブロックは 64 要素なので、単色のブロックがある場合だいぶ高速化されるはず。
単色のブロックは完全に透明なブロック以外にもところどころある様子。
単色判定を入れて立ち絵の動画で試したところ 2% 程度速くなった。
期待したほど速くならなかったが、IDCT や 色変換部分の処理が大幅に削減されるので、SSE2 が使えなくて MMX になるような環境であれば、もう少し効果があるはず。

他に考えられる高速化には、ジグザグ行列を転置済みのものにしておくというのがある。
転置済みにしておけば、IDCT 時に1回転置が減る。
SSE2 版で試したところほとんど速度差がない。
MMX 版であればもう少し効果があるかもしれないが、かなり書き換える必要があるので、転置はいいか。

非 SIMD 版も計ろうと動かしたらバグってた。
いつの間に。
まず使うことはないだろうけど、一応修正。
MMX と SSE では、IDCT 内でレベルシフトしていたけど、非 SIMD 版はそれをしていなかったのが原因で色がおかしくなってた様子。
速度的には、SSE2 版より2倍遅い。
非 SIMD 版はどちらかというと動作確認用みたいなものなので、それほど高速化などは考慮していない。

デコーダー側はこれで一通り完成かな。
後は高速化の残骸などを消してソースコードを整理してテスト。

エンコーダーはGUI版を作った。
1個1個エンコードする時はGUI版の方が楽。
エンコードのコア部分は DLL にしているので、コマンドライン版もその DLL を使うように書き換える予定。
でも、こまごまデータもらいながら作るのなら、コマンドライン版はあんまりいらないかも。

あるブロックを DCT 変換すると、最初の係数にはそのブロックの平均色が入る。
この係数は特別扱いし、DC (直流) 係数 と呼ぶ。
もし、ブロックが1色のみの場合は、その色を表した係数がこの DC 係数に入る ( と思っているけど、間違ってるかも ) 。
JPEG 圧縮で劣化する主な原因は、以前書いたと思うけど、この DCT 変換後の係数行列を量子化テーブルの値で割るためで、そこで小数点以下の値が失われてしまう。
逆に言えば、小数点以下の値が出ないような値で割れば、劣化しないことになる。
つまり、ブロックが完全に透明な色のみだった場合、その時の DC 係数値の約数を量子化テーブルの内の DC 係数の箇所に持ってくれば、完全に透明な色のみのブロックは劣化することなく復元できることになる。
という事で、量子化テーブルの最初の値は、完全に透明なブロックを DCT 変換した時の各要素の値の約数になるようにしようと思う。
クオリティーを指定して計算された量子化テーブルの最初の値を、その値より小さな約数値になるようにすることになるので、少し圧縮率は低下すると思うが、まあうっすらと枠が見えてしまうのは避けたいので仕方ない。

実際に試してみると、800x600 149フレーム のパーティクルの動画で 2.86MB が 2.96MB になったが、枠のようなものは見えなくなった。
この程度の圧縮率の低下であればいいかな。
まあ、エンコーダのオプションとして、有効/無効選べるようにしてもいいし。

2008/06/22 修正。
DC 係数を AC と間違って書いていました。

で、違う立ち絵の動画3つを Core2Duo E6750 で再生すると、CPU 負荷 10% ～ 15% 程度。
まだ、MMX 化までしかしていないので、SSE2 まで対応するともっと下がると思う。
ただ、SSE2 が使えない CPU では意味がない。
1.5 GHz程度のマシンでどの程度の負荷かはまだ確かめていない。
ほかに出来る MMX のみでの更なる高速化は、完全に透明なブロックの処理を省けるようにすることくらいかなぁ。
ただ、あの特許申請中のものがなぁ……
完全に透明かどうかではなく、ブロックが単一色かどうかは IDCT の前段階でわかる。
AC 係数がすべて0であれば、そのブロックは単一色となる。
単一色であれば、色変換は1ピクセルだけ行い、後はその色で塗りつぶせばいい。
αチャンネルを ZLib で圧縮したバージョンのほうは、ブロックのαチャンネルをすべて調べるのと気にせず合成してしまうのでどちらが速いかは微妙。
この方法で単一色ならブロックを塗りつぶすようにすれば、完全に透明などは関係なく、べたで塗られているところは高速化される。

今回作っているα動画は、krmovie.dll とは独立した機構になっている。
元々は、高速化のためにレイヤーのサイズをフレームによって変更する必要があったので、別のプラグインとして作ることにした。
それ以外にも制御の多くを TJS 側に持っていく形にした方が、いろいろと都合が良いだろうということもある。
このプラグインでは、バックグラウンドで動画を順にデコードしてキューにためていくことしかしない。
キューから取り出して描画を指示するのは TJS スクリプト側の仕事。
つまり、再生速度のコントロールは TJS 側で行うことになっている。
このような仕組みのため、プラグインを変更することなく、スクリプト側でより柔軟な制御が出来るようになるはず。
ただ、現在デコード順は順方向のみなので、この辺りの指定をもっといろいろ出来るようにすると、さらにいろいろな再生が出来るようになると思う。
また、ファイル終端までデコードが終了したら、指定した別ファイルを続けてデコードすることを可能にしたので、複数のムービーを滑らかにつなげるようになった。
従来セグメントループなどの形で実現していたことを、別々のファイルで出来るので、動画制作時の取り扱いなどが楽になるはず。

と言うことで、エンコーダーの開発に取り掛かろうと思う。
エンコーダーは、連番 PNG か無圧縮 32bit AVI から、専用フォーマットの α付きモーション JPEG にエンコードする形になる予定。
連番 PNG は、別に連番でなくても良くて、指定フォルダ内にある PNG ファイルを名前でソートして、それを動画としてひとつにまとめる形にするつもり。
最初のバージョンでは、ハフマン符号化テーブルは固定にする。
その後に 2パス圧縮をサポートしてテーブルを最適化し、圧縮率を高めるバージョンを作るかもしれない。
出来上がったものの圧縮率や再生負荷を見て、後の改良は考える。

このページに置いておきます。

AVI で書き出すものはごうさんが既に作っていたけれど、AVI 2.0未対応で無圧縮で保存されるので、あっという間に2GB超え＆HDDへの書き出しが間に合ってなさげで、扱いづらかった。
そこで、AVI 2.0 対応のために DirectShow を使用して書き出すことを考えていたが面倒くさい。
あれこれ考えていて、ふと、WMV で書き出すものなら、さくっと出来る気がした。
という事で、コーディング開始。
さくっと…… と思ったけど、4時間ぐらいコーディングにかかった。
動画系の API は手続きが多いので、いろいろと面倒だった。
改めて考えると、DirectShow を使っても大差なかった気がする。

で、動かすと IWMWriter::BeginWriting でエラーが返ってくる。
内容は、Video codec エラー ( An unexpected error occurred with the video codec ) 。
さっぱり理由がわからない。
サンプルのソースといろいろ見比べたり、サンプルをデバッガで動かして入っている値を見たりして修正するも改善せず。
もしかして、スレッドを分離しているのが原因？ と思って、IWMWriter::BeginWriting を初期化側のスレッドとあわせるとエラーにならなくなった。
別スレッドにしたらだめだったのか。
でも、実際の書き出し部分はスレッドが分かれていても問題ない様子。
バッググラウンドでひたすらエンコードしてもらう必要があるので、書き出し部分は別スレッドに出来ないと少し面倒なので、そこは良かった。

という事で、吉里吉里でゲーム画面の動画を書き出すプラグインを作った (結局１日かかった)。
が、ここではまだ音に対応していない。
吉里吉里の本体から直接音を得る方法はない様子。
本体をいじるか、ループバックで録音するか。
結局、ループバックで録音する方法で行くことにした。
エラー音やクリック音などが鳴ると、一緒に録音されてしまうという難点があるが、まあそこは諦めるという事で。
音のキャプチャー自体は、DirectShow を用いて行った。
ここは特に問題なかったのだが、WMV 書き出しでまたうまく行かない。
エンコードしていたら途中で落ちてしまう。
エラーは The writer has received samples whose presentation times differ by an amount greater than the maximum synchronization tolerance. You can set the synchronization tolerance by calling IWMWriterAdvanced::SetSyncTolerance. とか。
IWMWriterAdvanced::SetSyncTolerance で時間を長くすると、どんどんメモリに溜めていってなかなかエンコードしない様子。
で、終わったものをみてもうまく撮れていない。
なんなんだろう？ といろいろと調べていたら、書き出し時に指定するストリーム番号が設定されていなかった……
絵だけや音だけの場合、そこがおかしくても問題ないけど、絵と音のように2つ以上ストリームがある場合はまずいようだ。
というか、設定する部分を見逃していた。
これで音も撮れるようになった。
結局2日かかった。

ただ、これには問題がある。
WMV をリアルタイムでエンコードする関係上、すごくCPUパワーが必要。
640x480 30FPS では、Core 2 Duo E6750 (2.66GHz)、メモリ 4G、HDD RAID 0 でも間に合わない。
動きの少ないシーンでは大丈夫のようだが、動画を再生しながらとなるとだめ。
エンコードが間に合わない場合、メモリ上にひたすら画像を溜めていくのんだけど、どうも吉里吉里側の描画の方が処理落ちして、それであんまりメモリには溜まらずに進んでいく様子。
プライオリティーをいじれば解決するかもしれないけど、4Gあっても1分程度しか撮れないのであまり効果はない。
これはクアッドコア必須か。
ただ、Video Codec を Windows Media Video V7 や V8 にすると負荷が下がり撮れる。
というか、マルチスレッド化されておらず片方のコアをめいっぱい使っているだけのように見えるが、撮れることは撮れている様子。
まあ、これでいいかなぁと思ったが、もっと速い CPU が欲しいと自分も周りもつぶやいていて、少し考える。

連番 JPEG 書き出しバージョンを作ろう！
JPEG エンコードは、SIMD 拡張版 IJG JPEG library を使う。
で、組む。
1時間ぐらいで出来た。
WAV でもいいから音入らない？ と言われる。
で、組む。
さらに1時間ぐらいで出来た。
いい感じ。
Core 2 Duo E6750 (2.66GHz) で CPU 負荷が 20 ～ 30% 程度。
比較的軽い。
WMV よりも容量が大きくなってしまうのは仕方ないが、バラバラのファイルになるので HDD 容量のみの問題だから、容量が大きくなるのはそれほど問題ではない。

実際のゲーム画面がキャプチャーされたものを見る。
普通に見れる。
というか、ゲームじゃなくてこっちでもいいとか思ったり。
それはどうか…… と言う話なんだけど、字幕付きのアニメを見ている感覚で楽。
これはちょっと考えさせられた。

このプラグインは少し使い方が厄介なので、マニュアルを少し書かないといけない。
その辺り書けたら公開するかも。

mixi とは異なり、クリエーターの方ばかりでいろいろと刺激があります。
似たような悩みを持っている人や考えている人、開発上の話など、読みたいと思う日記が多いです。
それで、よくぐおーーーっもっとかんばってもっと早く開発しなければ！と思います。
負けず嫌いなので、すごい人とか見ると、絶対負けない、がんばると思います。

デジタルトキワ荘では、ブログと同じような日記を書いていますが、マニアックな内容は少し避けています。
読んでもそのことに詳しいプログラマ以外わからないようなこともブログでは気にせずガンガン書いていますが、日記ではもう少し軽めです。
後、ある程度クローズドなので、実験的に作ったものを適当に置いてみたりしてます。
ここだと、ある程度しっかりしないと公開し辛い面がありますが、SNS なら、まっ、いっかと。
日記も途中の段階であれこれ考えていることを書いています。
ここのブログはそうじゃないときもありますが、ある程度まとまってから書くようにしているので、途絶えたりする時がありますが、日記ではこーかな？あーかな？と書いてたりします。

後、○○出来る人募集とか、探したりするのもやりやすそうです。
これ出来る人いない？　こういう人探しているんだけどとか、今こういうことやってるけどうまくいかないなど、同じ開発者だからわかることや出来ることが出来そうで期待しています。
似たような人たちだから距離も近く感じます。
また SNS をしている人はわかると思いますが、ブログよりも SNS の日記の方がコメントしやすいです。

ちなみに私のページはここです。
よほど変な人でなければ、マイフレンド申請してもらえば OK します。
ただ、ある程度どんな人かわかるようにプロフィールなど書いておいて欲しいです。
さすがにどんな人かわらないのに OK すること出来ないので。

ま、気が向いたら一度お試しあれ。

ハフマン符号化 ( エンコード ) は、ある値を別の値に置き換える作業。
これでなぜ圧縮できるかというと、出現頻度の高い値に短い符号を、低い値に長い符号を割り当てるため。
つまり、「あ」はいっぱいあるから 01 にしよう、「ん」はほとんどないから 00000000001 にしようという具合に値を置き換えていく。
こうすると、データの偏りが大きければ大きいほど圧縮される。

ランレングスは、同じ値が連続でつながっていた場合、その値が何個つながっているかを保存することで圧縮する方法。
つまり、「あああああああい」となっていたら、「あ 7 い 1 」というように保存する。
こうすれば元のデータより圧縮される。
ただ、連続していない場合は、データが増える。
JPEG では、ゼロの値についてのみランレングスで圧縮を行う。
なぜゼロかというと、離散コサイン変換 ( DCT ) を行い、量子化を行ったデータにゼロが多く含まれるから。

離散コサイン変換とは、周波数領域に変換する作業。
画像を離散コサイン変換し、高周波領域を削って元に戻しても、劣化があまりわからないことを利用して、圧縮する。
削るのは割り算で行う。
劣化がわかり辛い高周波領域ほど大きな値で割る。
割り算は整数で演算するので、小数点以下はなくなる。
圧縮率を大きくするということは、大きな値で割ることなので、ゼロが多くなる。
JPEG では、この割る作業を量子化と言っている。
元に戻す時は掛け算を行う。
当然小数点以下は失われているので劣化していて、元の値には戻らない。

ハフマン復号化 ( デコード ) は、ハフマン符号化で変更した値を元に戻す作業。
対応表に従って元に戻せばいいんだけど、符号値は可変長なので、まじめにやると1ビット読み込んで比較してなかったらもう1ビット読んで…… とちまちま比較していかないとならない。
圧縮率が高い = 短い符号が多いということなので、高圧縮のデータは数回読めば比較は終了する。
でも、そうでない場合は時間がかかる。
一般的な高速化方法はテーブルを使うこと。
まず最大長のハフマン符号ビット数分読み込んで、その値をインデックスとしてテーブルを引く。
テーブルには値とその符号のビット数を記録しておけば、すぐにわかる。
読み込みすぎた分は元に戻す。( 実際には、最初は参照し、ビット数がわかったらそのビット数分捨てるような作り。参照では読込み位置のポインタは進めない )
ただ、最大長のハフマン符号が大きい時はテーブルが大きくなってしまう。
JPEG では、16 ビットまであるので 65536 個のテーブルになってしまう。
64KB なのでメモリ容量的にはそれほど大きくはないが、テーブルが大きいと遅くなってしまう。
SIMD 拡張版 IJG JPEG library では、ある長さでテーブルを切っている。
つまり、先頭数ビット分のテーブルのみ持ち、持っている長さ分読み込んでテーブルを引く。
テーブルを引くと、その長さ以下の符号なのか、その長さでは足りない符号かわかる。
もし、足りなければそれ以降は1ビットずつ読み込んで比較していく。
ただ、長い符号はあまり出てこないはずなので、結果的にはほとんどテーブルを引くだけで済ませられると思われる。
ハフマン復号化はこの方法を使おうと思う。
もっと高速化できる方法があればいいんだけど……

事の発端はガラスで出来た CD の音が良いと言う話題から。
そんなことはありえないと言う意見が多かったが、私は「ディジタルを構成しているものは全てアナログなのだから、何か影響があってもおかしくない」と言う意見だった。
つまり、音は変わることはあり得るという考えだ。

まず、疑ったのは音楽 CD は、読み込みエラーが多いと言う考え。
CD は、読み取りエラーが発生すると、エラー訂正によってほぼ元のデータに復元される。もし、それでも復元されなければ、補間によって、元のデータに近いと考えられるデータになる。
つまり、補間がかかればデータが変わるのだ。
だが、CD の読み取り面が綺麗で、CD プレイヤー自体も経年劣化などしてないければ、読み取りエラー自体発生しないようだ。
また、通常使用時においても、エラー訂正で訂正できないレベル以上、つまり補間がかかることはまずないということが複数の検証サイトによって検証されている。
補間がかかるというか、読み取りに失敗するのは、CD プレーヤー自体に衝撃が加わった時。
これの対策としてポータブル CD プレイヤーには音飛び防止バッファが数十秒積まれている。
ただ、カーオーディオにおいては、この音飛び防止バッファが削られていっているらしい。
理由は至極納得できるもので、常に振動が加わる車では音飛び防止バッファがいくらあっても、バッファを使い切ってしまうと言うことのようだ。
そのため、音飛び防止バッファに頼るのではなく、CD プレイヤーに加わる振動を軽減し、読み取りエラー自体が発生しないようにする方向に進んでいるんだとか。
話がそれたが、エラーによって音が変わるということはなさそうだ。
このエラー以外に音が変わる原因についての論拠は尽きたが、どうも釈然としないためさらにいろいろと調べた。

比較的信頼にたるソースとして、プレクスターの技術者が記者のインタビューに答えると言う記事が見付かった。
プレクスターと言えば、高性能 CD-R ライタで有名だったメーカーだ。
第14回：迷信だらけのデジタルオーディオ［特別編］ ～ドライブメーカー「プレクスター」に聞く、CD-Rの変化～

CD-R に焼くと、どうも音がこもった感じがするような気がしていたが、その感覚は間違いではなさそうだ。
さらに有名な検証サイトを以下にリンクしておく。
かなり、長いので上の記事で納得できない人や興味のある人は読むといいと思う。

以下、今日の必ず得する一言 より
音楽CDの音質とジッタの関係のナゾ(CDの神髄編)
音楽CDの音質とジッタの関係のナゾその２(原信号特性編)
音楽CDの音質とジッタの関係のナゾその3(ジッタ変動とスタビライザーX編)
音楽CDの音質とジッタの関係のナゾその4(みんなでジッタサウンド編)
音楽CDの音質とジッタの関係のナゾその5(ジッタの電源ライン波及編)
音楽CDの音質とジッタの関係のナゾその6(緑に塗ったりカットしたり編)
音楽CDの音質とジッタの関係のナゾその7(ジッタの影響はDACか？アンプか？)
音楽CDの音質とジッタの関係のナゾその8(ジッタ量とエラー訂正頻度)
音楽CDの音質とジッタの関係のナゾその9(TE信号とエラー信号記録法)
音楽CDの音質とジッタの関係のナゾその10(山本式メカニカルダンパー変造)
CD-Rのジッタとメーカーの言い分のナゾ

A-1 DRIVE
CD（ディジタルオーディオ -S/PDIF） エラーカウンタ／ステータスモニタの製作

ジッタ計測などを行っているページ efu's page

これらの記事を読んでどう判断するかは自由だが、私は音は変わるという意見になった。
まあ、元々そうだったんだが……

ブロックが完全に透明かどうかで処理を分けるか否かに関わらず必要な処理は高速化しないといけないと思うので、まずは一通りの処理を書いて、速度を測ってみるか。
後、ブロックが完全に透明かどうかで処理を分けるのも、一度書いてみよう。
構造的に、ifdef で使うかどうか切り替えられると思うので、そのようにしておけばどっちになっても大丈夫か。
でも、特許として認められるよりも早く製品を出した場合はどうなるんだろう？
これはもっと特許について勉強しないといけないな。

それよりも何よりも、どの程度高速化するのかしないのかについて興味がある。
たいして速くならないのならなくしてしまった方が安心と言えば安心。

1. αチャンネル映像のための符号化ブロックパターン生成装置及び方法とそれを利用したαチャンネル映像符号化／復号化装置及び方法

2. グレイアルファチャンネルを含んだ映像の符号化／復号化装置および方法

両方サムスンがとっているよう。
ぱっと見意味不明だが、2の方が今回考えていた高速化に引っかかる。
まず、1 の方は、αチャンネルと言っているが、1ビットのマスクを想定して書かれていて、ブロックが全て透明、全て不透明、混在の3つに分けて処理する方法が書かれている。
そして、JPEG などでは 16x16 のブロック を 8x8 に分けて圧縮するが、このブロックの透明/不透明の3パーンの情報を 8x8 に付与し、16x16 の方は 8x8 の透明情報の論理和などを取って判断することが書かれている。
つまり、8x8 単位で分類されているが、16x16 単位の段階でまず判断でき、そこで混在している場合は、8x8 単位で判断し処理できる。
なるほど、これはよく考えられている。
8x8 単位にすることは考えたが、そこで分けるよりも 16x16 単位にして処理してしまった方が速いだろうと思ってそうはしなかった。
ただ、8x8 単位で考えていた場合は、この特許に引っかかっていたかもしれない。

問題は2番。
ブロックのαチャンネル値が全て0の時、符号化処理を省く方法について書かれている。
また、αチャンネル値が全て0かどうかで処理を分けること自体が封じられているようだ。
なんてことだ。
こんな簡単に思いつく方法を特許にしないでくれよ。
1番はなるほどと思ったけど、2番はちょっと考えてすぐに思いついた方法と同じ。
特許がとられた年を考えると、既にこの技術を使った製品などあってもおかしくなさそうだけど、特許の取り消しとか個人で何とかなるのか良くわからないし、時間もかかるだろうからこの方法は諦めるしかないか。
何度か読んで回避方法も考えてみたが、請求項の範囲が広すぎてどうにもならないかと諦めることに。

仕方がない。
深い部分に踏み込むのは止めて、JPEG に α情報を付与したものを出来るだけ高速にデコードするように頑張るか。
1.5GHz で 3つ同時は辛いかもしれないなぁ。

2008/05/17 追記
これはまだ特許になっていないそうな。
審査請求されていないとか。
特許の審査未請求って？
特許のシステムをイマイチ理解していなかった。
もう少し勉強した方が良さそうだ。
公開されていたから、特許かと思ってた。

SIMD 拡張版 IJG JPEG library では、数ラインずつデータを取得していくが、中を見るとそのラインに必要な分だけデコードしているっぽい。
必要な分だけやっているとしたら、キャッシュの効率は良さそうだ。
高速化するのなら他の部分や特性を考えないと難しそう。

IDCT のアセンブリソースを C に書き直していて気付いたけど、どうも一度 char サイズの YCrCb カラーに変換してから、RGB カラーに変換している ( IDCT の係数行列は short 型 )。
YCrCb カラーから RGB カラーに変換する時、また一度 short に戻している。
これは少し無駄に見える。
元の IJG JPEG library の構造からくる制約だろうか？
それか、一度 unsigned char にすることで飽和処理を用いて 255～0 の範囲に丸める必要があるのかもしれない。
この辺りは実験した方が良さそう。

また、YCrCb カラーから RGB カラーに変換する部分でも、精度を重視したような実装になっている。
四捨五入したり、2倍してから計算して半分に戻すなど。
少しの誤差は気にしない方針にしてしまえば、ここも少し速く出来るかもしれない。

これ以上はアルファに注目して、高速化するのが良さそう。
16x16 のブロックで全て透明のものは保持せず、ブロックが完全に透明かそれ以外かでフラグを保存しておけば、完全透明の時は単純にゼロフィルすればいいだけになる。
また、色空間変換時にアルファ値を参照して 0 ならその部分の変換はスキップしてゼロフィルする。
これが出来るだけでも、かなり速くなるのではないかと思う。
画像にもよると思うが半分以上は透明なのではないかと思う。
そうなると、その半分はほとんどの処理を飛ばせるのでかなり速くなるはず。
ただ、完全に透明な領域が少ないと効果は少ない。
そこは動画なのでフレームによって差があると思うので、先読み分である程度処理負荷を平均化出来るのではないかと考えている。

でも、これやるとなると IJG JPEG library にかなり手を入れるか一から作る必要があるのが大変。
と言いつつ、SIMD 拡張版 IJG JPEG library のアセンブリソースを少しずつ C に直しているんだけど。

update がコールされた時、対象のボタンが押されていれば 1加算、離された時 ( 押されておらず値が 0 より大きい時 ) -1 に、押されていない時 ( 値が 0 以下の時 ) は 0 にする。
このようにすれば、0 より大きい時は押されていて、0 以下の時は離されているのがわかる。
また、マイナスの時は離された瞬間、1 の時は押された瞬間とわかる。
長押しは、どれぐらいの長さにするかによるが、値がいくつ以上かと判定することでわかる。
仕組み的にはこんな感じで。
もっといい方法があれば…… と考えていた気付いたけど、長い間押されていないのも判定できた方が良いだろうか？
単純に 負の値の時に 1 減算していくことで、どれくらい長い間押されていないかはわかる。
しばらく操作されていないとキャラクターがあくびするなどの時に使う…… ことはないか。
操作されていないのであれば、全ボタンで判定した方が効率的。
まあ、長押されてない判定もあってもいいかな。
あって不都合はないし。

ボタンエッジ検出や長押し判定は、状態取得のクラスに入れるのではなく、そのクラスをラップして実現するのがいいかな。
ゲームパッドの状態取得クラスは、IInputDevice インターフェイスを継承して作っている。
これの派生クラスは、XInput 用、DirectInput 用、DirectInput フォースフィードバック対応用の3つある。
継承関係の間に入れるという手もあるけれど、必ずしもボタンエッジ検出や長押し判定が必要とは限らないので、包含して拡張するのが良いかな。

ま、ボタンエッジ検出と長押し判定は入れよう。
いずれかのボタンが押されている離されているも。

XInput デバイスはボタン固定なので、ボタン設定用のメソッドは持たない。
このプラグインでは、あくまでパッド間の差異を吸収するための設定と考えている。
でも、そしたらゲーム個別の設定が出来るようにしようとしたら、2回も設定が必要か……
その辺りは少し考えないとダメかな。