TOP > プログラミング関係解説＆調査 > 背景グラフィックと効果

背景グラフィックと効果

スーパーファミコンにおけるグラフィックは、背景（BG）とキャラのドット絵（スプライト）に分かれる。
基本事項についてはグラフィックについてで、スプライトについてはスプライトについてでざっと説明したので、先にお読みいただきたい。
ここでは背景（BGと略す）について大まかに説明する。
また、背景や画面に関係する効果（モザイク処理や色の加算、ウィンドウの一部をマスクする処理など）も合わせて紹介する。

サブルーチンは次ページから紹介していく。

• フィールドでのサブルーチン
• 戦闘でのサブルーチン
• メニュー画面でのサブルーチン

背景について

背景もスプライトと共通の仕組みの部分が多い。
背景データをグラフィックデータ用メモリのVRAMに送り、そこから必要な部分をゲーム画面に表示、という意味ではスプライトと大まかな仕組みに変わりはない。
色情報をCGRAMに送るのも同一。

ただし、スプライトの配置や座標をオブジェクト属性データとしてOAMに転送していたことに対し、背景はBGマップというデータでVRAMに送る、という相違点がある。
それら含め、背景の設定を紹介する。
snes-docs-ja/video/bg/control.mdなども参照していただきたい。

背景の設定はI/Oレジスタを通して値を設定する。

BG制御レジスタ

レジスタのアドレスは$00:2105

• 背景の枚数と色数（BGモード）
• 背景のタイルサイズ

を決める。
BGモードはMode0～Mode7の8種類設定できるが、「ライブ・ア・ライブ」では、通常のゲーム画面だと、BGモードにMode1を指定する。
Mode1は、BG1～BG3の3枚の背景を使用でき、色数は以下のように設定可能。

• BG1：16
• BG2：16
• BG3：4

さらにMode1では、BG3優先度という設定ができる。
通常、背景4枚は、手前からBG1→BG2→BG3という順序におかれる。
さらに、タイルごとに置く順序の変更も可能。
BG1のBG優先度はどのタイルも0、BG2でBG1の上に置きたいタイルだけBG優先度が1にすることで、BG1が一番下、その上にBG2が置かれる。

BG3優先度は通常0だが、1に設定すると、BG3を一番手前に表示できる。
これを利用して、色数が一番少なくて済む、セリフ（テキスト）ウィンドウをBG3に設定し、一番手前に置いている。

結果、本作では、

フィールド

• BG2にキャラ（スプライト）に被せたいタイルがない箇所は手前からBG3→BG1→BG2
• BG2にキャラ（スプライト）に被せたいタイルがある箇所は手前からBG3→BG2→BG1

戦闘

• BG2が敵キャラ、BG1が背景なので、敵キャラを設置したタイルは手前からBG3→BG2→BG1
• それ以外は手前からBG3→スプライト→BG1→BG2

メニュー画面

• BG2が背景、BG1がコマンドウィンドウやセリフウィンドウなどのため、常に手前からBG3→BG1→BG2

というように、BG3は一番手前（上）で固定、BG1とBG2は場面・タイル位置に合わせて重ね順を変え、背景3枚を表示している。

背景のタイルサイズは各BGごとに設定でき、8×8または16×16を指定する。
「ライブ・ア・ライブ」では、通常のゲーム画面だと、どのBGにも8×8ピクセルを指定する。
つまり、スプライトの基本タイルサイズ8×8ピクセルと同じである。

BG制御レジスタは$00:2105で、ライブ・ア・ライブではだいたいの場合で$09(%0000 1001)を書き込む。
下3ビットがBGモード（%001, Mode1）、その上がBG3優先度（%1, BG3優先）、上4ビットはBG1～4のタイルサイズでどれも%0（8×8）。

例外として、ゲームを開始し、「スクウェアソフト」のボイスと共にロゴが表示される場面や、ＳＦ編キャプテンスクウェア開始時は、$00:2105に$0F(%0000 1111)が入る。
これはBGモードがMode7であることを表している。
スーパーファミコンの特徴のひとつにもあげられる、背景の回転・拡大・縮小モードである。
Mode7のVRAMの構成はMode7以外とはまったく異なる。
背景拡大・縮小・回転（BGMode7）を参照していただきたい。
この後は基本的にMode1での話になる。

なお、戦闘突入時に三角形の黒い画面がぐるっと回る効果はMode7ではない。
ウィンドウ（Window）効果の方である。
後で説明する。

BGマップ設定

レジスタのアドレスは$00:2107～$00:210A

BG1～BG4それぞれの背景全体のサイズ及び、VRAM内のデータ開始アドレスのデータが入る。

背景サイズ

背景全体は、タイル1個分を単位として、横×縦が、
32×32, 64×32, 32×64, 64×64
の、いずれかで設定する。
$00:21??の下2ビットが対応しており、

となる。
レイアウトはVRAM上での構造のこと。
背景は32×32タイルで$800バイト分、背景サイズが64×64だったら32×32タイルが4つ分必要となるが、タイルマップアドレスの最初の$800バイトにAの位置のデータ、+$800バイトにBの位置のデータ、……というようにデータが並ぶ仕組み。
もちろん、背景サイズ32×32であれば、最初の$800バイト分しか必要ない。
64×32のように横長サイズなら、最初の$800バイトに左側の32×32タイルデータ、次の$800バイトに右側の32×32タイルデータ、ということになる。

「ライブ・ア・ライブ」はタイル1個を8×8ピクセルで指定するため、ピクセル単位で考えると、
256×256ピクセル, 512×256ピクセル, 256×512ピクセル, 512×512ピクセル
の、どれかになるということである。

実際のスーパーファミコンのゲーム画面は、横256ピクセル×縦224ピクセルだから、どのサイズで設定しても画面からはみ出すことになる。
だが、実際のゲームでは背景をスクロールして広いマップを表現するから、はみ出すことは問題ではない。
逆に、狭い部屋などでも上サイズのどれかで指定しなければならないのだが、その場合は部屋の周りを黒色で埋めるなどしている。
広いマップの場合でも、スクロールを調整して、ほとんどの場合で512×256ピクセルで収めている（常に新たにマップをVRAMに送って更新している）。

いくつか例外もあり、例えば多重スクロールを使って遠近感を出すマップ、功夫編の大志山山頂や、中世編の勇者の山山頂・ルクレチア城テラス・魔王山山頂では、BG2に512×512ピクセルを指定して、一番下（遠景）に置き、BG1にキャラが移動できる手前側のマップを設置する。
BG2のスクロール量を、BG1の半分にすることで、遠くの景色だけスクロールを少なくして遠近感を演出している。

戦闘やメニュー画面は背景をスクロールする必要がないので、一番小さい256×256ピクセルで収めている。
が、メニュー画面については、各シナリオで変わる全体背景に大きめの512×256を使うなど、BG番号によって変動する場合もある。

VRAM内のデータ開始アドレス

$00:21??の上6ビットがVRAM内のデータ開始アドレスの値なのだが、実際にはその値に*$0800をした値がアドレス位置（単位をバイトで考えた場合）。
例えば、BG1のBGマップ設定が入る$00:2107に$41(%0100 0001)を書き込んだとしたら、

• 下2ビットは%01、背景サイズは64×32
• 上6ビットは%010000 = $10、$10 * $0800 = $8000だから、VRAMでのBG1のデータ開始アドレスは$8000

と、いうことになる。

タイルデータ

タイル1個は8×8ピクセルのデータでできているが、これらタイルのデータはVRAMに送られ、後で述べるBGマップに従い並べられ、カラーパレットから色を決めることになる。
VRAMのどのアドレスからタイルデータを書き込むか？　は、$00:210Aと$00:210B（BGタイルデータアドレス）に書き込む値で決まる。
$00:210Bの下4ビットがBG1の開始アドレス、上4ビットがBG2の開始アドレス。
$00:210Cの下4ビットがBG3の開始アドレス、上4ビットがBG4の開始アドレスである。
ただし、書き込まれた値 * $2000が実際のVRAMアドレス（単位バイト）なので注意。

例えば、フィールドならだいたい、$00:210Bは$00、$00:210Cは$03である。

• BG1のタイルデータVRAM開始アドレス：$0000
• BG2のタイルデータVRAM開始アドレス：$0000
• BG3のタイルデータVRAM開始アドレス：$6000

と、いうことになる。

タイル1個のデータは2バイトで構成されている。
上で述べたが、ライブ・ア・ライブはほとんどの場合でBGモードがMode1であり、それぞれのBGの色数が、

• BG1：16
• BG2：16
• BG3：4

と、なっている。
BG1とBG2は16色なので、スプライトの構造と同じと考えて良い。
つまり、色のデータが1ピクセルあたり4ビットになるから、各ビットに分けてデータを記す、例のわかりにくい方法である。
8×8ピクセルのデータに32バイト使う方式となる。
色データに4ビット使うことから、ビット深度(Bit depth)が4bpp(bits per pixel)である、という言い方をする。
色深度 - Wikipediaも参照していただきたい。

一方、BG3は4色であり、色のデータが1ピクセルあたり2ビットなので、2ビットに分けてデータを記すことになる。
ビット深度が2bppということになる。
データ量が半分で済むので、8×8ピクセルのデータに16バイト使う方式となる。

つまり、フィールドだったら、VRAMアドレス$0000～に入るBG1またはBG2のタイルデータ（共用ということになる）は、8×8ピクセルのデータに32バイト使っている。スプライトと同じような感じでデータが入ると考えて良い。
VRAMアドレス$6000～に入るBG3のデータは、8×8ピクセルのデータに16バイト使っている。

BGマップ

背景は32×32タイル（256×256ピクセル）が基本となると先に記した通りだが、そのタイルデータをどのように画面に配置するかのデータがBGマップである。
スプライトで言うところのOAM（オブジェクト属性）にあたる。
スプライトなら最大128個のスプライトを座標で指定して好きな位置に並べることができたが、背景の場合は、タイル1個（8×8ピクセル）ずつを順番に並べていくことになる。
さらに、「ライブ・ア・ライブ」だったらBG1～3の3枚分の背景を作らなければならない。
（BG3はセリフウィンドウやテキストなので、セリフなどが表示されていない時は、BG1とBG2のみになる）

タイル1個（8×8ピクセル）につき、2バイトのデータで構成されている。
下の値から順にBit0～とすると

例えば、BG1で、BGマップデータが
$1424 (%0001 0100 0010 0100)
とする。

• タイル番号：%00 0010 0100 = $024 ($024 * $20 = アドレス$0480)
• カラーパレット番号：%101 = $5
• BG優先度：0
• X反転：0
• Y反転：0

BG1のBG優先度はどのタイルも0、BG2でBG1の上に置きたいタイルだけBG優先度が1にすることで、BG1が一番下、その上にBG2が置かれる。

VRAMのアドレス$0480から$20バイト分のデータが該当タイルの8×8ピクセルデータであり、カラーパレットNo.5の色を使用する、ということがわかる。
ちなみにこのデータは近未来編・ちびっこハウスのトイレのあるタイルのデータである。
VRAMの$0480～のデータは、

CGRAMのカラーパレットNo.5のデータは、

これらデータの変換方法は、スプライトと同じなので、筆者がやっつけで作ったデータから画像変換のJavaScriptでそのままデータ変換ができる。
実際にデータに色を塗った結果が下。

はっきり言ってこれだけではわかりにくいと思う。
この右のタイルと、下側のタイルも処理してみよう。
ちなみにカラーパレットはいずれもNo.5である。

……結局わからないかもしれないが、これは左側にトイレットペーパーホルダー、下にトイレの便器前のマットが敷いてある、16×16ピクセルのマスなのである（便器の真下あたり）。
こんな感じで背景を作っているのである。

なお、この狭いトイレのマップも、マップサイズは横512×縦256ピクセルである。
トイレ以外の部分は黒一色で塗りつぶされている。
（このマップでいえば、BGマップデータの大半は$2810で埋まっているが、これが8×8ピクセル黒一色のデータになる）
本作におけるフィールドのマップは、どれほどの広さであっても、基本的に横512×縦256ピクセルで作っているようだ。

BG3のタイルデータ

16色が使えるBG1とBG2はスプライトと同じ考え方で問題ない、ということがわかった。
では4色のみのBG3について少し詳しく見てみよう。

スプライトのデータの基本で説明したが、画像データはビット毎に分けてデータを記す「ビットプレーン」方式でデータを記録している。
16色の時は4ビットで1ピクセルのデータを記録できたから（ビット深度が4bpp）、4ビット毎に分けていた。
BG3は4色（ビット深度が2bpp）、2ビットで1ピクセルのデータを記録できるから（%00～%11、つまり$0～$3）、2ビット毎に分ければ良い。

16色4ビットは、

と、データを並べていたが、4色2ビットなら、

これだけで済むことになる。
つまり、タイル1個のデータは16バイト（$10バイト）である。
後々でアドレス計算の時に注意すべき点のひとつである。

なお、後々でわかるが、セリフウィンドウでウィンドウ背景と文字部分の2色しか使っていない時、「%01」（ウィンドウ背景）と「%11」（文字色）しか使っていない。
例として、8×8ピクセルの横1列分4バイトが、

と、「%01」（$1）及び「%11」（$3）だけで作られているとしよう。
2進数表記にすると、

上の桁bit1と、下の桁bit0に分ける。

• bit1：%0101 0000($50)
• bit0：%1111 1111($FF)

よって、ビットプレーン方式だと、「$FF50」になることがわかった。
また、2色に「%01」と「%11」しか使っていない場合、必ず「$FF??」という表記になることもわかる。

4色のタイルデータがどのように記述されているかわかったところで、実際のBG3のデータの見方を説明していく。

ここではフィールドについて取り上げる。
まず、BG3のBGマップ設定が入る$00:2109だが、ほとんどの場合で$48(%0100 1000)が書き込まれるようである。
下2ビットが%00だから、BG3の背景サイズはタイル単位で32×32。
上6ビットは%010010 = $12、これに$800を掛け算した$12*$0800 = $9000が、VRAMでのBG3のBGマップデータ開始アドレスである。

一方、BG3のタイルデータVRAM開始アドレスが記される$00:210Cは$03である。
$3*$2000で、BG3のタイルデータVRAM開始アドレスは$6000となる。

セリフなどが表示されていない場合、BG3はすべて透過されていることになるが、セリフウィンドウなどが表示されている時は該当位置に何らかのデータが入る。
今回はわかりやすく、セリフウィンドウが画面上部に表示されている時の文字部分だけ拾ってみる。
アドレスでいうと$9088から。
1つのタイルで2バイトのデータであるから2バイト区切りで並べてみると、

と、明らかに1ずつ増加している。

BGマップのデータの見方はBGが何番であっても同じである。

$2100 = %0010 0001 0000 0000
$2101 = %0010 0001 0000 0001
$2102 = %0010 0001 0000 0010
$2103 = %0010 0001 0000 0011
$2104 = %0010 0001 0000 0100
...
$210b = %0010 0001 0000 1011

パレット番号は%000、BG優先度は%1（手前表示）、X反転とY反転はなしで統一されている。

一方値が変わるのは、下10ビット分（上の太字部分）、タイル番号である。
%01 0000 0000 = $0100から順にタイルを獲得していくことがわかる。
これはタイルのナンバリング（$0100番目のタイル）という意味なので、実際には、

が、タイル開始位置アドレスである。
BG3のタイル1個分のデータ量は先に記した通り$10バイトである点に注意。
よって、計算結果は、

$0100 * $10 + $6000 = $7000

これが、VRAMにおける、セリフウィンドウ内の文字位置開始アドレスである。
ここからタイル1つにつき$10バイトずつ文字データが入っているはずだ。
ただしセリフウィンドウの文字は、16×16ピクセル（8×8のタイル4個）で1文字を作っていることを文字データで説明した。
といっても文字部分は12×12で、余白部分があるのだが、いずれにしても、8×8のタイルを横に並べただけでは、文字の上半分または下半分のデータしか作れない。
とりあえずは、$7000～の文字データを見てみよう。
これは近未来編のとあるセリフウィンドウの文字である。

$7000～

以上がセリフ1行分の「文字上半分のみ」のデータになる。
FFとそれ以外の数値が1バイト置きに並んでいる。
先ほど説明した通り、ウィンドウ背景と文字部分の2色しか使っていない時、カラーパレットに「%01」（ウィンドウ背景）と「%11」（文字色）しか指定しないと、このような文字列ができあがる。
このデータをカラーパレットに対応した値に変換したい場合、先のようにせっせと手で計算するのは手間であるから、スプライト変換の時に使ったJavaScriptのプログラムを少し変更して、ビット深度2bpp用変換プログラムを書いてみた。
ただ、32バイト分を入れて変換するのは変えていない。
出力したデータは半分の16バイトで区切って、右横に並べていくようにしていただきたい。
横に繋げたら、次は$7180～からのデータを下半分としてつなげる。

$7180～

ちなみにこの時のカラーパレットNo.0であるが、

というデータになる。
こちらはカラーパレットデータをRGBカラー16色に変換のJavaScriptを使えば変換できる。
といっても実質2色しか使わないので、必要なカラーパレットはNo.1と3のみとなるが。

さて、完成した画像は以下のようになる。

近未来編でアイテム改造を粘ると何度も見ることになる藤兵衛のセリフである。
文字データは本来縦12ピクセル×横16ピクセルだが、横の4ピクセル分の空白がうまく詰められて、実質12×12ピクセルのデータとして並ぶことがわかる。
セリフウィンドウ背景と文字だけだと2色のみだが、セリフウィンドウそのものは、ウィンドウの縁取り部分がグラデーションになっていて、3色で構成されている。
アキラが心を読む時のウィンドウはカラーパレットを変えているのみで3色構成なのは変わらない。

また、戦闘コマンドについてで、戦闘コマンドの文字列データが妙な配置でコピーされていくことを紹介したが、これも、上のようにVRAMにデータが並ぶ都合からである。
文字フォント画像自体は0か1かの2進数（1ビット）で記録することができるが、それを2ビットのデータにする時に、間に「FF」を挟むから、アドレスを1つ飛ばしにして値を記録したり、文字を上半分と下半分に分けて記録するからアドレスの指定が飛んだりするのである。

フィールド上でのセリフウィンドウは3色で構成されているが、戦闘では4色使っている。
アイテム一覧を開くと、戦闘で使えないアイテムは灰色の文字列、回復アイテムは青色の文字列、攻撃アイテムなら黒色の文字列になる。
技一覧でも、反撃専用技などは灰色の文字列、回復技は青色の文字列、攻撃技は黒色の文字列になる。
これに背景色を加えて4色である。

後で説明するが、BG3は他にも、カラーマスという、背景の色味を変更する処理にも関わってくる。

以上がBG3についての説明である。

効果

背景や画面全体の描画で、本作に使用されている様々な効果の仕組みについてざっと紹介。

背景の回転・拡大・縮小モードにあたる、Mode7については、snes-docs-ja/video/bg/mode7.mdや、その他解説サイトなどを参照していただきたい。

輝度

画面の明るさが輝度で、$00:2100（ディスプレイ制御レジスタ）で制御する。
画面の切り替え（戦闘画面からフィールド画面、またはその逆など）で輝度を段階的に調節することにより、画面切り替えを自然に見せる、といった操作は頻繁に行われている。
戦闘でスタートボタンを押してポーズをかけると少し画面が暗くなるのも、輝度調整で行っている。
画面全体の明るさを変える仕組みなので、一部分だけの輝度を変えることはできない。

$00:2100の下4ビットが輝度の値になり、%0000～%1111の間で変更できる。
0なら真っ暗（黒）で何も表示されず、%0001(1)～%1111(15)の15段階で明るさ調整ができる。数字が大きいほど明るく、通常の明るさは%1111(15)である。

戦闘中にポーズをかけると、$00:2100に$08が書き込まれて、輝度が下がる。
通常の明るさ%1111(15)から、%1000（8）に下がるということである。
この時は段階的切り替えではなく、15から8にいきなり変更なので、スタートボタンを押した途端に暗めの画面に変わる。

メインスクリーンとサブスクリーン

snes-docs-ja/video/layer.md

背景（BG1～4）とスプライト（OBJ）には、メインスクリーンとサブスクリーンがあり、実際のゲーム画面はこの2つのスクリーンを合成して表示する。
どちらのスクリーンも、有効・無効の切り替えが可能（$00:212Cと$00:212Dで設定する）
通常画面はメインスクリーンで、基本的にはここにスプライトやBGを設置する。
サブスクリーンは、後述のカラーマスと、BGMode0で扱える512-pixel Hires Mode（512ピクセル擬似高解像度モード）というモードでのみ使用する。
512-pixel Hires Modeについては筆者にはよくわからないので横に置いておくが（本作に使われてもいないようである）、カラーマスは色々な場面で使われる重要な色処理になる。

カラーマス(Color Math)

翻訳すると「色の演算」となる通り、色の加算または減算処理のこと。
カラーパレットで指定した色に、さらに指定した色を被せて、色を変更する処理になる。
グラフィックソフトで言うところの覆い焼き発光などの処理だと考えれば良い。

本作では、戦闘で敵が攻撃してくる時、一時的に攻撃範囲マスが赤っぽい色合いになる処理など、全体的な色味の調節に使っていることが多い。
戦闘の攻撃範囲マスの場合でいうと、該当部分のBG1に、BG3サブスクリーンで色を$840000（この色）に指定した一色のタイルを加算処理（覆い焼き）で被せる、という処理をしている。
$840000という色自体は見ての通りくすんだ赤色だが、覆い焼き発光で被せると、背景であるBG1に、赤い色調の色味を与えることが可能となる。

他にはメニュー画面で、選択していない項目の背景が半透明になっていて透けているのも、カラーマス効果である。

I/Oレジスタの$00:2130、$00:2131、$00:2132がカラーマスの設定に関わってくる。

カラーマス（色演算）のページで詳細を説明している。

固定色（Backdrop Color）処理

カラーマスと似たような色の加算または減算処理になるが、サブスクリーンに設定したBGの色を加算または減算する場合がカラーマス効果で、固定色の場合、サブスクリーンは使わず固定色（Backdrop Color）というスクリーン層を設定し、色を構成する成分であるRGBのいずれか（または複数）の輝度を変更することで画面全体の色や明るさを変える。
本作では、主にフィールドにおいて、指定したBGやOBJ（スプライト）だけ色や明るさを変更する時に使うことが多いようである。
ＳＦ編で、コンピュータを調べた時に、背景だけ暗くなって緑色の文字列（テキスト）を表示する時や、ＳＦ編終盤で停電しマップ全体が暗くなったとき（セリフウィンドウのみ通常の明るさ、他は明るさを下げる）、原始編エンディングのラストで画面全体がピンク色っぽくなるシーン、最終編の時のダンジョンの明るさ変更などに使っている。

固定色処理のページで詳細を説明している。

ウィンドウ効果

上で少し触れたが、三角形の黒い画面が回転しながら戦闘画面に移行する処理は、背景のMode7による回転効果ではない。
ウィンドウ（Window）効果というものを使っている。

ウィンドウ効果とは、画面の一部を一時的に隠す（マスクする）ことである。
一時的に見せなくしている（黒くしている）だけであり、本作のように、あたかも三角形に画面を切り抜いているかのような演出を見えることができる。
戦闘突入時に主人公を中心として画面が円状に広がるのもウィンドウ効果である（こちらは一瞬なので少しわかりにくいが）。
また、背景だけでなくスプライトに対しても処理できるので、戦闘突入時には画面全体が回転する三角形に切り抜かれたように見える。

実際には、HDMA転送を利用して、横一列1ピクセル幅のライン毎に、マスクして隠す部分、隠さない部分を指定している。
とても簡易的な図にすると下のようなイメージである。

黒い横線がマスク部分である。
（隙間はわかりやすくするために表示しただけで、実際には隙間なく黒のマスクで埋まる）
黄色い線のように、マスクをどこまでするか、さらにどこからマスクするか、を横一列の座標で決めていくことで、三角形を描くのである。
この処理を戦闘突入時におそらく50フレーム（50/60秒）行っている。つまり三角形を50回分座標を変えながら描いている。
60FPSでの処理だから、人間の目だと、とても滑らかに三角形が回転しているように見えるのである。

ウィンドウ効果のページで詳細を説明している。

モザイク効果

スーパーファミコンの特徴のひとつとして、画面にモザイクをかけたような効果も可能である。

本作ではいくつかの場面で演出として使われているが、頻繁に見ることになるのは戦闘におけるテレポート時の演出だろう。
背景のモザイク設定は$00:2106で行い、モザイクがない状態なら$00が入っている。
モザイクは背景にしかかけられないため、テレポート時、スプライトのキャラたちはモザイクなしでそのまま飛んでいるが、敵は背景なのでモザイクをかけている。

$00:2106は、上4ビットにモザイクのピクセルサイズ、下4ビットにBG4・BG3・BG2・BG1それぞれでモザイクを有効にするかどうかの値を入れるようになっている。
上4ビットは%0000～%1111が入るが、それぞれがモザイクサイズ1×1ピクセル～16×16ピクセルに対応している。
つまりモザイクのサイズは、必ず正方形で、最大で16×16ピクセルまでとなる。
ここではモザイクのサイズをN×Nとしておく。

モザイクサイズに従って、N×Nサイズに画面を分割する。
画面分割初期位置（座標）は、画面を描画中でないなら画面左上隅、描画中なら描画しているラインになる。
分割したら、正方形の一番左上のピクセル位置の色で、正方形の中を塗りつぶすことにより、モザイクを作る。
正方形の中の平均的な色を取り出して……というような処理ではない。

テレポート時は20フレーム毎にモザイクのサイズN×Nを+1して、16×16ピクセルまで増やす、という処理をしている。
テレポート後は逆に、初期状態でモザイクサイズを16×16ピクセルに指定してから減らしていって、最終的に$00:2106を$00として正常な状態に戻している。

モザイク処理のページで詳細を説明している。

ラスタースクロール処理

ラスタースクロール - Wikipedia

近未来編の序盤、物質転送装置に乗った時、モザイク処理の後、画面が波打つように左右に揺れる処理があるが、これがラスタースクロール処理である。
他には、ＳＦ編のラストバトル前にOD-10がメッセージを送ってくるシーンでも使われている。
（ドラゴンクエストシリーズの旅の扉の処理、といった方がわかりやすいかもしれない。ファミコンの時代からあるテクニックである）
スーパーファミコンでは1ドット幅で横1列ずつ画面を描画していくのだが、その描画開始位置を少しずつズラすことで、一部分だけ横にずれたような効果を出す。
本作の場合は左右に揺れる処理のため、水平スクロール量を設定するレジスタ$00:210D（BG1水平スクロール量）、$00:210F（BG2水平スクロール量）が使われている。
背景のみを揺らす処理のため、ＳＦ編のラストバトル前での画面を見ると、背景に使っているBG1とBG2は揺れるのだが、画面右上の扉はスプライトなので揺れていない。

ラスタースクロールのページで詳細を説明している。

次ページから、サブルーチンを紹介していく。