たまりば

  パソコン・インターネット パソコン・インターネット  三鷹市 三鷹市

ゲームボーイの背景面とウィンドウ
2017年12月16日 00:19

この記事はGame Boy Advent Calendar 2017の16日目です。
15日目はtakeshi0406さんの「lsdj関連で何か」が現在のところ未投稿のようです。
17日目は現在のところ執筆者未定のようです。

一般的な2次元ゲーム機の画面は背景面とスプライトからできている。
ファミコンでは背景面が1枚だけだったのに対し後年のゲーム機は複数枚の背景面を持つのが当たり前になり、多重スクロールなどの技法で差を見せつけたものだ。

さてゲームボーイだが、これが背景面は1枚だけなのだが、特徴的な「ウィンドウ」という機能を持っていて、背景面1枚ではできないような表現が少しだけ実現できる。いわば背景面1.5枚とでもいえる面白い仕組みだ。

背景面が2枚あると、2枚の絵を用意してそれらを重ねて動かすことができる。上の絵の透過しているところでは下の絵が見える。
対してゲームボーイは、扱える背景面は1枚だけなのだが、その背景面の右下の一部を「ウィンドウ」の内容で置き換えたものを表示できる。

図で示すと分かりやすいだろうか。
例えばこのような2枚の絵があったとして、
いらすとやの草原 いらすとやの城
背景面が2枚あるとこういうことができる。
2枚の背景面での合成
一方、ウィンドウではこういうことしかできない。
ウィンドウでの合成

これを何に使うかというと、最も一般的な使い方は画面下部にステータス表示を出すことだ。
ウィンドウ側に書いたステータス表示を固定したまま、画面の残りの部分を自由にスクロールすることができる。
ファミコンで同様のことをするにはラスタースクロールが必要だが、ゲームボーイではウィンドウのおかげで画面下部に出すなら同じことを楽にできる。(ウィンドウの制限として、上部にはできない)
例はいくらでも見つかると思うが、とりあえず「ゼルダの伝説夢をみる島」を挙げておこう。ポーズをかけるとウィンドウ部がそのまませり上がってくる独特の挙動を示す。
ゼルダの伝説夢をみる島のウィンドウ
この作品、恐らく1画面の*ゼルダシリーズで唯一ステータス表示が画面下部にある。ゲームボーイでは画面上部にステータスを出すことが困難だったことの証左だ。
なお同じゲームボーイ(カラーだが)でも「ふしぎの木の実」では恐らくラスタースクロール的に頑張って画面上部に出している。
* 2画面のゼルダでは2画面の中央あたり(下画面上部・上画面下部)だったりする

ステータス以外にも、背景面に描いた大きな物体の下部を隠したい時に使える。
例えばこちらは「パロディウスだ!」の猫戦艦。水面から出現するところにウィンドウが使われている。
パロディウスだ!のウィンドウ
ここで背景面が2枚あれば波の間を透過できたところだが、ウィンドウではできない。

さて下に何か出すだけならラスタースクロールでもできる。
ウィンドウでは、画面の右側にも何か出すことが可能だ。(左にはできない)
「F1スピリット」がそのような表示を使っている。

左右に分割するのはラスタースクロールでは不可能だ。
ファミコンで同様の表示をしたゲームには「ロードファイター」があるが、
これはどうやらキャラクタパターンを1ドットづつずらした8種類作ってフレームごとに書き換える荒業を使っているようだ。そのため複雑な内容は表示できない。
これはスプライトで書かれているので、(ゲーム画面本体も含めて)複雑な内容は表示できない。


変わった使い方としては「ポケットモンスター金・銀」の英語版。
ポケモンSilverのウィンドウ
一見何も変わったところは無いように見えるが8×8のグリッドを描いてみると…
ポケモンSilverのウィンドウ_グリッド付き
画面の左側だけ文字の配置が3pxずれている。背景が1枚なら普通には8ドットのマス目に沿ってしか文字は表示できないはずだ。
これは右半分だけウィンドウに描画した上でずらして重ねているのだ。
さり気ない、しかし重要な使われ方だ。

最後に「P・マン(原題 Prehistorik Man)」を紹介しよう。

このゲームは凄まじいゲームで、飛び跳ねるアイテムを背景面を書き換えて表示したり、パースの付いた文字が流れたり、ライン中に画面を書き換えて文字を表示したりと様々な技術が詰め込まれている。
そんな中でウィンドウが使われているのがオープニングのこの画面。
P・マンのウィンドウ
主人公と木がスプライト、引かれている枠がウィンドウだ。
下が切れているがこれはラスタースクロール的に消しているのだろう。
ウィンドウの制限として枠が決して画面右端から離れられないのだが、その制限を感じさせないところが上手い。

以上、ウィンドウが特徴的なゲームを挙げたが、この機能はもうちょっと面白い使い方ができそうな気がしてならない。
巨大な敵を真っ二つにするとか、ラスタースクロールと併用して右上に行く階段とか、右半分を自由な形に隠すとか(左はスプライトでどうにかする)。
暇があったら何か作ってみたい。

2017/12/16訂正: 「ロードファイター」について、1ドットずらしだと記憶していたのだが、実際には単なるスプライトだと指摘をいただいた。1ドットずらしの技法はどこかで読んだ気がして、確かこのゲームだと思っていたのだが、記憶は当てにならないものである。  

  • Firefox57でタブ幅を縮めるuserChrome
    2017年12月04日 02:01

    自分はブラウザでタブを大量に開いている(先日1000を超えていた)。そのためタブ幅はファビコンが見える限界まで縮めたい。
    昔はabout:configでタブの最小幅を設定できたのだがいつからかできなくなり、何らかのアドオンで縮めたり、南っぽい名前の頃にはタブの形が丸みを帯びて無駄なスペースができて気に食わなかったのでClassicThemeRestorerを使ってタブを四角くした。
    Firefox56での表示はこんな感じだ。
    ClassicThemeRestorerでタブ幅を縮めたFirefox56
    しかしそのClassicThemeRestorerがQuamtum(57)になって使えなくなった。
    これはもうFirefoxを捨ててChromeに乗り換えるときかと真剣に悩み、せめてuserChrome.cssで多少なりとも使いやすくできないか…と色々いじっていたところ、なんかむしろ以前より使いやすいものができてしまった。
    それがこれだ。とても美しい(※感じ方には個人差があります)。
    userChromeでタブ幅を縮めたFirefox57
    以前との違いとしては、
    ・以前はタブの表示が破綻しない最小幅は36pxほどだったのが、もっと狭めても大丈夫に。
    ・以前はスピーカーマークが出るとタブ幅が広がって隣と重なってしまっていたのが、広がらなくなった。
    ・以前は幅を狭めるとタイトルは表示できなかったのだが、表示できるようになった。
    特にタイトルが重要だ。色々と限界まで切り詰めた結果、タブ幅30pxで全角1.5文字ほど表示できている。このわずかな文字数でもタブの内容を判断するのに大いに役立つ。

    ピン留めしたタブの表示が崩れるなど、もうちょっといじりたいところも無いではないが、とりあえず十分使い物になるものができたと思うので、公開する。
    誰かの役に立てば幸いだ。
    /* ピン留めされたタブの幅はいじりたくないところだが、パディングをいじった影響でそのままだとアイコン幅-4pxになる */
    .tabbrowser-tab /*:not([pinned]) */ {
    /*        max-width: 250px !important; なぜかmax幅を指定すると3タブまでfoxygestures以外で閉じた時空白になる症状が出たのでやめた */
            min-width: 30px !important; /* 本題 */
    }

    /* タブを閉じるボタンを消す。場所もないし元々要らなかったので。昔はabout:configで消せたのだが今はuserChrome必須。 */
    .tab-close-button{
            display: none;
    }

    .tab-content{
            /* タブ左端とファビコンの隙間をゼロに */
            padding-left: 0px !important;
            margin-left: 0px !important;
            /* タブ右端まで文字が表示されるように */
            padding-right: 0px !important;
    }

    /* ファビコンの右端に少し文字が掛かるくらいにしてスペースを節約 */
    .tab-icon-image, .tab-throbber{
            margin-right: -4px !important;
    }

    /* タブの右端で文字が薄くなるのをキャンセル */
    .tab-label-container{
            mask-image: none !important;
    }

    .tab-text{
            /* 文字の頭のスペースを無くす */
            margin-left: 0px !important;
            /* 文字間も詰めて少しでもスペースを節約 */
            letter-spacing: -1px !important;
            /* Windows10ではデフォルトで游ゴシックになるのが嫌いなのでメイリオに */
            font-family: 'メイリオ' !important;
            /* ファビコンに文字が掛かるとそのままだと見にくいので背景色で縁取りする。
               色は標準テーマの「Light」のものに合わせた。現在のタブとhoverしたタブは色が違うがあんまり気にならなかったのでそのまま。 */
            text-shadow: 1px 1px 0px rgba(227,228,230,0.5), -1px 1px 0px rgba(227,228,230,0.5), 1px -1px 0px rgba(227,228,230,0.5), -1px -1px 0px rgba(227,228,230,0.5) !important;
    }
      

  • 【訂正・加筆】
    2017年11月21日 00:00

    2017/04/23, 2017/05/22, 2017/07/24, 2017/11/21ゼルダの伝説ブレスオブザワイルドプレイ日記(ネタバレ有) 更新。
    2016/12/06 漢点字一覧表で、別の元データとの間で不一致があったので追記。
    2016/09/10 ネット契約を1Mbpsにしてみたの読み込み時間の記述が間違っていたので訂正。
    2016/09/04 ファミコンの縦解像度224px説の考察 左8pxを隠す機能の用途が思っていたのと違ったので追記。
    2016/06/06 Windows7でのペイントの劣化具合に新しく気づいたバグ情報を追加。
    2015/08/29 ベースラインPICの注意点で、型番の間違いを訂正、OPTION2の書き込み方法の間違いを訂正。
    2015/08/28 Windows7でのペイントの劣化具合に新しく気づいたバグ情報を追加。
    2013/09/26 5×5 ひらがなフォント5×5フォント改 / JavaScriptフォント表示機から5×5ドットフォント完成版に、思えばリンクを貼っていなかったのでリンク。
    2013/05/05 最弱のPICマイコンで電子オルガン_前編の単純ミスを1ヶ所修正。
    2013/04/27 文字コード表示機が特定の環境で動かない問題を修正、RTL文字での表示崩れを修正。
    2013/03/03 5×5ドットフォント完成版が紹介されていたので少々加筆しました。
    2012/11/18 ハロウィー?ンの正規表現に訂正・加筆があります。

    【このエントリについて】
    (2012/11/18)
    今まで、記事の内容にミスを見つけた場合はその記事だけ修正していたのですが、最新の記事はともかく古い記事にミスを見つけた場合は直しても気づかれないだろうと思って直すのが億劫になっていました。
    これではいけないと、どうするべきか考えた結果、訂正を知らせるエントリを1つ作ることにしました。
    記事を訂正した際にはこのエントリを更新して最上位に持ってくるように運用しようと思います。
    (2013/03/03)
    訂正だけに限らなかったので、エントリ名を【訂正】から【訂正・加筆】に変更しました。  
    タグ :お知らせ

  • 【お知らせ】ページタイトル変えました
    2017年08月15日 02:01

    今までページのタイトル(HTMLのtitle要素の中身; ブラウザでタブとかに表示されるやつ)は、
    WentWayUp: WebLog | 記事タイトル
    のようになっていました。これはこのブログサービスのデフォルトの表記だったと思います。
    それを今回、
    記事タイトル-WentWayUp
    のように変えました。
    長いタイトルの記事がGoogleの検索結果で後半が略されて肝心なところが切れてるのを見たので。
    Googleで肝心なところが切れた
    あと「WentWayUp: WebLog」の部分もちょっと長いなって思ったので。
    「 | 」から「-」にしたのは文字数減らしたかったので。

    2017/09/12追記
    それから毎日のように見張っていたのだがなかなか反映されずもしかしてずっとそのままなのかと思っていたが今日見たらやっと反映されていた。
    Googleで肝心なところが切れなくなった
    よし。  

  • ドラクエのカタカナが少ないのはROMの容量が少ないせいではない
    2017年07月31日 09:02

    ファミコンのドラゴンクエストシリーズにおいてカタカナが一部しか使えなかったことは有名だ。
    この理由としてROMの容量が少ないためと言われることが多い。
    試しにGoogleで「ドラゴンクエスト カタカナ」と検索し、上位50ページの中から初代ドラゴンクエスト(以下ドラクエ1)のカタカナが少ない理由を述べていると考えられる文章を(重複を除き)抜粋してみる。
    ・「当時はゲームソフトのメモリ(記憶容量)が少なかったため」「ROMの容量を増やしたこともあり、使用可能なカタカナは徐々に増加していった。」
    ・「64キロバイトしかありませんでした。」
    ・「容量の問題で」
    ・「容量の関係で」
    ・「わずか64KB!」「データ量削減」
    ・「使える容量はわずか64KB」
    ・「64kB」「容量を節約するため」
    ・「64KB」「データ量の削減のため」
    ・「512KB」「容量の節約のため」
    ・「ゲームソフトのメモリ(記憶容量)が少なかったため」
    ・「ソフトの容量が64キロバイト」
    ・「64KB」「容量がかなり少なかったため、データを削減するため…その一環」
    ・「約64キロバイト」「だから」
    ※「文字も1バイト使ってないんですよ。7ビットです。 だからカタカナなんか20文字しか使えない。」
    ・「容量の都合」
    ・「ファミコンカセットの容量は64KB」「だから、カタカナの文字データを全部入れることすらできなくて」
    ・「64KB」(ポートピアのカナ制限に対して「当時のROM容量では厳しく」)「初代ドラクエで使うことができたカタカナも、『ポートピア』と同じ20文字」
    ・「容量の関係で」
    ・「ゲームタイトルごとにフォントデータを持っていました。当然それは容量を食うものなので、いかにその文字数を減らすか」
    ・「64KB」「容量の問題で」

    1件(※)を除き、総合すると「ROM容量が64kBと少なかったため、カタカナを入れる余裕が無かった」とまとめられるだろう。(1件については後述する)
    このような説明に納得していた人は、ちょっと考えていただきたい。
    ドラクエの文字は8×8ドットなので、容量は1文字64bit=8バイト。
    50文字入れて8*50=400バイト。64kBの1%にも満たない。文章に大きな制限を加えてまで削減するような量だろうか。

    また、ドラクエ2ではROM容量が倍増し128kBになっている。本当にROM容量が問題であるならば解決しているはず。
    しかるに2でも多少文字数は増えたものの依然としてカタカナ全ては使えない。さらには3は256kB、4は512kBと倍増を繰り返しているのにやはり同様だ。



    では何が原因か。問題は背景面のタイル種制限だ。

    といって分かる人はそもそも誤解しないと思うので、詳しく説明しよう。
    ファミコンやスーパーファミコンなど多くの2次元ゲーム機の画面表示は内部的に、背景(Background; BG)面と、スプライトと呼ばれる小さい絵を重ね合わせてできている。
    ふつう、画面上を動くキャラクターはスプライトで表示し、背景画像や文章は背景面に表示する。
    スプライトも背景も、8×8ドットのタイルまたはキャラクタと呼ばれる小片を並べて作られる。
    そしてファミコンの場合、ふつうのプログラムでは背景面とスプライトに使えるタイルはそれぞれ別に256種づつとなっている。
    この256個のタイルはカートリッジによっては、マッパーと呼ばれる回路を積むことで大量のROMを何分割かして切り換えたり、RAMを積むことで1つづつ自由に書き換えたりできるものもあるが、一度に256個しか使えないのは基本的には変わらない。
    (なおドラクエ1に使われている「マッパー3」はというと、(背景+スプライトの)256×2個をいっぺんに切り替えることしかできない。)
    よって、背景面に同時に表示される「フィールドの画像」「戦闘時の背景画」「文章のフォント」は、すべて合わせて256種のタイルで賄わなければならないのだ。
    つまり文字を50文字用意するというのは、ROM64kB中の1%弱を使うだけでなく、タイルデータ256個中の50個、約20%という量を占領することになる。これは無視できる量ではない。

    ドラクエ1のタイルデータは次のようになっている。
    ドラクエ1_タイル(元画像はこちらのサイトから拝借した。 http://www.geocities.co.jp/Playtown-Bingo/2392/3syou.html )
    上から109個が文字および罫線、下147個がフィールド画像用である。
    ここから文字を増やせば増やすほど、地形のバリエーションが減っていくわけだ。

    ここで参考に、ひらがな・カタカナが全種類使われている場合の例として初代ポケモンのフィールドでのタイルデータを示そう。ゲームボーイもファミコンと同じく背景に一度に使えるタイルは256種類である。
    ポケモン緑_タイル
    文字だけで5/8が埋まっており、フィールドの表示に使えるタイルはわずか96個である。ドラクエ1の2/3程度しかない。
    これでフィールドを作るのは大変そうだと感じてもらえるかと思う。



    さて、後述すると言った1件。
    文字も1バイト使ってないんですよ。7ビットです。
    だからカタカナなんか20文字しか使えない。
    実は堀井雄二氏の発言である。( http://dq10maru.com/archives/7369365.html より)
    制作陣の中心人物であり、注目すべき発言ではあるが、堀井氏はプログラマーではないことに注意が必要だ。この発言は何を言いたいのかよく分からない。何が7bitなのか。

    1つの解釈としては、文字コードが1文字7bitだったと取れるが、どうもそのようなことはない。

    こちらにドラクエ2と3の文字コードについての情報があった。
    http://www.geocities.co.jp/SiliconValley-Cupertino/7098/
    該当する部分を引用する。
    ・2
    00:1文字
    8D:単語
    EC:数値
    ED:紋章
    EE:濁点
    EF:半濁点
    F0:数値
    F1:数値
    F2:仲間名
    F3:数値
    F4:数値
    F5:呪文名
    F6:名
    F7:繰り返し
    F8:呪文名
    F9:道具名
    FA:区切り
    FB:未使用
    FC:メッセージ終わり
    FD:名
    FE:改行
    FF:区切り
    ・3
    1文字につき6bit使用しています。
    つまり3byteで4文字分を表します。
    仕様:
    00~3B-ひらがなorカタカナ
    3C-ひらがな・カタカナ切替
    3D-圧縮単語+$00 圧縮単語は次の6bitと合わせて全部で192種類
    3E-圧縮単語+$40
    3F-圧縮単語+$80

    説明がなく少々分かりづらいが、おそらく次のような解釈でよいだろう。
    2: 1文字1バイト、00~8Cが通常の文字、残りが制御文字
    3: 1文字6bit、00~3Bが通常の文字、残りが制御文字

    肝心のドラクエ1の情報が無いが、2で1バイトだったのに1でそれより複雑なコードというのは考えづらい。あえて書くほどの事でもないので書いていないだけで、1も7bitではなく1文字1バイトであろう。

    またもう一つ、ドラクエ2と3では文字コードが一変しているのに、使えるカタカナ数は2が33文字、3と4が38文字でほぼ変わらない(2の紋章5つを加えれば全く同一)。これは「文字コードが7bit」を原因とするのでは説明がつかない。

    では堀井氏の発言は何を言っているかだが、これは「フィールド用のタイルを確保すると文字種は7bit分くらいしか取れない」ということではなかろうか。文字コードは1文字1バイトだが、そのうち7bit分128文字しか使われていない、と。
    先述の通り文字と罫線で109文字。これに濁音・半濁音を加えると128文字を超えるが、文章中に使われることのない罫線や英字・記号を抜いたり、濁音・半濁音でも使われていないものがあれば抜けばちょうど128文字程度になりそうだ。
    ただこれを指して7bitと言ったのだとした場合、問題なのは7bitになった原因の方であり、それは先述した通り背景面のタイル種制限だ。