Parallel force - パラレル・フォース
～デバッグ

ここ数年、『Atelier of Chiharu - Chiharu のあとりえ』のトップに日記を書き続けてきましたが、すんごく長くなってしまった上に、メンテナンスが煩雑になってしまったたので、日記を『はてなダイアリー』に移転しました。しばらくこのスタイルで日記を進めていきたいと思います。

お気軽にコメントください。（BBS よりは書き込みしやすいかな

Parallel force - パラレル・フォース
～デバッグ

そろそろゲームらしいものを作ろうと、色々弄っていたらぼちぼちバグが出てきました。出てきたバグをぷちぷちつぶしました。

コードを編集していると、相方から「またグレーの画面出してる。グレーの画面そんなに楽しいの？」と言われてます。折角なのでそのグレーの画面を掲載してみます。

隙あればグレーの画面を出す人だと思われているようです。グレーなのは重要じゃないんですが。

ATLACH=NACHA
～初音さん

アトラクナクアの初音さんを描いてみました。資料レスで空で。意外と覚えているものですね。

最近でこそ前髪ぱっつん女子は市民権を得ているように思いますが、当時はその潔い前髪ぱっつんぶりに衝撃を受けたものです。んー。次のゲームのネタは…、二次創作ならやっぱりこの辺かな。

3 連休の中日
～初詣と PSP

日本ファルコムが『零の軌跡』の続編を PSP でリリースすると発表しました。発表自体はずいぶん前だったのですが、PC 版の『空の軌跡 FC』からのファンであり、同シリーズの続編が PSP 版のみリリースされている状況下、PC 版リリースを信じて待ち続けてきた私ですが、ついにあきらめました。PSP に手を出すことにしました！『零の軌跡』買うぞ！PSP 本体も買うぞ！ついでに『とらドラ・ポータブル』も買うぞ！

と、意気込んで地元のショッピング モールやらおもちゃ屋さんやらゲオやらゲーム屋さんやらをはしごしましたが、ことごとく PSP 本体が品切れで泣けました。あまりにも心が折れそうでしたので、とりあえず Amazon で『とらドラ・ポータブル（THE BEST）』を購入しました。ソフトだけ。本体ないのに。なんだろう。できるところから手をつけたつもりが、涙が止まりません。震えるこの両手に、『とらドラ・ポータブル（THE BEST）』のパッケージだけがあります。とりあえず開封だけしてみました。UMD ってこんなサイズなのね。そっとしまいました。

PSP は全国的に品薄みたいですね。ゲオで在庫状況を確認したら、そもそもメーカー在庫自体が空なのだとか。んー。こりゃ PSP 本体入手は 2 月に入ってからだな。

午前中、地元の神社『真清田神社』に初詣してきました。本当は正月 3 ヶ日の間に行こうと思っていたのですが、例によって家族総出で風邪をひいてしまい、本日午前中の参拝となりました。下の子を前向きに抱っこ紐で固定して、でっかいウインド ブレーカーでくるんで行きました。なんだか周りから奇異の目で見られていた気がします。相方からは『笑える。あんた、相当おかしいよ』と言われました。うーん。子供は大喜びだったんですが。

あけましておめでとうございます
～今年もよろしくお願い申し上げます

面白そうなので『わんくま同盟 名古屋勉強会 #16』に行くことにしました。本当は去年の横浜勉強会あたりで参加したかったのだけれど、えーと、時期的に前の会社がアレゲすぎて自分のことどころじゃなかったので。今回はこころおきなく、フリーダムな感じで参加できそうです。まずは地元から攻めていきます（？）

あと、転職先の入社式がありました。ある程度の規模の会社に入ってみると、自分たちがやっていた経営が、いかにままごとだったのかが分かります。ま。そっちは特に長期経営が目的でなかったので、別に注力すべきことがあったという言い訳があるのですが。しかし、差がありすぎるなぁと感じた所存。ま、済んだ話。

今年もがんばろう。

31 歳になりました
～ひとつの区切り

何となく。本当に何となく、なんですが、仕事について人生設計があります。

• 20 代は『なんでもやろう』と思ってました。なので、営業でも経営でも開発でも企画でも、なんでもやってきました。
• 30 代は『方向性をつけたい』と思ってます。他人からの依頼物ではなく、自分発信の何か。少しずつチャレンジを始めてます。
• 40 代は『何かひとつ達成したい』と思ってます。具体的に何になるか分かりません。達成できるかどうかも分かりません。何を持って達成なのかも、よく分かっていません。
• 50 代は『後に続く人に何かを残したい』と思ってます。誰が続くのか、残すべき価値のあるものがそのときの私にあるのか分かりません。

こんな感じのことを、大学卒業して就職したときに考えてました。今も変わりません。さぁ。次いで 30 代。どんな感じになるのかな、と。

そんなこんなで、今年もお世話になりました。来年もよろしくお願いします。

神のみぞ知る世界
～ED 絵

最終話の ED 絵が、MIN-NARAKEN でびっくりしました。アリスソフト、最近いろんなところで見ますね。適度な露出はいいことだと思います。

Parallel force - パラレル・フォース
～バックバッファのフリップ

もー、バックバッファ コピーの設計が気持ち悪くて気持ち悪くて再設計しました。詳細はこちら。

結局フリップに対応しました。多分、これでバックバッファの扱いは完成形です。前よりちょっと速くなっているはず。SSE2 使ってキャッシュ制御して、やっと落ち着きました。『合成バッファ（オン キャッシュ）』『バックバッファ（転送待ち）』『バックバッファ（転送中）』の 3 つのバッファを下記のように扱うようにしました。

1. 全ての分割領域につき、下記を並列処理する。
   • 直前フレームの更新領域が現フレームの更新領域からはみ出す場合、『バックバッファ（転送中）』を『合成バッファ（オン キャッシュ）』にコピーする。
   • 『合成バッファ（オン キャッシュ）』に現フレームを描画する。
   • 『合成バッファ（オン キャッシュ）』を『バックバッファ（転送待ち）』にノンテンポラル転送する。
2. 全ての分割領域の描画完了を待機。
3. 直前フレームである『バックバッファ（転送中）』の非同期転送完了を待機。
4. 『バックバッファ（転送待ち）』と『バックバッファ（転送中）』を入れ替える。
5. 現フレームである『バックバッファ（転送中）』の非同期転送開始。

上記から、直前フレームを表画面に転送しながら、現フレームの描画を描画できるようになってます。以前『表画面への転送を非同期化』と言っていましたが、こんな感じの設計に落ち着きました。

(追記)

会社辞めました。1 月から転職です。私、普通の社員に戻ります。捨てる神あれば拾う神あり、という感じ。がんばろう。

Parallel force - パラレル・フォース
～表画面への転送 (4)

現状のコードをまとめました。詳細はこちら。

裏画面合成処理における分割描画についても、ちょこちょこ最適化しました。SSSE3 を使用したグレースケール画素データのロードと、描画タスクのクリッピングが対象です。Intel Atom だと 1 割くらい速くなっているようです。Core i7 だと。うーん。元が速過ぎて体感できない。描画処理もだんだん落ち着いてきました。

―――あ。イメージのアフィン変換まだだった。忘れてました。そのうち作ろう。

Parallel force - パラレル・フォース
～表画面への転送 (3)

バックバッファのコピー回避でーきたっと。ベスト エフォート型の回避だけど、パフォーマンス上がりました。よかったよかったー。

とりあえず今日はここまで。

Parallel force - パラレル・フォース
～表画面への転送 (2)

先の日記の日付を 2 度にわたって間違える始末。眠いとミスも増えますね。気をつけよう。

さて、バックバッファの扱いをちょっと再考しています。

昨日の日記のとおり、現在、描画処理に『裏画面の合成』と『表画面への転送』という 2 つのステージを設けて、それぞれを非同期処理しています。前者は描画タスクを受け取ってバックバッファに裏画面の合成結果を出力します。後者はバックバッファを受け取って表画面へ転送します。

前者の出力を後者が受け取る形になっているのですが、非同期処理のためには、バックバッファを何とかして双方の処理で同時にアクセスできるようにする必要がありました。バックバッファをロックしてしまっては非同期処理にならないので、バックバッファの多重化は避けられないとして、できればメモリ コピーのオーバーヘッドのないフリップで対応したいところでした。

• 裏画面の合成: 並列処理用に画面分割の上、分割領域ごとに更新領域矩形を管理。
• 表画面への転送: ティアリング回避のため 1 回の StretchBltで描画するため、転送領域は 1 つの矩形として管理。

フリップ不可の説明は図解抜きでは面倒なんで、ざっくり言うと、フリップすると裏画面の合成処理で 2 フレーム目と 3 フレーム目の差分を 1 フレーム目に描くことになり、3 フレーム目を表画面へ転送する際、1 フレーム目と 3 フレーム目が混じったアレゲな絵になって出力される、という事態になります。裏画面と表画面で更新領域の取り扱いが統一できれば、差分だけを表画面へ転送できることになるので、このような挙動でも問題ありません。しかし、『表画面への転送』の転送領域に 1 つの矩形しか採用できないということは、裏画面の更新領域の外接矩形で転送することになり、差分以外の領域も転送されることになります。ですので、2 フレーム目と 3 フレーム目の差分は必ず 2 フレーム目に描く必要があることになります。

昨日の日記でバックバッファを 2 枚用意したと書きましたが、上記から、『表画面への転送』側にコピーを保持するようにしています。コピーは無駄が多いので避けたいと考えています。ふーむ。何か浮かびそうなんで、ちょっと考えます。

Parallel force - パラレル・フォース
～表画面への転送

ティアリング回避に際して、描画の並列度が低下して速度が落ちる件ですが、表画面への転送処理を非同期化することで解消しました。詳細はこちら。

これで、タスク処理、裏画面合成、表画面転送が非同期になりました。単純な fork, join でないので、タスク管理も一苦労です。

裏画面合成と表画面転送の非同期化にあたり、バックバッファを 2 枚用意しました。裏画面合成時の合成バッファはオン キャッシュで動作させるよう調整してますが、合成後及び表画面転送時のバックバッファはキャッシュに対して大きすぎるので、画素データをノンテンポラル ストアすることで非キャッシュ領域として扱うようにしています。…と言っても、StretchDIBits で転送元として参照されるときにはキャッシュに乗ってしまうのでしょうが、ちょっとした抵抗です。

とりあえず今日はここまで。

Parallel force - パラレル・フォース
～ティアリング改善

画面更新時のティアリングが見るに耐えないので、バックバッファを実装しました。詳細はこちら。

表画面への転送を一回の StretchDIBits で処理するようにしたため、以前よりも並列度が低下しますが、ティアリングは軽減しています。裏画面は相変わらず分割描画で並列処理です。ここは崩していません。また、フレーム スキップ実装時に低下していた非同期描画の実行効率を改善しました。結果、CPU コアの多い環境においては、α14 よりも α15 の方が実行速度が速くなっているはず。

タイマーはとりあえずマルチメディア タイマーのままです。今のところ問題なさそう。

ふむ。後は音声のストリーム再生に対応したら、ちょっとしたデモが作れそう。ふむふむ。いい傾向だ。

Parallel force - パラレル・フォース
～FPS とティアリング

パラレル・フォースの過負荷時の処理について、処理落ちかコマ落ちのいずれにしようか迷いましたが、コマ落ちにしました。詳細はこちら。

昨日までの実装では、描画処理後にタスク処理を逐次実行していたのですが、これだとコマ落ちの際にタスクの処理間隔が著しく乱れてしまうため、本日のアップ内容では、タスク処理と描画処理を非同期で動作させるようにしました。えいやーで実装したので、パフォーマンス面でもう少し調整が必要かな、と思ってます。

また、今回のデモではマウス追従型のエフェクトをひとつ追加しました。パーティクル的な動作を実験してみたかったのですが、パッと思いついて作ったらこんな感じになりました。うようよ動きます。

ところで、FPS タイマーにマルチメディア タイマー（timeGetTime API）を使用しているのですが、これ、パフォーマンス カウンタ（QueryPerformanceCounter API）の方が良いんでしょうか。パフォーマンス カウンタの方が精度は良さそうなのですが、使用制限が厳しいかな、と思ってます。当該 API を使えない環境の考慮が必要だったり、CPU コアに計測スレッドを張り付かせる必要があったり。んー。この辺ももうちょっと調整かなぁ。

あー。あと、もうひとつ。FPS タイマーの実装により、手元の環境（Core i7）でのフレーム レートが半分くらいまで落ちたのですが、ティアリングえらいこっちゃな印象です。パラレル・フォースの場合、画面を分割の上、分割単位で非同期描画しているので、ティアリングの発生状況が普通（上から順）ではなくて、ちょっといやらしい感じです。せめてバックバッファ用意したほうが良いのかなぁ。これも要検討です。

作れば作るほど課題が見えてくる。良い傾向…なのかな。

魔法少女リリカルなのは The MOVIE 1st (BD)
～なぜか Amazon から届きました。

えーと。何やら以前、予約してしまっていたようで、宅配で届きました。パッケージ見たときは、やっちまった感満載でした。相方からは「悲しいわ。離婚ね」と言われました。相方の中で許せる範囲というものがあるようです。

• 許せる
  • ガンダム UC (1) (2) (BD)
  • とらドラ (TV シリーズ全巻) (DVD)
  • 化物語 (TV シリーズ全巻) (BD)
  • Fate/Unlimited Blade Works (BD)
  • 空の境界 (1)-(7) (DVD)
• 許せない
  • 魔法少女リリカルなのは The MOVIE 1st (BD)
  • 空の境界 (Box) (BD) ← すでに所有している映像を買いなおす意味が分からないようです。

上記で TV シリーズ全巻というのは「欲しいなぁ」と言い続けて、一気に全巻大人買いしたものです。家計で。大人として問題ある行動のような気もしますが、まぁ。離婚はしていません。意外と人生、やっていけるものです。

映像の内容はとてもよかったです。相方からは「小 3 とか意味不明」と言われました。そうね。私もそう思うわ。

このシリーズ、去年だったか地上波の再放送で A's を見たのが初見だったのですが、なかなか面白くて、何というか『熱い』アニメです。魔法少女とありますが、ヒーローものです。ここまで爽快で、作りが丁寧で、ヒーローものの王道を走るアニメも珍しいなぁと思います。そのあたりにこの作品の価値があるように思います。とりあえず、空中戦は必見です。かっけぇです。

Parallel force - パラレル・フォース
～サウンド周り (2)

とりあえず効果音用のものだけまとめました。

今時、サウンド機能がない環境があるのかどうか分かりませんが、NullDevice パターンで XAudio2 の初期化に失敗する環境でも、実行だけはできるようにしました。まぁ、保険的な意味合いで。

Alice Vocal Collection
～ありぼー買いました。今回、辛口コメントです。

アリスソフト大好き人間としては外せない一品。買いました。トップがアトラクでしたし、好きな曲のオンパレードでしたので。結構楽しみにしていました。

感想。

―――素直にインスト版リリースして下さい。

数日聞き込んでみての感想です。いや、まぁ。意外と男性ボーカルがんばってました。本当に意外でしたけど。これは評価してます。それに比べて、女性ボーカルがなんというかキツい。

これは歌い手だけの問題ではなくて、音を聞く限り、録音とミックスの問題も多分にあると思います。あと、アリス作品リリースされるたびに常々思うところですが、Shade さんの曲は歌うのに向いていない、というか難しすぎる曲が多いように思います。曲としてはすごくカッコいいんですけど、歌にはならないかなぁ。

それでも、Mars だけは面白いと感じました。何というか、声色が『ぴろんぴろん』て音とマッチしていてグッドでした。

最後に歌詞。

アトラクなのに英語とか、ちょっとキツい。Running To The Straight のアレを『ラ』にしちゃったのはどうか。タイトルから想起される日本語を安直に歌詞にしてしまった感じが否めない歌詞が多いように感じました。正直、『王様』？とか思いました。こーそくーどーろのぉー、ほしぃー！みたいな。

ということで改めて感想。

―――素直にインスト版リリースして下さい。

いやホントに。曲はめちゃめちゃカッコいいんですよ。

Parallel force - パラレル・フォース
～サウンド周り。

サウンド周りの設計に入りました。グラフィックスはとりあえず、ちょっと置いておきます。ゲームのエンジンだといっているのにグラフィックス実装ばかり進んで行くのはあまりにもアレだと感じましたので。

過去の経験から、効果音には DirectSound で、BGM には DirectMusic で良いかなー、とか思っていたら、これらの API は Vista 以降では非推奨なんですね。代わりに出てきているのが XAudio と。今だと XAudio2 なのかな。時代は移っていきますねー。

で XAudio さん。ふむ。CoInitialize(Ex) を強要するあたり COM コンポーネントである、と。XBox 360 リリースにあわせてクロス プラットフォームのサウンド API になってるっぽい、と。HAL はないっぽい、と。つまりソフトウェア処理オンリーになったっぽい、と。うん。まぁ、何となく状況は分かりました。ま。DirectSound 関連のドライバ不具合は、DirectDraw のそれと一緒で、尋常じゃないイメージがあったので、ソフトウェア処理のみになったのは素直に歓迎すべき点ですね。

日本語資料が全然ないっぽいのが玉に瑕ですが、まぁ、以前 DX8 リリース頃に DirectShow でキャプチャしてた頃を思えばまだマシかな。英語資料ならあるっぽいし。ちょっと勉強しながら頑張ってみよう。

(追記)

日本語資料がないのは XAudio のようで。XAudio2 については、調べればいろいろと情報が出てきますね。リファレンスも日本語化されてました。これならスムーズに開発できそう。

(追記) (2)

XAudio2 で音が鳴りました。最初、いろいろ試していたときは「ぶぴー」とかよく分からない音が鳴っていたのですが、デバッグしたら「ぴょりーん」という効果音がきちんと鳴りました。良かった良かった。オンメモリ再生については、いったんまとめて、ストリーム再生を検討します。

Parallel force - パラレル・フォース
～文字の描画でけた。

現在公開中のデモの文字描画は結構やっつけ実装でしたが、先ほど、ちゃんとまとめて、まともな実装に修正しました。描画対象のテキストも、イメージ同様にテキストとしてスプライト管理するようにしました。あと、やっつけ実装では加算合成で白文字を描画していましたが、まともな実装ではちゃんとαブレンディングします。

あと、いろいろ実験していて実行速度が気になったので、自前のフォント キャッシュを用意しました。といっても 100 行にも満たない程度の簡単実装です。が、速度に与える影響は大きいようで。新しい文字をスプライトとして構築するたびに GetGlyphOutline API を呼ぶのと、自前キャッシュ探索後に同 API を呼ぶのとでは、後者の方が圧倒的に速く、現状のデモにも大きく影響を与えるくらいの速度差でした。んー。キャッシュって大切。管理は std::map で。キャッシュの上限はとりあえずフォント別で 2048 文字にしてあります。ノベル系ゲームだともう少しほしいかな。ま。この辺はまた困ったときに考えよう。

わんくま同盟
～気になる気になる。

30 歳も過ぎて、なんだかプログラム開発系コミュニティに興味が出てきました。んー。どこかに飛び込んでみようかな、とか思ってます。わんくま同盟、良いのかなぁ。ちょっと考えよう。

録画予約で
～絶望した！

昨日、一昨日と、仕事のことでかなり疲れていて、帰宅後 TV を付けずに寝入ってしまったら、そういうときに限って録画予約ミス！先ほど気づいて愕然としました。ミスした番組は、妹なんかじゃない（違）と、空のおとしものフォルテ、スパロボ OG。素で凹みました。まぁ、空の～はミスしても大勢に影響はないのですが、それ以外はちょっと、ねぇ。

とりあえず今日は凹んだ気持ちを少しでも立て直すべく、昨日 Amazon から届いたユニコーンの episode 2 でも見ようと思います。シナンジュとかシナンジュとかシナンジュが楽しみです。そのためには子供を早く寝かしつけなくては…。

Parallel force - パラレル・フォース
～画面の更新について。

昨日アップしたイメージ中の『WAITING FOR I-SU-CHI』の上方が少しズレています。これは画面を分割描画及び分割更新していることにより、前フレームと現フレームが混在してしまったものです。もしかすると遅い PC の場合、画面更新が垂直同期に追いつかないと、こうしたズレが目立つことがあるかもしれませんが、手元の Atom D330 で 17fps 程度の画面を見ていても気にならないので、多分問題ない範疇だと思ってます。そもそも V-RAM へのイメージ転送に GDI 使ってる時点で、垂直同期がどうのこうのとか、何言ってんだ状態ではあります。経験的に、バック バッファを用意して全画面転送しても、垂直同期に GDI 呼び出しが間に合わなければ、画面はズレます。この辺、GDI アクセラレーションが効いていた時代はドライバの実装に依存する動作だったのだと思います。ズレないドライバも存在したのでしょうが。そうだとすると私はグラボの当たりが悪かったのかな。

そんな訳で、ズレない実装には DirectDraw（DX8 以降の場合 DirectGraphics の 2D 部） の使用が欠かせませんが、以前も書いたように、周辺コードが一気に膨れ上がるため、面倒で対応する気がありません。ロストしたサーフェイスのリストアとか、バック バッファを表画面のサーフェイス フォーマットに合わせないといけないとか、転送ルーチンいくつ書かせるんだとか。DirectX もバージョンが上がってこの辺整備されているのかな。ま。気が向いたらやるかもしれませんが、まずは機能から。

Parallel force - パラレル・フォース
～文字列描画に対応しました。

すっかり忘れていて、さっくり実装しました。文字列描画です。下図の『これはスクリーン 2 です。(ＭＳ Ｐゴシック で表示中)』が描画した文字列です。

GDI の GetGlyphOutline API でアンチエイリアス付きグリフデータを取得して、イメージ スプライトとして管理しています。文字列スプライトとしての管理機能も用意した方が良いかな。もうちょっと整理したらまたデモを更新したいと思います。

Parallel force - パラレル・フォース
～x64 対応しました。

Win64 対応とか書いておきながら公開バイナリは Win32 版のみという、ちょっと寂しい状況でしたので、開発環境を整備して x64 ビルドしてみました。

型の不一致で 4-5 箇所くらい修正しましたが、それ以外はすんなりコンパイルが通りました。修正内容は、データ長を Win32API に渡すあたりで size_t と DWORD の相違で発生しているもので、元々コード自体は size_t が 0xffffffff を超えるケースに対応していたので、static_cast するだけで対応は完了。意外なほどあっさり 64bit 対応完了しました。まぁ。元々、両対応を意識して実装していますので、当然といえば当然の流れなんですけれど。

気になる速度ですが、ボトルネックを SIMD 化していることから、x86 部分が x64 に変わった程度ではぜんぜん変化がありませんでした。んー。これも残念なほど予想通り。まぁ、これで動作確認用ビルドはできるということで、正式リリース時には Win32 / Win64 の両バイナリが公開されることでしょう。

ARM あっせんぶっらー
～最適化とか最適化とか最（以下略）

今週は ARM アセンブラ祭りでした。怒涛の最適化祭り。いい加減疲れてきました。今週末はちょっと休憩。ほんと。つかれたー。

Parallel force - パラレル・フォース
～トランジションくっきりはっきり。

αマスクによるトランジションにステップ数指定機能を実装しました。デモにも反映しました。以前のデモよりもスクリーン切り替えの境界線がくっきりしていると思います。詳細はこちら。

次はイメージの回転か、或いは、ちょっとやってみたいトランジションがあるので、そっちかな。んー。考えよう。

ARM とにらめこー (2)
～最適化とか最適化とか最適化とか最適化とか。

今日は仕事で（お客さんの都合により）ターゲット基板もないのに ARM アーキテクチャ向けの最適化をやってました。案件的にパフォーマンス チューニングが急務でして。

あー。昨日と同じイントロだ。結局、今日はお客さんの都合でターゲット基板を貸してもらえず。かといって指をくわえて待っているわけにもいかず、さらににらめっこ続行。すると見えてくる見えてくる。多重レジスタ ロード / ストアなんてものもありました。これは複数のレジスタを 1 命令でロード or ストアする命令です。これはいける！ということで早速導入。昨日時点で 30% 程度を命令数カットしていたところ、40% 程度カットまで進めることができました。

―――計測は明日。結果ちゃんと出るといいなー。（今度こそね）

ARM とにらめこー
～最適化とか最適化とか最適化とか。

今日は仕事で（お客さんの都合により）ターゲット基板もないのに ARM アーキテクチャ向けの最適化をやってました。案件的にパフォーマンス チューニングが急務でして。

ターゲット アーキテクチャの ARM 命令セットの実行サイクル数を確認後、コンパイラのアセンブラ出力と格闘。ボトルネックの命令数をガリガリ削りました。うん。C プログラムをコンパイラにやさしく書き直して、バレル シフタとポスト インクリメント アドレッシングの適用促進で、ガリガリ削りました。ふむ。命令数 30% 以上を削除。結構削れるものですね。ARM は、乗算とメモリアクセス、条件分岐を除けば、命令数が少なければ少ないほど速くなるアーキテクチャで分かりやすくて助かります。（という理解で命令ガリガリ削ってたんですけど合ってますよね…。この辺、実機ないと怖い）

―――計測は明日。結果ちゃんと出るといいなー。

Parallel force - パラレル・フォース
～トランジションのデモ追加。

デモにトランジション処理を追加しました。αマスクは適当に用意したものですので、エフェクトには当たり外れがあるかも。詳細はこちら。凡ミスもいくつか修正してあります。んー。画素の合成処理が増えてきたので、だんだん SIMD の効果が顕著になってきましたね。

Parallel force - パラレル・フォース
～αマスク トランジションでけたー。

昼過ぎから四苦八苦しながら実装してました。αブレンディングによるエフェクトなので SIMD が良く効きます。例によって SSSE3 まで対応しています。今日はもう夜遅いので、デモをまとめるのは明日にしようと思います。

Parallel force - パラレル・フォース
～アフィン変換その後。

体調不良で今日は会社を休みました。肺炎やってからなかなか復調しません。半日くらい寝てました。

とりあえず、先ほどアフィン変換の線形補間のα値保持バージョンを実装しました。デモに反映しても絵的な変化がないので、公開は次の機会に。

Parallel force - パラレル・フォース
～デモ更新。

イメージの拡大縮小処理の実装をとりあえず完了しました。線形補間の処理負荷が思っていたよりも高く、慌てて SSE2, SSSE3 に対応させました。むー。アフィン変換の線形補間は SSE2 には荷が重いですね。SSSE3 が使えないと、パック、アンパックの嵐であまり速度が上がりません。線形補間処理を _mm_maddubs_epi16 で高速化するために、画素の補間精度を 6bit にしました。座標計算自体は小数桁 16bit の固定小数で計算し、補間時に 6bit 精度に落とすようにしています。まぁ、イメージを 64 倍以上に大きくしないと限界精度が分からないくらいの精度です。ゲーム用なら問題ないでしょう。

ということで、当該処理をデモに反映しました。マウス操作に追従するスプライトを拡大縮小するようにしてあります。1 回の拡大縮小ごとに、線形補間と最近傍補間が切り替わるようになっています。詳細はこちら。

あー。デモには直接関係ないですが、α値付きイメージの線形補間がまだでした。んー。その実、こっちのが大事かな。時間見つけてやっておこう。

Parallel force - パラレル・フォース
～動物園とアフィン変換。

今日は私と相方と子供二人で、名古屋の東山動物園に行ってきました。

最近、絵本やテレビで動物に興味を持ち始めた上の子供に、本物の動物を見せてあげたいと思って出かけました。が、なかなか計画通りとは行かず。まず昨夜、子供がなかなか寝付かず、その日に限ってすげーしぶとくて、この時点で心が折れそうになります。2 歳児の就寝時刻が 23 時て。そのため今朝起きてしばらくするとすでに眠そうで。ただ、本人は動物園に行く気まんまん。バス & JR & 地下鉄で出かけたのですが、バスでテンション マックス！次いで JR で飽きてきて、地下鉄ではいよいよぐずり始めました。動物園ではそれなりにテンションが高かったのですが、2 時間持ちませんでした。移動も長かったし仕方ないかな。午前中から入園して、12 時過ぎにはおべんと食べて帰り始めました。0 歳児もいたので、なかなかに時間制限がきついです。帰りはマックス眠かったようで、ぐずりも最高潮。電車やバスで暴れなかったのがせめてもの救い、かな。

帰宅途中でバスを降りてからは、最寄りのスーパーのスガキヤでソフトクリームを食べました。家に帰ったときには、上の子は相方の腕に抱かれながら、いつのまにやら、お昼寝あそばされてました。それに気づいたとき、思わず相方と笑ってしまいました。

先ほど、上の子が就寝したのですが、眠りに入るときに今日のことを聞くと、どこに行って何を見たかをちゃんと覚えていたようで、少し感心しました。お気に入りはアフリカ象だったようで、象が餌を食べるマネをしながら「ぞーさん、ぱぉーんて（上の子談）」などと話してました。

さて、そんな子供との微笑ましいふれあいもありつつ、先ほど拡大縮小のアフィン変換を実装しました。とりあえず C++ (非 SIMD) 処理かつ最近傍補間でさっくり実装しました。パラレル・フォースでは並列処理のため、画面を分割描画しているのですが、拡大縮小に際して分割領域間で破綻のないように、少しだけですが気を使いました。でもやっぱりアフィン変換には線形補間が欲しいよね。ということで線形補間の実装と SIMD 対応ができたら、またデモに反映したいと思います。

Parallel force - パラレル・フォース
～SSSE3 でフェード完了。

実装したらうまくいったようです。偶数版は SSE2 よりも 2 割くらい速い、かな。奇数版は SSE2 とどっこいです。デモのスプライトの重ね合わせのフェード値が奇数に偏っていたため、効果確認用に、Z オーダー順に奇数偶数と交互に設定するようにしました。微妙な修正なので目視確認は難しいかも。Core i7 で確認した限りでは、デモの動作速度は平均値的に 1 割程度速くなってます。詳細はこちら。

Parallel force - パラレル・フォース
～SSSE3 乗加算、惜しい！

_mm_maddubs_epi16 を使用したαブレンディングですが、再考察したところ、0-256 は無理ですが、0-128 ならいけますね。α値が 0 のケースはそもそも上流で描画をカットしていますし、またα値が 128 (=256) の場合は上流で単純転送に振り分けています。つまり、0-128 の範囲でブレンドする場合、実際のブレンド関数に渡されるα値は 1-127 となります。これなら当該組み込み関数の乗数として収まる範囲、と。

んー。惜しいなぁ。精度 1/2 かぁ。符号なし演算なら文句なしに採用できたんですが。むー。

(追記)

どうにも悔しかったので、_mm_maddubs_epi16 で高速化しつつ精度を落とさない方法をもう一回考えてみました。

α値が 0-128 (1-127) の範囲であれば、当該組み込み関数が問題なく導入できることは上述のとおりです。この条件は 0-256 (1-255) 精度のα値に対して、下位 1bit 分の精度を捨てることと同義です。しかし、α値の全てのケースで精度低下が発生するわけではありません。0-256 (1-255) 精度でも、α値が偶数の場合は下位 1bit が必ず 0 となるため、当該ビットを切り捨てても精度問題が発生しないことになります。

このことから、α値の精度を 0-256 (1-255) の範囲で保つことを前提に、問題をα値が偶数の場合と奇数の場合に分けて考えます。

※以降、式中の変数は全て整数、かつ演算過程で発生する小数桁は発生時点で全て切り捨てとします。

成立させたいのは下記の式で、_mm_maddubs_epi16 利用のために dst と src に対する乗数（下記の 256 - alpha と alpha に相当）を、符号付 8bit 整数（正の数: 0-127）の範囲に収める必要があります。

dst' = (dst * (256 - alpha) + src * alpha) / 256
※alpha は 1-255 の範囲

α値が偶数の場合、下記の式が成立します。

dst' = (dst * (128 - alpha / 2) + src * alpha / 2) / 128
※alpha は偶数かつ 2-254 の範囲

上式において、dst と src に対する乗数である 128 - alpha / 2 と alpha / 2 はいずれも 0-127 の範囲に収まっており、符号付 8bit 整数で表現可能です。これで下線部に _mm_maddubs_epi16 が適用できるようになります。ここまでは想定どおり。

次。

α値が奇数の場合、下記の式が成立します。

dst' = (dst * (128 - alpha / 2) + src * alpha / 2 + (-dst + src) / 2) / 128
※alpha は奇数かつ 1-255 の範囲

下線部が偶数との相違点です。上式において、alpha / 2 は必ず端数 0.5 が発生しますが、上式は全て整数演算につき、これが切り捨てられます。この端数を拾うため、dst には負の方向へ 0.5、src には正の方向へ 0.5 を掛けて（2 で割って）補正を加えています。

んー。dst と src の乗数が 0-127 の範囲に収まっておらず、また、SIMD 化にはちょっと数式が複雑ですね。変形して SIMD を適用しやすくしましょう。

dst' = (dst * (128 - alpha / 2) + src * alpha / 2 + (-dst + src) / 2) / 128

dst' = (dst * (128 - alpha / 2) + src * alpha / 2 + (dst + src) / 2 - dst) / 128

dst' = (dst * (127 - alpha / 2) + src * alpha / 2 + (dst + src) / 2) / 128

とできました。すると、

dst' = (dst * (127 - alpha / 2) + src * alpha / 2 + (dst + src) / 2) / 128
※alpha は奇数かつ 1-255 の範囲

上式において、dst と src に対する乗数である 127 - alpha / 2 と alpha / 2 はいずれも 0-127 の範囲に収まっており、符号付 8bit 整数で表現可能です。これで下線部にそれぞれ _mm_maddubs_epi16 と _mm_avg_epu8 が適用できるようになりました。

ここまででなんとなく、_mm_maddubs_epi16 がαブレンディングに使えそうな雰囲気になってきました。まぁ。上式が間違っていなければ、の話ですけどね。今日は眠いので、明日にでも実装して答え合わせをしてみます。合っていたら正式採用です。

―――んー。えらそうに説明しちゃったけど、ちゃんとあってるのかなぁ。ちょっと不安。

Parallel force - パラレル・フォース
～次はアフィン変換？

次はアフィン変換かなー。よく使いそうですし。

ところで SSSE3 の _mm_maddubs_epi16 がいまいち使えませんでした。αブレンディングに組み込めないか検討したのですが、乗数が符号付バイトということで、-128 ～ 127 の範囲しか使えません。これが符号無ならαブレンディングに使えたのに…。悔しかったので、試しにα値を 0-256 から 0-64 に縮小して当該組み込み関数を使ってみたところ、Core i7 にて 220fps。ここまでα値の精度を落とすと、重ね描きに影響が出そうなので、やめておきます。数枚重ねる程度なら目視確認できませんが、パーティクルでたくさんスプライトを重ねるとマッハ バンドの出現が想定されます。ま、この速度は幻の数値ということで。

Parallel force - パラレル・フォース
～デモ更新。

高速化の効果が大きかったので SSSE3 を導入しました。動的切り替えにより、非サポート CPU では SSE2 で動きます。また、機能面では複数スクリーン処理を追加しました。デモには、2 つのスクリーンをクロス フェードするようにしました。一方はこれまでのデモの描画内容通りのスクリーンで、もう一方はイメージ 2 枚を適当に移動させるスクリーンです。詳細はこちら。

手元の Core i7 では並列処理かつ SSSE3 導入で、C++ 素直版との速度比が 10 倍を超えました。17fps : 200fps です。並列処理って素敵ね。

Parallel force - パラレル・フォース
～SIMD まだまだ。

公開中のデモについて、Atom や Core i7 では SSE2 適用でとても高速化するのですが、Core 2 であまり速くならず、何故だろうとインテル最適化マニュアルを紐解いてみると、あらなんと。Core 2 では XMM レジスタを使用した演算が、それ以前のアーキテクチャよりも高速化されているものの、パック、アンパック、シャッフル、シフトはその対象外だったのですね。BGR イメージの描画処理では、アンパックとシフトを使いまくりですので、なかなか速度が上がらなかったと。

んー。ためしに SSSE3 の _mm_shuffle_epi8 を使ってみました。4 画素あたり 3 回分のシフトとアンパックが、1 回のシャッフルに置き換わりました。

―――すると、なんということでしょう。（サザエさんの声で）

Core 2 で、あれだけ高速化の効果が薄かった SSE2 版に比べて、SSSE3 版ではさらに数割のスピードアップが確認されました。Core i7 においても、高速化が確認され。216fps になりました。すごいなー SSSE3。て、逆か。しょぼいな SSE2。

デモについては、もう少しグラフィックス系に手を加えて、また新しいものを近々公開したいと思います。

(追記)

よくよく確認したらシフトは高速化対象でした。

最適化、そればっかり
～お仕事の話。

これまで仕事で、x86, PPC, MIPS 向けの最適化の業務をこなしてきましたが、その延長で、このたび ARM（非 Cortex）の最適化業務にどっぷりつかっています。

最適化を行う場合、まぁボトルネック検証とかごくごく当たり前のことは当たり前にやるのですが、それ以外に重要なのが、ターゲット CPU のアーキテクチャとアセンブラを覚えることです。

C++0x を一巡りするよりも、1 種類の CPU アーキテクチャの把握とアセンブラの習得は楽チンです。ここでいうアーキテクチャとは、まぁ、大雑把なもので、汎用レジスタが何本あるかとか、C 言語で表現できない CPU 固有命令の有無とか、L1, L2 キャッシュの有無とかサイズとか way 数とか、FPU の有無とか、C 言語で表現可能な演算の CPU 命令有無とか。レジスタ数は、C 言語で局所ループに使用する自動変数の数の調整の参考にします。キャッシュは 1-way あたりのサイズを超える領域の扱いの調整の参考にして、ストリップ マイニングとかループ ブロッキングの導入を検討したりなどします。大抵のコンパイラは -S オプションで C/C++ コードを asm 出力してくれるので、アセンブラを覚えてからは、コンパイラの最適化コードとにらめっこです。

ARM アセンブラは 1 命令あたりの処理密度が高く、その中でも特に面白いなーと思ったのは、

• 累積加算命令
• シフト演算の合成
• 条件分岐フィールド
• 多様なアドレッシング

です。これらがパズルのようで面白く、コンパイラの気持ちになって C 言語のコードを最適化していくと、狙った処理のコードサイズが半分以下になったりして、思わずにやりとしています。

累積加算は d = a * b + c を 1 命令で実現するものです。x86 だとメモリ アドレス デコーダがこれをやりますね。C 言語で乗算と加算が入り混じる場合、うまく計算順序を調整してやると、コンパイラの最適化コードで当該命令が出力されるようになります。

シフト演算の合成は c = a | (b << 8) など、定数によるビットシフトを含む単純な演算を 1 命令で実現するものです。ARM では整数演算にまつわるほとんどの命令（全てかどうかは知らない）の末尾オペランドにて、定数のシフト演算を組み込むことができるため、C 言語でビットシフトとその他の整数演算が入り混じる場合、うまく（以下略）。よく把握していませんが、ALU にシフタでも接続されているんでしょうか。

条件分岐もなかなか特色があります。ARM は全ての CPU 命令に条件分岐フィールドを持っており、全ての命令を条件付実行することができます。条件分岐フィールドによる分岐は逐次実行なので、ジャンプ命令と比べて CPU のパイプラインを汚さないというアドバンテージがあります。ただし、条件分岐フィールドが空の命令よりも 1 命令あたりの処理時間がかかるので、連続して 3 命令を超える条件付命令はコンパイラは出力しないとか。これも、うまく（以下略）

アドレッシングで素敵だったのは、ポインタの参照剥がし時の後置インクリメントなど、ポインタ値の副作用を伴うロードとストアが 1 命令で処理できることです。これも、うまく（以下略）

今まで、いくつかの種類のアセンブラ コードとにらめっこしてきましたが、冒頭で挙げた CPU 向けのアセンブラの中では、ARM アセンブラが最も読みやすいと感じています。CPU によってカラーがあるものですね。

(追記)

非 Cortex 系の ARM には整数除算がなく、当該機能はソフトウェア処理されるというすばらしいパフォーマンス上の問題があります。除数が固定できるなら、無理やりにでも乗算化するのが鉄則のようです。

世間の親御さんもすなる
～幼稚園の申請などしてきました。

うちの上の子が来年から幼稚園ということで、その申請に行ってきました。我が家の周辺は幼稚園や保育園のそれなりに激戦区らしく、夜から幼稚園の前に並んできました。私が並んだときにはすでに 50 人ほど並んでおり、これって近所迷惑だよなぁとか思いながら、4 時間ほどを並びぬいて、子供の幼稚園の席をゲットしました！肺炎で病み上がりだったのですが、たまには親らしいことを、と気張って出かけたのでした。並んでいると、私の左右は女性陣で、ぽーっとしていた私に声をかけてくれて、世間話などをほどほどにしてました。女性と話をするのはちょっと苦手です。なんだか、相手に気を使わせてばかりいる気になってしまって。

みーまー 7 巻まで来ました。衝撃の展開でしたが、相変わらず地元ムード満載ですね。吹上（ふきあげ）とか今池とか、久屋（久屋大通から？）とか。あー、平針（ひらばり）なんてのも出てきました。以前そこで免許更新しました。

そして体調をまた少し崩したのでした。

（追記）

ところで、うちのサイトって『Chiharu のあとりえ』と『Atelier of Chiharu』のいずれが浸透しているんだろう。ふと気になりました。

Parallel force - パラレル・フォース
～デモを公開しました。

これまでの実装実績のまとめとして、デモを公開しました。詳細はこちら。んー。時間見つけてさっさとゲーム作りに移行したいです。がんばろ。できる範囲で。

サイトの構成
～微妙に更新しました。

すんごく微妙に、なんですが、サイトの構成を更新しました。新規追加のパラレル・フォースのところはまだ何も置いてないです。一度計画とかまとめたいです。某プロジェクトの再開はまだですが、自分ひとりでもできる何かをやりたいなぁ、と思ってます。今のところ思ってるだけですけど。

ところで、改めて過去の日記を読むと、最近の日記は長文ですね。絵とかないと、文字で黒過ぎでした。

CLANNAD
～忘れた頃にメインヒロイン

ということで渚を描いてみました。かなりオリジナル風味になりました。似せる気がないのはご愛嬌。多分、高校生ならこんな等身が妥当と思います。

―――イメージでかっ！

CSS デザインの都合上、イメージは幅 500px で統一しているのですが、しかしこれは縦長イメージには向きませんね。なんだか本文に対してすごく大きなイメージ データになってしまいました。

改めて描くと、ヒロインの髪の毛の長さが微妙だなとしみじみ。んー。この髪質でこの長さって、外向きに跳ねまくって仕方ないと思うんですけれど、どうなんでしょう。毎朝、超ブローしてるんでしょうか。手入れのはずが、かえって髪の毛が痛みそうです。

ためしに原作に忠実に描こうとしてみました。

―――5 秒で挫折。

あたりを描いた時点で心が折れました。このバランスは描けないですわ。ある意味神バランスというべきか。鼻が目の高さまで上がってきているところとか、Kanon の頃などは口は目じりの高さまで上がっていましたね。CLANNAD でもアングルによってはすごい位置にありますけど。ちょっと福笑い的な要素がありますね。

んー。学生時代からそうなのですが、この人の絵には辛口コメントになりますねー。

（追記）

『みーまー』に稲沢発見。これはばっちり名鉄（違った）JR ですね。

嘘つきみーくんと壊れたまーちゃん
～3 巻読んでます。

文章がライトなので、結構速く読めますね。んー。ここまで読んで一言。

―――岐阜過ぎ。

1 巻あたりでもそう思ったけれど、今度は確信に。畜産センターとか金華山（本文中に名前は出てきませんが多分そう）とか。人名にも地名（というか駅名？）が入っていますが、出自が JR、地下鉄で南は名古屋止まりなあたり、岐阜人さくれつですね。一宮（いちのみや）とか枇杷島（びわじま）とか伏見とか。まぁ、一宮は名鉄もありますけど。一緒の駅なので。

でも、もともと知ってる名前だと、漢字の読み方違うだけでかなり読みにくいですね。んー。言葉遊びきわまれり？まぁ、面白いからいいんですけれど。

まいこぷらずまー
～あと 2 週間。

マイコプラズマ肺炎の完治まであと 2 週間程度だそうです。とりあえず咳き込んだときの血とかなくなってきました。14 日間分の抗生物質をまとめて処方されました。これまで『クラリス（錠剤）』→『ジスロマック（ボトル）』→『クラビット（錠剤）』と推移してきましたが、これで最後になりそうです。ということで、処方箋もって調剤薬局に行ったら、なんだか薬剤師の方に驚かれました。14 日間分の抗生物質が処方されることって、普通はないことなのだとか。その発言にこちらもびっくりだったりするのですが。

嘘つきみーくんと壊れたまーちゃんの 2 巻を購入しました。前回いろいろ言ってましたが、コピーだろうが何だろうが面白いものは面白い。2 巻で文章が少しずつこなれてきてますね。1 巻はまだ小説を書きなれていない感じが出ていてどうかと思ったのですが、2 巻でこのクオリティなら何とか安心して読めます。

えー。私、文章の書き方には厳しい方らしくて、いくつかの小説というかライトノベルは日本語がアレで読めませんでした。読めなかった小説の代表格は『とある～』です。評判が良さそうだったので 6 巻くらいまで買いためて読み始めたのですが、我慢に我慢を重ねて 4 巻くらいで挫折しました。その後、全巻ブックオフに丁重に納品されました。えーとセンスが合う合わない以前の問題で、日本語がアレにもほどがありました。トライしたのは一昨年だったかな。懐かしい思い出です。

懐かしい思い出といえば、中学生の頃に泥沼の三角関係をやったことがあって、その相手のあだ名が『まーくん』と『みーちゃん』でした。だからどうということでもないんですけど、先の小説。そのせいで登場人物の名前が読みにくくて読みにくくて。

―――あー。さらにどうでもいい話で。結婚相手からは『ちーちゃん』と呼ばれてました。『Chiharu』の『ちー』です。本当にどうでもいい話。

嘘つきみーくんと壊れたまーちゃん
～読了しました。

まいこぷらずまーはなかなか治りません。再診の結果『レントゲンに写る肺の影は薄くなったが、範囲が拡大している』そうで、まだまだ抗生物質を絶賛投与中です。咳き込むと血のにおいがするとか、たんを切ると洗面台に広がる赤色、とか、そろそろ卒業したいです。とりあえず、一番ひどい時期は脱したようで、明日から職場復帰。完治するまでは様子見出社です。

さて、タイトルのとおりで、衝動買いして読了です。んー。まぁ、悪くはないです。3 年前に初版が出ていたことを考えると、まぁ次第点じゃないでしょうか。かなり、偏った作家の影響を受けているな、と感じる習作という雰囲気。悪くはないです。2 巻を買うのはちょっとためらわれます。少し考えます。

創作活動について、作る側の人間を注意深く観察すると、『コイツはオリジナルだ』と感じられる人間と『コイツはオリジナルにあこがれるコピーだ』と感じられる人間の 2 種類に分けられると、私は常々感じています。ちなみに私は後者です。即答です。前者を気取れるほど、オリジナリティにあふれる人間ではありません。説明が面倒なので、結論というか極論を言うと、前者でさえ何者かのコピーであるにもかかわらず、後者に至ってはコピーをコピーしちゃって、どこまで劣化の一途をたどるのか、とかそういう話。『見る力』と『作る力』において、『見る力』を発揮する先がすでに何者かの作品に引きずられていたりすると、後者の印象を強め、そうではない環境、或いは自身の経験や体験に基づいていたりすると前者っぽい創作物に感じられると、そういうことです。

この作者、後者だなーって感じました。あー、でも。悪いことじゃあないんでしょうね。多分。よくわからないんですけど、最近そういう作家さん、というかそのように感じられる作家さん、本当に増えてるように感じます。

―――あーでも、これ。短期的および中期的な話であって、長期的な話においては、これは当てはまらないですね。

今のミステリー作家が、それこそ初期のミステリー作家の影響を一切受けずにミステリー書けるわけでもなく、また、これを批判する人間もいないでしょう。源氏物語にインスパイアされて作品作って、それを盗作だという人もいないでしょう。

結局のところ、私は年をとってきたと、そういうことなのかもしれません。まぁ。それを否定的に捉える気もないですけど。少しずつではありますが、感性だけでなく、経験で生きるようになってきている自分を実感するところです。

(追記)

あら。途中から日本語がおかしいですね。説明もなく、『後者』を悪いものとして扱ってる。んー。私自身、本能的にそう思っているんでしょうね。きっと。

肺炎でした
～まいこぷらずまー

症状がぜんぜん改善しなかったため、先日、改めて内科を受診したところ、血液検査とレントゲンから肺炎を患っていることが判明。肺炎なんて、風邪の重症化で中学生のころに一度やったきりで、久しぶりです。どうりで息するのが苦しかったり、胸が痛かったりするわけだ。発熱も続いていたし。

診察の際「入院をお勧めしますが自宅療養もできます。どちらを希望されますか？」と聞かれたので、まぁ、マイコプラズマ肺炎なら学生時代に妹 (x2) が患っているのを見ているので、自宅療養でよかろうと、後者で即答しました。ただ、仕事は休んだほうが良いらしく、水曜日から週末までは休むことにしました。

そして今日、経過報告で受診したところ、症状が改善しているのでこのまま様子を見ようということになりました。週明けの再診で再検査して、全快していればやっと職場復帰という流れ。あー。やっと出口が見えてきた。ふー。相方から「あんたのあだ名『入院』な」と言われて、以来「この『入院』がっ！」とののしられる日々もそろそろ終わることでしょう。

―――えーと、仲睦まじい夫婦ですよ。

風邪なのか！？
～多分そう。パラレル・コールドとかそんなかんじ？

ここ数日、連日、体調不良で会社を休んでいます。もともと軽いのど風邪のようで、子供からうつったようだったのですが、休み始める前、1 週間程度ずっと症状がひどかったので医者に見てもらって薬を処方してもらった翌々日の夜からダウン。38 度後半から始まり、38 度前半、37 度後半、37 度後半、そして今日やっと 36 度台です。頭痛や体中の痛み、寒気がきつく、寝てばかりの毎日です。家族の様子を見ても、どうもうつったのど風邪は熱の原因ではなさそう。のど風邪の症状が治まることなく発熱が来たので、多分 2 つ以上の病気に同時に感染したのかな、とか思ってます。

仕事の方は受託案件の契約更新月なので、あまり寝てばかりもいられません。明日はちゃんと出社しよう。今日はとりあえず寝よう。昨日も朝は 36 度台をマークしたのですが、すぐに 37 度後半までぶりかえしたので。油断できないっす。あんまし体強いほうでもないので。

(追記)

自社製品の方は社長判断で、発売延期にしたようですね。土壇場で LCIE 関連で問題が発生したものです。修正版の実装は完了していて、あとは検証。がんばれ検証スタッフ！

日常会話
～ちょっと笑ったこと

さっき相方と車で話をしていて笑ってしまった語感。

• インドって三角形のとこ？
• アフリカは島国。

日本という国は大丈夫なんだろうか。

(追記)

忙しくてなかなか手をつけられていないパラレル・フォースですが、ワーカー スレッドのスリープ時間を調整したら、Core i7 で 195fps までいきました。

ボトルネックは表画面への転送じゃなくてスリープだったみたい。これまで毎フレーム必ずスリープしていたところ、試しにスリープを外すと 200fps を軽く振り切ってしまいました。しかし、これだと今度はワーカースレッドが CPU を占有しすぎてメイン スレッドの UI 処理が遅くなるので、これは不採用。間をとって、20ms 以上処理したら 1 回は必ずスリープするよう調整しました。

まぁ、でも。今は画像処理だけですが、音楽を鳴らすようになると、またバランスも変わってくるかもしれません。

自社製品
～デバッグ終わったー！

バイナリをフィックス！あとは社長が販売開始手続きとプレス リリースを滞りなく打てばよし。あと少しー。轟け！自社製品！！

振り返ると Office2010 の AppV 対応が一番きつかったです。意外と競合他社、この存在のやばさに気づいてないんじゃないかな。Wow64 印刷したときの UI ドライバの挙動のアレゲっぷりとか。デバッグ中に気づけてよかった。β版でもちゃんと対応してます。

マニュアル作成
～ドラフトでけたー！

はー。疲れました。Microsoft Word をここまできちんと使い倒すことってなかなかないと思います。今回、表紙における微妙なレイアウト調整以外は、すべてスタイルで書式設定しました。Adobe FrameMaker 使ってる気分でした。つかれたー。

あとは、会社のみんな。回覧チェックがんばれ。

マニュアル作成
～夜なべです。

PDF ドライバの Office アドインはとても便利です。しおりや相互参照が PDF に反映されるのはとても感動的だと思っているのですが、なかなかそれをうまくプレゼンできている製品は少ない。口下手な技術集団としてできることといったら、『成果で示すこと』ですので、自社製品の Office アドインを活かしたマニュアルを作ろうと。そういう話になりました。しました。

思い立ったが吉日で、自社製品のマニュアルの PDF 版を作っています。

毎日、その日の受託業務が終わってから、深夜までせっせこせっせこ作ってます。事前に XHTML 版（公開中のマニュアル）を検証スタッフにドラフト試作してもらっていたので、コンテンツには苦労していないのですが、Office アドインを活かしたマニュアル作りを目指していて、Word2007 用のスタイル作りに結構時間がかかりました。製品マニュアルということで、見栄え上 Word っぽさを解消するのに気を使いました。結構きれいに仕上がってきていると思います。んー。我ながら Word とは思えない出来だと自画自賛してます。

現状で冒頭とインストール、アンインストールの章まで書きました。あー。土日返上だー！あとは時間との勝負。8 月末発売に向けてがんばるよ！

(追記)

うわー。スカイコムもこのタイミングで新製品のプレスリリースかぁ。ISO 準拠を前面に出してくるとか、結構うちと被ってるなぁ。ふむ。ま。価格の差もあるし、旧バージョンだけど生成される PDF サイズと品質の社内比較も確認しているし、うちの敵じゃないな。（強がり）

ま、あちらはあちら、こちらはこちらでがんばるですね。

スカイコムは、ソースネクストの初代『いきなり PDF』の開発元です。諸般の事情で、現行バージョンは違いますが、市場のすそを広げたという意味では PDF 業界の功労者でもあり、価格競争の激化という意味では、ちょーっと禍根を残した会社でもあります。うん。正直、禍根残しすぎです（涙）

Ghostscript の PDF とか
～ネガキャンじゃないんですけど。

PrimoPDF とか CubePDF とか Ghostscript 使ったフリーの PDF ドライバ多いですけど、Acrobat で ISO 系のプリフライトかけると、PDF が壊れてるって表示されます。まぁ、昔っからなんですけど、これって大丈夫なんだろうか。とか、ビジネス的にはともかく技術的にはその辺が自社製品の開発動機になってます。

まぁ、一般にはその辺のフリーウェアで運用上問題出ていないんでしょうけれど、技術的にそれで PDF 名乗って良いのか、とか。それで ISO とか言っちゃって良いのか、とか。

以前、知る人ぞ知る PDF 専門ソフトハウスで PDF ドライバの設計とコードの半分くらいの実装をしていたことがあり、そのころ、お客さんからの問い合わせで『他社ツールで作成した PDF が開けない（作成時点で PDF が壊れてる）』とか『他社ツールで（略）で Acrobat のバージョンあがったら PDF が開けなくなった（互換性のない PDF が作成されてる）』とか、そういう話をわんさか聞いていたこともあり『将来にわたり互換性が保証される PDF』というやつをサポートする製品が、フリーにしろ OSS にしろプロプラエタリにしろ、Adobe Acrobat 9 以外にないなーとか、そんな感慨と憤りが、モチベーションです。

（繰り返しますが、あくまで技術上のモチベーションで、ビジネス的にはあんまし関係ない話）

尚、当時、壊れた PDF で多かったパターンは下記のとおり。

• 相互参照テーブルが壊れている（なんで壊れるんだろ。難しい処理じゃないのに。）
• コンテンツストリーム中でしか使用できないはずの、イメージ辞書の省略表記を間接オブジェクトで使用している（仕様書をどのように誤読したらそうなるのか…）
• 埋め込みフォントが壊れている（フォント関連の実装は難易度高いですからね）
• ストリーム開始記号直後の改行コードの配置パターンが規格外（論外）
• 名前オブジェクトの大文字小文字を間違えている（論外）
• 間接オブジェクトが循環参照してる（サードパーティ製のパーサの多くは無限ループ後、リソース不足で落ちる、かな。）
• エンコーディングに Identity-H/V を使用しているにもかかわらず、ToUnicodeCMap が存在しない（厳密には壊れてませんが、文字のコピペとか検索はできない）

―――今でもまだいくつか見かけますね。

この話、意外と笑えなくて『サードパーティ製ツールで生成された PDF の品質』って重要で、お客さんの中では帳票系の PDF 生成ミドルウェアがバグっていて、Adobe Reader のバージョン上がったら PDF 開けなくなって、オンライン取引業務に支障が出た、って話も聞いてました。この場合は、その時点の業務への支障でしたから、運用とお金で解決できたようですが、もし e 文書法に則って、法的根拠となる文書を PDF 保存していてたら。そして、それがもし『互換性のない PDF』だったりしたら。法的根拠を示すべきタイミングで、PDF が開けなかったら。結構ぞっとする話だと思ってます。

自社の新製品（初製品）をよろしく！
～えーっと。自社製品の告知です。

素性が割れるのが、自分的にと会社的にどうかということがあり、これまで書くか書くまいか悩んでいましたが、書いてみました。

趣味のサイトでの告知にどれほどの効果があるのかわかりませんが…、プレスリリースを発信したものの、いずれのニュースサイトにも採用されなくてちょっと凹んでいる、ということもありこんなところで告知してみています。ま。多分に弊社側の不手際だと思うんですが。開発スタッフばかりの集団ですので、露出というのがどうも苦手っぽく。

これまで受託開発で多忙を極める状態でありましたが、水面下で少しずつプロジェクトを進めてきた甲斐があり、会社発足当初からの目標の一つであった『自社製品』の第一弾を発売する運びとなりました。ちょっと感無量です。

―――願わくば、まずはβ版（無償評価版）が多くの人々の手に渡りますよう。

CLANNAD
～読了。

いや、まぁ。ずいぶんと前に読み終わっていたのですが、存在ごとすっかり忘れていました。

よかったです。ふつーに。10 代のころに読んでいたら、また印象がぜんぜん違ったのだと思います。

朋也と渚の関係とその家族と、うちの夫婦と両親同士の関係がよく似ていて、何といいますか、自分の過去克服したことを改めて見せ付けられているようで、まったく感情移入できませんでした。ありていに言えば、私の実家（両親離婚して元家族がちりぢりですので今はもうありません）は幸せとは縁遠い家庭でしたので。当時のことを今はもう多くは語らないですけれど、まぁ、何というか苦いだけのお話でした。

そういう私自身の個人的な都合との相性を除けば、とてもよく描かれた作品だったと思います。

ただ、このライターさんの作品に共通して言えることは、この人の作品における主人公はテーマであり、登場人物は、主人公すら例外でなく、それを引き立てるための脇役である、ということです。それが許容できるようであれば、この作品は良作と受け取れるものだと思います。私は良作だと思いました。

(追記)

―――あ。そうそう。第 2 子が誕生してます。女の子です。生まれて 4 ヶ月くらいになります。美人らしいです。私の妹も美人らしいので、そちらに似たようです。

オオカミさん
～第一話を見ました。

狙いすぎかな。えーと、超電磁砲（キャラと声優）ととらドラ（ヒロイン）がミキシンされたのかと思いました。導入部分を見た瞬間、夫婦そろって『どこかで見たような？』て言いました。キャラデザが超電磁砲の OP 原画の人で、目立つナレーションが黒子の人で…、アレも子萌先生かと思いました。子萌先生じゃなくて佐天涙子でしたね。

キャラ立ちしていないので、中の人が透けて見えまくりでデジャブまくりなんですが…。ま。とりあえず面白そうなんで見てみます。

CLANNAD
～前半戦終了。

今のところ、このシナリオの何がよいのか、よくわかっていません。

んー。悪くは…、ないと思います。ただ、このライターさん、ストーリーを書くことができないんですね。どうしても、テーマとシーンだけ、それしか手についていないように感じます。話の流れに、ブツッ、ブツッって音が聞こえる感じ。そうした音を感じるたびに、イラッ、イラッとします。もっと、うまいやり方があるだろう！ってイライラ。

あと、どうでもいい感覚かもしれませんが、このノベル、古河シナリオ プレイ後だと、その他のヒロインとのシナリオが、本妻公認の浮気ストーリーみたいに感じます。

まぁ、古河の可愛さはわかってきました。After story に期待―――かな。

Parallel force - パラレル・フォース
～計測まとめ。

これまでの高速化の軌跡を、Core i7 860 と Atom D330 とでまとめてみました。

…Atom が遅い、のは当たり前として。Atom の方は結構、面白い傾向がありますね。

D330 は論理コアの数が 4 なのですが、物理コアは 2 コア (SMT 有) です。上記『オリジナル』と『並列化』の比が 3 倍以上となっていることから、SMT の効果が 1.5 倍分は効いていることになります。SMT おそるべし。Atom はインオーダー実行なので、よほど Atom に特化して最適化されたコードでないと、単一スレッド処理では実行ユニットがひまひまなのかも。アウトオブオーダーの代わりに SMT 用意したのだとすれば、それはちょっと正解かも、と思えるくらいの速度比です。

さらに D330 は SSE2 を使ったときの速度向上っぷりが半端でないです。上記『並列化 (3)』と『並列化 + SIMD (2)』の速度比が 2.25 倍となっており、SSE2 さいこーって状態です。(それでも、i7 860 の『オリジナル』をやっと超える程度の速度なんですけれど…)

Atom はなかなか面白いプロセッサだと思ってます。踏ん張れば、Core i7 の 1 コア分くらいの働きをするプロセッサということです。

会社のことで
～キレた。

うん。キレました。さすがにキレました。社長相手にキレました。

これから納得いかないことは、ちゃんとキレようと思います。キレる相手は、部下ではありません。部下相手にキレるのは筋違いです。対等以上の関係でなければ、キレません。フェアじゃないですから。

クラナド
～藤林姉妹。

乙女もすなるクラナドというものを、性別不詳の Chiharu もやってみんとす。

とりあえず、古河渚をクリア後、藤林姉妹を攻略中。

ということで、藤林姉妹を描いてみました。

…描いてみました。…えが、いて、みま…。

似てないね。仕方がないね。私この人の絵柄、あんまし好きくないし。仕方がないよね。自分の絵柄で落書いてみました。

気が向いたら、他のキャラクタも描こうかな、とか思ってます。今のところ思うだけですけれど…。

プログラミングお遊戯
～std::minmax_element を使用したソート。

επιστημηさんの『わすれもので(ちょびっと)高速化』に挑戦！

掲載のサンプルをビルドして Core i7 で実行すると...

• 359 (min_selection)
• 421 (minmax_selection)

んー。ご本人の環境では高速化が確認されたようですが、私の環境だと minmax_element が速くないように見えてしまいます。

…が、よくコードを見てみると、ソート対象の集合を削除しながら、ソート済みの集合を 2 つ作って最後にマージしてます。minmax_element に問題があるのではなく、周辺のコードに問題がありそうです。最近、案件でメモリアクセスの最適化関連に従事しているので、ちょっと気になるコードです。ご本人もコメントしてますが、かなりリッチな富豪的アプローチという雰囲気。

書き直してみました。

//DWORD minmax_selection_sort2(list& data) {  // ←さっきアップしたとき不等号の変換忘れ
DWORD minmax_selection_sort2(list<int>& data) {
  DWORD t = GetTickCount();
  auto first = data.begin();
  auto end = first;  advance(end, data.size() - 1);
  auto end1 = data.end();
  while (first != end1) {
    auto mm_pair = minmax_element(first, end1);
    if (mm_pair.first == mm_pair.second) {
      break;
    }
    end1 = end;
    iter_swap(first, mm_pair.first);
    iter_swap(end, first != mm_pair.second ? mm_pair.second : mm_pair.first);
    ++first, --end;
  }
  return GetTickCount() - t;
}

集合を新たに作成することなく、ソート対象の集合を直接書き換えています。挿入ソートの場合、こうしたアプローチの方が一般的なように思います。結果は...

• 359 (min_selection)
• 421 (minmax_selection)
• 343 (minmax_selection2)

多少、速くなりました。1 割には満たないようですが、もうちょっと良いやり方があるのかな。

(補足)

計測に GetTickCount API 使ってますが、経験的に timeBeginPeriod, timeGetTime API が使える環境ならそちらの方がタイマーとしては安定した値が取得できると思います。

Parallel force - パラレル・フォース
～SSE2 終わり。

これ以上の高速化はあんまし思いつかないや、というところまで描画処理をまとめました。一例としてαブレンディングの最適化結果など。

1 画素ずつ処理する場合は、下記の非 SIMD 処理で...

inline const PixPacked32 operator()(const PixPacked32 iDst, const PixPacked32 iSrc, const PixLevel iAlpha)
{
  const auto aSrcAlpha = convertRange255to256(iAlpha);
  const auto aDstAlpha = 256 - aSrcAlpha;
  const auto aDst13 = (iDst & 0xff00ff) * aDstAlpha + (iSrc & 0xff00ff) * aSrcAlpha;
  const auto aDst02 = (iDst & 0x00ff00) * aDstAlpha + (iSrc & 0x00ff00) * aSrcAlpha;
  return ((aDst13 & 0xff00ff00) | (aDst02 & 0x00ff0000)) >> 8;
}

デスティネーションが 16 バイトアライメント可能かつ 4 画素ずつ処理できる場合は、下記の SIMD (SSE2) 処理で...

inline const PixPacked128 operator()(const PixPacked128 iDst, const PixPacked128 iSrc, const PixPacked128 iAlpha32x4)
{
  const auto aZero = _mm_setzero_si128();
  const auto aSrcAlpha = _mm_srli_epi16(_mm_mullo_epi16(iAlpha32x4, _mm_set1_epi32(129)), 7);  // 0-255 -> 0-256
  const auto aDstAlpha = _mm_sub_epi32(_mm_set1_epi32(256), aSrcAlpha);
  
  // 下位 64-bit
  auto aSrcAlpha1 = _mm_shufflelo_epi16(aSrcAlpha, _MM_SHUFFLE(2, 2, 0, 0));
  auto aDstAlpha1 = _mm_shufflelo_epi16(aDstAlpha, _MM_SHUFFLE(2, 2, 0, 0));
  aSrcAlpha1 = _mm_unpacklo_epi16(aSrcAlpha1, aSrcAlpha1);
  aDstAlpha1 = _mm_unpacklo_epi16(aDstAlpha1, aDstAlpha1);
  
  auto aSrc = _mm_unpacklo_epi8(aZero, iSrc);
  auto aDst = _mm_unpacklo_epi8(aZero, iDst);
  aSrc = _mm_mulhi_epu16(aSrc, aSrcAlpha1);
  aDst = _mm_mulhi_epu16(aDst, aDstAlpha1);
  const auto aLo = _mm_add_epi16(aSrc, aDst);
  
  // 上位 64-bit
  aSrcAlpha1 = _mm_shufflehi_epi16(aSrcAlpha, _MM_SHUFFLE(2, 2, 0, 0));
  aDstAlpha1 = _mm_shufflehi_epi16(aDstAlpha, _MM_SHUFFLE(2, 2, 0, 0));
  aSrcAlpha1 = _mm_unpackhi_epi16(aSrcAlpha1, aSrcAlpha1);
  aDstAlpha1 = _mm_unpackhi_epi16(aDstAlpha1, aDstAlpha1);
  
  aSrc = _mm_unpackhi_epi8(aZero, iSrc);
  aDst = _mm_unpackhi_epi8(aZero, iDst);
  aSrc = _mm_mulhi_epu16(aSrc, aSrcAlpha1);
  aDst = _mm_mulhi_epu16(aDst, aDstAlpha1);
  const auto aHi = _mm_add_epi16(aSrc, aDst);
  
  return _mm_packus_epi16(aLo, aHi);
}

SIMD 版の処理の半分以上がパック (アンパック) とシャッフルというところが泣けます。これでもかなり削ったんですけれど…。

ちょっとだけ工夫があるのは、8-bit の右シフトの回数が減っているところでしょうか。画素を 16-bit にアンパックする際、{ 0xbb00, 0xgg00, 0xrr00, 0xxx00, 0xbb00, 0xgg00, 0xrr00, 0xxx00 } として、α値 (0-256) との乗算結果の上位 16-bit を採用することでシフト不要にしてあります。

SIMD ってもうちょっと使いやすくならないものでしょうか。いくら並列演算がすごくても、並列演算自体が使いにくかったら仕方ないと思うのですが…。

とにもかくにも、今度こそ高速化は終わり。機能作ります！機能！

Parallel force - パラレル・フォース
～SSE2 苦戦。

まさかの凡ミス。SSE2 用の組み込み関数の意味をとり間違えていました。テストしてたらα値付きイメージのフェードで色化け。調べてみると、驚愕の事実。_mm_mul_epu32 がまさか 32bit x 32bit = 64bit だったなんて！普通に乗算結果の下位 32bit を期待していたのですが…。私が期待していた処理は _mm_mullo_epi32 らしく、これは SSE4 でのサポートの様子。くっそー。Intel め。足元見やがって！こんちくしょー！！こっちは Pentium M / Pentium 4 世代からサポートしたいのに、SSE4 て。仕方がないです。このフローの最適解ではないけれど、ルーチン書き換えます…。

(追記)

結局、速度重視につき、演算精度を落として対応しました。落としたのは、0-255 → 0-256 レンジ変換処理。といっても、プログラム中では輝度が統一されるため、演算精度の低下に起因する描画内容の破綻はありません。また、レンジの下端と上端の保証は変わらないので、まぁ、目視確認は多分不能な程度の精度低下です。α値の中間階調が若干変わる程度です。

具体的には...

inline const PixPacked32 convertRange255to256(const PixLevel iPixLevel)
{
  // return iAlpha * 256 / 255;
  return iPixLevel * 65794 / 65536;  // 0-255 → 0-256
}

上記が...

inline const PixPacked32 convertRange255to256(const PixLevel iPixLevel)
{
  // return iAlpha * 256 / 255;
  return iPixLevel * 129 / 128;  // 0-255 → 0-256
}

このように変わりました。利点は SIMD でのレンジ変換時に、16bit 精度で計算できることです。α値のレンジ変換時の乗算が _mm_mullo_epi16 で計算できるようになりました。従来処理は 32bit 精度が必要でした。中間階調の傾きが若干きつくなりましたが、まぁ、問題ない範囲でしょう。

Parallel force - パラレル・フォース
～ちょっと高速化。その 4 (SSE2)

ふとコードを見返したら、イメージの転送元フォーマットが BGR 時、読み込みと BGR / BGRX 変換にて、SSE2 が使えることに気づきました。対応したサンプルをアップしました。

• pforce_1.exe … 単一スレッド処理。(15fps)
• pforce.exe … 複数スレッド処理。(62fps)
• pforce_loop.exe … 複数スレッド処理、ループ展開。(70fps)
• pforce_loop_alpha.exe … 複数スレッド処理、ループ展開、ブレンド処理最適化 (C++)。(81fps)
• pforce_loop_sse2.exe … 複数スレッド処理、ループ展開、ブレンド処理最適化 (SSE2)。(125fps)
• pforce_loop_sse2_load.exe … 複数スレッド処理、ループ展開、ブレンド処理最適化、読み込み処理最適化 (SSE2)。(166fps)

結果、166fps になりました。挙動を見ると、CPU 使用率が 70% 程度まで落ちており、また、処理速度の変動が激しいことから、各描画スレッドにおける表画面への転送ボトルネックが少しずつ露呈してきたように思います。ま。とりあえず高速化はこんなところで打ち止めです。相方から『その雪、降りすぎじゃね？』との指摘も入りましたので。

Parallel force - パラレル・フォース
～ちょっと高速化。その 3 (SSE2)

結局、SIMD 対応しました。描画処理全般で SSE2 を使ってみました。先週から、いろいろ書き換えて効果が出てきたので、サンプルを公開します。実行ファイルの内訳は下記のとおりです。Intel Core 2 / i3 / i5 / i7 シリーズを使用している場合は、特に SSE2 の効果が体感できると思います。Intel Core 2 から、SSE2 はリリース当初の倍の速度が出るようですので。

• pforce_1.exe … 単一スレッド処理。(15fps)
• pforce.exe … 複数スレッド処理。(62fps)
• pforce_loop.exe … 複数スレッド処理、ループ展開。(70fps)
• pforce_loop_alpha.exe … 複数スレッド処理、ループ展開、ブレンド処理最適化 (C++)。(81fps)
• pforce_loop_sse2.exe … 複数スレッド処理、ループ展開、ブレンド処理最適化 (SSE2)。(125fps)

カッコ内の値は Intel Core i7 マシンでの計測結果です。前回 C++ での最適化ルーチンで 81fps だったものが、今回 SSE2 最適化ルーチンにて 125fps 出るようになりました。SIMD 侮れませんね。かなり速いです。SSE2 では 4 画素ずつ同時処理しているのですが、そう考えると、逆に 1 画素ずつ処理している C++ のコードも健闘しているのだな、とちょっと感心しています。SSE2 の方は処理の過程でビット深度が変動するため (ロード時:8x16, 乗算/シフト時:16x8, ストア時:8x16)、そのたびにパック & アンパック命令を入れており、必ずしも 4 倍の速度が出せるわけではなさそうです。

今回は組み込み関数でお手軽に SSE2 対応しました。かりっかりにチューニングするにはインライン アセンブラでも使うのがよいのでしょうが、VC が確か x64 にてインライン アセンブラ非対応だったのを受けて、組み込み関数での実装でまとめました。

ただ、ここでひとつ問題が…。

SSE2 組み込み関数を使用した場合、XMM レジスタの扱いに制限が入ります。VC (icc/gcc も同様) では __m128i 等の型を使用することにより、XMM レジスタ相当の変数を宣言できるのですが、これは必ずしもレジスタ割付されるとは限りません。当該変数の宣言数がレジスタ数よりも多い場合や、変数の宣言から参照までコード上の距離が離れている場合等、コンパイラにより一時的に XMM レジスタの内容がスタックへストアされることがあります。この動作自体は int や long など、他の一般的な変数宣言と同じ扱いですので、驚くところではないのですが、XMM レジスタのロード元とストア先は、SSE2 の仕様により 16 バイト アライメントされている必要があります。main 関数からカウントして SSE2 利用箇所までが一貫した自作コードであれば、コンパイラがアライメントを制御してくれるので問題ないのですが、途中で他のライブラリ等のコールバックを挟んでしまうと、16 バイト アライメントが正常に機能しません。コールバック元のライブラリ関数でアライメント保証がされなくなるためです。(32bit/64bit アプリにおける最大の組み込みデータ長は通常 8 バイトですので)

パラレル・フォースでは、ワーカー スレッド内で SSE2 最適化された描画処理が走るため、_beginthread API でスレッド プロシージャを呼び出した時点で、アライメント保証がなくなってしまいます。先ほどまで、この挙動に手こずってしまい、原因判明するまで、謎の強制終了処理に悩まされていました。結局、XMM レジスタ退避が発生しないよう、XMM 自動変数の宣言数を減らして、宣言から参照までの距離を極力短くすることで対応しました。

レジスタ退避がなくなった分、速度貢献はしていると思うのですが、対症療法につき、抜本的な解決ではありません。んー。任意のタイミングで簡単にスタックアドレスをずらす方法ってあるんでしょうか。

Parallel force - パラレル・フォース
～ちょっと高速化。その 2

新しい PC はあれから安定して動作しているようです。SE-90PCI のアナログ出力は音がいいですね。デジタル出力のような音の硬さ (多分硬いほうが正確な波形なんでしょう) がなく、柔らかな音の広がりを感じます。その割りに解像感が落ちるわけでもなく。好みの音です。

ま、にわかオーディオ レビューはこのくらいにして、パラレル・フォースです。仕事で体調を崩してしまい、なかなか手が加えられていませんが、アルファ ブレンディングのコードを見直しました。

これまでは...

// 0-255 -> 0-256
inline const PixPacked convertRange255to256(const PixLevel iPixLevel)
{
  // return iAlpha * 256 / 255;
  return iPixLevel * 65794 / 65536;  // 0-255 → 0-256
}

除算をビットシフト化するため、上記のように 0-255 レンジを 0-256 レンジに変換できるようにして...

// Alpha blending
inline const PixPacked operator()(const PixPacked iDst, const PixPacked iSrc, const PixLevel iAlpha)
{
  const auto aSrcAlpha = convertRange255to256(iAlpha);
  const auto aDstAlpha = 256 - aSrcAlpha;
  const auto aDst13 = (((iDst & 0x00ff00ff) >> 0) * aDstAlpha + ((iSrc & 0x00ff00ff) >> 0) * aSrcAlpha) / 256;
  const auto aDst02 = (((iDst & 0xff00ff00) >> 8) * aDstAlpha + ((iSrc & 0xff00ff00) >> 8) * aSrcAlpha) / 256;
  return (aDst13 & 0xff00ff) | ((aDst02 & 0xff00ff) << 8);
}

上記のコードでアルファ ブレンディングしていました。画素の並びが XBGR という前提で、B+R と X+G をそれぞれまとめて計算しています。Pentium4 全盛期に PentiumII 用に書いたコードで、計測した当時はテーブル参照による最適化とどっこいでした。メモリ アクセスを伴わないため、今の CPU ではフュージョンやら高度なペアリングやらが働いて、テーブル参照よりも速いんじゃないかなー、とか思ってます。

しかし、改めて、よくよく見直してみると、画素の並びが XBGR なんだから X に相当する上位 8-bit は要らないなぁ、と思って、下記のように修正してみました。

// Alpha blending (2)
inline const PixPacked operator()(const PixPacked iDst, const PixPacked iSrc, const PixLevel iAlpha)
{
  const auto aSrcAlpha = convertRange255to256(iAlpha);
  const auto aDstAlpha = 256 - aSrcAlpha;
  const auto aDst13 = (iDst & 0xff00ff) * aDstAlpha + (iSrc & 0xff00ff) * aSrcAlpha;
  const auto aDst02 = (iDst & 0x00ff00) * aDstAlpha + (iSrc & 0x00ff00) * aSrcAlpha;
  return ((aDst13 & 0xff00ff00) | (aDst02 & 0x00ff0000)) >> 8;
}

このコードだと、上位 8-bit が捨てられてしまいますが、ビットシフトの回数が、4 回分減っています。aDst13 算出時の "/ 256" が 1 回、 aDst02 算出時の ">> 8" が 2 回、同じく "/ 256" が 1 回。事前に 1/256 しないことにより、return 文のビットシフトが逆を向いていますが、これはシフト回数差し引き 0 ですね。

この程度で最新の CPU での処理速度が上がるかどうか、修正時点では眉唾だったのですが、前回の最適化時点で 70fps だったものが、81fps にまで伸びました。んー。いまどきの CPU も結構単純なのね。SIMD 使えばこんな話ともおさらばなのですが、環境非依存のプリミティブな部分については、しばらく ANSI っぽいところでがんばりたいと思います。

EPSON DIRECT Endeavor MR4000
～SE-90PCI で相性問題。

新しい PC ですが、しばらく使用していたらシャットダウンが正常にできないようになってしまいました。原因を調べると、SE-90PCI でフリーズ問題があるとか。ためしにドライバを抜いてみると再現しなくなりました。んー。いろいろ調べて、ローカル コンピュータ ポリシーの設定で、スクリプト (スタートアップ/シャットダウン) にて、devcon.exe を使用したドライバの有効化/無効化バッチを登録して事なきを得ました。WDK にしか x64 バイナリがなかったり、そもそもいまどき相性問題かよ！的な懐かしさを覚えつつも、このじゃじゃ馬な感じが PC だよね、とか感慨にふけりながら対策を施しました。とりあえず、VIA はもう少しドライバを安定化させるといいと思います。ドライバなら、PC の起動終了を普通にフックできるだろうに。そこで有効化/無効化と同内容の処理をやってくれれば問題ないと思うのですが。

Parallel force - パラレル・フォース
～ちょっと高速化。

Intel Core i7 の PC を購入しました。相方の要望で、省スペースかつ静かなマシンということで、EPSON DIRECT の Endeavor MR4000 をセレクトしました。CPU は i7-870、メモリは 8GB。グラボは静かな GT220。BD ドライブをつけました。音源が貧弱だったので、手持ちの SE-90PCI と組み合わせて、Windows 7 (x64) で動作させています。これでやっとパラレル・フォースの開発 & 動作確認環境が整いました。マルチコアのハイスペック (i7-870) と、低スペック (Atom 330) の双方が整いました。

ということで、早速 4 コア (8 論理コア) に対する並列度を計測。i7 にて 4 コアで 4 倍強の速度になりました。15fps 対 62fps。んー。論理コアが 8 つなので、多分もう少し速くなるはず。座標計算を 1 コアだけでやってるのが敗因かな。パフォーマンス モニタで CPU 使用率は 90% 程度なので、これを並列化すれば、もっと並列度が上がって高速になるはず。

ここまでの傾向から、パラレル・フォースの並列描画処理がそれなりに コア数比で伸びていくことがわかってきました。コア数比を抑制するボトルネックもなんとなくわかってきました。プロデューサ コンシューマ パターンは偉大です。ボトルネックはプロデューサ部をさらに並列化することで解消できそうです。こうなってくると、1 コアあたりの処理速度で手を抜いている部分が気になってきます。気になったので、少し速くしてみました。画素計算処理を 8 画素単位でループ展開しました。そうしたら、i7 にて 4 コアで 1 割程度高速化されました。62fps が 70fps 程度になりました。んー。CPU って単純ね。1 コアあたりの速度を向上させるには、アルゴリズム レベルではオクルージョン カリング、コーディング レベルでは SIMD が必要になってきます。でも、これはもうちょっと先かな。それよりも先にイメージのアフィン変換を実装しないと。

Parallel force - パラレル・フォース
～FPS 表示など。

サンプルにて、マルチコア動作におけるパフォーマンス向上効果が分かるよう、FPS (実効値) をタイトルバーに表示してみました。pforce_1.exe が 1 スレッドで描画、 pforce.exe が論理コア数のスレッドで描画です。環境に依存するのでしょうが、結構効果が出てると思います。

今日は出勤日ですが、休日中の疲れからか、本日ダウン中につき、欠勤。ダメ社会人です。ペース配分はしっかりしましょう。30 歳過ぎてからの子育ては想像以上です。人間の設計的に 20 代前半の有り余る体力は子育てのために用意されているのだと痛感しました。

とある科学の超電磁砲
～新 OP のタイトル、カルナバル・バベルでしたね (違

間違って覚えてました。当時は高校生だったかな。このころ、3x3EYES の OVA 買って見てたなぁー。パイに戻るの泣けるよね。PC ゲームでさんじやんへんじょう (漢字をど忘れ) とか、きゅうせいこうしゅ (やっぱり漢字ど忘れ) とかプレイしてました。VRAM の少ない PC-98 とか、まだ画面速度の足りない Windows 3.1 (Win32s) とかでメーカーが頑張っているころですね。あー。同級生 2 とか YU-NO とか EVE burst error とか闘神都市 2 とか零式とかアトラクナクアとか鬼畜王とかぱにょんとかこの辺だなぁ。自分の一番好きなものって、高校生くらいのころに固まりますね。なんだか懐かしい気分になってきました。酔っているんでしょうか。

とある科学の超電磁砲
～新 OP と新 ED の CD 買いました。

普段は気に入っても OP だけなんですが、今回は ED も買いました。今回の ED はさびが格好良かったので。疾走感が良いですね。

早速 iTunes で取り込んでループして、OP を空で口ずさんでいたら、どうしてもさびがカンナベルバベルになります。んー。曲的にはぜんぜん違うんですけど、メロディラインが似てるのかな。んー。その曲知らない人にとってみたら、新 OP もオンリーワンなんでしょうけれど、古い世代のファンからすると、ブルーシードの OP が頭をよぎるという。んー。アニメの OP や CM 見てるときはぜんぜん気づかなかったんだけどなぁ。ま。いい曲です。

まぁ、似ているといえば、母校の校歌のさびなどはウルトラマンの曲のさびに激似でしたけれど。全然関係ない話ですね。

仕事の話などなど。

あるプログラムをあるプラットフォームに最適化し、一定数以上のパフォーマンスを確保する、という案件をやってます。プラットフォーム非依存の最適化にて、ターゲット プラットフォーム上で 2.5 - 3 倍 (既存比) のパフォーマンスは出しているのですが、予定している改善と、見極め用の事前評価から、試算の段階でさらに 1.7 - 2.5 倍くらいのパフォーマンスになりそう、という感触。一定数以上、という数値に届くか届かないかの瀬戸際の数値かな、と思ってます。ターゲット プラットフォームのボトルネックは分かっていて、メモリが CPU に対して極端に遅いため、メモリアクセスを最適化する必要があります。ここ最近は最適化の仕事が多いな、とか思ってます。

よく、お客さんから『なぜそんなに速くできるのか？』と聞かれますが、常に答えはひとつです。『自分が CPU になりきれば、何とかなります』です。真面目な話、仕事で大切な姿勢とは『どれだけ相手に歩み寄れるか』ということだと思ってます。これを最適化に置き換えると、『どれだけ CPU に歩み寄れるか』ということになります。ま、これを回答すると、冗談を言われたという顔をするお客さんが多いのですが、私は大真面目です。これができないと、ボトルネックしか解消できない表面上だけの効率化しかできません。『プログラム全体がまんべんなく遅い』という如何ともしがたい状態が、現場には確実に存在します。これを解消するためには、短絡的な数字による効率化目安の算出だけでなく、徹底した『CPU 目線の』コードレビューが必要になります。うちの会社ではこれをやりますが、このあたりが、お客さんからすると『職人芸』に見えるようです。

そんなわが社も、4 月以降の案件がなかなか見えてきません。うーん。お客さんへのヒアリングや、提案などしてみていますが、なかなか案件をつなぐのが難しい。不景気って大変ね、という話。

DELL Dimension 9200C 故障！？

昨日、相方に脅迫されて促されて、とりためた子供のビデオをまとめていました。

PC の USB HDD にデータを吸い上げた段階で、「データはバックアップがないと不安」という絶対指令お願いを受けて、それとなく DLNA で PS3 からビデオが見られると素敵だなぁーとなんとなく思い立って、LANDISK HDLP-S500 を勢いあまって購入しました。PS3 からかわいい子供の映像が見られるようになりました。素敵。

データは全て、USB HDD と LANSIDK の双方に保持する運用ルールとすることで、データの多重化による安全確保を行いました。この方法だと落雷からの安全性は確保されないため、ま、そのうち、多重化したデータのバックアップを本当に考える日が来ると思います。

さて、子供の映像を PC (DELL Dimension 9200C) で確認していた際、下記の現象に遭遇しました。

• 映像に白いごま塩ノイズが載る
• 映像を再生するとたまに PC がフリーズする

再生データが MPEG2 形式のためコーデックのせいかな、と思ったのですが、最終的に PC の蓋を開けて愕然としました。グラボ (RADEON X1300PRO) のヒートシンクが外れていました。グラボが熱暴走していたのです！なんといいますか、生まれてこの方、15 年以上 PC を扱っていますが、ヒートシンクが知らない間に外れたのは初めてです。新居に引越ししたときに外れたのだろうか…。うーむ。とりあえずヒートシンクを取り付けなおして事なきを得ましたが、そろそろ PC も買い替えかなぁと思ってます。Intel Core i7 が欲しいです。これでパラレル・フォースのパフォーマンスを見てみたい。

Parallel force - パラレル・フォース
～ビルド オプション変更など。

Intel Atom D330 で動作させてみました。ちゃんと 2 コア (4 仮想コア) 動きました。良かったよかった。よくないっ！先ほど確認したら、サンプルのビルド オプションで、ランタイム DLL を参照する設定になっていて、VC10 入れてない環境で動きませんでした。よくないです。

再アップしました。今度こそいろんな環境で動くはず。

Parallel force - パラレル・フォース
～タスク システム、画面エフェクトなど。

それとなくタスク システムを実装しました。タイマーを実装していないため、FPS 管理がありませんが、タスク システムのサンプルとして雪など降らせてみました。いつも表現に困ると雪を降らせてる気がします。レパートリーがあまりないようです。

雪スプライトを加算合成で 1,000 枚ほど重ねてます。Intel Core 2 Duo (1.86 GHz) で CPU を 100% 使ってます。環境にあまりよくないような気もしてますが、せっかくなので、動くサンプルをアップしてみたりなどします。タイマーがないため動かす環境によって雪の速度が異なると思います。私もメイン PC でしか動作確認していないので、あとで Intel Atom D330 で動作させてみます。SMT の効果が確認できる…かな。

幼児のボキャブラリー (3)

破壊的セマンティクス。～そしてそれから～

• ハンバーガー ⇒ がんがーばー!
• とら ⇒ がいがー! がおー!! (タイガーのつもりのようです)

最初聞いたとき、空間歪曲するかと思いました。

Parallel force - パラレル・フォース
～スプライト管理、並列描画のコードなど。その 2。

昨日寝る前に、お酒など飲みながら、なんとなく、先ほどの関数を分離してみました。

//
// スレッド プロシージャ
//
void Screen::threadProc(ThreadNotifier& iNotifier)
{
  // コア数取得
  const auto aProcessors = SystemInfoHelper::getProcessors();
  
  // 描画スレッド構築
  std::vector<TaskThread> aTaskThreads;
  aTaskThreads.reserve(aProcessors);
  
  for (std::uint32_t aCt = 0; aCt < aProcessors; aCt++) {
    // スレッド構築
    std::shared_ptr<Thread> aThread(new Thread());
    std::shared_ptr<Event> aBeginEvent(new Event()), aEndEvent(new Event());
    TaskThread aTaskThread = { aThread, aBeginEvent, aEndEvent };
    aTaskThreads.push_back(aTaskThread);
    
    // スレッド開始
    aThread->start(createDrawerThreadProc(aBeginEvent, aEndEvent));
  }
  
  // 描画ループ
  while (!iNotifier.isStopRequestIssued()) {
    try {
      auto aLock = pforce::lock(mDrawerThreadCriticalSection);
      if (mPrimaryScreen->isDirty()) {
        // 描画準備
        mTaskInfo.reset(mPrimaryScreen);
        auto aScreenLock = pforce::lock(*mTaskInfo.screen);
        
        // 描画開始
        std::for_each(aTaskThreads.begin(), aTaskThreads.end(), [](TaskThread& iThread) {
          iThread.beginEvent->set();
        });
        
        // 描画終了
        std::for_each(aTaskThreads.begin(), aTaskThreads.end(), [](TaskThread& iThread) {
          iThread.endEvent->wait(INFINITE), iThread.endEvent->reset();
        });
      }
    } catch (std::exception&) {
      // do nothing.
    }
#if defined(PFORCE_STRESS_TEST)
    // ストレス テストの場合はスリープしない。
#else
    iNotifier.sleep(1);
#endif
  }
  
  // 描画スレッド終了
  mTaskInfo.reset();
  std::for_each(aTaskThreads.begin(), aTaskThreads.end(), [](TaskThread& iThread) {
    iThread.thread->invalidate(), iThread.beginEvent->set();
  });
  std::for_each(aTaskThreads.begin(), aTaskThreads.end(), [](TaskThread& iThread) {
    iThread.thread->stop();
  });
}

//
// 描画スレッド プロシージャを生成する。
//
const ThreadFunction Screen::createDrawerThreadProc(const std::shared_ptr<Event> iBeginEvent, const std::shared_ptr<Event> iEndEvent)
{
  // 合成バッファ構築
  const auto aRowbytes = ImageHelper::getRowbytes(mPrimaryScreen->getWidth(), imageB8G8R8X8);
  auto aPixelData = MemoryHelper::alloc<std::uint8_t>(aRowbytes * mPrimaryScreen->getBandHeight());
  std::shared_ptr<IImage> aImage(new Image(mPrimaryScreen->getWidth(), mPrimaryScreen->getBandHeight(), imageB8G8R8X8,
    aRowbytes, aPixelData));
  
  // 描画スレッド プロシージャ
  auto aDrawerThreadProc = [this, iBeginEvent, iEndEvent, aImage](ThreadNotifier& iNotifier) -> void {
    while (!iNotifier.isStopRequestIssued()) {
      iBeginEvent->wait(INFINITE), iBeginEvent->reset();
      try {
        if (mTaskInfo.screen) {
          // 描画
          auto aScreen = mTaskInfo.screen.get();
          const auto aMax = aScreen->getBandCount();
          const auto aBandHeight = aScreen->getBandHeight();
          for (;;) {
            const auto aBandIndex = mTaskInfo.getTargetBandIndex();
            if (aBandIndex < aMax) {
              // 描画
              Rect aDirtyArea = aScreen->getDirtyArea(aBandIndex);
              if (!RectHelper::isEmpty(aDirtyArea)) {
                aScreen->draw(*aImage, aBandIndex);
                // 表画面へ転送
                auto aLock = pforce::lock(mTaskInfo.cs);  // GDI はスレッドセーフでないため転送はシーケンシャルに実施
                blitImageToDeviceContext(mDeviceContext, *aImage, aDirtyArea, aBandIndex * aBandHeight);
              }
            } else {
              // 終了
              break;
            }
          }
        }
      } catch (std::exception&) {
        // do nothing.
      }
      iEndEvent->set();
    }
  };
  
  return aDrawerThreadProc;
}

うん。こっちの方が意味の通りが良い気がしますね。

さて、次の更新の時にはもうちょっと前進しようかな。

Parallel force - パラレル・フォース
～スプライト管理、並列描画のコードなど。

なんとなく、並列描画のコードなど公開してみます。

//
// 描画スレッド プロシージャ
//
void Screen::drawerThreadProc(ThreadNotifier& iNotifier)
{
  // コア数取得
  const auto aProcessors = SystemInfoHelper::getProcessors();
  
  // 描画スレッド構築
  std::vector<TaskThread> aTaskThreads;
  aTaskThreads.reserve(aProcessors);
  
  for (std::uint32_t aCt = 0; aCt < aProcessors; aCt++) {
    // 合成バッファ構築
    const auto aRowbytes = ImageHelper::getRowbytes(mPrimaryScreen->getWidth(), imageB8G8R8X8);
    auto aPixelData = MemoryHelper::alloc<std::uint8_t>(aRowbytes * mPrimaryScreen->getBandHeight());
    std::shared_ptr<IImage> aImage(new Image(mPrimaryScreen->getWidth(), mPrimaryScreen->getBandHeight(), imageB8G8R8X8,
      aRowbytes, aPixelData));
    
    // スレッド構築
    std::shared_ptr<Thread> aThread(new Thread());
    std::shared_ptr<Event> aBeginEvent(new Event()), aEndEvent(new Event());
    TaskThread aTaskThread = { aThread, aBeginEvent, aEndEvent };
    aTaskThreads.push_back(aTaskThread);
    
    // 描画スレッド プロシージャ
    auto aThreadProc = [this, aBeginEvent, aEndEvent, aImage](ThreadNotifier& iNotifier) -> void {
      while (!iNotifier.isStopRequestIssued()) {
        aBeginEvent->wait(INFINITE), aBeginEvent->reset();
        try {
          if (mTaskInfo.screen) {
            // 描画
            auto aScreen = mTaskInfo.screen.get();
            const auto aMax = aScreen->getBandCount();
            const auto aBandHeight = aScreen->getBandHeight();
            for (;;) {
              const auto aBandIndex = mTaskInfo.getTargetBandIndex();
              if (aBandIndex < aMax) {
                // 描画
                Rect aDirtyArea = aScreen->getDirtyArea(aBandIndex);
                if (!RectHelper::isEmpty(aDirtyArea)) {
                  aScreen->draw(*aImage, aBandIndex);
                  // 表画面へ転送
                  auto aLock = pforce::lock(mTaskInfo.cs);  // GDI はスレッドセーフでないため転送はシーケンシャルに実施
                  blitImageToDeviceContext(mDeviceContext, *aImage, aDirtyArea, aBandIndex * aBandHeight);
                }
              } else {
                // 終了
                break;
              }
            }
          }
        } catch (std::exception&) {
          // do nothing.
        }
        aEndEvent->set();
      }
    };
    aThread->start(aThreadProc);
  }
  
  // 描画ループ
  while (!iNotifier.isStopRequestIssued()) {
    try {
      auto aLock = pforce::lock(mDrawerThreadCriticalSection);
      if (mPrimaryScreen->isDirty()) {
        // 描画準備
        mTaskInfo.reset(mPrimaryScreen);
        auto aScreenLock = pforce::lock(*mTaskInfo.screen);
        
        // 描画開始
        std::for_each(aTaskThreads.begin(), aTaskThreads.end(), [](TaskThread& iThread) {
          iThread.beginEvent->set();
        });
        
        // 描画終了
        std::for_each(aTaskThreads.begin(), aTaskThreads.end(), [](TaskThread& iThread) {
          iThread.endEvent->wait(INFINITE), iThread.endEvent->reset();
        });
      }
    } catch (std::exception&) {
      // do nothing.
    }
#if defined(PFORCE_STRESS_TEST)
    // ストレス テストの場合はスリープしない。
#else
    iNotifier.sleep(1);
#endif
  }
  
  // 描画スレッド終了
  mTaskInfo.reset();
  std::for_each(aTaskThreads.begin(), aTaskThreads.end(), [](TaskThread& iThread) {
    iThread.thread->invalidate(), iThread.beginEvent->set();
  });
  std::for_each(aTaskThreads.begin(), aTaskThreads.end(), [](TaskThread& iThread) {
    iThread.thread->stop();
  });
}

完全なコードではありませんが、なんとなく、C++0x っていいな、って気になるコードじゃないかと思ってます。ラムダとか、左辺値の型推論とか、右辺値参照によるロックの簡略化とか。C++03 にはない世界ですね。

改めて書くと、1 関数あたりが長いですね。描画スレッド プロシージャの生成だけ、関数分けようかな。

幼児のボキャブラリー (2)

破壊的セマンティクス。

• めがね ⇒ がねね (!?!?)

最初聞いたとき、意味がわかりませんでした。

幼児のボキャブラリー。

kokonowo と連絡をとりました。その際、言葉を覚える過程で出てくる幼児語についての話題がありました。ということで、それとなく我が家の息子の幼児語など書き連ねてみんとす。(ぜんぜん関係ありませんが、みんとす、ってミント酢みたいだな、とかいつも思います)

• 母さん ⇒ あーしゃん (んー、べたですね)
• しまちゃん ⇒ ぃまちゃん (こどもチャレンジ の しまじろう のことなのですが「し」が発音できないようです)
• 父さん ⇒ とーと (このように呼ばせてます)
• だっこ ⇒ がっこ (例文：とーと、がっこ！)
• 寒い ⇒ ぁむーい (「さ」が発音できないようです)
• ぬくぬく ⇒ ぅくぅく (「ぬ」が発音できないようです)
• ぐー、ちょき、ぱー ⇒ ぅー、ちょち、ぱぁー (「ぐ」「き」が発音できないようです)
• NHK ⇒ もっち (英語であそぼ が由来で、彼にとって NHK = もっち になったようです。例文: もっち みゆー。)
• 新幹線 ⇒ かんしんせん (私も幼児のころ かんしんせん だったそうです)
• 新幹線のコップ ⇒ かんしんせんのぽっく (逝きそう…)
• 消防車 ⇒ ぼうそうしゃ (暴走車!?)
• パトカー ⇒ ぽこかー (壊れそう…)
• 大丈夫 ⇒ ぼーじょーじょ (フランス人!?)
• さーいーたー♪さーいーたー♪チューリップーのー ⇒ かーにーさん♪かーにーさん♪ちゅーぃっぷーのー (もはや主題が変わっています)

火事の現場に暴走車と ぽこかー が到着する様を想像し「ぷっ」となる毎日です。子育ては大変ですが、楽しい気持ちも大きいです。んー。子供はかわいいね。

Parallel force - パラレル・フォース
～スプライト管理、まずはパイプライン 1 段。

とりあえず合成先スクリーン 1 枚の描画ルーチンが完成。表画面への転送も含めて、動作確認が取れるところまできました。

スクリーンサイズは 800x600 pix (RGBX)、50 枚のスプライトをαブレンディングしてみました。Intel Core 2 Duo (1.86 GHz) でスレッド数振って 1 フレームあたりの描画時間 (表画面への転送込み) を計測したら下記のような感じになりました。(絶対値はともかく、相対値に注目です)

• 1 スレッド: 113ms
• 2 スレッド: 58ms

うん。結構コア数比例で伸びる感じですね。良好良好。ただこれ 1 点注意があります。表画面への転送には StretchDIBits API を使用しているのですが、これをスレッド間で同時にコールすると失敗することがあり、この API 呼び出しだけはクリティカルセクションでガードしてシーケンシャルに実施してます。なので、合成負荷よりも表画面への転送負荷が大きい場合は、コア数比例というほどにはスコアが伸びないと思います。DirectX 使ってサーフェイスに直接描画しろよ、という話もありますが、DirectX を使うと、とたんに周辺コードが増えるので極力使いたくないなぁ、とか思ってます。サーフェイスのフォーマット対応やロストしたサーフェイスのリストア処理なんて面倒くさすぎて失神しそうです。

また、今回の実装では、スレッドをコアに貼り付けるようなことはしていません。その代わり、合成バッファをスレッドに貼り付けるようにしてます。スレッド割り当ての最適化は OS に任せて、データ割り当てだけプログラムで制御してるって状況です。まぁ、割り当ての有無の相違を検証していないので、どれくらい効果があるのかわかりませんけどね。せっかく合成バッファでキャッシュ サイズを考慮しているので、載るならコア別でキャッシュに載るといいかな、とか。そんなことを期待してます。

とりあえずネイティブな合成処理はできました。次は多段スクリーンかもうちょっと上位のエフェクト系機能に取り掛かろうかな。今は SIMD を使っていないので、気持ちが乗ったらそちらにも手を出そうかと思いますが、優先順位は低いかな。まずは機能を作っていこうと思います。

Parallel force - パラレル・フォース
～スプライト管理、実装そろそろまとまるかも。

結局、スプライト管理と分割描画ルーチンを 1 つのクラスとしてまとめました。1 画面分のスプライトの管理と描画をまとめてあります。描画ルーチンはスレッド用の分割単位でメソッド コールできるようにしてあります。これをスクリーン管理クラスに、単数または複数インスタンス持たせるようにします。スクリーン管理クラスは描画用のオフスクリーンを持ち、これが常に 2nd キャッシュ (できれば 1st キャッシュ) に載るよう管理し、並列描画を実行します。(字面だとわかりづらいですね。図でも描けばよいのでしょうが)

懸念事項で、コア間のキャッシュ競合の回避を考えています。通常、スプライト合成は重ね描きになるので、合成中は描画先バッファをキャッシュに載せて、合成後にキャッシュ外のメモリにノンテンポラル転送する、という工程で設計を進めていますが、更新領域あたり 1 回のノンテンポラル転送が発生するという点がちょっと引っかかっています。ノンテンポラル転送するとキャッシュはきれいなままなのですが、せっかく高クロックの CPU が FSB に引っ張られるということがあり、悩ましいと感じています。(キャッシュ競合やキャッシュ汚染するよりマシなんですけど) Intel Core i7 などはコア共通の 3rd キャッシュを数 MB オーダーで持っているため、ノンテンポラル転送しなくてもここが吸収してくれそうな気がするのですが、たとえばデュアルコアの Intel Atom などは、コア共通のキャッシュがないばかりか、2nd キャッシュが 512kB (64kB at 1-way) しかないため、書き込みバッファの取り扱いに十分注意しないと、キャッシュ競合だけでなく、キャッシュ汚染がビシバシ発生しそうな気がしています。んー。

ちなみに、キャッシュキャッシュと連呼していますが、下記を満足するメモリアクセスであればキャッシュに載るという前提でコード書いています。外してたら設計し直しなんですが。

• サイズ要件
  • 64kB 未満のメモリ領域
• アライメント要件
  • 4kB アライメントされた先頭アドレスを持つメモリ領域
  • 4kB アライメントされた終了アドレスを持つメモリ領域
• アクセス要件
  • 前後それぞれ 4kB へのメモリ アクセスは発生させない
  • 高頻度で連続アクセスする
  • 極力シーケンシャル アクセスする

サイズ要件は Intel Atom の 2nd キャッシュの 1-way あたりのサイズ を考慮してます。1st キャッシュを考慮した方がよいのかな。んー。アライメント要件は Intel CPU のキャッシュ制御アルゴリズムが 4kB 単位で連想判定するらしいことを考慮してます。このあたり、ちゃんと効いているかどうかを、また確認しないといけないですけど、経験上、そんなに外してない数字と要件かな、と思ってます。

動作確認まで、あとちょっと。がんばろー。

Parallel force - パラレル・フォース
～スプライト管理、実装中。

グラフィックス パッケージで矩形フィルとイメージの dot by dot 転送の実装を完了。描画先は RGBX-8bit 固定で、すべての描画ルーチンで下記の組み合わせが利用できるようになっています。

• 合成モード (通常・加算・減算・乗算・スクリーン合成)
• 入力カラー (RGBA-8bit, RGBX-8bit, RGB-8bit, Gray-8bit, GrayA-8bit)
• 不透明度によるフェード指定 (0-255)

実装は、幾何計算と合成処理の直行性を利用したファンクタ ベースの描画ルーチンになっています。以前作った類似のエンジンよりも幾分すっきりした実装になりました。それなりに実装スキルは向上しているようです。上記の描画処理だけで、えーと…、Graphics/Drawer.cpp は 800 行程度ですね。短い…、かな。テンプレート万歳！

現在、描画命令をタスク化して、スレッドに食わす直前くらいのところで詰まってます。

ただ描画するサンプルコードを作るのであれば、そのまま実装を進めても良いのですが、一応ゲーム用のエンジンとして利便性を高めておきたいと思います。スプライト パッケージの実装が欠かせません。ということで、現在スプライト関連の実装中です。スクリーンとスプライト、複数のオフスクリーン バッファと描画ルーチンの関係を整理するのがなかなか大変です。いや、実装するだけならすぐなんですが、きれいにまとめようと思うと、それなりに時間がかかるものだな、と。シングルスレッドで描画するだけのエンジンなら、スプライトの管理クラスと描画ルーチンが渾然一体となっていても良いのですが、キャッシュ考慮の並列描画を前提とすると、ちょーっと一考しないとすっきりしません。並列化対象は決めてあるので、それに合致するよう描画管理はすでにスレッド分散用に分割してあるのですが、んー、それをスプライトと関連付けようとすると、んー。もう一ひねりかな。

あけましておめでとうございます。

昨年は一昨年から引き続き、サークル Chiharu のあとりえとしてはなんら成果を上げることがありませんでした。今の会社の状況からすると、今年もサークル活動としてはなかなか難しい状況ですが、去年名前だけ宣言し、概要すら明らかにしないまま進めている個人活動のパラレル・フォースについては、何らかの成果を挙げたいと考えています。

まぁ、もともと個人サークルなので、活動自体こんなもの、という見方もあるのですが、個人サークルであるのならなおのこと、私個人納得のいく成果というやつをどこかでちゃんとあげたいという、漠然とした思いに駆られる 30 歳なのであります。一時期はそれを会社であげようかという考えもありましたが、どうも私は『収益』というやつに鈍感なようで。鈍感なだけでなく生理的嫌悪感があるようで。儲けるのがいやなのではなく、金の話に生理的嫌悪感があります。金の話が続く時期は、著しく体調を崩します。そんなんで役員やってて良いのか、って話はあるのですが。まぁ、そっちはそっちでぼちぼち収益ちゃんとあげているので、最低限のことはこなしているかなと思ってます。なんといいますか、役員をやってはみたものの、私は私のやりたいことを会社という枠組みで実現するのには向いていない人種なのだと、最近改めて感じるところであります。

だから、というわけではありませんが、パラレル・フォースをできることろまでがんばりたいと思います。

Parallel force - パラレル・フォース
～スレッド周り、ひとます実装終わりです。

ロック機構の実装に手間取りました。

これまでロック機構というと、クライアント コードは下記のように実装してきていたのですが…、

CriticalSection aCs;
{
    Lock<CriticalSection> aLock(aCs);
    // このブロック中はロックされる
}

Lock<CriticalSection> aLock(aCs);

のように毎度ロック用の型を明示するのが面倒くさくて、パラレル・フォースでは

auto aLock = lock(aCs);

のように記述できるよう lock メソッドの実装を進めていました。せっかく左辺値の型推論が有効なのですから、型名は極力省略したいものです。

さて、この lock メソッド実装の課題は 2 つ。

• Lock<> はコピー不能を前提とする。
• Lock<> のコンストラクタ以上の大きなオーバーヘッドを発生させない。

メソッドの型は下記を想定します。

template <class LockObject>
Lock<LockObject> lock(LockObject& iLockObject);

C++0x より前の枠組みで素直に実装すると、下記のようになってしまいます。

template <class LockObject>
Lock<LockObject> lock(LockObject& iLockObject)
{
    return Lock<LockObject>(iLockObject);
}

これでは Lock<> インスタンスのコピーが 1 度以上発生してしまいます。RVO を期待したところで、それはコンパイラの最適化ヒントにつき、言語仕様上、上記のコードでコピーを抑制することはできません。

コピー抑制について、C++0x を知る前の自分では、戻り値を std::auto_ptr<Lock<> > として Lock<> を new してしまうことくらいしか、アイデアがありませんでした。負けた気分です。new 演算子を使用する方法では、前者は満足しますが、後者のパフォーマンスに問題が発生します。直感的に、高々ロック処理程度で new 演算子をコールしたくはないと感じます。ロック対象がクリティカルセクションならまだ良いかもしれませんが、たとえば速度重視でスピンロックする場合などは、new 演算子によるパフォーマンス劣化は許容できるものではなくなってしまいます。

いろいろ調べた結果、よりよい解決方法は C++0x の右辺値参照にありました。

右辺値参照の詳細は他のサイトや書籍に譲りますが、概要としては std::auto_ptr のような破壊的セマンティクスを C++ の文法レベルで導入したものです。lock メソッドにおいては、Lock<> にムーブ コンストラクタとムーブ演算子を実装した上で、下記のように実装しました。

template <class LockObject>
Lock<LockObject> lock(LockObject& iLockObject)
{
    Lock<LockObject> aLock(iLockObject);
    return std::move(aLock);
}

これで、Lock<> インスタンスのコピーは抑制され、コンストラクタ以上のオーバーヘッドは、ムーブ コンストラクタ & ムーブ演算子に記載のポインタコピー程度となり、非常に満足いく結果が得られました。

CriticalSection aCs;
{
    auto aLock = lock(aCs);
    // このブロック中はロックされる
}

その後、スレッド関連オブジェクトのロックだけでなく、イメージの画素ロックにも Lock<> クラスを使用するようになり、部分特殊化したテンプレートクラスに画素データへのアクセサを用意した都合上、lock メソッドはもう少し変化していますが、おおむね上記のような感じで収まっています。クライアントコードには変化はなく、当初の目的だった、クライアントコードを極力省略することそれ自体はきちんと達成されています。

んー。C++0x 便利。素敵過ぎます。

Parallel force - パラレル・フォース
～まずは 2D ゲーム用描画エンジン、スレッド周り作ってます。

MSVC10 で C++0x をがりがり使ってます。待ちに待ったラムダ式と左辺値の型推論が便利すぎて涙腺が緩みます。無名名前空間にファンクタ定義する必要もなくなりましたし、自動変数宣言時の型も auto か decltype でほとんど伝播可能なので、すっごく便利。コンテナや配列のループ処理は、ラムダ式が素敵過ぎることから、std::for_each ばかり使ってます。あー、待ちに待った便利環境。std::function も便利。あと、C99 互換の std::int*_t, std::uint*_t が地味に便利です。

ということで、プラットフォーム抽象化パッケージの実装終わり。グラフィックス パッケージは設計がほぼ完了。イメージ クラスの定義とイメージ ローダの定義終わり。とりあえず libpng でお手軽に png だけフルサポートしてみました。現在スレッド パッケージの設計が完了して実装中。並列処理の肝のうちのひとつなので、いつもよりちょっと慎重に進めてます。今日中にスレッド周りも完了かな。ぼちぼち進めています。

現状の設計では、描画周りだけでアホみたいにスレッドが稼動する予定です。目指せ！全コアフル稼働の並列描画エンジン！！扱うデータが大きめなので、キャッシュ サイズの考慮が必要なのがちょっとめんどいけど、がんばります。んー。プロデューサ・コンシューマ パターン考えた人、偉いね。なんだか、いける気がします。

Parallel force - パラレル・フォース
～並列処理、はじめました。

名前だけ宣言しておきます。徐々に進めていきます。内容は近々。プログラム系の話題が多くなると思います。

サークルとして、というよりも齢 30 の節目に Chiharu 個人として、はじめます。

プリンタが壊れました。修理に出しました。数日で直って帰ってきました。結局、一部の人には転居ハガキを出し損ねました。んー。年賀状で対応しよう。

今月分の納品物もまとまりました。上期の仕事は一段落できそうです。

ところで、Intel TBB が密かに私の注目を集めています。あー。ひっさびさのパラダイムシフト。アイデア浮かびそう。

HDD がお亡くなりになりました。

といっても PC 用ではなく年末に購入した REGZA Z7000 に付けていた HDD (Buffalo 製 500GB)です。TV の裏にしっかり隠して配置したつもりが、1.5 歳の息子に目ざとく見つけられ、ここぞとばかりにはたき落とされ、動画再生中にガシャン。勢い余って TV と HDD をつなぐ USB ケーブルも引っこ抜けてました。落とした本人の第一声は「あーあ。」あーあじゃねぇよ。その後 HDD の電源を On にすると『カカカカカカカカカカカ…』という規則的な異音を発して戻ってきません。たった半年程度ではありましたが、我が家の HDD さんは短い人生 (HDD 生？) を全うされていったようです。あー。不景気なのに出費がかさむ－。とりあえず CANAAN は撮り損ねました。飛ばすのもアレですし、今期中の鑑賞はあきらめて秋口から Blu-ray を買おうと思います。

ふむ。しっかし、子供が大きくなるにつれ、REGZA の液晶表面に爪あとができたり (一部が白くなってます)、引っ越したばかりの新居の壁紙が削られたり (この日記書いている時に気づきました)、フローリングを傷だらけにされたり (意外と私持ちの瑕疵も)、まぁ、予想通りの展開ではあるのですが、まさかまさかの HDD 落下でした。(ちゃんと隠したつもりだったのに…)

明日 HDD 買ってこよう…。

結局大事をとりました。

客先からの要請もあり、完治するまでは出社を自粛することになりそう。あまりやる気もおきないため、いつまで経っても片付かない引越し後のダンボールの開墾やら片づけやらをやって過ごしてます。多分、明日いっぱいまで休めば、明後日には全快という感触です。

お腹が痛いです。頭が痛いです。一昨日は母の在所で痙攣していました。盆休みを体調絶不調で過ごしました。人生初の血便体験。医師からはカンピロバクターか O157 だろうと言われました。まだ痛いです。早く治ってほしいです。くぅ。

そんなこんなで盆休み中にやろうと思っていたあれやこれやが全くできませんでした。とってもがっかり。明日から仕事復帰予定です。…、が大事とった方が良いかな。うーん。

(追記) 更新忘れていましたが、今年で私 30 歳になります。みっそっじっ！現在、20 代、最後の一年を謳歌中です。

最近の仕事で、客先のコード (C 言語で 20 万行くらいのコード) を下記の要求仕様のもと、パフォーマンスアップを目的としたポーティングをしていています。1 年以上続いたプロジェクトなのですが、今では検証も佳境に入ってきています。

• 機能は as is
• 同一プラットフォーム上の動作速度 2 倍
• スレッドセーフ
• マルチプラットフォーム対応 (エンディアンの異なるプラットフォームの対応)
• ANSI C 準拠

プロジェクト検討当初から『as is』というのが問題でした。何故なら下記の特徴を持つすばらしい原本を元に開発する必要があったからです。

• 仕様書がない (当然のようにコメントも整備されていない)
• モジュール境界が曖昧 (というかない)
• コードが体系化されていない (サブモジュール化されていない、コピペと思しきコード多数、通ることのない処理フロー多数 etc)
• 書き換え用途のグローバル変数多数 (当然のように各 *.c ファイルから extern されていたりとか)
• 構造体を活用できておらず、メンバに相当する変数について、多くの箇所で unsigned char* 型の変数を任意バイト オフセットの上、任意型にキャストして参照 (または代入) している。(これで構造体のみならず、共用体やら配列やらリスト相当の動作をさせていたりとか…)
• 3,000 行を超える関数多数。(通称ネバーエンディングファンクション。中には 6,000 行に達しようとする関数も…)
• エンディアン決めうちでコーディングされている
• コード中のシンボルに誤り多数 (スペルミスや、全く意味の異なるシンボルが割り当てられていたり…。台形を操作する関数に ～rectangle とか。)
• バグの積み上げによって表面化した動作仕様が多数 (仕様とバグの相違が不明確)
• 初版開発当時の担当者不在
• コードが ANSI C 非準拠につき特定のコンパイラでないとコンパイルすらできない (一部の CPU 向けのコンパイラはコンパイル中にコアダンプ)

結局、プロジェクト離陸前に『ポーティング』は無理と判断し、原本の実装を全て読み下して仕様書を作成し、その仕様書を元に『再実装する』という工程を採りました。先方のマネージャにこの工程を納得してもらうのはとても大変でしたが、今となっては先の求仕様を満たしつつあり、方針として間違っていなかったものと思っています。

このプロジェクトでは、設計を UML (といっても使ったのはユースケース、パッケージ図、クラス図、シーケンス図、アクティビティ図程度) で実施し、C 言語上で OOP を達成するためのコーディング規約を用意して、複数人で実装に取り組みました。調査・設計工程はとても大変でしたが、実装工程に入ってからは、スケジュールあたりの工数がきっついこと以外は、特に大きな問題はなく、プロトタイプができあがったときに、動作速度 2 倍が優に達成できていたときにはちょっとした感動がありました。追加工数によるその後のチューンナップで、結果として動作速度は 4 倍になりました。この速度には先方も大満足でした。そして、当然ですが、新しいコードには 1 関数あたりで何千行もあるようなコードはありませんし、スレッドセーフを妨げるようなグローバル変数もありません。妙なバイトオフセットでメンバ参照することもありません。あってたまるか！

あと、おまけとして、マクロ切り替えすることなくバイエンディアンで動作します。これは『Write Portable Code』の前半あたりにヒントがあります。

振り返ると、よくもまぁ、焦げ付くことなくプロジェクト遂行しているものだ、と自分で自分をほめてあげたくなります。そしてこの提案をよく通したものだとも。当然、私一人の力でなく、先方のマネージャの尽力だったり、うちのスタッフの献身だったり、そうしたものの積み上げでこのプロジェクトが成り立っているわけですが。ただ、たまには自分で自分をほめるのも良かろうと思う次第です。まぁ、これに関わるうちのスタッフ全員、ちゃんと笑ってますので。

ただ、最近になって新しい問題が 1 点浮上してきていて、それは…

• 原本の実装のいくつかの根本機能が数学的に間違っている

ことです。『機能は as is』を考慮してアルゴリズムはそのままにしておいたのですが、一部の根本機能が、致命的なまでに強烈に誤っていて、そこを直すとどこの機能が破綻するのか特定不能というくらいのものです。結局、不況のさなか、先方には申し訳なかったのですが、状況報告の上『機能は as is』の要求仕様から外れるため、実施の場合は別見積もりです、と提示して、別工数もらいました。もう少しこの仕事は続きそうです。

長い前置きでしたが、もし、プログラマを目指している人がいれば、その人たちに言っておきたいことがあります。

• 高卒程度の数学は完全にマスターしておいてください

今回のプロジェクトで分かったのは、画像処理だというのに、本当に、初等幾何や単純な行列計算さえ理解できていない人が多すぎです。お願いですから、行列計算の乗算順序を入れ替えないでください…。アルゴリズム説明中に、2D ベクトルの内積の計算式を質問しないでください…。本当に…。

今期アニメの No.1 は CANAAN かな。

というか、金の力は偉大だと感じます。TBS 系の TYPE-MOON アニメと比べて、フジテレビの TYPE-MOON アニメがこれとわ。金の力ってすごい。いや、本当にすごいのはクリエイターの人たちなんですけれど。腕の立つクリエイターを 1 つの連続 TV アニメに集約できる財力がすごいな、と。なんだかそう思うわけです。とりあえず、OP の CD と Blu-ray は買います。

これは個人的な感想ですが、TYPE-MOON の作品は全て昭和のにおいがします。昭和のテイストを平成の表現力で飾っている、そんな感じを受けます。TYPE-MOON が平成の表現力を得たのは法人化してからですね。表現の部分で外の力を借りてから。サークル中の作品は、テイストのみならず表現力も昭和でしたから。サークルや個人である以上、表現力には限界があります。社会の中でパワーを発揮しようと思うと、お金と人脈が必要になります。これは仕方のないことですし、当たり前のことです。その中でもサークルとしての TYPE-MOON はよくやっていたと思います。

えーと、何の話をしていたんでしたっけ。あー、そうそう。これもやはり個人的な見解ですが、平成よりも昭和の時代の方が日本に (作品に) (社会に) (人に) パワーがあったと思います。私は昭和が好きです。でも、昭和の表現力は古くて貧弱だと感じています。なので昭和のテイストを平成の表現力で飾るというのは、個人的にはすごくアリだと思ってます。

何が言いたかったかというと、むしろ今コンテンツもので売れているものって、昭和を平成でくるんだものばかりだったりして、と思った次第ということです。

(追記) あれ？CANAAN 地元の放送局が東海テレビなだけで、フジテレビは担いでないのか？フィルム買ってるだけ？うーん。とりあえず、早く会社行こう。

この不景気に家を購入しました。一軒家。建売でモデルルーム見に行ったその日に決めました。今、引越しに向けて準備の真っ最中。仕事も大忙しなのですが、何とか引越し中。

大きな決断をするときはいつもそうなのですが、何かに強く引っ張られる感覚があります。引っ張られる方向に行かないと、足場を踏み外すような感覚。今までその感覚に従って失敗したことがないため、今回もその感覚に乗りました。逆に、後から振り返って、その感覚に逆らった場合のことを考えると、結構背筋が寒かったりします。今回、周りから『よく決断したね』とか言われるのですが、私はその流れに乗っただけで、特に決断したという感覚はありません。はい。がんばってローンを返します。

メイン PC で ONKYO 製スピーカーの GX-D90 を使っているのですが、ある程度スピーカーのボリュームを上げない (つまみをひねらないと) と左チャンネルから音が聞こえてきません。入力は光デジタル。PC 側で音質を落としたくないので、PC 側ソフトのボリュームを最大にして、スピーカーで音量調節したいのですが、両チャンネルをちゃんと鳴らそうと思うと、結構な音量になります。GX-D90 のヘッドフォン端子からの出力はそんな症状もないので入力に問題はないのだと思うのですが。うーん。スピーカーってこんなもんなんでしょか。

仕事の話。雑誌社から自社企画α版 (フリーウェア) の掲載依頼がありました。社長と協議の結果、快諾しました。拒む理由もないですし。むしろ大歓迎。うぇるかむうぇるかむです。扱いは one of them だと思いますが、まずは第一歩。がんばれ。自社企画α版！闘え！自社企画α版！！

子供の夜泣きで先ほどまで格闘中でした。うーん。目が冴えてしまいました。

1 歳児の泣き声はなかなか強烈です。まぁ、泣いても可愛いあたり、子供はずるいですよね。(親ばか？) お腹が空いていたようで、スナックパンを少々と水を与えて、子守唄でぐっすり寝ていきました。うーん。寝てる時が一番可愛い…のかな？

自社企画α版が公開の上、vector にも登録された様子。機能はまったく目新しいところのない、一見、地味ーなソフトですが、速度と対応データサイズのスケーラビリティだけは別次元。このサイトが硬派なサイトだったら紹介もできるんですが、今日はこの辺で。いずれ機会があれば、紹介することもあるかもないかも。

今期のアニメは神曲が多いようですね。かくいう私も、アスラクラインと Pandra Hearts の OP を先ほど CD を注文しました。Phantom の ED もかなり惹かれましたが、ちょっと様子見です。神曲というと、タイトルから連想される肝心のポリフォニカの曲が微妙なのがちょっと残念です。せっかく音楽を主題にした作品なのに、音楽いまいちなのはちょっと…。これから良くなるのかな。様子見です。

ところで、今期のアニメのうちのひとつで、主要キャラが私と同名で、そのアニメを見ているとすごくくすぐったい気持ちになります。うーん。他であまり聞かない名前なので、かちあうことも少なかったのですが、うーむ。くすぐったいなぁ。

『とらドラ』さいこーでした。アニメ版がトゥルーエンド、小説版がグッドエンドという雰囲気ですね。あまりにおもしろくて 1 週間足らずで小説の本編全巻とスピンオフ 2 巻を会社の行き帰りで読んでしまいました。アニメ版の最後は心理描写をかなり端折った感もありましたが、許容範囲でしょう。川島亜美の立ち位置の違いがちょっと気になりますが、おおむね小説版の内容を踏襲し、ある部分では補完する形で良く描けていたと思います。小説版は描写が垢抜けない感じがありましたが、アニメ版はその辺がきちんとクリーンナップされている印象を受けました。逆に、アニメ版では淡泊にしか描けなかったものが、小説版で濃密に描かれていたり、なんというか、小説とアニメの双方を同時にゴールインしたので、倍楽しめた気分です。双方の良さがきちんと整理された作品だと感じました。

最近休日を使って自社プロジェクトを進めています。一次開発は今週で完了。リリース内容と提供形態の検討は社長のタスクだけれど、うまくいけばα版等、近々お披露目かな。小粒だけれどキラリと光るツールになる見込み。このサイトの性質から、多分、直接リリース製品へのリンクや紹介をすることはできませんが、願わくば多くの人の手に渡りますよう。

1 つ前のクールから見てますが『とらドラ』さいこーですね。たいが、かわいいわ。ラブでコメい話は大好きです。あと『夏目友人帳』の『続』も相変わらずおもしろい。

不況だけど、今期のアニメは豊作だなぁ。『とらドラ』は BD 出たら買っても良いなぁ。今 DVD 買う気しないので…。

みなさん、あけおわりまして、おめでとうございおわりました。今年もよろしくお願い申し上げました。

年が明けたら不景気真っ盛りでびっくりです。うちも主要取引先が製造業ということもあり、結構かつかつです。年商減って役員報酬だだ下がりです。まぁ、役員報酬変わったところでモチベーションが変わるものでもないので良いんですけど。

ここまでは会社立ち上げ時のロードマップ通りきてるので、今年、自社製品がんばって作ろう。現時点で 1 本、企画と設計はできていて、実装も進んでいます。きちんと日の目が見られれば、今までにないコンセプトのツールが世に出ていくものと思ってます。これは私の勝手な想像ですが、IT 系については、高価な多機能よりも手頃な高機能が売れる時代だと思ってます。よく『選択と集中』という言葉で雇用状況を伝える報道がありますが、製品コンセプトにこそ、それが必要だと感じています。

• 選択: 使うかどうかわからないものが詰め込まれた多機能よりも、本当に使う機能だけに絞られたもの。絞った結果、安価であること。
• 集中: 機能を絞った分、品質の高いもの。品質を向上させた結果、付加価値を感じられるもの。

と。そう考えています。上記を達成する製品が、今後ヒットしていくんじゃないかなー、と。がんばろー。

『紅刻の唄』は、まだペンディングが続きます。申し訳ないです。今は、生きる (会社を離陸させる) のに必死の状況です。

「かんなぎ」休載は「作者入院のため」　発行元が説明、「中傷で休載」は否定

騒動は杞憂だったかな。けど、入院するほど体調崩していたとは。しっかりと休養して、万全の状態で復帰してもらいたいと思います。

年賀状書きました。今年は秋頃に EPSON の本気を感じて EP-801A を (発売と同時に) 購入したので、その画質にわくわくてかてかしながら印刷してました。色変換の設定で試行錯誤はあったものの画質は良好。今年は子供を前面にアピール。かわいいなぁ。と、宛名を印刷して気づく。そういえば、高校の同級生に出産の連絡してない。

…………………………………いかんじゃん (三河弁)

お詫び必至かなぁ。

仕事の終わりが見えてきた。無事に年が越せそうです。よかったよかった。

今回の開発は特に『マルチプラットフォーム開発は潜在バグの発見に役立つ』ということに気づかされる開発でした。大変な開発だったけど、良いものが出来上がったと思います。あと、お手軽にマルチプラットフォーム展開目指すなら float は駄目だって悟りました。プラットフォームによって精度が大きく左右される型の扱いはもうちょっと熟練しないときついかも。今回、必要な桁数に対して float の仮数部がぎりぎり足りるか足りないかくらいで、プラットフォーム間の計算誤差が顕著に出てしまうという状況に悩まされました。速度重視ビルドでは float で、精度重視ビルドでは double で計算できるようコンパイルスイッチ用意して解決しました。まぁ、大きな配列をとるような処理ではないので、FPU があれば動作速度に大差ないのですが、FPU がないケースを考慮すると、float に比べて double のシミュレーションは重いのでスイッチ必須でした。

あー、そろそろ年賀状書かないと。今年は子供の写真かな。

「かんなぎ」無期限休載の背景に「怒りのオタクが抗議」説

これ本当だとしたら、実力行使した人はちょっとやり過ぎだと思いますよ。私もファンなんですが、この件で作者を非難する気持ちにはなれないですね。

「かんなぎ」の作者はアンソロジー本の頃から注目してたんですけど、初の連載でこの騒動だと、もしかすると立ち直れなくなるかもしれないと心配してます。センスある作品を世に出せる数少ない貴重な作家だと思ってます。どうか気を落とさないで欲しいと願います。こうした激しい抗議活動も愛されていればこそだと感じる度量を…、ってのを今の作者に求めるのも難しいでしょうね。まだ作家として駆け出しですし。この記事が本当なら当人ショック大きいと思いますよ。しばらく何もできないんじゃないでしょうか。ご飯はちゃんとのど通ってるだろうか。出版社もちゃんと作家をまもってあげなよー。

私は 2ch は見るだけで書くことは一切しませんが、紅刻の唄のリリース後、2ch での叩かれようを目の当たりにしたときは、さすがにちょっと凹みましたし。注目されると言うことはそういうことだと覚悟はしていましたが、こういうのは慣れるまで時間がかかりますね。最終的には達観するんですけど。そうするしかないので。

これは個人的に感じていることですが、「かんなぎ」からは「ぼくのマリー」と似たような空気を感じてます。初めて持った連載に手持ちのすべてを投入している感じ。一般的な男性向け漫画にありがちな男性のための女性像でなく、肝心なところで男性をつきはなすちょっと人間くさい女性像が特徴的だと感じています。処女がどうだと騒ぐ人もいるようですが、私はむしろこういうところにも作品の良さを感じていただけに、今回の騒動と現状は残念でなりません。作品批判は大いに結構だと思いますが、実力行使の抗議活動はただの嫌がらせです。

長くなりましたが、Chiharu は「かんなぎ」を夫婦で応援してます。作者さん、くじけないで。

あー。仕事の締め切りせまるよー！！(心の叫び)

お仕事の話。

現在、うちの会社の一番の大口顧客から、継続案件の契約が締結できそう。よかった。不況のさなか、忙しいながらも継続してお仕事がいただけることはありがたいことです。

次の案件の目玉は…『速度』…、ということで。

あー。きちゃったよー。私に対して『競合他社より高速に…』なんて言われたら、リミッタ解除しちゃうよー。心のリミッター。まぁ、なんと言いますか、ゲームプログラマって基本『スピード狂』だと思うのですが、私もご多分に漏れずその類です。あー。今組んでるモジュールで、設計レベル、アルゴリズムレベル、コーディングレベル問わず高速化アイデア浮かびまくりでうずうずしてたところ。今の契約の要求速度は割と普通に達成できるのでそれらの高速化アイデアほとんど未着手だったんですが…、次はいきますよー。他社ぶっちぎっちゃうよー。

私の仕事上のモットーは『お客さんの期待の右斜め上を行くこと』です。まぁ、お仕事ですので当然その分コストはいただくわけですが、お客さん自身が発注時にご自身の要求内容が把握しきれないということを常に念頭に置いてます。なんだかお客さんをなめた発言に聞こえるかもしれませんが、弊社として実現しておかなければならないクオリティというのがあります。これまで経験したたいていのお客さんは、最初に A を要求された後、契約終盤には A' や B を要求していることが多いです。しかも、最初から A' や B を要求していたという認識の元。ま、この状況が発生することが事前にわかっているのであれば、こちらも A を要求された際に A' や B あるいは C を開発することを念頭に契約を結び、スケジュール進行させるわけです。契約上、完全なお客さん主導でなくなるため、最初は『下請けが偉そうに』と思われることもありますが、付き合いが長くなるとこのスタンスは結構重要だったりします。何事も相互に気づき、気づかせてあげることが重要です。付き合いが長くても、会社間で強力なトップダウンを要求されることもあります。その場合はさすがに『右斜め上』なんて考えは持ち出さずに『契約当初に言われたとおりのこと』を実践します。結果は当然『言われたとおりのこと』ができあがるだけです。それがお客さんの要求の本質かどうかはともかくとして。

今おつきあいしている会社のほとんどは、上記スタンスについて『つーかー』になりつつあり、話の通りが速く、ありがたいかぎりです。

話がそれましたが、次の案件は血湧き肉躍る内容です。がんばるよっ！

THUNDER FORCE VI を購入!

TF は大学時代に V でその音楽と演出に惚れて、IV からプレイし直して、その世界観にも惚れたものでした。なんというか、TF シリーズのファンです。その続編が 10 年越しでリリースされるということで、わくわくしながら予約して購入しました! プレイしました!!

感想。

……………………………………………、なんだ、これわ。

えー。音楽、グラフィックス、演出、ゲーム性。ほめるところがないんですけど…。

私は元々シューティングは好きな方ではなく、プレイ本数も少なく (TF、レイ、どんぱちシリーズくらい)、だからなのかなぁ、シューターではないせいか、全然琴線にきませんでした。仕事が忙しく、それでも好きなシリーズだからと、ない時間割いてプレイしたのですが、なんだか時間とお金を返してほしい気分になりました。正直がっかりしました。何が駄目だったか、ではなくて、何が良いのかさっぱりわからないゲームでした。BROKEN のときは正直、同人だからとあきらめていましたが、プロの仕事でこれはなかろうと。プロの仕事に二次創作は求めてないんですよ。TF を題材にした手慰みのゲームじゃなくて、TF を作ってほしかったんです。このゲームをプレイしてファンとして悲しくなりました。ゲームってもうちょっと夢とか希望とかを振りまくものだと思ってたんですけど。最近は違うんですね。

まだ手元に TFV の CD だけはあるので、サターンを買い直してプレイしようかと、本気で思案しています。ふむ。

TV アニメ版の我が家のおいなり様。最終回にして気づいたこと。

男性陣、みんな着物と浴衣のあわせが逆だね。これじゃあ死に装束では？うーん。細かいこと気にしすぎなのかな。

訂正。私の理解が逆だったようだ。男女で逆だったように記憶してたんだけど。間違いだったのかな。20 年間以上も間違い続けていたのか。…というか、私も男性キャラの和装は右前で描いていたじゃないか。うーむ。もうろくしてきたかな。

仕事の話－。いい加減、設計ばかりでアーキテキター。

夏目友人帳いいですね。わたしあの話好きです。わびさびっていうか。いいですね。

仕事で、高速処理のために MMX (今回使用したのは MMX2) を使用するプログラムを書きました。汎用レジスタ割り当ての最適化が面倒だったため、アセンブラではなく C で組み込み関数を使用したのですが、コンパイラに gcc4.1.2 と VC8 とを試したところ、生成されるアセンブラ コードがあまりにも違って愕然としました。gcc4.1.2 の方は素直な出力で問題なかったのですが、VC8 の方は、スループットとレイテンシって言葉知ってるかい ? って顔をしかめたくなるくらいにはお馬鹿な出力で大変がっかりました。

8 本ある MMX レジスタをきっちりかっちりぶん回す C のコードを書いたのですが。コンパイラにやさしくなるよう、わざわざ MMX レジスタ用の自動変数を 8 個宣言して使いまわしたんですけど。8 本すべて使いまわすために親切にもループ展開したんですけれども。えーと、C で記述した組み込み関数部分をそのままアセンブラに置き換えれば最速コードになるように記述したんですけれども。残念ながら VC8 では何故か処理の途中で、MMX レジスタ同士で不要なコピーを繰り返すコードが生成されてしまい、同一レジスタに連続クロックでアクセスするコードになっていて、大変がっかりしました。

MMX のすべての演算は 1 クロックで呼び出し完了する (うろ覚えだけど確かそう) のですが、実行完了するまでにかかるクロック数は 1 ではありません。実行完了するまで演算中のレジスタにはアクセスできないため、当該レジスタへのアクセスは処理待ちのペナルティが発生することになります。で、先のコンパイラの話に戻ると、C のコードでは、当該ペナルティが発生しないように演算の実行順序を工夫していたのですが、VC8 が親切にもペナルティ発生しまくりのコードに書き換えてくれたのです。当該コードについて、実際に同一 PC で gcc4.1.2 ビルドと VC8 ビルドのバイナリの実行時間を比較すると、1 割以上 gcc4.1.2 ビルドの方が速かったです。まぁ、なんと言いますか、がっかりした一日でした。

まぁ、今回はベタ C でカリッカリにチューニングしたコードとの比で、MMX 使用コードが 2 倍以上のパフォーマンス出したんで良いのですけど。VC9 だと改善されているのかしらん。

常用するブラウザを IE7 から Firefox3 に変えてみました。ウェブ ブラウジングがすごく快適になりました。たまにレンダリング結果が崩れるサイトがありますが、これはウェブ サイトのつくりの悪さが原因ですね。みんなちゃんと W3C の勧告に従いましょう。ということで、ぼちぼち使っていきます。

いそがしー。

ま、忙しいなんてのは甘えで…、なんて議論もありますが、まぢめに忙しいっす。誰か、上流やってほしい…って思うくらいには。ドキュメント書ける人が少なすぎるよ、この世の中。みんなちゃんと数十ページ程度の日本語を書けるようになろう。あと、IT 系の技術者なら UML2.0 くらいはちゃんと読み書きできるようになろう。自分の身の回りでは、できない人が多すぎです。

スケジュール切って、調査してレポート書いて、仕様書書いて、実装もして、他人のコードのチェックして、テスト仕様もチェックもして、テストコードのチェックもして、納品して。挙句案件掛け持ちで、休み中にも仕事して (形容矛盾)、ちょっとやること多すぎますねん。人の手借りられるのが実装フェーズ以降だと、ちょーっと厳しい時期もあって。今、かなりげんなりしています。孤軍奮闘っちゃ、このことかっ ! うーん。そろそろスタッフのスキルアップを検討しようかな。

もってっけー♪ (←現実逃避)

仕事忙しすぎです。いや。なんていうか。忙しいだけならいいのだけれど、結構滅入る系の。業務でお客さんのコードを手直ししているんですけど、これがまた…。ホントに、日本のプログラマってこんなにレベル低いのか、ってーコードとお付き合い。うちの会社にはこれだけ汚いコード書く人いないなぁ…。というか、うちでこんなコード書く人居たら小一時間説教かなぁ。まぁ、ある意味感心するコードではあります…。心臓に悪い…。

これまで 1 年程度 Let's note CF-W5 の Windows Vista モデルを使い続け、その遅さに耐えて耐えて耐え抜き、SP1 のリリースを待ちましたが、このたび Windows XP にダウングレードしました。つーか、Vista 重すぎです。特にディスク周り。確かに SP1 で速度向上しました。体感できました。ファイル コピー時間が半分くらいになりました。…ですが、数 kB かつ数個のローカル ファイル コピーに 10 分 (ワーストケース) かかっていたものが 5 分程度になってもうれしくも何ともないんですよ。ぐがー！！

ということで、Windows XP に移行しました。SP3 も入れて快調に動作しています。先のファイル コピーも 1 秒未満で完了します。当たり前です。これが求めていたレスポンス。というか、よくあんな遅い環境で今まで開発やっていたな、と。自分で自分をほめてあげたいです。いろんな意味で。

GW も最終日。イベント尽くしでちょっと疲れました。楽しかったですけど。

お仕事の契約更新が無事に進みそうだ。よかったよかった。

アパート暮らしのため、出産の挨拶 (これからちょっと騒がしくなるけど、よろしく的な) をご近所にしようと思って菓子折りを用意したのは良いけれど、うちのアパート、日中、人の気配なさすぎで、挨拶のタイミングがぜんぜんつかめません。ちょっと難儀。そもそも社交的な行動自体が苦手なのもあり、結構緊張気味です。がんばろう。

ぴりぴりするのは花粉症によるところが多そう…。やっぱり心身ともに健康って重要ですね。

子供が産まれてから思い出したのですが、私の手の親指の第一関節は曲がりません。また、第二間接も真っ直ぐに伸びません。不便があるのは、ペンをある方向にだけは安定して進められないこと。ペンを使うとき、意外と親指って使います。もうひとつは鍵盤楽器がうまく弾けないこと。決定的なのは 1 オクターブ離れた音を片手で弾けないこと。親指の第一関節を曲げて第二間接を伸ばして、親指と小指で弾かないといけないのですが、それができません。親指の第一関節が曲がらず、第二間接が満足に伸びないため、ド + ドを弾こうとするとドレ + ドとなります。小さい頃エレクトーンを習っていたのですが、親指を使う音がぜんぜんうまく引けずに、長続きしませんでした。当時はそれが疾患であるという理解が私にも親にもなく、ただただ「なぜ弾けないんだ！」と叱られて親にひっぱたかれながら泣きながらエレクトーン弾いてました。当たり所が悪く、涙と一緒に鼻血を流しながら弾いていたことも多かったと、当時をなつかしく思い出します。絵的に結構壮絶だな、と、改めて。

ま、生活には支障ないため、動かないなりに今の私は自分の体と付き合うことができているのですが、子供に遺伝しました。結構ショックでした。が、「赤ちゃんの早い時期に治療すれば、ちゃんと治ります」と医師に言われたのでホッとしています。がががっ！、じゃあ、私のときは何も手を施していなかったってことかっ！と、ちょっと残念な気分になってみたり。ま、今更いいんですけどね。

ところで、最近絵を描いていないです。余裕がないみたい。契約更新時期はぴりぴりするなぁ。

契約でトラブルか。詳細は書けませんが、仕事でトラブルなんて久しぶりだなぁ。まぁ、今回のはトラブルのうちにも入らないような気もするけど。ということは、うちの会社は結構順調なのだろうか。うん。多分そうに違いない。

突然ですが、Windows の ClearType (フォントのアンチエイリアシング機能の一種) は水平方向にしかアンチエイリアシングしないんですね。まぁ、オーバースキャンの手間を考えると、実行コストがその方が軽いんですけどね。水平方向のオーバースキャンはスキャンライン時の交点計算を固定小数化することで実現できますが、垂直方向のオーバースキャンは単純にスキャン回数を増やす必要がありますので、計算コストがα値の分解能 (階調) に比例して計算コストが増えることになります。なので、この実装は理解できなくはないのですが、これだと水平方向に傾いている (水平ラインに傾きが近い) 形状の文字はほとんどアンチエイリアシングされないことになります。英語フォントだと、真横と垂直方向に傾く (垂直ラインに傾きが近い) 成分でそのほとんどが構成されているようで、ClearType も有効だと思うのですが、日本語のように縦にも横にもグリフが伸びているような文字はあんましキレイにならないですね。例えば“ら”の 1 角目など、アンチエイリアシングあってもなくても変わらないんじゃないか、と。そうした箇所が日本語には多いな、と。Vista 上でメイリオ フォントを見ていてそう思いました。縦横方向に正直にアンチエイリアシングしている MacOS X のフォント表示はキレイだな、と。そう思いました。いや、ホントにふと思っただけなんですけれどね。

何故か掲示板へ書き込みができない…。掲示板サービスのフィルタになにやら引っかかっている様子。ということで、掲示板に返信できなく申し訳ないです。わが子への祝福のメッセージをくれた方々、ありがとうございます。頑張って生きていきます。kokonowo の件も本人から話を聞いています。完全復活までまだ時間がかかりますが、どうか気長にお待ちいただければと思います。

最近、PowerPC (Linux) の組み込み開発で、クロス環境を構築しているのですが…、めんどいですね。PC 用アプリ開発に慣れた身としては、『開発ツールをコンパイルする』という発想がなく。いや、ライブラリくらいならやるんですけど、コンパイラをコンパイルするところから、というのは経験がなくて、ちょっとびっくりしました。そんなこんなで現在クロス環境構築中です。コンパイルなかなか終わらないし、コードにパッチしないとすぐにコンパイルエラーになるし。組み込み (特に Linux) 開発ってかなりマゾいなぁ、とか思いました。がんばろう。

最近、レンマギとシゴフミにハマってます。(といっても、TV アニメみたり、小説読んだりする程度) レンマギは小説の方がアニメよりも断然面白いですね。アニメ版は回によって当たりはずれが激しいです。原作についても、原作者が作中で日本語に不自由している感があるのが玉に瑕ですが、アイディアはとても良いと思います。シゴフミは TV アニメしか見ていませんが、とてもグッドですね。OP の歌も良いし。話も私好みでグッド。ダウン系が好きなようです。(ダウン系 !?)

とっても久々の更新。あけ終わりましたし、おめでとうござい終わりました。

子供が産まれました。名前は明かせませんが、元気な男の子。ここ一ヶ月くらい生活がばったばたでした。

久々の更新です。すでに日記ですらなく月記も超えました。はるか銀河。

今日、久々に休みをとって、免許証を更新してきました。私の誕生日は 12 月なのです。射手座なのです。めざまし TV では順位が低いことよりも、あやパンに読まれないことの方が結構ショックだったりする年頃なのです。…で、免許証を更新してきたのですが、更新したての真新しい免許証をよーく確認すると…、本籍が違う…。

…。

あー。結婚してから『住所変更』は届け出たけど、本籍変更は警察署に届け出てないなー、ということに気づく。かるく凹みました。来週、また休みとろう…。

自社企画発動。

…仕事の話です。技術立国日本の意地を見せていきますよ。

でもね、最近目を酷使しているみたいで、目の調子がすんごく悪いです。細かいものを見るとチカチカして目を開けていられません。ひどいときには、相方の車の助手席に乗っているときに、フロントガラスにひろがる景色が、電線やら電線とかたくさんの車が目に痛くて、目を閉じていないと車に乗れないです。学生時代からそういうことはちょいちょいあったのですが、流石にちょっとケアしないと拙いかなと思い、少しずつ目の使用時間を短くするようにしてます。今もテキスト エディタがチカチカしています。ケアしなきゃ。

少しずつやるぞ！という気になってきました。

…仕事の話です。人間、やりたいことをやるのが一番。ふふふ。今に見ていろ! とかほくそ笑んでみたり。誰に宛てた言葉でもないですけど。そんな気分です。がんばろう。

p タグの p はプチ (petit) 愚痴り大会の p かな。

仕事で受託の工数合わせにちょっと疲れました。

何というか、私にゃ営業はできないですよー、とすごく思います。ノルマって言われてもねぇ、的な何か。目の前にある業務に対して正しい見積もりを出して遂行するスキルと、お客さんから仕事を引き出すスキルはまったくリンクしていないので、前者できるからって、後者を期待するのは、すんごく違う。後者に手を出すことで前者がおぼつかなくなるディスティニー。でも、そうはいっても自分の会社なので、何とかしないと。

ふぁて、れあるたぬあ、を読了。

良かったです。とっても。ところどころ声優さんによる漢字の読みが統一されていなかったり、話の流れに対して言葉のイントネーションに違和感を覚えることもありましたが、いや。よかったです。最後の追加シナリオに、ちょっと、感無量になりました。良いと思う。あれわ。

コンテンツ部分が良いのは当たり前だと思ってるんですが、それ以外のところで、あんだけメモリとストレージが貧弱な環境で、VGA の 2D 画像をよくもまぁあれだけローディング時間を隠蔽して動かせるね、とか思ってました。どこかの『ひぐ～』とはえらいちがいだ、とか。地味なところですが、こういうところの作りこみがストレスのないプレイ感を生むのです。いやはや。私も見習わないと。

日記にすらならず、月記さえ超えました。

最近、仕事で疲れているせいか、本来休日である土日のうち、片方をダウンしてしまいます。先週は相方のご両親と一緒にお出かけをしたのですが、出先で立っていられなくなってしまい、しばらくベンチで座り込んでいました。子一時間ほど休憩したらまた起き上がれるようになったのですが、先方のお宅に上がってすぐにまたダウン。情けない姿を見せてしまいました。

もう少し体力をつける必要があるのか、働きすぎなのか、判別つかないですが、現状もうちょっとなんとかならないものか、と思います。

PC を買い換えました。

DELL の Dimension 9200C というやつです。本体だけ使ってます。キーボードもディスプレイもマウスも、みんな本体付属でないものを使用しています。ワイヤレスにこだわったため、とり回しがよく、大変使い勝手がよいです。ネットワークも無線。マウスもキーボードも無線。USB 接続もハブで線の集中箇所を分離して、なかなかすっきり収まっています。使わなかったとはいえ、ディスプレイも付いてきたのですが、いまどきの PC は安いですね。いい時代になったものだ…。

ひぐらし PS2 版について。(以下ネタばれ含みます。)

えーと、昨日の日記で書き忘れたことです。羽入の最期。それなんてセイバー ? って。思いました。すんごく。

ひぐらし PS2 版、読了。(以下ネタばれ含みます。)

全体的に、作りこみが甘いです。誤字、声優による漢字の読み間違い、テキストと声の不一致。イベント画とテキストの不一致。まぁ、ここまでは凡ミスなのですが (凡ミスだからこそ、この程度のことを残しておいてほしくなかった…)、個人的に納得いかなかったのが、ジジ抜きを美としておきながら、最終的にババ抜きとして話をまとめたこと。また、原作と大きく異なる一部のキャラの立ち位置。そのどれもが納得いかなくて、今、原作の祭囃し編を読んでます。

PS2 でリリースするにあたり、原作においては審査のクリアが難しい表現のある最終章でしたが、だからって PS2 版であんな風にまとめる必要なんてなかったじゃん ? て、一読者としては思うわけです。

多分、問題は、ゲームからゲームへのリメイクだから、このような感想になるのだと思います。これが、小説から映画への展開であったら、描写不足や解釈の違いも、あるいはそれらしく受け取れたのだと思います。そういう意味では、心を大きく持ったとして、その場合は上記の凡ミスこそが許されない欠点ということになるんですけどね。

個々の構成は良かったと思います。声優陣の熱演も良かったですし、刷新されたグラフィックスも、キャラ絵も基本的には好感の持てるものでしたし。とにかく詰めの甘さが、なんだかなぁと、残念な気持ちにさせてくれます。惜しい、の一言ですね。

さて、ひぐらしをプレイしていると、大学時代、岐阜にいたときのことを思い出します。大学の近くの不動産屋さんでシステム管理のバイトをしていたのですが、当時そこのおばちゃんにとても良くしてもらい、しばしばお手製のおかず等をもらっていたのでした。特に印象深いのがサトイモの煮っ転がしで、それがすごく美味しくて、ルームシェアをしていた友人と一緒に食べたときお互いに、一瞬言葉をなくし「本物だね。うちらが今まで作っていた煮物って何だったんだろう」って話をしていたことを思い出します。タッパーいっぱいに詰めてもらったのですが、その時はふたを開けて 5 分くらいで完食しました。本当に美味しかったなぁ。

復活。

会社用のノート PC を Let's note CF-W5 にしました。今まで使っていたノートよりもキーピッチが変則的で慣れるのに少し時間が掛かりそうですが、久々の新ハードでわくわくです。

今後の業務で開発対象 OS になる可能性もあるので、人柱覚悟で Vista Business 搭載版にしたのですが、Aero が意外と曲者で、Aero を有効にしていると、キーボードが触れないくらい熱くなります。まぁ、あれだけのシェーダを常時動かしているので、チップセット (Intel Chipset のグラフィックス機能) が熱くなっているんだろうと思うのですが、触れません。熱くて。有効にしているとバッテリ駆動時間も短くなるということで、Aero は已む無く無効にしました。あと、Office も 2007 にしたのですが、Excel がよく落ちます。Explorer も日に数度落ちます。まぁ、まだまだ人柱専用 OS って感じですね。意外と Visutal Studio 2005 はすんなり動いているので、まだ致命的な状況はないと安心しています。がんばって使っていこうと思います。

Kaspersky は返品しました。結局、自宅 PC にはウイルスバスター 2007 を入れました。ライセンスが余っていたので。まぁ、何と言いますか、特にトラブルなく動作してます。うーむ。これが実績ぱわーなのでしょうか。業務でも使用していて勝手が分かっているので、安心して使ってます。

体調不良ふたたび。

昨日がピークだったのですが、頭痛がひどいです。多分夏風邪だと思うんですが、今日も症状が少し残っていたので大事をとって欠勤。欠勤しても、在宅でできる仕事をしてたりするんですけど。まぁ、できるといってもスケジュール調整とか仕様書検討する程度ですけどね。こんな状態でコードは書けない…。まぁ、折角欠勤したんだし、きちんとベッドで休もうかな。

文字きれい !

D 端子、結局買ったらしいです。接続したようです。いや、ホント。体感できるとかそういうレベルじゃないです。これまで PS2 なめててゴメン。相方からも、「あー。ひぐらしの文字読めるようになったねー。」とコメント。ケーブル一本で全然ちがうものなんですね。

PS2 版ひぐらし。大変、目がちかちかします。

ところで、常々文字が読みにくいと思っていたんですけど、PS2 版。Fate やる前になんとかしたいと思っていたところ、これ、接続ケーブルによってかなり画質って変わるものなんでしょうか。うちの TV は SONY 製の 32 インチくらいのフラット トリニトロン (地デジ普及する前で、フル HD 対応じゃない液晶を買う気がしなかったのでブラウン管に走りました) なんですけど、D1 とか RGB マルチとかって口がついてるんです。今は PS2 に標準添付の赤白黄のコンポジットケーブル使ってます。もしかしてこれを、その、D1 とか RGB マルチとかに変えると、ノベル系の文字がくっきりはっきり読みやすくなったりしたりするんでしょうか。(技術系の人とは思えない素人炸裂のコメントですね。)

ぐぐってみると結構、画質に影響あるとか書いてあって…。あー。だめだ。ケーブルをしょーどー買いしそう…。でも買うにしてもどっちを !? もし、明日以降の日記で『文字きれい !』とかって書いてあったら笑ってやってください。

補足。

Justsystem の名誉のために言いますけど、サポセンのスタッフの対応は大変丁寧でした。5,000 円程度のソフトであれだけのサポートを受けられれば十分だと思います。問題は製品の品質だけでした。いや、それが一番の問題じゃないかと言われればそうなんですけど。私見ですが、OEM (特に海外の) だからどうしようもないんじゃないかと。

終わった。Kaspersky。

先日、サポセンから設定変更して常用できないか打診がありました。ログの解析結果で、Kaspersky の一部の機能と、PC の BIOS やらドライバやらがコンフリクトしているとのこと。で、それを切ると動きます、と。うん。動くんだけどさ。先週試したから。

ある程度予想していた回答ではありましたが、『なんか相性問題でブルーバックになることもあるみたいなんで、その機能切って使ってみてください (メールは大変丁寧なんですけどぶっちゃけるとこんな感じ)』て。ごめん。技術者のカンなんですけど、それ、他の機能も同様の危険性^(●)を孕んでいて、たまたま動いているって状況だと認識しちゃうんです、私。

そんなわけで、Kaspersky の常用を断念。来週末くらいに別のウィルス対策ソフトを導入します。

色々使ってきたけど、バスターが一番安定してるかな。安定して不具合があり、安定して遅く、安定して問題があり、けど、致命的なものはあんましない。長いこと付き合っていくソフトだし、実績のあるものに戻ります。5,000 円はちょっと高めの授業料でした、と。それ以上に、めちゃめちゃ忙しい時期に費やした時間が惜しまれるぞと。多分、Justsystem は悪くないんですが、看板背負っちゃった以上は Kaspersky も Justsystem 製品だから。製品の導入はまたの機会に。あでゅー。

• ここで言う危険性は「その他の処理が問題のある箇所と同程度のクオリティ」ってこと。まぁ、気にしすぎってことは分かってるんですけど。(うーむ。IE は CSS の生成コンテンツ使えないのか…。)

続くよ。Kaspersky。

先日、サポセンから連絡が入り、受け渡し方法が確保できないとのこと。謝罪コメント付きだったけど、うーん。じゃあ何で、完全ダンプを指示するかな。さすがにちょっとイラっと来ました。愛機をわざわざダウンさせているのに…。何より、この再現テスト。一回あたり 3 時間くらいかかるんですよ。わざわざ愛機を痛めつけるためだけに 3 時間かけて…、まぁ、いいけどねぇ。

で、以前のログの解析結果が出てきたみたいで、IAA と RecordNow! を更新してみて欲しいとのこと。ちょっと調べてみると、IAA って途中でモジュール名変わってるのね。知りませんでした。ちゃんと同一ソフトウェアのバージョンアップかどうかを確かめるのに小一時間かかりました。で、更新してみるも、ブルーバック再現。うーむ。

コレで直らない場合は Kaspersky の設定をかえて完全スキャンを実施してみて欲しいとのこと。えーと、今回は 2 パターン来たんですけど、一方は成功。もう一方は失敗。朝の 9:00 頃から始めて、終わったのは 15:00 頃でした。その間、愛機を使用できず。休日仕事をするとき (形容矛盾) には、仕事用 PC を使うのですが、その後ろでいつも音楽を愛機でかけるので…。今日は音楽を聴けず、ストレスでした。

ブルーバックのメッセージも送って欲しいとのことで、仕方なく、ブルーバックの画面を見つめながら別 PC でメッセージをテキスト化。先ほどサポセンに送付しました。

まぁ、あちらも工数かけて対応してくれているとは思うのですが、こっちも手間隙かかって。かるーく検証スタッフみたいになっているね、お金欲しいね、と後ろから相方のヒンヤリした声が聞こえましたとさ。

Kaspersky のサポセンから返信があり原因不明とのこと。まぁ、そうだろうなぁ。で、再現テストと再現時の完全メモリ ダンプの提供を求められて実施するも、メモリ ダンプ ファイルのサイズが 1GB あって (完全だから当たり前なんですが) 受け渡し方法がなく、再度問い合わせ中。今月いっぱいやりとりして、駄目だったら他社のソフトの導入を検討かな。個人的には Justsystem を応援したいんですけど。

スパム メールってなくならないものでしょうかね。毎日 50 ～ 150 通くらい来るので、大変辟易していたりしていなかったり。今時スパムにひっかかる人なんているのかな。う～ん。

仕事用ノート PC (Windows XP) が起動直後、操作を受け付けないようになってしまいました。

…と、思ったら反応が異様に重いだけ。クリックを 2 ～ 3 分くらいのラグで受け付けるみたい。『まさかウィルス !?』と思って 5 分かけてタスクマネージャを見てみると、cidaemon.exe というプロセスが CPU を占有しているようで。ぐぐってみると Windows の検索インデックス構築用のサービス アプリとのこと。つーかさ。バック グラウンド サービスが CPU 占有率 100% てどうなんでしょ。途中、インデックス構築の合間合間で Sleep するなりして CPU 占有率を低い状態で実行させようとか、設計段階でそういうこと考えなかったんでしょうか、Microsoft さんは…。

まぁ、当該 PC には、申し訳程度にウィルス バスターも入れてあって、ウィルスでないのが分かったのは良かったのですが、Microsoft 君の設計のアレ具合にちょっと首をかしげてしまいました。Vista だと優先順位の低い I/O とかいうので、ちょっとは改善されているのかな。

久々に出社。意外と仕事できるものだ。休日中に仕事してたのでなまっていないだけなのかもしれない…。

今日は、夫婦一緒に私の実家 (ではないんだけど、とりあえず実家で) に帰省しました。母も妹たちも元気なようで、なかなか楽しい一日でした。

Kaspersky の続報。ジャストシステムのサポセンの指示で、さらにシステム情報の収集用アプリを使ってログを作成し、今朝送付したところ、昼ごろ返信があり『原因の調査に一週間以上かかる』とのこと。まぁ、難しいだろうなぁとは思ったけれど、やはり、という感じ。それにしても、GW もサポセン稼動て。担当者さんはご苦労様です。まぁ、私も休日に仕事 (だから形容矛盾だって!) してたりするわけですけど。

時間は掛かっているけど、丁寧なサポートで特にストレスは感じず。ウィルス対策ソフトってやっぱりサポート大変なのね、と感じるくらいで。

昨日、大学のサークル仲間と集まって公園で遊びました。もちろん相方も一緒です。年がたつごとに、だんだん子連れ率が上がってきて、うちも続いていければなぁとほんわか思いました。子供と一緒に遊ぶのは楽しいね。

途中抜けした友達の子供が、去り際にお母さんに抱かれながら、集まっていたみんなの顔を見てぐずっていたのが印象的でした。まだ帰りたくなかったみたい。子供たちも、大きい子はそろそろ自己主張するようになってきたなぁ。

Kaspersky のハングアップ問題がなかなか解決しない。長丁場かな。気長にがんばろ。常用している分には問題ないところまでは来てるし。

ところで、Kaspersky サポセンからのメールが Kaspersky によりスパム メールだと判別されたのは新手のジョークなのでしょうか。

• 元タイトル … 【Kaspersky】お問い合せの件につきまして
• 受信タイトル … [!! SPAM] 【Kaspersky】お問い合せの件につきまして

ちょっとびっくりしました。

昨日の続き。

ジャストシステムのサポセンの指示に従い、セーフモードで Kaspersky を起動し、完全スキャンを実行。動くねぇ～。セーフモードでディスク周りが正常に動作するということは…、HW じゃなくてソフトウェアが問題なのかな。さすがサポセン。あたりのつけ方がうまい。

次いで、システム情報のログを採って先方に送付。送信前にログの内容を確認してみると…。インストールされているソフトウェア一覧が csv 形式でずらり。あぁ。ひぐらしとか顔のない月とか、ばりてんとかしまいまとか書いてある。軽く羞恥プレイな…。まぁ、恥らうような年でもないので良いんですが。

…今、後ろから「恥らえよ！」と野次が飛んできました。私はもう少し恥じらいを覚えた方が良いらしいです。がんばろ。

休みの日もお仕事。

何か形容矛盾を感じるけど、別にいいんです。きっと。名実ともに自分たちの会社ってこともあり、仕事≒趣味に近いものがあります。気軽さについては仕事してるっていうより、サークル活動してるって感じで。発生する責任は仕事そのものですけどね。

さて、先日、使用期限が迫っていたことから、自宅 PC のウィルス対策ソフトを Norton 先生から Kaspersky に変えてみました。

近年の Norton 先生は、PC 終了時にハングすることが多く、買い替えを考えていたところ、以前業務で知り合ったスタッフがオススメだと言っていたのを思い出し、このたび導入しました。Norton 先生に比べて動作が非常に軽快で、GUI も私好みでとてもすっきりした印象。Luna がちゃんと有効になっているのも良いですね。未だに Luna スキンが有効にならないしょーもないアプリが多いのですが、こういうところがきちんとしていないと、そのメーカーを信用できないんですよね。プラットフォーム展開を甘く見てる感じがしてしまって。その点 Kaspersky は合格点ということで。

ただ、いいこと尽くめでもないようで。

インストール直後の『完全スキャン (インストール直後に要求される動作) 』時のブルーバックに悩み、現在ジャストシステムのサポセンにお世話になってます。ntfs.sys が落ちるあたり、Kaspersky のフィルタドライバか、HW のドライバかいずれかが原因ではないかと思うのですが、餅は餅屋。しばらくサポセンの担当者と連絡取りながら状況改善を図りたいと思います。

液晶ディスプレイを新調しました。20.1 inch です。UXGA です。EIZO です。さすがに 5 年振りのディスプレイの買い替えで、PC が生き返ったかのような印象です。

GW 突入。

先々週末、GW 前に東京ディズニーシーに夫婦で行ってきました。GW 前の平日。穴場狙いでいったら、ドンピシャ。どのアトラクションも、10 分以上待つことなく堪能できました。ひさびさの行楽地でしたが、良い息抜きになりました。(オフィシャルホテルに泊まったので、なかなか諭吉さんの手離れが良かったですが (^^; 良い思い出になりました。)

人様の書いた 20 万行くらいの仕様書のないグローバル変数だらけのコードをデバッグ。ほかの人があたりをつけてくれていたおかげで、比較的早めに収束。とりあえず修正はした。問題は収まったけど、コードが入り組んでいて修正内容の正当性が判別つかない。

うーん。仕様書を書かないならコメントを書く。コメントを書かないなら仕様書を書く。徹底してほしい。あとデータの局所化も。

オブジェクト指向 (以下、OOP) に慣れ親しんだ技術者が OOP を知らない技術者に OOP の設計を伝えるのは難しいのかな。

両者の間で、デザインパターン (オブジェクト指向における慣用句。以下、デザパタ) が共通語として、またはそれがデファクトであることとして通じないことがある。後者の人は、デザパタを『特殊な設計方針』であると考えることがあり、そうなると、前者の人は一般的な慣用句をしゃべっているつもりでも、後者の人は慣用句を (または慣用句自体を理解できてもその有用性を) 理解できない。

要するに、コミュニケーションは難しいね。と思ったという話。

あるプロジェクトのコードの最適化完了。プロファイルを元に最適化したので効果があると信じたい。クロス開発のため、開発環境で結果が見えないのがもどかしい。

ひぐらし PS2 版の OP CD が届く。当然、プレイ中に OP テーマの『嘆きノの森』にハマって購入したのですが、何？このカップリング。格好良すぎじゃんか！ネタばれだからあまり書きませんが、コレがあのタイミングで流れるのだとすると、PV によっては泣いてしまいそう。原作ファンとしては、曲聴くだけでも泣けてくるってのに。

相方からの一言。

「オタクって怖いね。」

…怖くてごめん。
その科白、週に 3 回は聞くね。改善される予定はないからこれからもどうぞよろしく。

ところで、カップリングを B 面と思ってしまうのはジェネレーションギャップなんでしょうか。私の方が相方よりも若いはずなんですが…。

Windows Update で標準フォントの新 JIS 対応版をあてたところ、全体的に字体がかわってしまった…。さいてー。そういうことは、事前に知らせてほしいよ。マイクロソフト…。それとも、私が何か説明文を読み飛ばしてしまったのか…。

体が辛くて、一日寝てしまう。

相方が友人の結婚式で一日家にいないため、ここぞとばかりに仕事をするつもりが、「予定外でーす。」な状況に。まぁ、まだ切羽詰った仕事でないので良いのですが。ちょっと助走をつけておきたかったな、と。

今週一週間の忙しさったら。

あるプロジェクトのコードの高速化と。あるプロジェクトの動作検証と。あるプロジェクトの調査と設計と。(全部、別々の仕事)

この上コーディングが重複したらちょっと辛いかな。スケジュール調整やなぁ。

最初に勤めた会社の上司から「同時に抱えるプロジェクトは 4 つ以上になると、覚えていられるのは 3 つ目まで。4 つ目以降を忘れていく。」と言われたことがありました。これまでの経験から得られた感覚として、実務を担当するにあたって同時に履ける草鞋は 3 足までですね。今、丁度 3 つなので、このあたりが限界かな。4 つ以上になると、たぶん仕事にならなくなる…。その時は私を管理してくれる上司が必要になるなぁ。

昔やっていた仕事と違って、それぞれのプロジェクトに複数の人が関わっていて、きちんと協力体制ができていることが救いですね。仲間がいるというのは大変ありがたいことです。昔の仕事で、1 人ですべて担当するというのも面白かったのですが、仕事として続けていくのには鉄の意志が必要だと思いました。

で、結局今日も仕事ー。デスマーチじゃないので良いんですが、自分の見積もりの正確さに涙が出ます (w

薬を飲んでたら、少しずつ回復。

安静にしていたら、宅配が届きました。Fate/Zero が届いた様子。…が、せっかく届いてもまだ小説読める程の体力は戻ってない…。仕方ないので積読状態。ところで、相方に言われるのですが、私は活字を読むペースが凄く速いのだそうで。自覚ないんですが。速読やってる人程では全然ないんですが。速いらしいです。あと、読んだことをよく覚えているね、とも。学生時代、似たようなことを周りの人からも言われたなぁ。一度覚えたことをなかなか忘れないとか。みんな忘れていることを一人だけ覚えているとか。つまらないことを良く覚えているとか。あー。最後のコメントが多かったなぁ。そういえば。

でも、就職して学び (経験し) ました。人間、詰め込めば抜けてくって。

デスマーチを一度だけ経験したことがあるのですが、その時は、仕事で調べること、試すこと、推測すること、作ること、確かめることに追われていて、半年間ほぼ無休でそれを続けたら、それ以前に経験してきたことの多くを忘れてしまったというオチ。単純な知識だけでなく、人の顔とか声とか名前とか友人関係やら、何というか徹底的なまでに記憶がなくなりました。そう、実際には忘れたとかいう生易しいものではなく、記憶がなくなったという感覚。後から覚えていたはずのこと (周辺の事情から類推して覚えていて然るべきこと) を指摘されても、それを思い出すことができませんでしたから。今思えば、医者に行ったほうが良かったんでしょうか。

まぁ、人間、限度を知りましょうってことで。あれ。何の話してたんだっけ？

ここ数日、へヴィな風邪でダウンしていました。(今もまだ静養中…。)

昨日、体中が辛くて身動きが取れなくなり、さすがにヤバいと思い、相方にいきつけ (?) の内科医に連れて行ってもらいました。本当は自分で行こうと思っていたのですが、意識が朦朧として全然だめでした。診てもらって、抗生物質を注射。その後は処方された薬飲みながら様子を見てます。結婚してから風邪を引くといつも行く医院なのですが、今まで行ったことのある医院の中でも、即効性 No.1 なのでとても助かっています。薬も漢方交じりで飲みやすいのも Good。今回もかなり回復してきました。医者パワーは凄いです。

仕事で納品。あー疲れたー。まぁ、良いものができたと思う。

ひぐらしの PS2 版を夫婦で読んでいます。感想。誤字多いね。絵とテキスト合っていないことが多いね。子機を持って 2 階に上がったはずの圭一君がダイヤル電話を持っているのはなーぜー。せっかく雰囲気は良いのに。こういうところはもったいない。

昨日、結婚記念日 (前後の休日) ということで、夫婦でワインを飲みました。友人の披露宴に出席した際に引き出物で頂いたワイングラスがあったのを相方が見つけ、こたつに入ってワイングラスでワインを飲むという、素敵空間を満喫しました。

昨日のフィギュア。キムヨナがこけなければ彼女。そうでなければ安藤美姫。そういう流れでしょう、と夫婦で話をしていたら、安藤美姫が金を取り、何となく納得。彼女は今の演技に 4 回転ジャンプが加わったら完成形じゃないかと思う。対する浅田真央は、ジュニアからシニア向けの演技に改造途中という感じ。たぶん、次のオリンピックに合わせて最初の完成形を持ってくるのだと思う。みんな凄いね。

あー。体調悪…。
花粉がおさまってきたと思ったら風邪をひいた様子。鼻出る…。

親戚にアメリカ人の男性がいるのですが、今日その人から「お化けとか幽霊とか妖怪の総称って何っていうの？」と聞かれ、その場に居た日本人は誰も答えられませんでした。「アメリカでは Fantastic creature っていうんだけれど」というので、何とかそれらしい答えをと思い「それなら幻想種？でもそんな言い方しないか。」と言いました。後からよく考えたら、幻想種って欧米の Fantastic creature を和訳したもので、日本のお化けやなんかを表す言葉じゃないなと思いました。

ところで、幻想種って言葉、TYPE-MOON の作品が初出なのでしょうか。小学生のころ、ファンタジー図鑑とかで読んだ記憶があるのですが。(うろ覚え) Google で検索しても、ゲームの話しか出てこないので。ちょっと気になりました。

あー。日越えてしまった。

今日は久々にあんかけパスタを食べました。からめ亭というお店なのですが、大変おいしいです。くろこしょーさいこー。

時間切れー。

結局、昨日の件、後者は解決せず、ランタイムのマージモジュールを使用するのをあきらめ、再頒布モジュール (exe) を事前にランチャでサイレントインストールすることで対処。ちょいダサい。

補足。下で連呼している DLL は C / C++ / MFC / ATL ランタイム DLL という理解でひとつ。言葉足らずでした。

今日はちょこっと仕事の話。

業務で、Windows XP 以降に導入されたという Side by side にハマる。開発環境では、MSVC2005 でバイナリ作るとデフォルトで使用される。断言していいけど、新たな DLL-Hell の仕組みだよ、これ。致命的なのが、システムにインストールされている DLL とビルド時にリンクした DLL のバージョンが違うと異なるモジュールと認識され、当該 DLL にリンクした exe が起動してくれないこと。本来はこれがウリらしいのだが、現状、開発環境だけバージョンアップして、ユーザ環境へのアップデータは一切無配布という MS の姿勢はどうなのか (最低限、Windows Update で当該 DLL を強制アップデートさせるとかする必要があると思う。) これを開発者の責任でバージョン合わせろというのは、ちょっと OS ベンダとして無責任な気がする。たぶん、今、MSVC2005 SP1 でビルドしてる人は軒並みハマるんじゃないかな。開発環境では動作するのに、テスト環境で動作しないって。それとも一通りハマった後なのかな。

あと、ランタイムに付随した問題で、再頒布パッケージの MSM。MSI に MSM 形式のランタイムインストーラを組み込むのは良いのだけれど、例えばインストーラ起動中に当該ランタイムを使用するカスタムアクションの起動やら、サービス起動をしたい場合、ランタイムインストールとのタイミング問題はどうすればよいのか。

上記 2 点は根の異なる問題だけど、こんな面倒なことになるなら、COM じゃないけど、system32 フォルダの下にインストールする共有ライブラリは一度リリースしたら I/F を変えないとか、そういう規約を設けるを設けて、従来どおり『アバウトなリンク』で昔の DLL を名前を変えずにアップデートしてくれた方が良かったと思う。

まぁ、何かにつけて Windows は面倒だな、と。あぁ。ハマるハマる。ホント、前者は理解すればなんとかなるけど、後者はハマったまま。解決しないと。

結局ブログは続けられませんでしたが、この形式は続けられそう。なんというかブログ書く程のパワーが必要ないのが素敵。もしかすると、タグの手打ちに慣れているから (手打ちしかしたことないから) かもしれませんが。

最近、C++ 触っていない。禁断症状が。

Firefox での見栄えをちょっと改善。メニューはそれらしく見えるようになったのではないでしょうか。残りは週末かな。

IE6 用にサイトの CSS を調整しました。が、よくよく確認すると Firefox で NG。ちょっと、時間見つけて調整しよう。

散々デバッグした挙句、テストコードが間違っているというオチ。いや。ホントにしょーもないバグだったんですが…。自分自身、設計レベルのミスっていうのは最近はあまりないのですが、ケアレスがホントに多い。質の程はともかくとして、最近はこれも天賦の才だなと思う。ここまでミスする人も珍しいと思う。

結婚届を念のため 2 枚用意したにも関わらず、狙ったように 2 枚とも書き損じ、親子合わせて 2 桁近い記入ミスしたりとか。ホント。天賦の才ですわ。

先日、のび太の恐竜が TV でやっていたので見ました。が、途中、絵くずれすぎじゃないですか？原作のタッチを活かしたいというのはわかるのですが、それにしたって許容できないくらいヘタレてるところが。まぁ、話は良かったのでいいんですが。

それはそれとして、今日気づいたこと。

リニューアルしたサイトは IE7 でしか確認していなかったのですが、IE6 で見ると、一部 CSS がうまく適用されていない箇所がありますね。ブラウザが標準規格にきちんと準拠していないとこういうとき困ります。オレオレ仕様はいけないですよ。

ということで、ちょっとだけリニューアル。XHTML ぽくしてみました。a 要素の target 属性がいまひとつ XHTML1.0 Strict ではないですけど、それを除けばそれなりに規格に準拠できているように思います。

もし表示でおかしいところがありましたら、BBS にでも報告をいただけるとうれしいです。

昨晩、ちょっと気になって Web ラジオの『Fate/stay tune』を聞いてみました。おたく向けの番組っぽく、結構痛い系なのかなと思っておそるおそる聞いてみましたが、意外と聞ける内容でびっくりしました。…というか、何のことはない。最近仕事漬けですっかり忘れていましたが、私も十分おたくなのでした。

そんなこんなで一週間の業務も終わりです。まぁ、週末にちょっとデバッグ作業が残っていますが。納期が近いのでがんばらねば。サイトの更新もね。

何となく思い立ってサイト全体を XHTML にしてみようと思います。最近、業務でそのあたりを触ることが多いので。週末に作業かな。デザインは変えない予定です。構造だけすっきりさせようかなと。無駄な table 多いし。

リハビリを兼ねて落書き。1 年近く絵を描いていなかったので、なかなか勝手が戻ってこない。がんばろう。

長らく放置していたカウンタですが、どうやら初期化されてしまっていたようです。残念。

ところで、先の更新のサンプルコード。引数書き忘れていてコンパイル通らないですね…。

テスト書き込みですよ。

p タグのテストです。

p タグのテストです。

// がんばろう。コードを書くときはこんな感じ。
#include <stdio.h>
int main(void)
{
  printf();
  return 0;
}

リストを書くとこんな感じです。

• テスト
• テスト

番号つきリストを書くとこんな感じです。

1. 番号つきリスト
2. 番号つきリスト

とりあえず、気軽に日記を書けるようにトップを更新しました。せっかくのウェブスペースを放置しておくのももったいし、今続けられる (かもしれない) ことって言ったら、この程度のことしかないので。できれば日記にはプログラムの話題よりも絵等を載せていきたいと思います。

あと、ブログやめました。続きを期待していた方、ごめんなさい。