日々適当

「デジタル専用機は録画補償金の対象外」　知財高裁認める、二審も東芝勝訴 [ITmedia ニュース]

このまま判決が確定されるなら、私的録画補償金管理協会はこういう提案をしたらどうだろう。我々の収入源を守るために、テレビ放送のコピーコントロールをやめよう、とw
従来のアナログチューナー搭載のレコーダーにかけられてた保証金の値段と、BCASの仕組みを入れるためのライセンス料金？と、どちらがお高いんでしょうね。でも、個人的にはもし1万円ぐらい機器の値段が高くなったとしても、私的録画保証金を支払う範囲がそれだけにとどまるのならば、払ってもいいと思う。そのかわり、HDMI経由でのキャプチャや、取り込んだBD・DVDからのキャプチャを認める、って内容になるならば、だけど。

DigiTimes: 2880-by-1800 Retina Display rumored to come to 2012 MacBook Pro [9to5Mac]

次期MacBook Proが高解像度になるという噂が出ています。

「OS X 10.7.3 beta」でもRetina対応Macの登場が予想出来るヒントが見つかる [気になる、記になる…]

それに対応するように、OSのベータ版でそんなオプションが出ていたそうで。ベータ版の最新ではそのオプションのチェックボックスは削除されていたようですが、Appleがその方向に向かっている、という事が確認できる資料です。

Lionになって、ディスプレイの環境設定で、解像度の値の横に「拡大」という文字の入った選択肢が現れました。



これを選ぶことで、例えば従来、ディスプレイの持っている解像度よりも低い解像度での出力を選ぶと、小さな画像が大きく拡大されたような、つまりぼけた絵が表示されていました。しかし「拡大」文字付きの解像度を選択すると、UI要素のdpi数が向上し、文字なんかは非常に滑らかな状態で表示されるようになります。例えば上図だと、1920 x 1200のモニタに対して「1280 x 960（拡大）」という選択肢があるわけですが、この場合、横方向の表示の細かさが1.6倍に向上します。なぜかもともとのディスプレイの解像度に合わせたアスペクトの選択肢が現れないので、この選択肢だと横につぶれた状態（縦方向は1.25倍に向上）になってしまうのですけどね。

なお、実際に実行してみると、画面の変化の仕方が違います。1280 x 960の「（拡大）」がつかない選択肢を選ぶと、画面が真っ暗になって、再び表示された時に1280 x 960の絵がMacから出力されてくるわけですけど、「（拡大）」がつく選択肢では、画面が暗くなることなく切り替わります。これは「（拡大）」無しの方は、Mac側の出力を1280 x 960にしているから、ディスプレイ側でも入力の設定の変更を行うのに対し、「（拡大）」付きの方は、Mac側の出力はあくまでも1920 x 1200なので、ディスプレイ側の設定の変更が行われることがないという差でしょう。

ついでに、その両者でスクリーンショットを撮ると、同じ絵が出力されてきます。「拡大」付きの方は、UI要素が大きくなった1920 x 1200の絵が出てくるんじゃないかと期待しましたけど、そうではないようです。

このようにOS内部では準備ができつつあるようで、それがいよいよ高解像度のディスプレイの搭載により、最近の携帯電話のような細かな文字列の表示がなされるかもしれない時が近づいている、と（噂されているのは、iPhoneのような高精細さはありませんけど、ディスプレイの表示面と目の距離が違うものなので、十分きれいに見えるはず）。

本当に出るか分かりませんが、それが出るなら欲しくなっちゃうなぁ…

パーティクルを原点中心に回転させた時、その回転速度を、外側に行くほど遅くしたい。

この場合、パーティクルの位置をsin, cos使って指定してやればいいんだけど、グリッドをエミッタにしてパーティクルをばらまく場合、そのばらまいた場所の初期位置を（半径、角度）っていう座標に変換してやって、その値を元にしてやればいいんじゃん、って普通に考えた。

そしたら、ある人は、半径だけ取得しておいて、後はパーティクルのIDを元にしてやればいいじゃん、って考えた。

はい、両者を再現したICE Treeです。Aが座標を変換することで処理を行ったもの。BはIDを元に処理を行ったもの。Bの方がシンプルです。





ブール値が格納された配列の中でTrueのものの数を数える

もともと、ある条件を満たしたパーティクルの数を数える、って案件だったようです。で、そうした時、何らかの判定を行って、その条件に対し真が偽かを調べるわけですね。んで、それを全部配列に入れてやる。ここまではいいんです。問題はその後。

配列の中のTrueのものの数を調べたいのだから、Find in Arrayノードを使ってTrueのインデックスのリストを得て、Get Array Sizeノードで配列のサイズを得れば数が出るじゃん、って考えたのだけど、ブール値の配列の中身って、結局0か1が入っているわけで、んじゃ、その中身の値を全部足せばいいじゃん、という解法を見た時、俺って頭わりぃな、と(^^;