諸事情からちょっとしたテストプログラムで3D空間の入力を色々変更したくなったので、その為だけにスクリプトを書き換えるのは面倒なのでパースペクティブでのドラッグ処理をあれやこれや. しかしアナグリフにすると立体感はある程度前後関係は把握できるもののヘッドトラックまで導入しないと結局回して詳細を確認する事になる. 更に入力カーソルが2D投影なんで意外と物体の特定の位置を掴み難い、思った程には扱い易くはならぬ、難儀なもの :-< 結局細かい作業するなら三面図+パースが一番妥当だろうとまぁありきたりに帰結する.

---------------

まぁ大した話では無い、個人的に3Dインターフェイスでのヒットテストの定型化とドラッグ処理を作っていなかったというだけで、実際にはfov設定値と操作基準位置までのZ位置 (+パースによる表示位置の歪みを考慮して代表値を算出) で単位をスケールすれば良いだけの事. まーこうして1個1個地味な要素を積み重ねないと僕みたいな人間は一気に大きなものを作ろうとすると途方にくれる事になるのでというカンジなワケです、ええ(苦笑)

OpenGLの周辺ライブラリを調整する途中でシャドウ(Depth)マップを試してみたが、glTexGenにGL_EYE_PLANEを指定した場合、glTexGenを呼んだ時点のモデルビュー行列 (の逆行列) が加味される事に気付かなかった (知らなかった) 為、3日程ちゃんと影が出ないなーと見事にハマる事にorz

まぁ仕様さえ分かってしまえばシャドウマップを適用する際にいちいち現在のカメラ変換の逆行列を求める必要が無い為、こちらの方が便利なので異論があるワケでは無いのだが、ともかく疲れた、まー間抜けな限り X-<

しかしこれ以上真面目にやるとなると3Dソフトでシーンビルドする為のスクリプトを作ったりする必要がありそうで、ただ現状労力の配分として余りがっつり3Dをいじっている余裕は余り無い. LW関連を放置 (9.xのバージョンアップしてないし) しているのもそれが理由だが、ちと頭が痛い :-<

シャドウマップは実用的に使うなら最低マルチテクスチャ環境で扱わねばならないのが難点、ステンシルシャドウよりはプログラム側の負担やコストは少ないものの、投影領域の見積もりの問題や貴重なテクスチャユニットを1個占有する事を考えると使い分けは少々考える必要がありそう. ただ色々いじっててエンジニアリングを否定するようだが、ゲームの場合セルフシャドウがどうのと言ってもゲームが面白くてある程度の基準だけ満たしていればそんな要素ははっきり言ってユーザーとしては(一部のマニアを除き) どーでも良いような気もしていたり(笑) アクションゲームしかやらないせいかもしれないけど、極端な話内容が面白ければステンシル丸影ですら良い気もする僕は果たして少数派だろうか？さて.

フレームレートの検証の為延々ポケモン(だったと思う)風の背景点滅画面ばかり表示している、いい加減目が痛い. OpenGL向けの2Dスプライトクラスを作りそれをフレームバッファとしても使う形でかなり柔軟な表示はできそう、ペイントソフトから引張ってきたフォント描画ルーチンも組み合わせて良いカンジ、多少の難点は2の累乗以外のテクスチャはOpenGL2.0以降の要件である為、1.4〜1.5 (マルチテクスチャまで) 程度までしかサポートしてないIntelのオンボード系(※1)に合わせると転送量が少々大きくなる事か、まーそんなにGLに拘る事も無いのだが、他の描画ルーチンがGDIなんかも呼んでいるから互換性的に役立つワケでも無く、単に大文字打つのにシフトを押さえるのが面倒だというだけの理由だったりもする、後は表記上(転置して考えりゃ良いだけだけど)ベクトルを左からかける表記が嫌いとかまー割とどうでも良い理由ばかり :-<

骨組みを考えるのは好きだがコンテンツを作るのは余り好きじゃない、という事でゲーム作りには向かない性格なのは重々承知しているので、ゲームを作る予定は無いものの、何となく3Dをどう取り回すかも含め具体的なコードのイメージがかなり見えてきたような気もする. ゲーム業界出では無い自分にとっては例のボード (この辺内輪ネタ) での経験がMSXやX68000といった過去のハードの知識と今の3D全盛のハードのギャップを埋めるものとして今更ながらイメージを連想するのにかなり役立ってくれている、そういった意味ではあの経験に感謝、電話でわめき散らしたのも良い思い出也哉(笑)

おまけでアナグリフの処理部分をちゃんとglFrustumを使用するよう修正、物体をズームしても領域が重なり易くなった為ズームした時の違和感軽減と目が疲れ難くなった ;-)

※1) 先日のwglSwapIntervalEXTがIntel 945GM (公式にはOpenGL1.4相当) を搭載したマシンで動かないという件、一応拡張関数のエントリだけは取得できているのだが、それが動いてないっぽい、確かこの部分は標準規格にはなってなかったと思うのでダミーなのだろーか :-<

何故か延々ゲームループ(※1)の検証なんぞやっている、別段ゲームが作りたいワケでも無いのだが. 汎用的なグラフィック画面としての共通項が抽出できないかと思ったのだが、やっぱ難しいね、目的により可視化、Flashみたいなフレームベースで動作するフレームワークのスケルトン、ゲームなど微妙に重視する個所が違って理想的なスレッドやメッセージの繰り回しが違ってくる.

まぁいつものフレームワーク遊び、副産物としてGDI, OpenGL, DirectXのスケルトンなど作ったけど、padの入力はどうせDirectInput使うんだし、Vsync待ちの為だけにいずれもDirect3Dデバイスを作成しているので意味ねーじゃん、みたいな. まぁGDIはフラットなバッファとしてアクセスし易いので有りかもしれないが、OpenGLは完全に趣味 (とリソースの共通化(※2)) 程度かもなぁ. Direct3Dはデバイスが無効になったらテクスチャ等VRAMに展開されたリソース (テクスチャとかストリーム化された頂点リストとか) を全部手動で作り直さなきゃいけないのがかなり嫌なカンジだけど、試行錯誤段階ならともかくゲームとか用途を確定してしまえばどうせフレームワークで吸収させてしまえるし.

※1) よくある固定フレームレート (Winの場合垂直同期周波数が必ずしも固定では無いのでVsyncとは別に時間調整の機能要) でメインで無限ループして入力&更新処理、Vsync中に画面をflipという例のアレ、後はWinの場合この部分に加え通常のメッセージループの繰り回しを同時に行う必要があったり少々面倒な個所が多いので、その辺を自分の中で定型化してしまおうという所.

※2) OpenGLのwglSwapIntervalEXTを使ってVsyncを待つ方法はサポートしてない環境も結構多い模様につき未使用、nVidiaのカードは比較的古いものでも動いたけどノートのIntelオンボードでは不可だったりしたので、多分OpenGLで拡張機能ガシガシ使う場合はnVidiaとATIのカード限定とかに環境搾った方が良いのかも :-<

、、、つーかたかがVsyncなんてマップされた標準のVGAレジスタの状態だけ覗けりゃ何でも良い筈なんで、OSがその機能だけ提供してくれれば良いのだが、何でこんな面倒な事をやる羽目になっているのか X-<

今検討している内容に絡んで、C++でコルーチンやジェネレータ関数と呼ばれる処理を模倣するサンプル.

/*-------------------------------------------*/
/* ベース */

#define yield(st)   do{ _yield_state=st;    \
                        return;             \
                    _yield##st: ;               \
                    }while(0)
#define yield_(st,r)    do{ _yield_state=st;    \
                        return (r);         \
                    _yield##st: ;               \
                    }while(0)

#define resume(st)  if(_yield_state==st)    goto _yield##st;


class Coroutine{
protected:
    int _yield_state;
public:
    bool done;

    Coroutine(){ init(); }
    virtual ~Coroutine(){}

    void init(){
        _yield_state=0;
        done=false;
    }
    void die(){
        done=true;
        _yield_state=0;
    }
    virtual void process()=0;
};
/*-------------------------------------------*/
/* ここから使い方サンプル */

class Foo : public Coroutine{
    /* process()に関わるローカル変数 */
    int i,j,ct;
    /*-----------------------------*/
    string  name;
public:
    Foo(const char *n, int c){
        name=n;
        ct=c;
    }
    virtual void process(){
        resume(1);
        resume(2);

        init();

        for(i=0;i<ct;++i){
            printf("%s state1: %d\n",name.c_str(),i);
            yield(1);
        }

        for(j=0;j<ct;++j){
            printf("%s state2: %d\n",name.c_str(),j);
            yield(2);
        }

        die();
    }
};

int main(void){
    vector<Coroutine*>list;
    list.push_back(new Foo("A",5));
    list.push_back(new Foo("B",3));
    list.push_back(new Foo("C",2));

    while(list.size()){
        vector<Coroutine*>::iterator p;
        for(p=list.begin();p!=list.end();++p){
            (*p)->process();
        }

        /* 完了したものを削除 */
        for(p=list.begin();p!=list.end();){
            if((*p)->done)  p=list.erase(p);
            else            ++p;
        }
    }
    return 0;
}

結局の所ローカル変数をインスタンスメンバにしてしまい、マクロでラベルを自動生成してgotoでそこに飛び込むだけというシンプルなもの、こういった機能を言語レベルで所持している言語に比べると余りに壊れ易い屋台骨であるので、乱用すべきものでは無い事は言うまでも無い. まぁただコードは愚直であるべきだが馬鹿正直であるべきでは無いという所で、時分周でスレッドにするには非常に細かいorコスト高で同期処理を考えねばならない場合にはそれなりに役に立つかもしれない. エンベとかは時分周処理が活躍する個所も多そうだが、そもそも限定的なC++しか使えない (以前 Embeded C++仕様のコンパイラを使った時にはかなり泣けた) とかCしか使えないとか、mallocは禁止とかあるので、そうして考えるとせいぜいゲームとか音源のコントローラなんかを作る個所に限定されそうな気もするが.

どうも少し前にこの手のモノが流行ったのか、検索しているとファイバ系のAPIを使ったページなどが引っかかるのだが、CreateFiber (本来移植用の為のAPIで他のモジュールとのメモリモデル互換性は考慮されていないので、その最も重要な問題を提示せずにAPIだけ紹介するのはどうかと思うが) や昔の擬似マルチタスクモニタのようにスタックを切り替える方式は、複数のモジュールが関与しその互換性を配慮すると使うべきでは無い気がするのだが、、、はて？？？ :-<

まぁちょっと検証過程で必要になったのでという程度の話、後はよく引っかかるCreateFiber使うよりはマシだろとか (とゆーかそれを誇らしく紹介しちゃ駄目だろとか) 最近日記のコードが減ってきているなーと感じていた (実際書けないor書きたくないネタが多い) のでその誤魔化しであるとか、まー色々 ;-)

---------------

セキュリティ関連の書籍を読んでいたら、まだ以前セキュリティの仕事をしていた頃読んだ時点ではネタ程度だったレインボークラック (巨大な平文-ハッシュのペアを格納した大容量ストレージを使用する手法) が最近では有料でそういう表のセットが売買されていたり十分実用になっているのだそーな、へー.

他者と話す時、自分の状況が如何に充実しているか、どれだけ物事を楽しんでいるか、について語るのは非常に居心地が悪い、実際にはそれは同じ状況の者にしか受け入れられぬ話題であり、それよりは不幸自慢宜しく世の中が如何にままならぬか、そしてまぁ「結構そんなものだよ」という台詞を反復し確定的な事は何も示さず全ての意思のベクトルを曖昧に帰する方が万人において親しみ易い話題ではある.

己の状況は世間から一般化した状況だけ抽出するとあまりに惨憺たる状況にも関わらず、実際には圧倒的に充実と実感を得られる状況に居る、とは言っても大した話では無く、己の舵を取り、己の欲する所を知り、それについて行動するという事に過ぎない. 無論その為に犠牲にしたものも多いから、何ら後ろめたい事があるワケでは無いのだが. 真面目に生きながらも満たされぬ人を目の前にすると、正直このような状況、僕のような人間はもっと不幸でなければならないのではという妙な、余りに馬鹿馬鹿しい「やましさ」すら感じてしまう.

あるいは、、、単純に僕がただ底抜けに「おめでたい」だけかもしれぬ、そういう風に流しておく方がまぁ当たり触りはあるまい :-P

# いきなりなネタなのだが、年末から新年にかけてそう感じる状況に多分に遭遇した為、ある意味のガス抜きみたいなカンジなワケです. 人に対し変わる事を強制はできないけど、何かね、みんなもっと自由に生きて良いと思うんですよ、ええ.

---------------

かつて友人が飲みの席で吐いた言葉に「俺は、だってしかたないじゃない、という台詞が大嫌いだ」というのが有り、その時はいまいちピンと来なくて「あーそういうものかねぇ」みたいに流していたが、何となくその言葉の背景が理解できたような気もしないでもないよーな気がしないでもない (どっちやねん(笑)

---------------

バイクの修理に行った所で聞いた話によると4輪も厳しいらしいが、2輪はそれに環をかけて厳しいのだそうな、メーカーは慎重になりエコブームと相まってマシンとして面白い新機種が出てこないとか、パーツ共通化してしまうからどうしても同じようになってしまうとか. そう言えば店内を見回すと所謂ギア付きのバイクが随分減って8割近くが(大型含む)スクーターになっている状況だったり、うーむ :-<

なおパンクはチューブ自体に寿命がきてたらしく空気入れの付け根の部分が割けていた模様.

出先でバイクがいきなりパンク、バイクを押しながら1時間半かけて帰宅する羽目に、疲れたX-<

まぁ後は帰省中に書いたプログラムのマージ作業など、実家のPCがログインで画面が出てから安定化するまで数分、スクリーンセーバからの復帰だけで30秒以上かかるというトチ狂った環境であった為その環境でそれなりに動くよう描画関連のイベントに手を入れる、かなり人間の感覚に近い個所に関わる修正なので暫く使い込んで見て加減を見る必要がある. まぁでもプログラマのマシンというのは大抵安定していて一般的とも言い難いので、それとは真逆の環境でのテストが出来た事は極めて実入りが大きかったと言うべきか.

ただ、多分だけどコンシューマ全体のPCの比率からすると実家のような状態のマシンが全体の半数程度はあるんだろうなぁ、などと思うと正直薄ら寒い気分になるのも事実 :-<

---------------

会計関連の仕事をやっている人の話によればタスポ導入後煙草の自動販売機の収益は総じて大体20％程度(-20%では無く1/5ね)まで落ち込んでおり、現状導入後の普及によると見られる期間経過による回復の兆しは全く無いのだそーな、何ともはや(苦笑)

個人的には裏に何か利権絡みがありそうなので、取り合えず無いと絶対困る状況になるまでは申請しない予定、暫くはニヤニヤしながらその界隈を眺めるといういつもの僕の「趣味」を全うする所存 :-P

年末は少々慌しく帰省しており、本日帰宅しました(^^;;

遅ればせですが、皆様あけましておめでとうございます、という所にてm(_ _)m

新年まずは現在メンテナンスのアクティブなプログラムとしてペイントソフトに言語処理系x2(汎用言語 & 行列処理言語)のabout表記を2009年に書き換える所から開始ですとも、ええ(笑)