昔の最近の出来事(2007.06)

2007/06/30

みっちり寝て昼ごろ起床。

ちょろり本屋に。特に収穫無し。

何気にチャンネルザッピングしていて、たまたま観た 「サイエンスZERO」。土曜の夕方に放送されていると思っていたのですが、 いつの間にやら深夜枠に移動されているというのを初めて知りました。 しかもアシスタントが 真鍋かをり から 安めぐみ に変わっていたり。 で、最新の顕微鏡の回だったのですが、それよりもシミュレーション医療教育 の話が面白いなぁと思ったり。問診シミュレーションを実演していたのですが、 ゲームメーカーと共同開発したというソフトの画面が、まるでゲームそのもの。 問診シミュレーションとは、予め病気を設定しておき、それに対して人が症状 などを問いかけると、コンピュータが設定した病気に応じた返答を返すという 問診の練習ソフトです。問診の返答から、予め設定した病名を当てるという点に加えて、 何度も同じ事を聞くとか、いきなり専門用語を使ってしまうといった、問診の仕方に ついても評価を行うという優れものでした。実演を見てみると、音声はリアルタイムで解釈するし、 受け答えも自然な発音で行われていて、ゲームのような見た目からは想像できないような本格的な シミュレータのように思いました。でも、ここまでできるのであれば、 むしろ逆に、問診をコンピュータにさせて、原因の可能性を自動推論させる方には 使えないかしら？とも思ったり。 問診で誤診する事ってあるみたいなので、診断確度を上げる為のサポートに 使うとか、そんな感じにできないのかなぁと思いました。
医療シミュレーションと言えば、15年ほど前に「LIFE and DEATH」 というゲームがありました(TANEは実際にやった事は無いですが)。 洋ゲー特有のキワモノ感漂う印象のあるゲーム(TANE的主観)なのですが、 現在の技術で作るとまたちょっと違った感じになるのかなぁとも思ったり。 でも、リアル過ぎるのは嫌かも(^^;

早くもなく遅くもなく。

ターミネータ３を観てたら途中で眠くて死亡。

気持ち早めに帰着。

気が付いたらいつの間にか寝てたり。そんな訳で「わたしたちの教科書」 の最終回は観れずじまい。

早めに帰着。

ちょろりコーディング。

早くもなく遅くもなく。

キャラと絵の対応付けの話。あんま良い方法を思いつかず。 キャラに対応する絵を外から与えられるようにすると、結局キャラクタクラス の絵のIDを外から与えられるという事で、突き詰めていくと動きなども外付け にしないと中途半端な感じになって、それってのはスクリプト的なもので キャラ定義を与えているのと同じ意味になっているような気がしてきたり。 でもまぁ、キャラ一個の定義と絵が1:1ならば問題無いですが、キャラ一個 に対して、アニメーションパターンの絵を複数使用する時とか、結構面倒 臭い感じがします。色々なケースに対応しようとすると、一意の手順では うまく表現できないのかも。

DEATH NOTEのアニメの最終話。基本は原作通りなのですが、最後は何だか 変な演出。

気持ち遅めに帰着。

ハードコーディングするのも面倒臭くなってきたので、キャラと絵の対応付けとかを 外付けの設定ファイルから読み込めないかなぁと思ったり。絵を読み込むだけ ならどうって事は無いのですが、絵とキャラクタを連動させようと思うと、 どうしてもクラス内のハードコーディング要素をどうにかしなくてはならない 気も。という訳でイマイチ方法がまとまらず。

昼前起床。散髪の予約を入れようとしたところ「20:00頃になりますね」 (11:30時点)と言われたので無しに。

タイマーの精度についてしんさんより 御教授いただいたり。 timeBeginPeriod(),timeEndPeriod()についてはVSYNC代わりに timeGetTime()やSleep()を使う所で色々出ていたのですが、 イマイチ使うのが正しいのかどうかの判断が付かなかったので保留してました。 で、全プロセスが影響を受けるとか、timeBeginPeriod()の方は値を指定 しつつも、timeEndPeriod()の方はtimeBeginPeriod()の値を識別子に使って いるとか、謎な感じのAPIである事が判ったり。それにしても、全プロセスが 影響を受けるってどういう事？って気がしなくもありません。高精度を要求した プロセス起動後に、別のプロセス起動で低精度の要求を入れたらどうなるの？ とか、疑問は色々あるところ。

一応、精度が変わる事は確認できました。普通に使って良いものか どうかはよく判らないですが。因みに、SDLではどうやってるのかしら？とちょっと見て みたのところ、timeBeginPeriod(1)とか実行している節が見られます。でも、 時間を取得する為だけに使っているような気も。イマイチ読めてません(^^;

インターネットTVで「FREEDOM」のアニメを観たり。カップヌードルの CMと連動して製作されたオリジナルアニメです。キャラクターが3DCG 表現なのですが、フェイシャル、動き、線画 がセルアニメっぽく表現 されてて、よくできてるなぁと思ったり。製作時の話とかも放送されてましたが、 セルシェーダーで一発レンダリングという訳ではなくて、 何層かのレイヤーを重ねて最終的な絵になっているようです。 線画については、自動生成っぽく無いように思えたのですが、 実際どうやって描いているのかはよく判りませんでした。動きは 多分手付けだと思われますが、それもあってか よりセルアニメぽい 感じになっていると思いました。ただし、全て3DCGでうまく表現できているように 見えるのは、デッサンのしっかりしている大友克洋のキャラクターデザイン だからか？とも思ったり。しかしながら、最近は萌え系っぽい感じの キャラクターも違和感の無い程度にうまく立体化できていたりするようなので、 要はやり方次第という事なのかも。

昼前起床。

とりあえずSleep()安定の話はおいといて、CPUの使用率について。 Sleep()を使用して約60fps待ちをした時、CPUの使用率は1〜5% (＠Pentium4(3.06GHz)) くらいといったところでした。フレーム落ちするか否かは表示サイズのみ に依存しているようです。



約1900[3Dオブジェクト/フレーム]の表示(3Dオブジェクト1個あたり平均で25三角ポリゴン) で、フレームサイズ240x320ならOK、480x640だとぎりぎりアウトくらいの感じ。 流石にこのレベルになると、ソフトウェアレンダリングでは敵わない という感じに思います。
てな事を考えると、ハイデフ対応できるかどうかは、グラフィックハードウェア に大きく依存すると言えるかも。逆にCPUは物理シミュなど動きの制御を メインに使ってゆくという感じになるのでしょうかね。 例えば、バネシミュレーションなどは60fpsという単位で動かすと解がすぐに 発散する場合があったり、当たり判定は物体の移動速度が速過ぎると判定をすり抜けたりする為、 内部処理は実際の表示フレームよりも高いフレームレートで動かす なんてのが考えられると思います。因みに、Xbox360の「Forza Motorsports 2」 では、描画の3倍のフレームで内部処理をしているようです。 他にも、表示はされないがリアルタイムで大量のNPCのステートを動かし続けるなんて のもCPU時間を大量に使う要素だと思います。
とは言っても、簡単な処理だけど大量に行う為にCPUを多く使用するが、描画も大量に 行わなくてはならない場合ってのが、意外と多いように思います。例えばパーティクルの ような感じ。こうなると、CPU×n＜GPU×n という負荷の関係となり、 オブジェクト数 nが多くなると、負荷格差が広がる事になると思います。 この場合ばかりはどうしようも無い所かなと思われます。

ちょろり本屋に。6/20頃に新刊が集中していたため一気買いな感じに。

気持ち早めに帰着。

気が付いたらいつの間にか寝てたり。

気持ち早めに帰着。

毎回なんとなく続きが気になりながら見ていた「わたしたちの教科書」。 今の状態でも一体どうなるんだ？って感じで、やっぱりラストが どうなるのか気になる今日この頃。

ちょろっとコードを足したり。

早めに帰着。

コード見直し。フレーム描画の時間同期を取る為に、timeGetTime()関数を 使用して時間差が16ms(約1/60秒)になるまで、「ループで待ち合わせ」して ました。これを、Sleep()を使った待ち合わせに変えてみた所、とりあえず うまく動いているかな？という感じだったのが、風呂に入ったあと、続きで もっかい動かしたら何故かうまく動かなくなったり。何故？

調べてみたところ、何が契機か判りませんが、Sleep()が指定した値 よりも約15ms余計にSleepしていることがわかりました。

    nowtime = timeGetTime() ;
    difftime= nowtime - beforetime ;
    printf("befor difftime=%d[ms]\n",difftime) ;
    
    Sleep(32) ;
    
    nowtime = timeGetTime() ;
    difftime= nowtime - beforetime ;
    printf("after difftime=%d[ms]\n",difftime) ;

befor difftime=0[ms]
after difftime=47[ms]  #約15ms多い
  : 繰り返し

befor difftime=0[ms]
after difftime=16[ms] #約15ms多い
  : 繰り替えし

befor difftime=0[ms]
after difftime=78[ms] #約14ms多い
  :繰り返し

早くもなく遅くもなく。

DMDのコンパイラの2.0がリリースされているもよう。gdcにフィードバックが かかるのはしばらく先という感じかも。

コードの整理。

遅めに帰着。

敵パターンをちょこちょこ増やしてみたり。

暑さで割と早めに起きてみたり。掃除したり洗濯したり。

ちょろり本屋に。ついでにゲーセンに寄ってみたり。 「むちむちポーク！」 を一回だけやってみたり。舞台設定はなんだかよくわかりませんが、 ゲームは思いのほか弾幕が薄くて割と普通に遊べるような気がしたり(恐らく 気のせいでしょう)。２面道中死になので、その先の事はよくわかりませんが。

暑さでぐったり。

ちょろっとコーディングしたり、TV見たりして終了。

少し遅めに飲みから帰着。

そのまま爆睡。

気持ち早めに帰着。

コーディングはかどらず。

「デジ絵の文法」 。存在は知ってましたが有料コンテンツの為、そのうちDVDに でもならないかしらと思ってました。で、DVDになるとかで深夜に 少しだけ放送されてました。オリジナルは1〜2作家あたり27分くらいの放送みたい なのですが、特別編集の為か3人で30分だったので、かなり駆け足な 感じになってました。その為、レイヤーの構成はおろか、複数のソフトを 渡り歩いている所とか、細かい点はあまりよく判りませんでした。 ただ、始めの方でマシンスペックや編集画像サイズは出てました。 大体 一辺3000〜4000pixくらいのサイズで描く場合が多いようです。サイズが大きいのは 元の線画をスキャナで取り込んだ為とか、印刷用途の為だとか色々な理由があるかと 思います。でも、実際の着色過程では、細かいところを時間をかけて塗る感じに なっているようなので、編集時の実効サイズは小さいという感じに思えました。

省メモリ作画法って需要が無いのかしら？ 例えば、スキャナで取り込んだ線画を、フルピクセル(データとして全ピクセルが有効な状態) のまま乗算で重ねるとか、色調節の為に同じレイヤーを何枚もコピーして統合せずに 置いておくとかは、無駄にメモリを使用する典型的な例だと思います。 あーでも、前者の場合は、画像が 適当なサイズのブロックに区切って管理されていて、 ブロック内の全てのピクセルが透明の場合は実際にメモリが割り当てられないって、 内部の構造が判らなければ、白部分を透明に抜く事で(多くの場合)省メモリにつながる って考えには辿り着けないかも。

早くもなく遅くもなく。

横になってたらいつの間にか寝てたり。

早くもなく遅くもなく。

ネプ理科。ウミウシが何を食べて生きているのか良くわからない為、 飼育できないというのに へぇ。

ロールしながら周回移動軸に沿ってヨー回転するような2軸回転を、 一回のglRotated()で実行するにはどうすれば？という事で、 随分昔に実装したまま使う機会の無かったクォータニオンクラスを 引っぱり出して使ってみたり。ヨーとロールを別々のクォータニオン で保持しておいて掛け算し、そこから取り出した回転角と回転軸 を3D描画時に一回だけ使用できるglRotated()に指定するという感じ。

気持ち遅めに帰着。

ちょろっと敵パターンを足してみたり。意外と敵の動きって思いつかないなぁ。

AM中に起きてぐうたら過ごしたり。雨で外に出る事ができず。

敵の出現パターンを外付けのファイルで書けるようにしてみたり。 経過時間で敵が出現する方式を採用しています。本当はBGのパターン などに合わせて敵を配置する感じにすると調節しやすいのかも知れませんが、 それはそれとして。

SAIの新しいのが出ていたり。何故このタイミングで？

AM中に起きてぐうたら過ごしたり。

フォントを少し調節して使ってみたり。でも、イマイチな感じ。 16dot以下のフォントはドット単位で調節した方が良いのかも。

そういや、本物お仕事ではかなり前からw3m-m17nを使用しているのですが、 つい最近、「タブ」が使える事を知ったり。マルチウインドな 使い方ができるので、検索結果を残したままサイトを回れる事が、 当たり前ですが異常に便利に感じたり。でも最近はコンテンツデータも、 PDFだったりFlashだったりJavaアップレットだったりとHTML以外の 方法で表示する場合が増えており、w3mでは直接閲覧できない 場合が多くなってます。テキストブラウザ自体を使うのが今の時代に 合っていないのかなぁと思ったりもするこの頃。

飲みから帰って即死。

気持ち早めに帰着。

フォントを書いたり。今使っているのは8x8の手書きのピクセルマップフォント なのですが、Inkscapeを使ってベクターで書いてみたり。2Dスプライトを スケール変更できるようにした都合、16x16くらいで書いておいて、必要に応じて 縮小して使った方が良いかなと思ったので。



上下が詰まっているので、アンチエリアシングが隣のフォント域に漏れ出てます。 調節が必要かも。

早めに帰着。

ちょろり調べもの。

2Dスプライトをスケール変更できるようにしてみたり。何かしらエフェクトに 使えるかなぁ？これと言って思いつかないけど。3Dスプライトのスケール変更は 法線の再計算が必要になる為、パフォーマンスに問題が出るらしいので入れる事を 躊躇した(glScaleを実行するコード自体を入れたくなかった) のですが、試しに入れてみたところ意外と問題にならないかもと思ったり。 そんな訳で3Dスプライトのスケール変更コードもそのまま入れてみたり。 くるくる回りながらしぼむとかできるかも。

気持ち早めに帰着。

TV見てたらいつの間にか寝てたり。

ちょろりコードを整理。なんとなくスッキリした気も。気のせいかも知れませんが。

早くもなく遅くもなく。

ちょろりコーディング。飾り表示とかを考え始めたら少し仕込みが 足りないなぁという感じ。

割と普通に起きて TVアニメの「ONE PIECE」を見て朝から涙腺緩みっぱなし。

GoogleEarthで高知の一部の解像度が上がっている事を知ったり。確かに以前は、 何故か高知市内の解像度がダメダメで実家の周辺を見る事ができなかったのですが、 はっきり見られるようになってます。でも、解像度の上がっているのは 高知市内までで、隣の南国市は以前のままっぽい。

ちょろっとコーディング。大した進みは無し。

起きたら昼過ぎ。

ぐうたら過ごして一日終了。

ちょろりコーディング。ステージ管理を少し考え直したり。 背景表示やステージ開始時の表示などをあまり散らからない感じで 行う為の制御クラスを用意してみたり。一意の手順で管理しようと 思うと考慮しておかなくてはならない事が色々あって、面倒臭い なぁという感じ。かといって、力ずくで書くのもそれはそれで 後で手を入れるのが大変になるでしょうし。一長一短かも。

早くもなく遅くもなく。

少し触れなかったオーディンスフィアを進めたり。ぎりぎりなんとか 先に進めたり。でも体力足らずにその先までは進めず。