昔の最近の出来事(2005.07)

2005/07/31

昼過ぎ起床。

TV見たり鉄拳やったりしながらぐうたら過ごしたり。

ポリゴンサーチが思惑と違ってて悩んでみたり。 デバッグ表示を仕込んだりして調べた所、やっぱり妙な位置にあるポリゴン をサーチしていたり。何故そのポリゴンに当たってしまうのか謎。 しつこくポリゴンの内外判定を間違っていそうな動きに見えるのだけど、 コードは間違ってないように見えるのは何か思い違いをしているからか?

2005/07/30

昼頃起床。

王様のブランチで、でんじろう氏が実験やってたり。その中で、水で溶いた 片栗粉を使った実験で、圧力をかけると固くなるけど、そうでなければどろどろ になるというのをやってました。うつわに満たした片栗粉液にゆっくり指を つっこむとずぶずぶと入るのに、早く突っ込もうとするとゴムの様に表面が固く なって指を液中に入れることができないという現象から、「もしプールに満た した片栗粉液の上を右足が沈む前に左足をつけば液上を歩く事ができるハズ」 というので、本当にスタジオで試してみたり。結果、本当に液の上を渡る事が できたのに、思わず「おーー」とか声が出てしまったり。ただし、止まると ずぶずぶ沈み始めるのですが、どうやら抜け出すのも大変そうで、とにかく 一度はまると田んぼの泥の様に抜け出せなくなるという感じでした。

ちょっこりお出かけ。「虫姫さま」を探してみたのですが、どこも売りきれ。

先日の裏で動いているプロセスでのforkが失敗する件、例えば裏でCygwinの ビルドを動かしながら表でmakeなどを動かしたら、裏のビルド(makeだったり スクリプトだったり)がずっこける模様。逆に表でmakeを実行しながら裏で ビルドを動かした所、表のmakeがずっこけたり。別プロセスにつられて死んでいる という感じ。ビルドした新しいスナップショットでも現象は変わらず、 fork.ccに当てているパッチを外したりしても変わらず。

CygwinのMailingListを手繰ってみた所、似た現象に当たった人が いるらしく、その解決方法として、「rebase」なるシステムパッケージを 使用すれば良いらしいと言うのを見て、早速ダウンロードしようとした所、 他の更新も入ってて、そちらのダウンロードの方が時間がかかってみたり。
で、rebaseパッケージをインストールした後、全てのCygwinアプリを終了させて から、DOSプロンプトよりc:\cygwin\bin\ashを起動し、/bin/rebaseall というスクリプトを実行すると、何やら少し動いた後終了。その後、 forkがずっこける手順を試してみた所、大丈夫そうな予感。何がまずくて forkずっこけになるのか謎なのですが、とりあえずOKそう。

2005/07/29

日付け越え。

Cygwinのスナップショットをビルドしてみたり。その裏でコーディングでも しようと思い、スナップショットのビルドとは別のシェルプロンプトから makeを実行した所、何故かforkがエラーしてビルドが失敗してみたり。 しかたないので、スナップショットをほったらかして眠くて死亡。

2005/07/28

日付け越え前に帰着。

眠くて死亡。

2005/07/27

日付け越え。

仕込みを入れて動かしてみるも思惑通りにならず。むーん。

2005/07/26

日付け越え前に帰着。帰る頃にはすっかり台風は通り過ぎてしまってた予感。

色々足りないことが判ってみたり。

2005/07/25

日付け越え。

壁との当たり判定を行なおうとした所、イマイチごちゃごちゃになって死亡。 少し整理してみたり。

2005/07/24

昼過ぎに起きてぐうたら過ごして一日終了。

先日のポリゴンの継ぎ目でサーチがうまくいかない件。なんとなく これかなぁという原因を予想してみたり。
まず、ポリゴンサーチは次のような感じに行なっています。

  1. 判定を行なう直線(ray)と3角ポリゴンで生成される面との交点を求める。 ここでの面は無限平面で、面とrayが平行でなければ、必ずどこかに交点 が存在するという感じになります。
  2. 1.で求めた交点が3角ポリゴンの内側にあるかどうかを判定する。 内側にあれば、そのポリゴンにヒットしている。

という感じ。この時、2.の交点の内外判定で、交点pと三角ポリゴンの 各頂点f0,f1,f2 のなすベクトルをpf0,pf1,pf2としたとき、 pf0とpf1,pf1とpf2,pf2とpf0のそれぞれの外積が同じ方向を向いていたら ポリゴンの内側に交点pが存在するという方法で判定しているのですが、 例えばpがポリゴンの辺に乗っているとか、頂点に重なっている場合に、 特異点を踏んでしまいますが、そこんところでうまく反応できないと いう感じではなかろうか?と想像しています。

んー、ちょっと違ったかも。見かけ上同じ値を入力とした時、何故か 結果が0.0だったり-0.0だったりする場合があるようで、-0.0を踏んだときに 判定が外れるという感じみたい。指数表示してみた所、

chkinside  dot0=-1.925930e-34  dot1=8.552442e-03  dot2=0.000000e+00
chkinside  dot0=0.000000e+00  dot1=8.552442e-03  dot2=0.000000e+00

の二つの結果になる場合があり、「dot0=-1.925930e-34」の方が限りなく0に 近い負数という事みたい。なんとなく浮動小数点誤差から生じている模様。 外積を求めてから内積を求めるみたいな、プリミティブな演算を組み合わせている 部分の式を展開するなどすれば解決する話なのかしら?

もっと良い方法があるのかも知れませんが、結局、「n0.dot(n1)>=-1.0e-16」 みたいな感じで、値を丸める感じで比較すればなんとなくOKっぽい。

2005/07/23

揺れで起きたり。寝過ぎ。

休出。出たのが夕方頃だったので、結局日付け越え前に帰着。

やっと意図通りの結果が得られたような。ポリゴンサーチ (移動方向の直線とポリゴンとの当たり判定)がバグを埋め込んでいて、 全然関係無いポリゴンが反応していたのに悩んでました。 でも、ポリゴンの継ぎ目の部分のサーチがうまくいったりいかなかったり、 ちょっと悩ましい挙動を示していたり。

2005/07/22

日付け越え。

眠くて死亡。

2005/07/21

日付け越え。

だいぶ意図通りになってきたけど、何かがやはり変。

2005/07/20

日付け越え。

ちょろっと調査して終了。何が悪いのか良く判らないまま。

2005/07/19

日付け越え少し前に帰着。

ちょろっとコーディング。んー、何かを間違えているせいか意図通りにならず。

そういや、gdcでプロファイラって使えるのかしら?と思い、gdc -pg foo.d などと してみたところ、一応使えるみたい。ただし、クラス内のメソッドは、名前が 置き換わってCで言うところの関数呼び出しイメージになっているので、 どのメソッド実行が、プロファイル結果の関数名のどれと対応 付くのかを見分けるのに少し慣れが必要な予感。

2005/07/18

AM中に起床。でも暑くてぐうたら過ごして一日終了。

WBSのトレたまでやってたUSBハードディスクからブートする話。 既にありそうなものの様にも思ったのですが盲点だったような気も。 でも、壊れたHDDからデータをサルベージする時のバックアップブート用途 くらいしか使い所は無い様にも思いました。 結局のところ、一台のPCを複数の人で共用する際、HDDだけは自分専用に する事で、プライバシーを保護するという感じでしたが、冒頭、 「複数台所有しているPCが一台で済む」と言っていたのとは意味が違うと 思ったり。

2005/07/17

昼頃起床。

先日のビルドはエラー無く終了してたり。いくつか手持ちソースをコンパイル してみましたが、特に問題は無さげ。

gcc-4.0.1のPPCクロスビルドを仕掛けて休出。

帰った所で見てみたら、エラー無く終了。インストール後、POVをPPCクロスビルド しようとした所、手が滑ってディレクトリ内のファイルを消してしまったり(汗; 元に戻すのに少し時間がかかったりしましたが、クロスビルド&ppcsimテスト。 4.0.0に対して0.1%程度実行命令数が増えている予感。ポリゴン描画プログラム (整数系テスト)の方は4.0.0の時と全く同じ実行命令数になりました。即ち、 stwがstb×2に置きかえられている のはそのままという事になりそうです。

2005/07/16

起きたら昼過ぎ。

暑くて死亡。
鉄拳やったりgdcの0.15をビルドしたりしながらぐうたら過ごしたり。
ビルドは終りそうにないのでそのままほったらかしで眠くて死亡

2005/07/15

日付け越え。

gccダウンロードしたり。
眠くて死亡。

2005/07/14

日付け越え。

コード整理したり。

2005/07/13

日付け越え。

コードを少し整理したり。今のところそれでずっこけたりする事は無い ので順調。

gdc-0.15が出ているみたい。バグフィックスとかは特に無いようなので、 取りあえず週末にでもビルドしてみるという事で。gcc-4.0.1も出ている 模様。

そういや、戻り値があるメソッドでreturnで値を返していないとき、 -Wallを付けないと、そのまま実行バイナリができてしまいます。 しかも実行できたりして、そのメソッドを呼び出して戻るときに、 「Error: AssertError Failure GLprim.d(48)」という感じでエラーメッセージ を出力して終了するようです。-Wallを付けると、コンパイル時にエラーします。 てゆーか、実行してもずっこけるんだったら、オプションなど付けなくても コンパイル時にエラーすれば良いのにと思ったり。謎。

2005/07/12

日付け越え。

やりました!ついに原因らしき理由が判ったかも!原因は多分TANEのチョンボ(ぅおい!)。
恐らくな原因は次のような感じ。実行開始直後、スレッドは一つも無い状態から 始まり、そこでGCの初期化などが行なわれるようです。初期化後、スレッドを 一つ起こし、そのスレッドが以後メインスレッドとなります。この時、Windowsの メッセージドリブンやら、Win32APIのCreateThread()などを使ったりして、 全く別管理のスレッドでDな関数などを実行しました。そうした時、 GCはあるスレッドでnewが実行された際、場合によってGCが起動される場合が あります。この時、スレッドが切り替わったとすると、GCでメモリのマーキング などを処理中に、全く別のスレッドに切り替わり、そこから再びGCが実行されて しまうと、途中までで止まっているGC処理を全く別の人がぶっ壊してしまう 可能性があります。
先日の通常は失敗するハズの無い処理を踏んで実行した結果が、スレッドがらみ という事で、そういう推測に至ってみました。で、Dのマニュアルに書かれている ようなWindowsアプリな開始方法 (こんなの) をやめて、main()(_Dmain)の直下でメッセージループを回すという方法を 使ってみました。

int main(char[][] args)
{
  MSG      msg;
  HWND     hmain;
  int      res;
  BOOL     bRet;
  HACCEL   hAccel;
  HINSTANCE hInstance ;

  hInstance = GetModuleHandle(NULL);
  MainFrame mainframe = new MainFrame(hInstance) ;

  
  if( mainframe.open()<0 ) {
    return(0) ;
  }
  hmain=mainframe.getHWND() ;
  
  
  hAccel = LoadAccelerators(hInstance, "MYACCEL");
  while( (bRet = GetMessage(&msg , null , 0 , 0)) != 0 ){
    if (bRet == -1) {
      break;
    } else {
      if (!TranslateAccelerator(hmain, hAccel, &msg)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
      }
    }
  }
  return(0) ;
}

そうした所、ずっこける事は無くなりました。
本当か?という感じがしなくもありませんが、これでしばらく使ってみる 事にしてみます。多分、Cygwin+gdcという少しWin32APIに殻がかぶっている 環境で使っている所からくる、特殊事情によるものという感じがしなくも ありません。でも、自分でビルドしたgdcは、

Thread model: single
gcc version 3.4.3 (gdc 0.14, using dmd 0.127)

って出てくるので、てっきりマルチスレッド対応にはなっていないのだと 思い込んでいたのですが、それが罠だったような気も。

2005/07/11

日付け越え前に帰着。

先日のずっこけぶりをスタックダンプから調べてみた所、モロにGCの 中でsegfaultが発生しているもよう。構造体gcxのmark()メソッド内の 実行で死んでいる感じ。
死んでる個所を追跡してみたのですが、やはりfullcollect内で死んで いるもよう。しかし、今回は空きを探すとか、そういう個所よりも 遥かに手前で死んでいるようで、こちらの方が壊れている現場に近い のかも?と思ったりそうでもなかったり。

なにやら、マークの付け方が変な模様。スレッドが自分自身の時は スタックのトップを得るのですが、そうでなければ初期値0のままと いう条件なのですが、何故か後者の方を通って、変な領域にマーク を付けようとして死んでいるという感じ。何がなにやら。

2005/07/10

昼過ぎ起床。

GCの初期化ではなく、fdなどの初期化部分がまずいのかもと思い、 Dのmain(_Dmain)から始めて、Windowsなスレッドを生成して、その中で 動かしてみるのはどうだろうと試してみました。結果、fullGCの実行 前にsegfaultしている予感。でも、配列の割り当てサイズを変えると 動いたりする辺り、状況変わらずという感じ。むーん。

食料調達ついでに本屋に。「ONE PIECE」とDEATHNOTE」の新刊購入。 デスノ。こうなるかー。そんな感じ。

2005/07/09

起きたら夕方。寝過ぎ。

メモリプールをスキャンして、未使用領域をサーチしているように見えるのですが、 同じビットマップを何度もスキャンしているような動きに見えるのがなんだか 良く判らず。

久しぶりにCygwinのスナップショットをビルドしてみたり。ところが、 fork.ccへのパッチが当たらなくなっててへこり。そんな感じで少し手で書き換えて みたりして、取りあえずOKそう。 冗長な直し方は変わらずな上、用事のある所だけをいじった感じですが、 こんなのでひとつ(fork.cc.patch)。

2005/07/08

日付け越え少し前に帰着。

ページテーブルのマーク付けは行なわれている感じになっているので、それを 探し出す部分がマズイのか?と思い、動きを眺めてみたのですが、イマイチ やってる事がよく判らず。

2005/07/07

日付け越え。

えー、ボケてました。先日のコード、同じじゃないですね(汗;
pool.pagetable[iiii]はpool.pagetable[pn+iiii]が正解で、ここを直すと 結局、動きに変化はありませんでした。それにしても、なんとなくでも 動いてしまう辺りは結構謎ですが。

2005/07/06

日付け越え。

GC追いかけ。ついに現場を押さえたかも!

struct GcxのbigAlloc()いうメンバー関数で、4096byteを越えるメモリサイズの 割り当てを行っているようなのですが、この時、割り当てサイズをブロックサイズ の整数倍に丸めた後、pooltableにプールを使用しているフラグを、 先頭ブロックをB_PAGE、残りをB_PAGEPLUSとして付けます。ここんところのコードが、

        pool.pagetable[pn] = B_PAGE;
        if (npages > 1)
            memset(&pool.pagetable[pn + 1], B_PAGEPLUS, npages - 1);

となっていたのを、

        pool.pagetable[pn] = B_PAGE;
        if (npages > 1){
          int iiii ;
          for( iiii=1 ; iiii<npages ; iiii++ ){
            pool.pagetable[iiii]=B_PAGEPLUS ;
          }
        }

てな感じに変えると何故か反応が変わったり。なんとなく同じに見えるのですが、 何かしらの影響があるっぽい。

でも、Segfaultはしないものの、何故か読み込んだ形状データが思惑と違う感じ になってたり。はて?........

2005/07/05

日付け越え少し前に帰着。

GCの追いかけポイントを思い出し、printfで様子を観察。 まだ、誤って開放されている領域とそうでない領域との 動きの違いが見つけられず。

2005/07/04

日付け越え少し前に帰着。

えー、すっかり何やってたのか忘れ去っていたり。思い出すのに精一杯。

液晶だと走査線による書き換えが無いというか、脳による残像補間が必要でない為か よく判りませんが、我が家のPCの最大解像度である1280x1024にしても、 目があまり疲れなかったり。不思議。

2005/07/03

いつもより早く起きて(と言っても午前中というだけですが)、久しぶりに 秋葉に行ってみたり。近所のパソコン屋でも良かったのですが、選択肢が あるかもと思ったのが理由。

日記を辿ると2年前に行ったログがあるっきり なので、それ以来だと思われます。ドンキホーテとか無かったし、ヤマギワ も建替え工事中だし、駅前の高層ビルも記憶に無いという感じだったり なのですが、よくよく見てみると、基本的なものは大して変わっていない のかも。適当に見て周って、結局「持ち帰るのに耐えられるか?」という理由 だけで、「17インチの液晶でいいや」という結論に達してみたり。 EIZOのを買ってみたのですが、どうやら液晶に関してはどのメーカーも同じというか、 好みの問題というか、それによる所が大きいという感じがします。
Laoxで買ったのですが、梱包に時間がかかるとか言われたので、店内を 少しウロウロしてみたり。「ヴァナディールベンチ」とか、最近は面白いもの があるなぁと思ったり。ベンチの様子を見ていると、やっぱ大量のキャラクタを スムーズに動かすというのは、現在はそれなりに意味のある事なのかもと いう感じ。アバターが大量に存在したところで、同時にしゃべるのは、せいぜい 2,3人という所なので、通常のシーンでは大量のキャラクタを同時に画面に出せる 事は、事実上あまり意味の無い所なのかも知れません。しかしながら、例えば騒ぎが 起っているとか、見れば判るような視覚効果により、野次馬的な要素を発生 できるという点とか、多人数でプレイするネットゲームなんかでは効果を 発揮するのではないかと思います。

帰ってディスプレイ設置。見る角度によって色が変わるのは液晶だからしかたない として、視点を固定した時に、やっぱ画面の中で下の方と上の方とで、色の違いが 出る(口角が狭いっていうの?)のは、イマイチという感じ。TVの場合、ある程度の サイズがあれば、離れて見る事で画面内での色むらがあまり生じない(視点 から画面上の各画素までの画素毎の視線が平行に近づくから)と思うのですが、 PCディスプレイの場合は比較的至近距離で見るのがその原因の様に思います。

とか、やってるうちに疲れて眠くて死亡。

2005/07/02

起きたら夕方。

少し様子を見るも、調べる道具が無いので、もうあきらめてみることに。 で、近所のパソコン屋にディスプレイの調査に。17インチの液晶で大体4万円 くらいが相場の模様。

ファミ通WaveDVD見たり。E3レポート。PS3やXbox360なんかのデモ映像が もう少し観られるかと思ったのですが、本体の映像のみという感じでした。 バーンアウトのPS3対応(になると思われる)デモがチラッと映っていた 様に思ったのですが、あれがリアルタイム映像だとすると凄過ぎ。

2005/07/01

飲み会から帰って、日付け越え前に帰着。

眠くて死亡。


TOP PREV