或曰

10:20 起床, 11:00 会社着。 目覚ましかけ忘れ……。

@ ゲームオブジェクト

エフェクトを発生・実行させるタイミングを見直し。 これまで直接エフェクトを作成していた部分を、

1. エフェクト作成要求をキューに貯める。
2. キューに蓄積されている作成要求を一括処理。

と二段階に分けるように変更。デザパタだとコマンドパターンかな。

主な理由は以下の通り。

• エフェクトの発生要求は、ゲームオブジェクトの処理・状態遷移中に発行される。その場でエフェクトを作ってしまうと、エフェクト描画時点でゲームオブジェクトの位置が変わってしまい、ずれて表示されることがありうる。
• エフェクトの生成を一括管理することで、負荷が高いときには重要度が低いエフェクトを消すなど、シーン全体の制御が容易になる。
• シーンの再構成が楽になる。

@ リソース

モデル・テクスチャなどに利用できるリソース量に関して、 アートディレクターと打ち合わせ。 最終的には実際のモデルを出してみないと確約はできないが、 そうも言っていられないので現状の描画負荷を見ながら見積もり。 まぁ、どうにかなるだろう。

途中でさらっと新しい仕様の話が出てきたが、それは今回は却下。 やるとしても、仕様がもう少し煮詰まってから。

@ 人事関係

管理職クラスの人間とミーティング。 その場で決まることあり、 暗い見通しを告げられることあり。

ま、無い袖は振れないので仕方ない。 見通しが暗かろうが、 ともかく先が見通せれば覚悟はできるし、 妥協のしようもある。

@ 有給

それはともかく、月末で消える有給休暇は消化する方向で。

@ 帰宅

20:10 離脱。

09:00 起床, 10:00 会社着。

@ 体調不良

どうも調子が悪い。 何か悪いものでも食べたか？

@ ブレインストーミング

久しぶりにプロジェクトメンバー全員集まってのミーティング。 メンバーが少ない立ち上げ期には良く全体ミーティングやってたけど。

@ 帰宅

やれることやって、 19:50 離脱。

ダメだ、さっさと寝よう。

09:00 起床, 10:00 会社着。

@ ハンドル移行

前にあった load() したが release() 忘れてた件 。 グローバルな管理オブジェクトの load(), release() メソッドを private にし、 ヘルパクラスを管理オブジェクトの friend クラスに。 ヘルパクラスの使用を強制。

@ PVM

クラスタを構成する仮想マシンに対して、どういう基準でジョブを割り振っているか調査。 設定ファイルに、ホストの相対的な速度を記述する speed というパラメタがあるのだけど、 挙動を見る限りでは意味がないように見える。

What does ``speed'' in the machine configuration mean?

現在使ってません、という結論に。

PVMGmake に手を入れて、簡単なスケジューラを実装してしまおう。 ざっとソースを追ったところ、 PVM クラスタでプロセスを起動する pvm_spawn() を呼び出しているのは remote-pvm.c の start_job() 関数。 ここに手を入れて、 第三引数に PvmTaskHost、 第四引数にジョブを割り振るホスト名を渡せば良いのかな。

ここまで分かったところで、 先送り。

@ ld が刺さる

ld が割り込み不可能スリープ状態になったまま刺さる。 ps コマンドでの表示を見るとプロセス名の前後に [] がつき、 procfs を見てみると resident memory size 0。 ゾンビプロセスってワケでもなさそうだけど、 なんだろう？

どうもオブジェクトファイルに対する I/O で固まってるようなので、 一度 make clean してとりあえず問題回避。 対処療法だなぁ……。

@ 他

細かい打ち合わせやら何やら断続的に。

一つ大きな TODO 項目が残ってるんだけど、 設計途中で時間切れ。

@ 帰宅

21:00 離脱。

相変わらず体調がイマイチなので、 さっさと寝よう。

09:00 起床, 10:00 会社着。

@ ハンドル化

サウンド関連のメモリアロケーションもハンドル化。 デストラクタでよろしく開放するように。

@ ミーティング (1)

他のプロジェクトの人間を囲んで質問。 人的資源さえ確保できれば、 技術的にはどうにかなりそうなんだが。

@ ミーティング (2)

進捗確認。

私は予定より 3 週間ほど先行しているので、 他の人のサポートをしつつ、 マイルストーンを踏み越えて先に行く事に。 当面の目標は達成したとはいえ、 最終目的地はまだ遠い。

スケジュールが先行している理由は、 予想以上にサブプログラマとの作業分担がスムーズにいっているため。 もう少し手間取ると予想していたのだけど。

@ PVM GMake

PVM GMake のソースコードに手を入れて、 PVM でホスト追加時に設定したパラメタ (speed) を見てジョブ割り振りを変更するように改修。 スケジューラというほど本格的なものは作らず。

リンク処理がネックになっているので、 プログラムのリンクを担当しているホストは、 リンク & PVM の制御専用に使うことに。 コンパイルジョブは他のホストに分散させる。

@ 帰宅

21:00 離脱。

有休。

体調が回復傾向にあるとはいえまだ本調子ではないのと、 プレゼン資料作成のため。

ポーク角煮, 虚空100, スープ大盛り, クイティオ大盛り。 食後にココナッツアイス。

08:50 起床, 10:00 会社着。

@ cvs commit mail

有休とった金曜日の分が大量に。

@ ミーティング

価格は重要だよ。 まぁ、頑張って下さいとしか言いようがないけど。

@ ヒット判定

記憶域の割り当て方法を変更。 これで当面は fix。

@ SE

管理方法を煮詰める。 明日中には組み込めそう。

@ 最近

最近、微妙に雑談で時間を潰してる気がする。 ま、雑談できるぐらいに心理的距離が近づいたのは良いことだけど。

@ リファクタリング (1)

プロジェクトのメンバーがバブルソートの自前で書いていた部分。 「これで行けるんじゃない？」と std::sort() + boost::lambda で書いてみる。一行になった。

@ リファクタリング (2)

識別子によるオブジェクト生成

switch - case で場合分けして、微妙に似て非なる引数で new、 そうしてできたインスタンスをキューに追加する処理。 コンストラクタの引数を揃えた上でテーブル使うときれいに書き直せるよね、 ということでそのプログラマの目の前で書き直し。

使用前

#include <stddef.h>

struct IFoo { virtual ~IFoo() {} };
class Foo1 : public IFoo {};
class Foo2 : public IFoo { public: Foo2(int) {} };

enum PRIO_TYPE { PRIO_LOW, PRIO_NORMAL, PRIO_HIGH };
enum FOO_TYPE { FOO1, FOO2, FOO3 };

void addQueue(IFoo* foo, PRIO_TYPE prio);

void Create(int id)
{
    IFoo* p = NULL;
    switch (id) {
    case FOO1:
        p = new Foo1;
        addQueue(p, PRIO_LOW);
        return;
    case FOO2:
        p = new Foo2(0);
        addQueue(p, PRIO_NORMAL);
        return;
    case FOO3:
        p = new Foo2(1);
        addQueue(p, PRIO_LOW);
        return;
    }
}

使用後

#include <stddef.h>

struct IFoo { virtual ~IFoo() {} };
class Foo1 : public IFoo { public: Foo1(int) {} };
class Foo2 : public IFoo { public: Foo2(int) {} };

enum PRIO_TYPE { PRIO_LOW, PRIO_NORMAL, PRIO_HIGH };
enum FOO_TYPE { FOO1, FOO2, FOO3 };
void addQueue(IFoo* foo, PRIO_TYPE prio);

#define D(cls_name) \
static IFoo* create_##cls_name(int param) \
{ \
    new cls_name(param);\
}
D(Foo1)
D(Foo2)
#undef D

void Create(int id)
{
    struct create_tbl
    {
        FOO_TYPE foo_type;
        IFoo* (*creator)(int);
        int param;
        PRIO_TYPE prio;
    };

    static create_tbl const db[] = {
        { FOO1, create_Foo1, 0, PRIO_LOW    },
        { FOO2, create_Foo2, 0, PRIO_NORMAL },
        { FOO3, create_Foo2, 1, PRIO_LOW    },
    };

    for (size_t i = 0; i < sizeof(db) / sizeof(db[0]); ++i) {
        create_tbl const* p = &db[i];
        if (p->foo_type == id) {
            IFoo* foo = (*p->creator)(p->param);
            addQueue(foo, p->prio);
            return;
        }
    }
}

実際には数も多いし前後の処理も addQueue() だけでなく色々あるので、 テーブル化しておいた方が圧倒的に保守性が上がる。

これ create_Foo1() というような関数を定義せずに、 その場でコンストラクタから関数オブジェクト作れないんだろうか。 boost::function とか使うと上手く書けそうな気がするので、 後で調べてみよう。

09:00 起床, 10:00 会社着。

@ ライブラリ更新

サクッと更新完了、と思ったら微妙にリリースエンジニアリングの問題が……。 今後は、何があってもリリース経路を一本に絞ってもらおう。

@ メモリがらみ

特定のタイミングで assert() に引っかかって死ぬ問題。 cvs のログを見ながら当たりをつけて、 再現条件が整ったところで担当者を捕まえてお話。 解決。

サブプログラマの人が書いてるコードでリークしてるようなので、 ある程度まで再現状況を狭めて調査依頼。 static 変数にスマートポインタコピーしてたのが原因。

@ スクリプト

字句解析に不備を見つける。 ちょうど担当のプログラマが席を外していたので、 私の方で lex の入力ファイルを見てサクッと修正。

@ SE/BGM

暫定で組み込み完了。

@ 相談事

企画サイドから「こういう案があるのだけど、できる？」という問い合わせ。

• できる
• できない
• できるかできないかさえ分からない (卒論ネタぐらいにはなりそう)

と分類して回答。 代替案を幾つか出してみる。

私はゲーム性に関わる部分には口を挟まない方針だけど、 ま、思いつき程度で良ければ。

@ とか

細かくタイムスライスされた一日でした。

@ 帰宅

20:00 離脱。

@ あと、一生さん、プレゼン上手いよなー、とか。

ありがとうございます。

というわけで InfoPath の売り込みかけてきたので、 そのうち聴いた人の間で (バッドなものも含めて) ノウハウ蓄積されるかなーと期待。