インテルってピンチ？

http://pc-info.hypermart.net/cgi-bin/i.cgi?articleID=1692によると、Rambus社はインテルに対してDDR-SDRAMに関するライセンスを与えない方針だそうだ。

一部でRambusは疫病神と呼ばれているんだけど、さらに疫病神度アップ！って感じ？

IA-32アーキテクチャ（イワユルx86系）CPUではAMDの追い上げ、チップセットではVIAの追い上げくらって、ただでさえヘロヘロのインテル。痛いね。

まぁ、Rambus社がDDR-SDRAMを含む諸々の権利を主張している件に関しては、Micron等のメモリメーカーが裁判起こして反対してるし、インテルとしては密かに協力したい所かもね（公に協力するとRDRAM関連でRambusから不利な事言われちゃってニッチもサッチもいかなくなる可能性有るし）。

又は、インテルがキレてRambus潰しにかかってくれると面白いんだけどなぁ。

Nintendo64をRGB出力化改造してみた。ま、DACチップから出力端子まで３ヶ所ハンダ付けするだけなんで超簡単だけど、作業が細かいので超面倒だった。

で、RGB出力だけど、任天堂がNintendo64のRGB出力機能OFFにした理由がナントナク解るよ。だってRGB出力の方がビデオ出力よりキタナイんだもん。画像が…。

同じ例に、サターンのRPG「グランディア」のムービーがある。あれもRGB出力で観るとキタナイ。

両者に言える事は、画像が圧縮率の高いJPEGイメージ的である事だ。噂に聞くと、Nintendo64は内部では表示される倍の（面積では４倍）解像度でレンダリングし、それを縮小して表示しているそうだ。で、縮小時に方式は知らないがバイリニアフィルタリング等の処理をしてフルスクリーンアンチエイリアス（要するに、画面をぼかしている）としているらしい。PlayStation2で問題になっているジャギーを消すのが目的だろう。1ドットがでかいから。

しかしエッジアンチエイリアスではないので、やはりボケボケ画像な感じは否めない。

買ったまま放置してあった「ゼルダ64」プレイするためにNintendo64改造したんだが、タイトル画面の「（C)Nintendo」は雰囲気でしか読めん。

任天堂としてはぼかしを家庭用テレビ向けに調節したんだろう。結果、RGB出力は最悪。しかし、自分のゲーム環境はRGBディスプレイしかないので仕方ないのだ…。

次期任天堂据え置きハードのNintendoGameCubeは、従来のアナログ出力端子に加えてデジタル出力端子を備えている。15kHz出力なら従来の端子も持っているので、Dreamcastと同じように31kHzの出力（いわゆるVGA出力）をサポートするのだろうか？又はD端子？

所で最近始まったデジタルBSテレビ放送はプログレッシブスキャンなんだろうか？インターレススキャンだったら、旧来のテレビ放送から以降する理由無しだ。元々あまりテレビ見ないしな（ディスプレイは多くの時間見ているが）。

上でも触れた「ゼルダ64」。まだほんの触りしか遊んでないけど忙しいゲームだな。

ファミコン、スーファミのゼルダシリーズ遊んだ事が無いから、感じとしては「３Dになったビックリマンワールド（モンスターワールド）」って所か。

んで、何が忙しいかというと、ダンジョンでのカラクリ操作。まぁアクションゲームだからだけどRPGみたいにまったりプレイできないからね。

カラクリに対してのヒントは、過去のカラクリに対して自分が行ったアクションの経験だけが頼りな感じ。いや、なんか「ナビィ」という名前の妖精がヒントくれているようなのだが、それを読むためのボタンが遠いんで面倒につき読んでないんだよ。それでも過去にやった事覚えていれば詰る事なくゲームを進められるってのはデキが良いね（って、まだ火山の麓の村で鶏追いかけてる段階だけど）。

ってか、ナビィのヒント無視して自分で手持ちのアイテム駆使してカラクリ動かしたりボスやザコの弱点見つけるのが楽しいとも言える。

ってか、ザコ敵無視して走りまわってるんで、金が無くて買い物に苦労するわい。金は主に草刈やツボ割りで取得している。ま、盾くらいしか買うものないけど。

ネット対戦ゲームのパケットデータ構造を考えてみる。

座標データやなんか送るとデータ量が多くなるから、キー入力等のイベントを送るのが良かろう。そうなると、ストIIのような４方向レバー＋６ボタンで10bit、スタートボタンを入れても11bitでいいか。ヴァーチャロンだと４方向レバー×２＋ボタン４（オラタンだと５）＋スタートボタンで13（14）bitでいいか。16bitでデータ送れば2bit以上余るからECCエラー訂正もできそうだ。

マジにイベント型にした場合、「押した」イベントと「離した」の区別が要るけど、リアルタイムに（1/60毎に）キー入力状態を垂れ流ししてその状態をそのまま使うとかにすれば、そんな判断要らない。

垂れ流しリアルタイムキーステートなら再送とかも要らないから、さらに単純だな。

つまり、16×60＝960bps。1200bpsの全二重通信でOKってか？

ただ、データが来なかったのが判らないと、双方にズレが生じて良くないな。TICKデータも持つか。TICKの最小単位は1int（1/60秒）で、これまた16bitだと65536TICK、つまり1092秒、つまり18分でありゲームに使うにゃOKかな？。ゲームスタート毎（「FIGHT!」とか表示するタイミング）に初期化すれば何とかなるけど危険かなぁ。ま、いいや。

合わせて32bit。これだと1920bps。TICKカウンタのエラー訂正もせにゃいかんけど、2400bpsあれば足りそう。

設計に余裕を持たせて、TICKカウンタ32bit、キーステート32bitだと64bit。3840bpsか。4800bpsすな。

割りと低速でいいんだなぁ。なんつったりしてな。

実際はどうなんでしょ？