Last update: Saturday, 08-Oct-2011 03:32:38 JST
Access Count: (start 1997/07/04)
この日記はGNSで生成しています。
この日記の画像はOPTPiX webDesigner Ver.4で生成しています。
|
Last update: Saturday, 08-Oct-2011 03:32:38 JST |
」（羅川真里茂）
」（高橋しん）
」（若木民喜）
」（Cuvie）
」（あづまゆき）
」（Cuvie）
」（藤真拓哉, 都築真紀）
」（緋賀ゆかり, 都築真紀）
_ BSスカパーの試験放送を正午から見届ける。
_ じゃ録画鯖に新しいチャンネルの登録をしようか・・・と作業しているうちに日が暮れた・・・。
_ うちは「昔のままのPT2録画環境をカスタムして使っている」ので、最近のバージョンでの対応方法は使えない。各種チャンネルテーブルに新チャンネルを追加後、結局BonDriverとRecTestに新しいBSチャンネルを追加して再コンパイルする作業が必要だった。
_ おまけに、KB2538242でVS2005SP1のvcredistパッケージを最新版にしなければならないところ、録画鯖は「安定動作を保つためOS更新をしない」方針で使っていたため、結局OS更新が必要になり大幅に時間を食ったり。
」（小畑健, 大場つぐみ）
」（安部真弘）
」（安部真弘）
」（宮原るり）
」（星里もちる）
」（石川雅之）
」（佐伯かよの）
」（井ノ本リカ子）
」（タアモ）
」（山本航暉）
」（大井昌和）
」（畑健二郎）
」（藤崎真緒）
」（園田健一）
」（石黒正数）
」（大井昌和, 北島和洋）
」（あさのゆきこ）
」（あっと）
」（横山知生）
」（新谷かおる）
」（刑部真芯）
」（藤真拓哉, 都築真紀）
」（藤真拓哉, 都築真紀）
」（きゆづきさとこ）
」（櫻井寛, はやせ淳）
」（克亜樹）
」（竿尾悟）
」（宮尾岳）
」（三澤康広）
_ ついったでの話の流れから、液晶の残像時間を計ってみることに。
| 機種 | 時間 |
|---|---|
| PSP-1000 | 12/240秒 |
| PSP-3000 | 8/240秒 |
| DSi | 8/240秒 |
| Thinkpad X40 | 8/240秒 |
| VAIO Z11 | 6/240秒 |
| iPad | 6/240秒 |
| GALAXY tab | 6/240秒 |
| LCD2490WUXi2 | 5/240秒 |
| REGZA 37Z7000 | 3/240秒 |
_ 調査方法はいたって単純で、「白地に黒の文字が表示されている状態」から、「文字が消えたときに完全に白地になるまで」をExilim EX-FH100の240fpsムービーで撮影して、フレーム数をみるという方法。
_
やはりPSP-1000の遅さが際立つ。そのへんから話は始まったんだけども。
_ ついったでの話の流れから、垂直・水平同期処理を語ることに。
_ 自分の分は以下の通り。
|
今だと意識しなければいけないシーンはそうそうないが、CRTコントローラが扱うレジスタやメモリをCPUから触るときは「いまCRTが画面上のどこを走査しているか」を把握しなければならない時代があった 最も基本的なこととして、CRTは「１つの点が左から右、上から下に動きながら輝度を変えることで面を表現する」ことを知っておく必要がある。画面制御系のレジスタやメモリ内容をCRTへの信号に変えるのがCRTコントローラの役目 最初期は「画面走査中にCRT系のレジスタやメモリに触るとCRT制御に影響が出てノイズになる」ので「画面走査中はアクセスできないようにハード的に処理する」とか「CPUアクセス時は画面走査そのものを止める」とかだった 少し進むと、「CRTが画面走査中でも適宜CPUが書き込めるように配慮する」ようになり、また「画面走査中でない」ことをCPUで監視できるようにすることで高速転送が可能に。「監視しなくてもいいようにCPU割り込みをかけられる」ものも 「１つの点が左から右、上から下に動きながら面を描く」ということは、その点が右端へ到達したら左端へ戻す必要があり、下端に到達したら上端に戻す必要がある。これにかかる期間を帰線期間といい、それぞれ水平帰線期間・垂直帰線期間という ゲームは高速大量に画面処理を行う必要があるので、帰線期間、それも比較的長い「垂直帰線期間」にまとめてアクセスすることが重要になる。また監視にCPUを割くのがもったいないので割り込みが重宝される。これが垂直同期（VSYNC）処理 もちろん、水平帰線期間も有効に使おうという考えはあり、同様に水平同期（HSYNC）処理といわれた。ただ、当時のCPUは性能が低くあまりできることがないと考えたのか実装はそれほど多くはなかった HSYNCが検出できるようになると、「任意の水平帰線期間でCRTコントローラが扱うレジスタやメモリを書き換える」ことで、静的な表示では不可能だった表現を行うようになる。これがラスター処理といわれるもの HSYNCを検出できないハードは珍しくなかったが、「CRTCがスプライトを描画するときに重なりがあったら割り込みを発する」機能を代替で使ったり、「VSYNCからの経過時間」をポーリングor割り込みで検出して代替することもあった HSYNC処理でできることは「スクロールレジスタの書き換え」だけに留まらず、スプライト座標やパレットカラーの書き換え、CGの書き換え、画面の色モードや解像度の書き換えなど多岐に渡る うねうね系のスクロールレジスタ変更は使いやすくてインパクトがあったのでよく使われ、ついにはラスター毎のスクロールレジスタまで持つに到ったと このへんまでがラインバッファ系の画面表示のしくみで、フレームバッファ系の画面表示になるとこの手の知識はほぼ不要、せいぜい「VSYNCでバッファのフリップを行う」ことくらいしか知らなくてよくなる ただ、フレームバッファ方式でも「１つのバッファをフリップさせず常に表示させ続け、垂直帰線期間に入ったらバッファの更新を始める」やり方もある 更新が間に合わないと画面が崩れるが、間に合うなら「ラインバッファ方式と同等のレイテンシで描画できる」利点があり、昨日TLに出ていたダブルバッファ方式のレイテンシの欠点はなくなる話につながる、と |
Last update: Saturday, 08-Oct-2011 03:32:38 JSTメールはこちらへ...[後藤浩昭 / Hiroaki GOTO / GORRY / gorry@hauN.org]
