もう一つのライブラリ
目次
ＳＧＬ
新OS と呼ばれた SGL については、本文中ですでに扱っていますが、書いていないことも含めて改めて説明します。
まず最初にお詫び。
本文初出では、僕の記憶を元に SGL は Sega Game Library の略だとしていました。
先に書いた通り、今回調査中に流出した書類を発見したのですが、正式名は Sega Saturn Graphics Library だった模様。
本文はすでに修正してあります。
ただ、書類中に「SEGA 3D Game Library 、略して SGL」って記述もあるんですよね…
最後に書きますが、僕がいた会社では、SGL の正式発表前から開発中バージョンの提供を受けていました。
なので、当初は Game Library の略だったのが、何らかの理由で Graphics Library に改められた可能性はあります。
日本語版マニュアルを今でも持っている、という方から、「日本語マニュアル表紙には 3D Game Library とあるが、中は Graphics と書かれている場所もある」と情報頂きました。
そして、「記憶の限り、改められた覚えはないので途中で変わったのではないのだろう」とも。
マニュアルは一応「社外秘」なので、持っているのはマズいのでは？ ということで、ご迷惑はおかけできないので匿名情報とします (^^;;
「正式名が SGL で、これが何の略かは特に決まってなかった」と言うあたりが真実にも思います。
というか、ライブラリの関数群、全部 sl が接頭語としてつくんだよね。
開発時点で「Sega Library」で、G は後から入れたのではないかと…。
SBL の上をいく SGL とか（キーボード上、B の上に G があります）、そんな適当な理由で名前が付けられて、G が何の略かは後付け、というのもありそうな話です。
さて、SBL が家庭用部署で作られたのに対し、SGL は業務用の部署で作られています。
バーチャファイターは、業務用を開発した AM2 研がサターン版を直接作ったことが知られています。
この際、MODEL 1 ボードの V60 アセンブラプログラムから、SH2 のアセンブラに単純変換することで開発が始まっています。
（昔の雑誌に書かれていましたが、すでに手元にないため詳細失念）
すでに本文で書いていますが、MODEL 1 では 3D 演算はハードウェアが行いました。
そこで、サブ CPU にこの 3D 演算をエミュレートさせ、MODEL 1 のプログラムがスムーズに移植できる環境が整えられます。
このプログラムから共通化できそうな部分を拾い集めてＣ言語のライブラリとして整えたのが SGL の元となったもの。
より正確を期すなら、SGL は「バーチャファイターリミックス」から切り出して作られたように思います。
バーチャファイターの時には 3D 部分にはまだ多少バグが残っていました。
また、回転ＢＧ面も使用されておらず、サターンの性能を十分に引き出してはいませんでした。
バーチャファイターリミックスでは、これらの部分が改良されています。
SGL を切り出して改良した成果が「リミックス」に再反映された、という可能性もあります。
VF2 の時には、すでに SGL が使用されているようで、スタッフロールに Special Thanks として、S.G.L. Team の名前が入っています。
ともかく、SGL は実際に「バーチャファイターが作れる程度」に性能を引き出せる、実践的なライブラリになっています。
内容は３Ｄポリゴンゲームを作りやすくするための仕掛けがたくさん盛り込まれています。
その反面、VDP1 や VDP2 に直接命令を出すことはそれほど想定されていません。
サブ CPU も、ライブラリが勝手に活用してしまっているので、プログラマーが自由に使うことはできません。
格闘ゲームができれば良い、という作り方のライブラリだったので、３Ｄ演算の精度が低く、フライトシミュレーターなどを作ろうとすると精度が足りなかった、という証言も聞いたことがあります。
性格の違い
ＳＢＬはハードを直接制御できるため、性能がプログラマーの腕次第。
全然能力を引き出せないかもしれませんし、限界ギリギリまでも引き出せます。
ＳＧＬは、プログラマの腕前に関係なく、そこそこの性能が引き出せます。
一方で「限界ギリギリまで」は望めません。
どうも、性格の違うライブラリなので、ＳＧＬが出来たから皆がそちらに移行した、というわけでは無さそう。ここが僕の認識が間違っていた点です。
僕は、ＳＧＬ普及後は皆がそちらを使って、「サブCPUはちゃんと使われていた」と思っていました。
別々に作られたライブラリなので、作成中のゲームを移行する、ということは容易ではなかったはずです。
ＳＧＬが発表されても、恐らくは、「次回作」のタイミングから移行するのが順当だったでしょう。
とはいえ、いくつかの理由で移行がためらわれたことも容易に想像できます。
1) ＳＢＬに慣れたのに、ＳＧＬの学習コストを掛けたくない
2) ＳＢＬ上でライブラリを構築したので、次回作でもそのライブラリを使いたい
3) ハードを直接制御したいので、ハードを隠しすぎるＳＧＬは使いたくない
などなど。
そして、これらの理由とはまた別に、プログラマーの腕前があります。
ハードを十分に使いこなせるプログラマーがＳＢＬを使い続けるのは問題なし。
十分使いこなせない人が、ＳＧＬに移行して性能を引き出せるようになってもよいでしょう。
問題は、ハードを使いこなせない程度の腕前で、ＳＢＬにとどまった場合ですね。
腕前が低いからこそ、1 の理由、「新たなライブラリを学習したくない」と考えたプログラマーもいたのではないかと思います。
…腕前が低いのに、腕前がそのまま表れてしまうライブラリを使ってしまう。
何が起こるとは言いませんが、ここには、悲劇が待っているわけです。