いろいろ調査してみたところ、リモートデスクトップでPCに接続すると、セキュリティのためUSBのスマートカードリーダーとの接続が解除されるらしい。リモートデスクトップの仕様とのこと。しかも、リモートデスクトップ終了しても接続は復帰しないとな。これはひどい。実家からリモート接続したせいで、カードリーダーとの接続が解除され、以降の録画はB-CASカードが認識できないので全部スクランブルが解除されていないと。
・引き出しを掃除
開発用やら私用やら歴代の携帯電話がたくさんでてきた。あとMovaがいくつかあるはずなんだけどどこいったのかわからん。
携帯アプリを作っていると、携帯の機種ごとに処理能力が違ったり挙動が違ったりバグがあったりと実機での動作確認はやはり必要で、最低限これはという端末は中古で買ったりしてた。おもにバグが多くて評判の悪い機種を中心に。最近はガラケーのアプリプラットフォームもだいぶ成熟して、メーカー側の実装も共通化されてきてるのかおかしな挙動をするものは少ないような印象。Android端末は歴史が浅いのでちょっと怪しい気がするけどiアプリの黎明期に比べればだいぶマシな気がする。メインで使用しているのはまだガラケーなんだけど、P07Aから薄いガラケーに買い替えたいなぁ。
・PS Vitaを購入
リッジでコースを何周かしてみて、あとはずっと俺の屍を越えてゆけを購入してプレイ中。裏ボス撃破。やっぱおもしろい。
Vitaは有機ELがきれい。画面が初代PSPより大きい。全体の大きさも同じく少し大きい。ただし薄い。そのため、初代より軽く感じる。システム画面における操作がすべてタッチ操作を要求されてうざい。そのため指紋がつきまくる。せめて裏面で操作させてー。電池は結構もつ。PSPのDLゲームやってるのだが6時間以上は持つ感じ。Vitaは初代とPSPと比べて解像度が丁度4倍なので、PSPのゲームは綺麗に拡大してくれる。単純拡大だけではなく、バイリニアも選択できる。
ハードとしてはとても好き。あとはソフトがたくさん出てくれれば。ハックとかも偉い人がなんとかしてくれると信じてます。
・帰省
そして、実家に帰ってきてるときに関東で地震とな。震度3だか4だかとなると、積み上げた荷物とかは散乱しそう。。。リモートデスクトップが繋がるから壊滅的なことにはなってなさそうだけど、Webカメラでも起動させて帰ってこればよかった。次の機会にはWebカメラを設置しておこう。ついでに空き巣対策で動体検知したらサイレン鳴らすようなアプリ作っとこうかな。単純な変化の検知であれば差分とって閾値決めるだけでアルゴリズムとか適当でもなんかできそうだな、面白そう。サイレンじゃなくてお経とか心理的にくるもの流してもよし。前に買った赤外線リモコンと連携して家中の家電が動き出すとか。
2011/11/28(月) Sandy Bridge-e ( Corei7 3930K )
ダブルチューナーで録画しまくってたら、エンコードの遅さが気になってきたのでニューマシンをぽち。いろいろとケチのついてるSandy Bridge-eですが、Core2Q 9550からの買い替えなので、まぁそんなに悪くないと思う。欲しい時が買い時です。
Core2Qを3.4GhzでOCして常用してたけど、3930Kの定格[3.2Ghz]でエンコード時間が半分以下になったので満足。メモリは16GB。奮発してIntelSSDの300GBも乗っけた。今までは160GBを使っていたけど、不足がちだった。ビデオカードやら光学ドライブやらは以前のものを流用。以前と比べて、アイドル時のマシン全体の消費電力が130W→90Wに減りました。一方でエンコードガンガン回してCPU使用率100%にすると、180W→250Wとなかなかの暴れっぷり。6コア12スレッドでタスクマネージャが壮観です。さらにオーバークロックで試しに4.2Ghzで回してみたけど、危なげなく動作してます。もっと上げられそうだけど、消費電力も半端なくあがってるので、定格に戻して運用中。あぁ、2パスでH264にもりもりエンコードできるわ。一晩で終わらなかったエンコードが一晩で終わる。(´∀`)
2011/11/25(金) kindle fire
kindle fireゲッツ
送料込で21000¥
日本語入力できない…orz
AndroidMarket使えない…orz
AmazonMarketで我慢しようかとおもったら、日本からだとリージョンが違うとか言われてAmazonMakrketからさえアプリダウンロードできない…orz
あと微妙に動作不安定な…orz
改造しないとなんもできないなー。さっさと弄ろう。
いろいろ弄ってカスタマイズすればコスパのよいAndroidタブレットだと思う。
液晶きれいだし、性能も悪くない。
2011/11/12(土) HTML5 Canvas
ふとHTML5が気になってJavascript+Canvasの勉強。ぷよぷよもどきを作ってみた。
Canvasが使えるとJavaでゲーム作るのとそんなに差はないと思うけど、JavaScript自体になれていないので、いろいろなところでひっかかる。ちゃんとしたゲームを作ろうと思うと、もう少しノウハウためないと無理ぽい。正確なフレーム制御やダブルバッファリングやら、そもそも開発環境どうするんだ、とか。コードアシストないとつらいなぁ。
2011/11/06(日) Range GET
今まで使ってた地デジチューナーが壊れたので、9月末にKTV-FSUSB2を2台購入。ダブルチューナー体制になりました。TOKYO MXの映りが際どいので根本にブースターも設置。写真右が以前使ってたHDUS。
これらは所謂
TS抜きが可能なデバイスで、少し弄ると放送のストリームをそのまま保存できます。この黒いやつは分解してICチップの足を一本切ると、ファームの書き換えが可能に。有志がいろいろとツールを用いしてくれているので、改造はすぐすみます。で、撮り溜めた動画を外出先などからアクセスして見れるようにしたいと思い、ASP.NETでファイル公開用のアプリを用意してみた。利便性を考えてHTTPで。2バイト文字等あるので、アプリがパスの管理して、ファイル読み込んでバイナリデータ返す感じ。WebDAVサーバーでもほとんど用事は足りるんだけど、まぁカスタマイズ性と勉強とで。
で、本題。
自分用でほかの人にアクセスしてほしくないものなので認証つけてHTTPS必須にした。さくっとWebアプリを作って、PCのブラウザからはファイルダウンロード成功したのだけど、iPhoneからアクセスするとうまくいかない。調べてみるとiPhoneは
Range指定によるGETを使う模様。ガラケーの大容量アプリとか、動画ファイルとかはRange使ってた気がしたけど、iPhoneでも必要とは。Rangeによる分割ダウンロードに対応して、今度こそはと思ったけど、やっぱりiPhoneで動かない。でも試しにHTTPSじゃなくてHTTPで構成してアクセスしてみると動作する……。なんでだろう。HTTPSの時の問題なのでパケットも解析できないし、どうしたものか。結局週末の二日間がんばって解決せず。まぁiPhoneのブラウザから直接アクセスなんてしないからいいんだけど、すっきりしない。GoodReaderとかのアプリはわざわざRangeなんか使わないので、iPhoneでもちゃんとダウンロードできます。
IEについて言えば下記のようなキャッシュに絡んだ問題があるみたいだけど、これも違う。
てか今やってみたらhttpsだと自作アプリ経由せずに直でアクセスしてもダメじゃないか。IISの設定で変わるのか?もうだめぽ。わからん。
2011/10/30(日) MapEditro5
だいぶ前に作っていたマップエディターを弄って少しばかり整えたので公開しておきます。
エラー処理とかはいつも通り適当です。あんまり使ってないのでバグがたくさんありそう。
レイヤー(16層まで)、レイヤーの半透明描画、チップの自動配置、スクリプト作成の補助、チップカット、チップリスト出力とかができます。
2011/10/30(日) C#で高速描画
MapEditorを作っていたのは3年近く前。ソースコードに一切コメントない…。
いろいろ忘れすぎてもう一度調べなおした。備忘のためメモ。
1.GDIの利用とDDBとDIB
今回のMapEditroを作るにあたって、描画について、透過、拡大縮小、αブレンドが必要になった。
C#(GDI+)だとこれらすべて簡単に使えるのでそれで実装しようと思っていたのだけど、GDI+が遅すぎて使い物にならなかった。マップエディタは小さいなマップチップを大量に描画するため結構重い。しかも今回は半透明機能なんてつけたので、カックカクもいいところ。
「GDI+ 遅い」でググると速度比較などもろもろ情報が出てくる。
今回はアンチエイリアシングなどは必要ないので、GDIを使って描画することにした。GDI+はただでさえ遅いのに、C#のGraphicsクラスやBitmapクラスから利用すると、スムージングなどが入ってたり、画質優先になってたりするためなのか、ものすごく遅い。
GDIのBitBltで頑張る。
使用するバッファ(ビットマップ)の形式は、DDB(Device Dependent Bitmap)とDIB(Device Independent Bitmap)がある。これらはその名前のとおり、デバイス依存ビットマップと、デバイス独立ビットマップ。前者はVRAMなどに格納されたりするそのデバイスに依存(そのデバイスのドライバに依存)した形で、非常にパフォーマンスの良い動作をする。後者はシステムメモリ上に格納されて、デバイスに非依存で使用できる。この形式は、Windowsのペイントとかで使うBitmap形式と同じらしい。
高速に描画ということでDDBのほうがいいだろうと思って、DDBを使った実装をしてみるが、実行してみると途中からビットマップの領域確保に失敗している。VRAMはたんまり空いているし、VRAM足りなかったらシステムメモリ使えよ、とか思ってたのだが、DDBはシステムリソース領域にとられるらしく、数十MBで領域が枯渇するらしい。しょうがないのでDIBを使う。とはいってもこれでも十分早いので問題なし。
・ハードウェア互換のBitmap(DDB)作成
CreateCompatibleBitmap()
・ハードウェア非互換のBitmap(DIB)作成
CreateDIBSection()
・システムリソースを消費する関数
http://support.microsoft.com/kb/402113/ja
・描画速度に関する参考資料
2.マスク処理
BitBltで透過描画を行うにはマスク処理が必要。今回は以下のような手順を用いた。
元画像は透過情報をもったGIFやPNG。.NETのGraphicsクラスとBitmapクラスを使えば、簡単に読み込めて、簡単に透過描画できる。しかし大変重いので、読み込みと事前準備だけを.NETのGraphicsクラスとBitmapクラスを使用する。下記のように画像読み込み時にDIBで「背景を黒色化した画像」と「マスク」を用意する。DIBSectionは黒色で初期化されている。GraphicsクラスはHDCからインスタンスを作成できるので、初期状態のDIBからGraphicsクラスを生成し、drawImageメソッドで背景が黒色の画像を生成する。一方でマスク画像は、空の2値DDBをCreateBitmap関数で作成し、そこに画像を描画することで強制的に2値のマスク画像を生成する。このときSetBKColor関数で描画元の画像の背景色を指定することで、背景と背景以外で2値に分けることができる。またマスクは24bitDIBに変換しておく。
実際に描画を行うときは、まずマスク画像を対象領域にAND合成する。すると対象領域から白色(1)部分がが残り、黒色(0)
部分が黒になる。その後、背景を黒色化した画像をOR合成すると完成。
AlphaBlendの場合は、もう一枚バッファが必要になる。描画対象領域(背景)をバッファに転送し、そこに対して上記の透過描画を行う。透過合成の結果を描画対象領域に対してAlphaBlend関数で転送する。
コードの一部抜粋。動くかどうかは知らない。参考に。
3.使用方法
面倒くさくなったので省略。
描画はすべてGDIを使ってオフスクリーンで行い、最終的にPictureBoxのPaintイベントでオンスクリーンに描画する。おそらくここはそこそこ描画コストがかかるはずなので、オフスクリーンからオンスクリーンへの描画は最小限に。