実家に里帰り。知らない間にこんなもの ができていました。ガラス越し撮影だぞー、暗いぞー、逆光だぞー、一眼レフ持ってきてないぞー(言い訳)

今年3月にできたばかりのようで、今回が最初の連休…てなこと知ってたら、混雑してるって容易に想像ついたんだけどなぁ。雨混じりにも関わらず、チケット買うのに並び、イルカショーは混雑のため入場できず、お土産コーナーは何を買いたいのだと思うほどの混雑振りでした。でも京都駅から徒歩20分の場所、流して見れば1時間以内で見終わる内容で入場料大人2000円はちと高い気がする。

あと感じたのが、泳ぐ魚を触らせたりなど入場者へサービスしたい営業的思惑と、魚へのダメージを避けなければいけない責任の板ばさみになっている現場。結果あちこちでフラッシュ炊かないで、魚には二本指以上で触らないで(たぶん握るなってことだと)、いるか水槽の壁の内側にカメラ入れないで、現在ペンギンが泳いでいませんという謝罪などをあちこちで叫ぶ職員たち。そんなこと気にしていては水族館なんて見てられないのでしょうが、気になりだすと気になってしょうがない。

ともすれば景観を守れという圧力のせいか(*1)こういった現代的な観光施設の少ない京都なのですが、さて定着するかなぁ。

(*1) 今の京都駅だって結構もめた。市民団体だかなんだかから対案として京都の山を模した形の建造物が提案されましたが、個人的には京都タワー共々やめてくれ状態でした。

期間前半は不安定 だったPSO2 のClosed β。4/26のメンテナンスで改善したものの、残り期間が僅かだったので二日間の延長。それを望む声もちらほらあったし、このままでは不安定だというイメージが付いてしまうのを恐れたからという面もあるでしょうけど、GW予定組んでたスタッフも居るだろうにサービス業は大変だ。

フォース(魔法使い)好きの私としては、やっぱりフォースが楽しい。前作PSU よりもテクニック(魔法)の性格付けが強いのでケースバイケースで使い分ける内容を検討する楽しさも。テクニックを遠隔地で発動できるタリスの存在も大きい。これ使って後方から前衛さんにめがけて回復かけれたら楽しいだろうけど、操作が難しそう。

そういった複雑な事ができる裏返しとして操作に要するボタンが多いのが難点。XBOX360のコントローラでも足りない (´・ω・｀) 対策としてボタンを長押しするという操作があるのですが、これはこれで指が疲れる…

あとスクリーンショットとゲーム中の画質が現時点結構違う。後でスクリーンショットを見ると背景の枝の表現にびっくりすることもあるのですが、残念ながらプレイ中にはその面影はなく。この記事にあるスクリーンショットくらいの画質が通常ゲーム画面でも描かれればキャラクタークリエイトに手間かける甲斐もあるんですが、これも正式版までに改良されることを期待。

あぁ、あと、もうちょっと選べるショートヘアの種類増やしてください。セミロングも欲しいです(^_^;)

C# 4.0でRGB24bitの画像をGrayscale 8bitに変換する必要ができたのですが、調べ方が悪いのか.NET Frameworkに該当する機能は見当たらず、自力変換しているケースがちらほら。

というわけで、以下のように画像データをbyte[]配列に放り込み実験。

JpegBitmapDecoder jpegDecoder = new JpegBitmapDecoder(
    new Uri("4288x2848.jpg"),
    BitmapCreateOptions.PreservePixelFormat,
    BitmapCacheOption.OnLoad);

BitmapSource InputBitmap = jpegDecoder.Frames[0];
int InputStride = InputBitmap.PixelWidth * 3;
if ((InputBitmap.PixelWidth * 3) % 4 > 0) InputStride += 4 - (InputBitmap.PixelWidth * 3) % 4;
byte[] InputData = new byte[InputStride * InputBitmap.PixelHeight];
InputBitmap.CopyPixels(InputData, InputStride, 0);

int OutputStride = InputBitmap.PixelWidth;
if( InputBitmap.PixelWidth % 4 > 0) OutputStride += 4 - InputBitmap.PixelWidth % 4;
byte[] OutputData = new byte[OutputStride * InputBitmap.PixelHeight];

ここではWPF系のBitmapSourceを使ってますが本質は画像データをbyte[]配列に入れることなので、System.Drawing.Bitmapを使う場合は、Bitmap.LockBitsとMarshal.Copyを駆使して下さいませ。

で、安直に以下の二重ループで変換すると、4288x2848ドットの画像を変換するのに約960msec (@Core i7 920)。今回の要件でこの速度はちと不味い。

for (int y = 0; y < InputBitmap.PixelHeight; y++)
{
    for (int x = 0; x < InputBitmap.PixelWidth; x++)
    {
        double intensity =
            0.29891 * InputData[y * InputStride + x * 3] +
            0.58661 * InputData[y * InputStride + x * 3 + 1] +
            0.11448 * InputData[y * InputStride + x * 3 + 2];
        OutputData[y * OutputStride + x] = (byte)intensity;
    }
}

で、半日こねくり回してたどり着いたのが以下のコード。同条件で約50msec。

Parallel.For(0, InputImage.PixelHeight, y =>
{
    for (int InputOffset = y * InputStride, OutputOffset = y * OutputStride; OutputOffset < (y + 1) * OutputStride; )
    {
        int intensity =
            313430 * InputData[InputOffset++] +
            615105 * InputData[InputOffset++] +
            120041 * InputData[InputOffset++];
        OutputData[OutputOffset++] = (byte)(intensity >> 20);
     }
});

• byte[]配列のインデックスを和積(x+y*stride)でなくint値を増加させると、倍速くらいに
• intensityをdoubleじゃなくintで計算するのは10%程度の効果。8bitの結果を得るのに20bitで計算するのは明らかに過剰ですが、別にintに収まっているうちは何bitにしても速度変わらないし…
• 最も効いたのがParallel.For。Core i7 920が4コア+HTなので、4~5倍速はあるかなと思ったのですが、それをはるかに超える上がり方。これがCore2 Duo 2.4GHz上だと20倍速以上7～8倍速程度になるようなのですが、理由がわからない(^^;)

もちろん上記コードが最速とは思っておらず、unsafeやC++を使えばもっと速くできそうですが、Parallel.For使った結果で目的は達してしまったのでやめた次第。

今回はParallel.Forがうれしい誤算だったわけですが、逆にシングルスレッド処理は何をやっているんだという疑問が…

[参考] [.NET]いまさら？Parallel.Forを使ってみた(その1) (GDD Blog 2010/9/25)

[2012/4/26 追記] 同じプログラムを改めてCore2 Duoで走らせると両者の速度差は約7.4倍。それでも2コアじゃ説明付かない速度差ですが。

[2012/4/27 追記] 以下のUnsafeコードだとさらに10%速い(44～45msec@Core i7 920、Parallel.For部分のみの計測)。ここまでする必要があるかどうかはケースバイケースかな。

IntPtr srcData = Marshal.AllocHGlobal(InputStride * InputImage.PixelHeight);
IntPtr dstData = Marshal.AllocHGlobal(OutputStride * InputImage.PixelHeight);
try
{
    InputImage.CopyPixels(System.Windows.Int32Rect.Empty, srcData, InputStride * InputImage.PixelHeight, InputStride);

    Parallel.For(0, InputImage.PixelHeight, y =>
    {
        unsafe
        {
            for (byte* pInput = (byte*)srcData + y * InputStride, pOutput = (byte*)dstData + y * OutputStride;
                pOutput < (byte*)dstData + (y + 1) * OutputStride; )
            {
                int intensity =
                    313430 * *pInput++ +
                    615105 * *pInput++ +
                    120041 * *pInput++;
                *pOutput++ = (byte)(intensity >> 20);
            }
        }
    });
}
finally
{
    Marshal.FreeHGlobal(srcData);
    Marshal.FreeHGlobal(dstData);
}

[2012/4/28 追記] Unsafe版のコードに余計なものが入っていたので整理

[2012/5/1 追記] Strideの計算を訂正

抜いた歯の跡にできた巨大な陥没。痛みはすっかりないのですが、ここに食べ物がしっかりと詰まります(；´Д｀) 抜糸の時、医師からは強めにうがいして詰まったものを取って下さいと言われましたが、

全然取れないし

職場の先輩の話だと2ヶ月くらいで歯茎が埋まって詰まらなくなるらしい。憂鬱だな。

PSO2 Closed β参加者にはすっかりおなじみになっただろう、サーバへの接続不良。前作PSU では正式サービス開始直後に押し寄せたユーザー数を捌ききれず接続不良が大きな問題となりましたが、あれを知っている人にはその再来に見えちゃう。

やっぱりねぇ2月のα2であの完成度だったのに、わずか２ヶ月でβってなんか無理があるなぁとは思ってたんです。しかもかなり機能追加(曰く正式版で予定しているものは全部入れた)してきている。α3ですと言っておけばまだプレーヤーの期待を損ねる度合いも少なかったと思うのですが、開発発表から既に一年、2011年中リリース予定が2012年にずれ込み、営業方面の顔色見るとそうは言えなかったのだろうな。

参加者の中には期間延長を主張する人もいるようですが、この状態でGWに突入すれば結果は見えてるような。開発側が大量負荷のデータを欲していたなら最初からGW挟んだ日程を取ったと思うので、一旦撤収してClosed β2というのが個人的予想。

でもこういう混沌、嫌いじゃない(笑)