反論紹介

(前のページより続く)

目次

はじめに

 注意・重要

テクスチャ表現

 8bitテクスチャ・シェーディング プレステとの比較

メモリ

ＳＧＬ

 プレステとの比較

回転ＢＧ

まとめ

メモリ

こちらも執筆時には忘れていました。指摘されて思い出しました。

サターンが採用していた SDRAM は、高速なのですが当時まだ高価でした。ちなみに、プレステは通常の DRAM。

まず、プレステはメインラムに 2Mバイト、VRAM に 1Mバイトを搭載していました。

サターンは、メインメモリが 2M バイト、VRAM が 1.5M バイトでした。しかし、これを全部 SDRAM で用意すると値段が高くなりすぎるため、メインメモリの半分、 1M バイトは DRAM になっていました。

ここで問題が起こります。プログラムとよく使うデータは、SDRAM に置いておかないと、実行速度があからさまに低下するのです。

なんでそんな変な構成に？　…というのは、推察は出来るけど不明です。

つまり、プログラマにとってはメインメモリが「プレステの半分」と言っても良い状況だった、ということ。

ここに巨大なＳＧＬライブラリが入るので…という話ですが、今調べてみたら、ＳＧＬが使用するのは 272Kbyte でした。メモリサイズの４分の１強。半分とまでは行きません。

一応サターン側の肩を持っておけば、プレステの CPU R3000 は１命令が 32bit ですが、サターンの SH2 は 16bit です。なので、プログラム「だけ」なら、メモリは半分程度で大丈夫です。

でも、この頃のゲームって、すでにプログラムよりもデータの方が大きいんですよね…。そして、データは R3000 だろうが SH2 だろうが同じサイズです。

事実がどうかではなくて、「感覚的に」と断ったうえで５分の１という窮屈感を感じるのは、非常に良くわかります。

個人的な話になりますが、プログラムを組んでいた当時、自分で「メモリマップ表」を作り、コピーして鉛筆で書きこんでいました。

プログラム修正などで細かくメモリ配置が換わったら、消しゴムで消して修正します。

大きく変わったら、新しい紙に書きなおしていました。

VDP1 RAM と VDP2 RAM と、メインメモリと…全部で４つあったはずだけど、あと何書いてたっけ？

と思っていたのですが、kozo さんの指摘で思い出しました。メインメモリを２つに分けていたのだった。

プログラムとよく使うデータを高速メモリに、あまり使わないデータを低速メモリに置くようにしていた覚えがあります。

ただ、僕がプログラムしていた ST-V の場合、CD-ROM よりも高速な ROM にデータを置けるので、すべてのデータをメモリに載せておく必要もありませんでした。

低速メモリは出来るだけ使わずに置いといて、サターンに移植する必要が出た時のバッファとする…というのが暗黙の了解だったように思います。

これも、低速メモリの存在を忘れていた理由かな。

これは…先に書いたように、僕自身グーローを使ったゲームに関与しなかったので実感がないです。

フラットな 4bit テクスチャ（16bit よりメモリを食わないので、細かく書き込める）でも、回転ＢＧと組み合わせた時に、テクスチャが荒く見えましたけどね (^^;;

…って、結局テクスチャは荒かったって話か。

以下、プレステのグーローがらみの話をしてくださっていますが、僕が経験していないのであまり補足はできないです。

ここら辺は、先に説明したテクニックのことです。

技術的には同じことを書いていても、当時の使用感を伝えるものとして引用しておきます。

ＳＧＬ

ここからはＳＧＬライブラリの話。

バグの多さには僕も泣かされたので共感します。僕はサウンドバグで泣いたなぁ。

業務用の ST-V で作っていたので、３日くらい電源入れっぱなしでも動作がおかしくならないこと、というチェックがありました。

ところが、丸一日動かしておくと、サウンドが止まってしまうのです。

最終的に、その時使っていたサウンドドライバのバグだと言うことになり、古いバージョンをもらって（そのせいで一部機能が使えなくなって）解決した覚えがあります。

…と、僕の経験談はともかくとして、「ハングアップ」と言うのは大バグです。

kozo さんに後で詳細を聞いたところ、2int で動作させていなければ出ないうえ、PAL 版では出なかったので、ハードのバグではないか、とのこと。95年末ごろまでは、このバグがあった覚えがあるそうです。

…先に書いた、僕が関わったゲーム、調べてみたら 2int で、95年末以前に作っていました。でも、そのバグに遭遇したことは無い。

ハードの問題ならば、ST-V では微妙な差異によってハングアップしなかったのでしょうね。

提供されるツールが貧弱である、というのは、プレステはサードパーティ獲得に熱心だったが、当初のセガにその考えがなかった、ということとも関係しているように思います。

ゲームを作りなれている会社だけを相手にするつもりなら、多少貧弱でも最低の物が揃っていればいいです。

でも、ソニーがサードパーティの「数」を問題にし始めたので、セガもあわてて数を獲得しようとして、ゲームを作りなれていない会社もサードパーティに加えます。

しかし、泥縄対応だったので十分なサポートはできていませんでした。もちろん、ソニーは当初通りの計画なのでサポートは手厚く行っていました。

セガサターンが現役だった時代、手厚いサポートを提供するための部署、というのは結局作られなかったのではないかな。そして多分、ドリームキャストの時にも。

ハードウェアが複雑で開発しにくかった、とよく言われているのですが、むしろ「サポートが貧弱で」開発しづらかったのではないかとも思います。

そして、生成されるのは確かにＣのデータでしたね。

ついでに言えば、テクスチャデータはたしか 8byte アライメント（先頭が、8byte 単位の区切りに来ないといけない）という制限があったにもかかわらず、その形式でないデータを作ってくれました。

横は８ドット単位、縦は１ドット単位なので、１ドット4bitのデータを作ると 4byte 単位の「端数」がでる場合があるんですよ。

この端数を処理するパディングデータ（アライメントを合わせるためだけに存在する、無意味なデータ）を入れてほしいのだけど、入れてくれないので正しく表示できない。

そんな変なサイズのテクスチャ描くほうが悪い、という気もしますが、実際困ったことがある。

Cソースでデータが作られるのは正直なところ問題で、僕は perl で処理してました。

この頃にかなり perl を使い込んで覚えたので、後に独立して WEB プログラマになった時に非常に助かった :-)

テクスチャとモデルのデータをディレクトリに入れたら、あとは自作ツールで

・テクスチャ・モデルデータをツールで処理

・得られたＣソースを整形して、欲しい形式のデータの Cソースに

　（後にパディング問題に気づき、この時点で処理するようにした）

・データをまとめ、アクセスしやすくするためのテーブルも同時に生成

・make を起動して C コンパイル

までこなしていました。

変更されていないデータも毎回処理するので遅かったけど、こまごま手作業しても同じくらい時間がかかるし、全自動の方がミスがなかったので。

…このプログラム、自作で誰にも見せなかったはずなのに、会社辞める直前になってみんなが使っているのに気付きました。

人に使わせようと思ってなかったから、バグが多数あったのも知っているのだけど、面倒だから黙って会社辞めました。

次ページ: プレステとの比較