アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
UI (スコア:5, 興味深い)
そういえば、パソコンもGUI関連がマウスにべったりですから、マウスホイールや、ペン・タブレットのように「マウスあり」きな発展をしてしまうんですよね。OSレベルの深いところでIOをサポートされたタッチパネルなんかが出回ると、ブレイクスルーになりそうな気がしますが、タッチパネルって現状は、組み込み系でしか使われてないんですよね。なんか、不思議だ。
レタッチソフトはもちろん、ブラウザからなにから、全てを巻き込む可能性を秘めているのに…
Re:UI (スコア:0)
PSのハードはゲーム機としてはヘンテコで使いづらく、初期の開発環境がその辺に転がってたオープンソースでSCEのライブラリが未完成で使えない物だった。
だけど、ゲームソフトを出すときSCEに払うロイヤリティーが任天堂よりも激しく安かったし、ナムコのPS用ライブラリが優秀だったので、ヘンテコハードだけどなんとかなった。
しかし、SCEが天狗になって資料の出し惜しみなどで中小ソフト会社を差別化したので、喧嘩別れしてワープして逃げ出したやつも出たけど、残念なことにあまり食卓に上ることが無かった。
PS2はN64を激しくリスペクトしてた。業務用CGの権威だったsgiが作ったN64を妄信的にリスペクトしてた。
業務用CGはゲームでなくてムービーを作ることが目的だったのにね。
シェーダーとかもリスペクト、ランダムアクセスが遅いRambusの採用とかメモリが少ない失敗までリスペクトしてる。
PS2やN64の設計は、ゲーム機がプレイヤーの操作に対してCGがインタラクティブに反応するためにレイテンシーが非常に小さくなきゃいけないことを理解してなかった。
ゲームを書いたことがない人たちが設計してしまったので、お絵書き以外のプログラム処理が意外と重く複雑であることを知らなかったのだ。
衝突判定など重い処理もハード支援がほとんどないのでポリゴンが欠けたりめりこんだ。
格ゲーなどで分岐予測して次ぎのシーンで投機的な準備をする処理が、WindowsなどのOOP並に巨大になることを知らなかったようだ。
3Dがしょぼいので、ムービー用にmpeg1程度のハードが載ってた。
昔の飛行機に喩えると、マシンが自動化されてなかったので、機長、副操縦士、六分儀で測って手計算する航法士、ECUがないエンジンや各燃料タンクの面倒を見る機関士、モールス符号を打つ無線技師の5人の仕事を1人でやって乗けるプログラマ負担がとても大きかった。
さらに、CGデータが入ってる倉庫が店から遠くて客を待たせ、倉庫が狭くて荷物が多いので倉庫番の仕事がつらかった。
GCはATIのCGチップ設計やMOSYSのメモリ、ローカルキャッシュなどを使ってレイテンシーが小さい設計を心がけた。GDP(ビデオチップ)から遠いCPUの配下に倉庫を置かず、GDP兼チップセットの配下に倉庫を置いた。また、CDやDVDと違ってGD-ROMは回転数が一定なのでロードがとても早い。またディスクが小さく軽いので回転の立ち上がり加速が速い。
DCはSDRAMを直結できるSH-4を使った。モデムは専用PCIスロットにつながっていた。PCユーザがPCIやSDRAMを全く知らなかった時代だ。
(ちなみにSDRAMというハイテクが一般家庭に入ったのはDCでもPCでもなく、CATVの端末が最初だったようだ)
DCはPS2よりもエフェクトなどが優れてた。車のライトは光を放射してるし、窓を透けて反対側の景色が見えた。しかしPCI程度ではタイルレンダラーが十分な性能を出せなかった。