ゲームシステム、情報記憶媒体及び圧縮データの生成方法
【課題】 データの使用記憶容量を抑えながらもリアルで高品質な画像を生成できるゲームシステム、情報記憶媒体及び圧縮方法を提供すること。
【解決手段】 元画像の色データの圧縮データＣＰ１をデコード部で伸張して色データを得ると共に、元画像のα値を色データに設定し圧縮することで生成された圧縮データＣＰ２を色データ用のデコード部で伸張し、得られた伸張データＥＸ２をα値に設定する。そして色データとα値とを用いたα合成処理を行いゲーム画像を生成する。伸張データの緑色成分の階調に応じた値にα値を設定する。圧縮時に横、縦方向にサイズを縮小すると共に伸張時にサイズを拡大して元に戻す。圧縮・伸張の対象となる第１のデータとして、ヒットチェック用データ、オブジェクトの移動制御用データ、オブジェクトの画像制御用データ、奥行き値のデータを用いる。
【解決手段】 元画像の色データの圧縮データＣＰ１をデコード部で伸張して色データを得ると共に、元画像のα値を色データに設定し圧縮することで生成された圧縮データＣＰ２を色データ用のデコード部で伸張し、得られた伸張データＥＸ２をα値に設定する。そして色データとα値とを用いたα合成処理を行いゲーム画像を生成する。伸張データの緑色成分の階調に応じた値にα値を設定する。圧縮時に横、縦方向にサイズを縮小すると共に伸張時にサイズを拡大して元に戻す。圧縮・伸張の対象となる第１のデータとして、ヒットチェック用データ、オブジェクトの移動制御用データ、オブジェクトの画像制御用データ、奥行き値のデータを用いる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ゲームシステム、情報記憶媒体及び圧縮データの生成方法に関する。
【背景技術】
【０００２】
従来より、仮想的な３次元空間であるオブジェクト空間内の所与の視点から見える画像を生成するゲームシステムが知られており、いわゆる仮想現実を体験できるものとして人気が高い。ロールプレイングゲーム（ＲＰＧ）を楽しむことができるゲームシステムを例にとれば、プレーヤは、自身の分身であるキャラクタ（オブジェクト）を操作してマップ上で移動させ、敵キャラクタと対戦したり、他のキャラクタと対話したり、様々な町を訪れたりすることでゲームを楽しむ。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１０−０９８７１９号公報
【特許文献２】特開平４−１６７１８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
さて、このようなゲームシステムでは、プレーヤの仮想現実感の向上のために、よりリアルで高品質な画像を生成することが重要な技術的課題になっている。
【０００５】
一方、画像のリアル度や品質を向上させることの反射的効果として、画像生成に必要なデータの使用記憶容量が増加してしまうという課題が生じる。そして、このような課題を解決するために、この種のゲームシステムでは、色データ（ＲＧＢ）を圧縮してＤＶＤやＣＤなどの情報記憶媒体に記憶しておき、画像表示の際にこの圧縮された色データを伸張（展開）し、得られた色データに基づいて画像を生成する。このため、家庭用のゲームシステムなどでは、圧縮された色データを伸張するためのデコード部を備えているものが多い。
【０００６】
ところが、この種のゲームシステムが有する圧縮データのデコード部は、色データ（ＲＧＢ）のみを伸張処理の対象としており、表示物の半透明処理等に使用されるα値などの他のデータについては伸張処理の対象としていない。従って、色データについては圧縮して情報記憶媒体などに記憶しておくことができるが、α値などの他のデータについては圧縮して記憶しておくことができず、データの使用記憶容量が増加してしまうという課題がある。
【０００７】
本発明は、以上のような課題に鑑みてなされたものであり、その目的とするところは、データの使用記憶容量を抑えながらもリアルで高品質な画像を生成できるゲームシステム、情報記憶媒体及び圧縮方法を提供することにある。
【課題を解決するための手段】
【０００８】
（１）本発明は、圧縮された色データを伸張するデコード手段を有するゲームシステムであって、
色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを第１のデータに設定する伸長データ処理手段と、
設定された第１のデータを用いて、画像を生成するための所与の処理を行う手段とを含み、
前記第１のデータが、奥行き値であることを特徴とする。
【０００９】
また本発明は、コンピュータ読み取り可能な情報記憶媒体であって、上記各手段としてコンピュータを機能させるためのプログラムを記憶した情報記憶媒体に関する。
【００１０】
（２）また本発明に係るゲームシステム及び情報記憶媒体では、
前記所与の処理を行う手段が、
設定された奥行き値に基づき陰面消去を行うようにしてもよい。
【００１１】
（３）また本発明に係るゲームシステム及び情報記憶媒体では、
前記伸長データ処理手段が、
ムービーデータが含む奥行き値を色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを奥行き値に設定し、
前記所与の処理を行う手段が、
設定された奥行き値と、移動オブジェクトの奥行き値とに基づいて陰面消去を行い、ムービーと移動オブジェクトが合成された画像を生成するようにしてもよい。
【００１２】
（４）本発明は、圧縮された色データを伸張するデコード手段を有するゲームシステムに用いられる圧縮データについての生成方法であって、
前記デコード手段の伸張処理の対象となる色データとは異なる第１のデータを色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成し、
前記第１のデータが、奥行き値のデータであることを特徴とする。
【００１３】
（５）また本発明に係る圧縮データの生成方法では、
ムービーデータが含む奥行き値を色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成するようにしてもよい。
【図面の簡単な説明】
【００１４】
【図１】本実施形態のゲームシステムの機能ブロック図の例である。
【図２】本実施形態により生成されるゲーム画像の例である。
【図３】ゲーム画像を構成する各パーツの絵の例である。
【図４】各パーツの絵を構成する画像データの例である。
【図５】本実施形態の原理について説明するための図である。
【図６】伸張データが含む色成分の階調に応じた値に、α値を設定したり、伸張データが含む緑色成分をα値に設定する手法について説明するための図である。
【図７】α値のデータを横方向、縦方向にスケーリングする手法について説明するための図である。
【図８】図８（Ａ）、（Ｂ）、（Ｃ）は、第１のデータとしてヒットチェック用データ、移動制御用データを用いる手法について説明するための図である。
【図９】図９（Ａ）、（Ｂ）は、第１のデータとして画像制御用データを用いる手法につい説明するための図である。
【図１０】第１のデータとして奥行き値（Ｚ値）を用いる手法について説明するための図である。
【図１１】図１１（Ａ）、（Ｂ）も、第１のデータとして奥行き値（Ｚ値）を用いる手法について説明するための図である。
【図１２】インデックスカラー・テクスチャマッピングについて説明するための図である。
【図１３】インデックスカラー・テクスチャマッピング用のＬＵＴを有効利用して、Ｇプレーンの色データをα値に変換する手法について説明するための図である。
【図１４】ＬＵＴを用いて分割ブロックサイズのポリゴンにテクスチャマッピングする手法について説明するための図である。
【図１５】本実施形態の処理の詳細例について示すフローチャートである。
【図１６】本実施形態の処理の詳細例について示すフローチャートである。
【図１７】本実施形態の処理の詳細例について説明するための図である。
【図１８】本実施形態の処理の詳細例について説明するための図である。
【図１９】本実施形態を実現できるハードウェアの構成の一例を示す図である。
【図２０】図２０（Ａ）、（Ｂ）、（Ｃ）は、本実施形態が適用される種々の形態のシステムの例を示す図である。
【発明を実施するための形態】
【００１５】
上記課題を解決するために、本実施形態は、圧縮された色データを伸張するデコード手段を有するゲームシステムであって、色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを第１のデータに設定する手段と、設定された第１のデータを用いて、画像を生成するための所与の処理を行う手段とを含むことを特徴とする。また本実施形態に係る情報記憶媒体は、コンピュータにより使用可能な情報記憶媒体であって、上記手段をコンピュータに実現させるためのプログラムを含むことを特徴とする。また本実施形態に係るプログラムは、コンピュータにより使用可能なプログラム（情報記憶媒体又は搬送波に具現化されるプログラム）であって、上記手段をコンピュータに実現させるためのモジュールを含むことを特徴とする。
【００１６】
本実施形態では、色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データが用意される（例えば情報記憶媒体やネットワークから読み出される）。なお、ここで第１のデータは、α値、ヒットチェック用のデータ、オブジェクトの移動制御用のデータ、オブジェクトの画像制御用のデータ又は奥行き値などの色データ以外のデータであり、例えば、ピクセル（テクセル）に関連づけて設定されるデータである。
【００１７】
そして本実施形態では、この用意された圧縮データが、色データ用のデコード手段を用いて伸張され、得られた伸張データが第１のデータに設定（変換）される。そして、この設定された第１のデータを用いて、画像を生成するための種々の処理（α合成処理、ヒットチェック処理、オブジェクトの移動制御処理、オブジェクトの画像制御処理、陰面消去処理又はテクスチャマッピング等）が行われる。
【００１８】
このようにすることで、色データの伸張用に設けられたデコード手段を有効利用して、色データとは異なる第１のデータの圧縮データについても伸張できるようになる。この結果、データの使用記憶容量を抑えながらも、この第１のデータを用いたリアルで高品質な画像を生成できる。
【００１９】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記第１のデータがα値であり、画像データが含む色データを圧縮することで生成された第１の圧縮データを、前記デコード手段を用いて伸張し、色データを得ると共に、前記画像データが含むα値を色データに設定し圧縮することで生成された第２の圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データをα値に設定し、得られた色データとα値とを用いたα合成処理を行うことを特徴とする。このようにすれば、色データの伸張用に設けられたデコード手段を有効利用してα値の圧縮データを伸張できるようになり、色データとα値（例えば色データとα値を有するテクスチャ）を用いたリアルで高品質な画像を生成できるようになる。
【００２０】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記デコード手段により得られた伸張データが含む色成分の階調（グレースケール）に応じた値に、前記第１のデータを設定することを特徴とする。このようにすれば、その値が細かく変化する第１のデータを用いてリアルな画像を生成できるようになる。
【００２１】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記デコード手段により得られた伸張データが含む緑色成分を、前記第１のデータに設定することを特徴とする。このようにすれば、圧縮・伸張に伴う第１のデータの情報劣化を最小限に抑えながら、高品質な画像を生成できるようになる。
【００２２】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記圧縮データが、横方向及び縦方向の少なくとも一方のサイズが縮小された後に圧縮されることで生成され、前記デコード手段により得られた伸張データが、横方向及び縦方向の少なくとも一方のサイズが拡大されて元のサイズに戻されることを特徴とする。このようにすれば、例えば第１のデータが、情報の劣化がそれほど問題にならないようなデータである場合に、データの使用記憶容量を大幅に節約できるようになる。
【００２３】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記第１のデータが、ヒットチェック用のデータ、オブジェクトの移動制御用のデータ、オブジェクトの画像制御用のデータ及び奥行き値のデータの少なくとも１つであることを特徴とする。このようにすれば、データの使用記憶容量を節約しながら、適正なヒットチェック処理、オブジェクトの移動制御処理、オブジェクトの画像制御処理又は陰面消去処理などを実現できるようになる。
【００２４】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、オブジェクトの各位置における第１のデータの値を求め、求められた第１のデータの値に基づいてオブジェクトに対する処理を行うことを特徴とする。このようにすれば、例えばオブジェクトが移動するマップ上に第１のデータが設定されているような場合に、マップ上でのオブジェクトの位置に基づいて第１のデータの値を求め、求められた値に基づいて、移動制御、画像制御又はイベント制御などの種々の処理をオブジェクトに対して施すことができるようになる。
【００２５】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、オブジェクトに対する前記処理が、オブジェクトの移動を制御する処理及びオブジェクトの画像を制御する処理の少なくとも一方であることを特徴とする。このようにすれば、第１のデータの使用記憶容量を節約しながら、リアルで精度の高いオブジェクトの移動制御、画像制御を実現できるようになる。
【００２６】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記圧縮データを伸張することにより得られた伸張データを、インデックスカラー・テクスチャマッピング用のルックアップテーブルのインデックス番号として設定し、伸張データがインデックス番号として設定された前記ルックアップテーブルを用いて、仮想オブジェクトに対してインデックスカラー・テクスチャマッピングを行い、伸張データを前記第１のデータに設定することを特徴とする。このようにすれば、伸張データを第１のデータに設定する処理を、例えば１回のテクスチャマッピングで一括して行うことができるようになり、処理を効率化できる。
【００２７】
なお、仮想オブジェクトは、ポリゴンなどのプリミティブ面であることが望ましいが、立体的なオブジェクトであってもよい。また、仮想オブジェクトは画面上に表示しないことが望ましいが、表示するようにしてもよい。
【００２８】
また本実施形態は、圧縮された色データを伸張するデコード手段を有するゲームシステムに用いられる圧縮データについての生成方法であって、前記デコード手段の伸張処理の対象となる色データとは異なる第１のデータを色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成することを特徴とする。
【００２９】
本実施形態にすれば、色データとは異なる第１のデータを圧縮し、生成された圧縮データを、情報記憶媒体やネットワークを介してゲームシステムに読み込ませ、色データ用のデコード手段を用いて伸張させることなどが可能になる。
【００３０】
なお、第１のデータの圧縮をゲーム処理中にリアルタイムに行うようにしてもよい。
【００３１】
また本実施形態は、前記第１のデータがα値であり、画像データが含む色データを圧縮して、第１の圧縮データを生成すると共に、前記画像データが含むα値を色データに設定し圧縮して、第２の圧縮データを生成することを特徴とする。このようにすれば、色データのみならずα値についても色データとみなして圧縮できるようになり、圧縮データのデータ量をより少なくすることができるようになる。
【００３２】
また本実施形態は、前記第１のデータが、前記第１のデータの値に応じた階調の色データに設定されて圧縮されることを特徴とする。このようにすれば、その値が細かく変化する第１のデータについても適正に圧縮できるようになる。
【００３３】
また本実施形態は、前記第１のデータが、横方向及び縦方向の少なくとも一方のサイズが縮小された後に圧縮されることを特徴とする。このようにすれば、例えば第１のデータが、情報の劣化がそれほど問題にならないようなデータである場合に、圧縮データのデータ量をより少なくすることができるようになる。
【００３４】
また本実施形態は、前記第１のデータが、ヒットチェック用のデータ、オブジェクトの移動制御用のデータ、オブジェクトの画像制御用のデータ及び奥行き値のデータの少なくとも１つであることを特徴とする。このようにすれば、色データのみならず、ヒットチェック用のデータ、オブジェクトの移動制御用のデータ、オブジェクトの画像制御用のデータ、奥行き値のデータなどについてもコンパクトに圧縮できるようになる。
【００３５】
以下、本発明の好適な実施形態について図面を用いて説明する。
【００３６】
１．構成
図１に、本実施形態のゲームシステム（画像生成システム）の機能ブロック図の一例を示す。なお同図において本実施形態は、少なくとも処理部１００を含めばよく（或いは処理部１００と記憶部１７０を含めばよく）、それ以外のブロックについては任意の構成要素とすることができる。
【００３７】
操作部１６０は、プレーヤが操作データを入力するためのものであり、その機能は、レバー、ボタン、マイク、或いは筺体などのハードウェアにより実現できる。
【００３８】
記憶部１７０は、処理部１００や通信部１９６などのワーク領域となるもので、その機能はＲＡＭなどのハードウェアにより実現できる。
【００３９】
情報記憶媒体１８０（コンピュータにより使用可能な記憶媒体）は、プログラムやデータなどの情報を格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）などのハードウェアにより実現できる。処理部１００は、この情報記憶媒体１８０に格納される情報に基づいて本発明（本実施形態）の種々の処理を行う。即ち情報記憶媒体１８０には、本発明（本実施形態）の手段（特に処理部１００に含まれるブロック）をコンピュータに実現（実行、機能）させるためのプログラムが格納され、このプログラムは、１又は複数のモジュール（オブジェクト指向におけるオブジェクトも含む）を含む。
【００４０】
なお、情報記憶媒体１８０に格納される情報の一部又は全部は、システムへの電源投入時等に記憶部１７０に転送されることになる。また情報記憶媒体１８０には、本発明の処理を行うためのプログラム、画像データ、音データ、表示物の形状データ、本発明の処理を指示するための情報、或いはその指示に従って処理を行うための情報などを含ませることができる。
【００４１】
表示部１９０は、本実施形態により生成された画像を出力するものであり、その機能は、ＣＲＴ、ＬＣＤ、或いはＨＭＤ（ヘッドマウントディスプレイ）などのハードウェアにより実現できる。
【００４２】
音出力部１９２は、本実施形態により生成された音を出力するものであり、その機能は、スピーカなどのハードウェアにより実現できる。
【００４３】
携帯型情報記憶装置１９４は、プレーヤの個人データやゲームのセーブデータなどが記憶されるものであり、この携帯型情報記憶装置１９４としては、メモリカードや携帯型ゲーム装置などを考えることができる。
【００４４】
通信部１９６は、外部（例えばホスト装置や他のゲームシステム）との間で通信を行うための各種の制御を行うものであり、その機能は、各種プロセッサ、或いは通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。
【００４５】
なお本発明（本実施形態）の各手段を実現するためのプログラム（データ）は、ホスト装置（サーバー）が有する情報記憶媒体からネットワーク及び通信部１９６を介して情報記憶媒体１８０に配信するようにしてもよい。このようなホスト装置（サーバー）の情報記憶媒体の使用も本発明の範囲内に含まれる。
【００４６】
処理部１００（プロセッサ）は、操作部１６０からの操作データやプログラムなどに基づいて、ゲーム処理、画像生成処理、或いは音生成処理などの各種の処理を行う。この場合、処理部１００は、記憶部１７０内の主記憶部１７２をワーク領域として使用して、各種の処理を行う。
【００４７】
ここで、処理部１００が行うゲーム処理としては、コイン（代価）の受け付け処理、各種モードの設定処理、ゲームの進行処理、選択画面の設定処理、オブジェクト（１又は複数のプリミティブ面）の位置や回転角度（Ｘ、Ｙ又はＺ軸回り回転角度）を求める処理、オブジェクトを動作させる処理（モーション処理）、視点の位置（仮想カメラの位置）や視線角度（仮想カメラの回転角度）を求める処理、マップオブジェクトなどのオブジェクトをオブジェクト空間へ配置する処理、ヒットチェック処理、ゲーム結果（成果、成績）を演算する処理、複数のプレーヤが共通のゲーム空間でプレイするための処理、或いはゲームオーバー処理などを考えることができる。
【００４８】
また、処理部１００は、上記のゲーム処理結果に基づいて各種の画像処理を行い、ゲーム画像を生成し、表示部１９０に出力する。例えば、いわゆる３次元のゲーム画像を生成する場合には、まず、座標変換、クリッピング処理、透視変換、或いは光源計算等のジオメトリ処理が行われ、その処理結果に基づいて、描画データ（プリミティブ面の構成点（頂点）に付与される位置座標、テクスチャ座標、色（輝度）データ、法線ベクトル或いはα値等）が作成される。そして、この描画データ（プリミティブ面データ）に基づいて、ジオメトリ処理後のオブジェクト（１又は複数プリミティブ面）の画像が、描画バッファ１７４（フレームバッファ、ワークバッファ等のピクセル単位で画像情報を記憶できるバッファ）に描画される。これにより、オブジェクト空間内において所与の視点（仮想カメラ）から見える画像が生成されるようになる。
【００４９】
更に、処理部１００は、上記のゲーム処理結果に基づいて各種の音処理を行い、ＢＧＭ、効果音、又は音声などのゲーム音を生成し、音出力部１９２に出力する。
【００５０】
なお、処理部１００の機能は、より好適には、ハードウェア（ＣＰＵ、ＤＳＰ等のプロセッサ又はゲートアレイ等のＡＳＩＣ）とプログラム（ゲームプログラム又はファームウェア等）との組み合わせにより実現される。但し、処理部１００の機能の全てを、ハードウェアにより実現してもよいし、その全てをプログラムにより実現してもよい。
【００５１】
処理部１００は、デコード（伸張）部１１０、伸張データ処理部１２０、ヒットチェック部１２２、移動制御部１２４、画像制御部１２６、テクスチャマッピング部１３０、陰面消去部１３２、α合成部１３４を含む。
【００５２】
ここで、デコード部１１０は、ＪＰＥＧ、ＭＰＥＧ等の圧縮方法で圧縮された色データを伸張（展開）する処理を行う。
【００５３】
例えば、データ圧縮は以下のようにして実現できる。
【００５４】
即ち、まずデータが複数のマクロブロックに分割される。そして、分割された各ブロックに対して、ＤＣＴ（離散コサイン変換。広義には、アダマール変換、固有値変換等を含む直交変換）が施される。これにより、データが周波数（空間周波数）分解される。次に、ＤＣＴにより得られた各ＤＣＴ係数（広義には直交変換係数）が量子化される。そして、ハフマン符号化（エントロピー符号化、可変長符号化）が行われ、これにより圧縮データが得られる。
【００５５】
一方、データの伸張は以下のようにして実現できる。
【００５６】
即ち、まず圧縮データが情報記憶媒体１８０から読み込まれる。或いは、圧縮データがネットワーク（伝送ライン、通信回線）、通信部１９６を介して外部から読み込まれる。デコード部１１０は、この読み込まれた圧縮データに対してハフマン復号化（エントロピー復号化、可変長復号化）を行う。次に、デコード部１１０は、ハフマン復号化後のデータに対して逆量子化を行う。そして、逆ＤＣＴを行い、これにより伸張データが得られる。
【００５７】
なおＭＰＥＧ（ＭＰＥＧ２、ＭＰＥＧ４等）の場合に、例えば時間的相関関係を利用した予測符号化、予測復号化（動き補償フレーム間予測）を行ってもよい。
【００５８】
そして本実施形態では、元の画像データが含む色データ（例えばＲＧＢ）を圧縮することで生成された圧縮データ（ビットストリーム）をデコード部１１０を用いて伸張（展開）し、色データを得る。更に本実施形態では、元画像のデータが含むα値（広義には色データとは異なる第１のデータ）を色データに設定し圧縮することで生成された圧縮データ（ビットストリーム）を、色データ用のデコード部１１０を用いて伸張し、得られた伸張データをα値（第１のデータ）として設定する。このようにすることで、色データとは異なるα値（第１のデータ）についても、圧縮された状態で情報記憶媒体１８０に記憶したりネットワーク、通信部１９６を介して外部から読み込んだりすることができるようになる。
【００５９】
伸張データ処理部１２０は、デコード部１１０により得られた伸張データに対して種々の処理を施す。
【００６０】
例えば伸張データ処理部１２０は、色データ用のデコード部１１０により伸張されたデータをα値（第１のデータ）に設定して後段の処理に渡す。より具体的には、伸張データが含む色成分（赤、緑又は青）の階調（グレースケール）に応じた値に、α値（第１のデータ）を設定する。更に具体的には、伸張データが含む緑色成分をα値（第１のデータ）に設定する。
【００６１】
なお、伸張後のα値にノイズが重畳され、例えば０〜１２８内の値になるべきα値が１２９以上の値になる場合がある。このような場合には、α値の値を上限値（所与の値）にクランプ（クリッピング）する補正を行うことが望ましい。
【００６２】
また本実施形態では、横方向及び縦方向の少なくとも一方のサイズが縮小された後に圧縮されることで圧縮データが生成されている。そして伸張データ処理部１２０は、デコード部１１０により得られた伸張データの横方向及び縦方向の少なくとも一方のサイズ（描画バッファ１７４でのサイズ）を拡大し、元のサイズに戻す処理を行う。
【００６３】
ヒットチェック部１２２は、オブジェクト間のヒットチェック処理を行う。
【００６４】
キャラクタや車などのオブジェクトがマップ上で移動するゲームを例にとれば、ヒットチェック部１２２は、移動するキャラクタや車とマップ上の障害物（壁、建物等）とが衝突したか否かを判定し、キャラクタや車が障害物の中に入り込まないようにする。
【００６５】
また、プレーヤが標的キャラクタを狙ってショット（弾）をヒットさせるシューティングゲームや、キャラクタ同士でキックやパンチをヒットさせる格闘ゲームを例にとれば、ヒットチェック部１２２は、ショットやキックやパンチがキャラクタにヒットしたか否かを判定する。そして、ヒットした場合にはヒットによるダメージ量を計算し、キャラクタの体力パラメータを減少させたりキャラクタを消滅させたりするなどの処理を行う。
【００６６】
そして本実施形態では、このようなヒットチェックに使用するデータについても、色データとして圧縮しておき、ゲーム処理時に色データ用のデコード部１１０を用いて伸張するようにしている。
【００６７】
移動制御部１２４は、マップ上で移動するオブジェクト（移動体）の移動を制御する処理を行う。即ち、プレーヤが操作部１６０を用いて入力した操作データやマップの地形データなどに基づいて各フレームでのオブジェクトの加速度や速度を求め、各フレームでのオブジェクトの位置や回転角度（方向）を求める。例えば、ヒットチェック用のデータや移動制御用のデータがマップ上に設定されている場合には、オブジェクトの各位置におけるヒットチェック用データの値や移動制御用データの値を求め、求められたデータの値に基づいてオブジェクトの移動を制御する処理を行う。
【００６８】
そして本実施形態では、このようなヒットチェック用データ、移動制御用データについても、色データとして圧縮しておき、ゲーム処理時に色データ用のデコード部１１０を用いて伸張するようにしている。
【００６９】
画像制御部１２６は、マップ上で移動するオブジェクト（移動体）の画像を制御する処理を行う。即ち、オブジェクトのマップ上での位置に応じてオブジェクトの画像（色、輝度、α値、又はテクスチャ等）を変化させる。例えば、オブジェクトの画像制御用データがマップ上に設定されている場合には、オブジェクトの各位置における画像制御用データの値を求め、求められたデータの値に基づいてオブジェクトの画像を制御する処理を行う。
【００７０】
そして本実施形態では、このようなオブジェクトの画像制御用データについても、色データとして圧縮しておき、ゲーム処理時に色データ用のデコード部１１０を用いて伸張するようにしている。
【００７１】
テクスチャマッピング部１３０は、テクスチャ記憶部１７６に記憶されるテクスチャをオブジェクトにマッピングするための処理を行う。この場合、テクスチャマッピング部１３０は、ＬＵＴ記憶部１７８に記憶されるインデックスカラー・テクスチャマッピング用のＬＵＴ（ルックアップテーブル）を用いたテクスチャマッピングを行うことができる。
【００７２】
陰面消去部１３２は、例えば、以下のような手法により陰面消去処理を実現している。
【００７３】
即ち、移動オブジェクトの第２の奥行き値を所与のルーチン（アルゴリズム）により求める。そして、求められた移動オブジェクトの第２の奥行き値（移動オブジェクトを他のオブジェクト間に割り込ませるための奥行き値）と、他のオブジェクト（２次元オブジェクト、立体的に見えるように表現された表示物の２次元画像が描かれたプリミティブ面）の第１の奥行き値とに基づいて、移動オブジェクトの陰面消去を行う。
【００７４】
この場合、移動オブジェクトの第２の奥行き値は、例えば、移動オブジェクトの位置（移動オブジェクトの最下部に設定された代表点の位置）と、他のオブジェクトの下側境界線（下側境界線を所与の距離だけ延長した延長境界線）とに基づいて求めることが望ましい。また、移動オブジェクトの方向や移動履歴（移動経路、移動順序）を考慮して第２の奥行き値を求めてもよい。
【００７５】
なお、陰面消去部１３２が行う陰面消去は、例えば、奥行き値（描画プライオリティ値）に応じてオブジェクト（２次元オブジェクト、プリミティブ面）をソーティングし、視点から見て奥側から順にオブジェクトを描画する奥行きソート法（Ｚソート法）により実現してもよいし、ピクセル毎に奥行き値を比較し、視点から見て手前側のピクセルを描画する奥行き比較法（例えばＺバッファ１７９を用いたＺバッファ法等）により実現してもよい。
【００７６】
α合成部１３４は、α値を用いたα合成処理（αブレンディング、α加算又はα減算等）を行う。なお、α値（Ａ値）は、各ピクセルに関連づけられて記憶されるデータであり、例えば色データ（ＲＧＢ）以外のプラスアルファのデータである。α値は、半透明度（透明度又は不透明度と等価）、マスクデータ、バンプデータなどとして使用できる。
【００７７】
なお、本実施形態のゲームシステムは、１人のプレーヤのみがプレイできるシングルプレーヤモード専用のシステムにしてもよいし、このようなシングルプレーヤモードのみならず、複数のプレーヤがプレイできるマルチプレーヤモードも備えるシステムにしてもよい。
【００７８】
また複数のプレーヤがプレイする場合に、これらの複数のプレーヤに提供するゲーム画像やゲーム音を、１つの端末を用いて生成してもよいし、ネットワーク（伝送ライン、通信回線）などで接続された複数の端末（ゲーム機、携帯電話）を用いて生成してもよい。
【００７９】
２．本実施形態の特徴
次に本実施形態の特徴について図面を用いて説明する。
【００８０】
なお本発明の第１のデータはα値には限定されないが、説明を簡素化するために、以下では第１のデータがα値である場合を主に例にとり説明する。
【００８１】
２．１ 画像データの構造
図２に、本実施形態により生成されたゲーム画像の例を示す。
【００８２】
このゲーム画像は、図３のＦ１、Ｆ２、Ｆ３に示すような３つのパーツの絵により構成されている。Ｆ１は背景の絵であり、Ｆ２は木（図２の画面左において上から下に横切る木）の絵であり、Ｆ３はキャラクタ（登場人物）の絵である。
【００８３】
そして、図３のＦ２に示す木の絵の画像データは、図４のＧ１に示すような色データ（ＲＧＢ）とＧ２に示すようなα値のデータとにより構成されている。また図３のＦ３に示すキャラクタの絵の画像データは、図４のＧ３に示すような色データとＧ４に示すようなα値のデータとにより構成されている。
【００８４】
より具体的には図３のＦ２の木の絵は、図４のＧ１の色データとＧ２のα値とをテクセルデータとして持つテクスチャを、例えば板状のポリゴン（広義にはプリミティブ面）にマッピングすることで表現されている。同様に、図３のＦ３のキャラクタの絵は、図４のＧ３の色データとＧ４のα値とをテクセルデータとして持つテクスチャを、例えば板状のポリゴン（プリミティブ面）にマッピングすることで表現されている。
【００８５】
そして図４のＧ２、Ｇ４に示すように、木やキャラクタの輪郭の外側領域では、α値が透明に設定されており、木やキャラクタの輪郭の内側領域では、α値が不透明又は半透明に設定されている。これにより、図３のＦ２、Ｆ３に示すような木やキャラクタの絵を表現できる。また、例えば木やキャラクタの輪郭付近においてα値を透明から不透明に徐々に変化させることで、木やキャラクタの輪郭をぼやかすアンチエリアシングを実現でき、ジャギーの発生等を低減できる。
【００８６】
２．２ α値の圧縮
さて、例えば家庭用のゲームシステムなどにおいては、圧縮データを効率よく伸張するために、ＭＰＥＧ、ＪＰＥＧ用のデコード部を専用のハードウェアとして内蔵しているものもある。
【００８７】
ところが、この種のゲームシステムが有するデコード部は、色データ（ＲＧＢ）のみを伸張処理の対象としており、α値などの色データ以外のデータについては伸張処理の対象としていないのが一般的である。その理由は以下の通りである。
【００８８】
即ち、この種のゲームシステムが有するデコード部は、ゲームのオープニング、幕間、エンディングで表示されるＣＧムービー（ＣＧ画像）のデータを伸張するために設けられているのが通常である。そして、このようなＣＧムービーのデータは、α合成などのレンダリング処理が既に完了した後のデータ（いわゆるベタ絵のデータ）であり、α値などを含まない色データ（ＲＧＢ）だけのデータになっている。従って、デコード部は、色データだけを伸張できれば十分であり、α値などの色データ以外のデータを伸張できる構成にはなっていない。
【００８９】
また、ＭＰＥＧ、ＪＰＥＧ方式では一般的に色データを圧縮及び伸張処理の対象としているため、これらのＭＰＥＧ、ＪＰＥＧ方式でデータを伸張するデコード部も、沿革的に色データのみを伸張処理の対象とするようになっている。
【００９０】
以上のように、この種のゲームシステムが有するデコード部は色データのみを伸張処理の対象としているため、図４のＧ２、Ｇ４に示すようなα値などのデータについては伸張できない。従って、α値を圧縮して情報記憶媒体などに記憶しておくことができず、データの使用記憶容量を今一つ節約できないという課題があった。
【００９１】
このような課題を解決するために、本実施形態では次のような手法を採用している。
【００９２】
即ち、色データとは異なる第１のデータ（α値、ヒットチェック用データ、オブジェクトの移動制御用データ、オブジェクトの画像制御用データ又は奥行き値のデータ等）を色データに設定し圧縮することで生成された圧縮データを、例えば情報記憶媒体やネットワークから読み込む。そして、読み込まれた圧縮データをデコード部を用いて伸張し、得られた伸張データを第１のデータに設定し直す。そして、設定された第１のデータを用いて、画像を生成するための種々の処理（α合成、ヒットチェック、オブジェクトの移動制御又はオブジェクトの画像制御の処理等）を行う。
【００９３】
より具体的には図５に示すように、元画像データが含む色データをエンコード部で圧縮することで生成される圧縮データＣＰ１（ビットストリーム）と、元画像データが含むα値（広義には第１のデータ）を色データに設定してエンコード部で圧縮することで生成された圧縮データＣＰ２とを用意する。
【００９４】
そして、圧縮データＣＰ１をデコード部で伸張したデータＥＸ１に基づき色データを得る。また、圧縮データＣＰ２をデコード部で伸張したデータＥＸ２をα値に設定することで、α値を得る。そして、得られた色データとα値とを用いてα合成処理を行うことで、図２に示すようなゲーム画像を生成する。
【００９５】
このようにすることで、デコード部の伸張処理の対象とはならないα値（第１のデータ）についても、情報記憶媒体に圧縮して記憶しておくことができるようになる。従って、データの使用記憶容量を節約できるようになり、より高品質な画像を少ないデータ使用記憶容量で生成できる。
【００９６】
２．３ α値の設定手法
さて本実施形態では、デコード部で得られた伸張データが含む色成分の階調（グレースケール）に応じた値に、α値（第１のデータ）を設定したり、伸張データが含む緑色成分を、α値（第１のデータ）に設定するようにしている。
【００９７】
例えば図６のＨ１に示すように、圧縮対象となるα値が０〜２５５の範囲のデータであったとする。この場合には例えば図６のＨ２に示すように、α＝０の場合はＲ＝Ｇ＝Ｂ＝０、α＝１の場合にはＲ＝Ｇ＝Ｂ＝１、α＝２の場合にはＲ＝Ｇ＝Ｂ＝２、・・・・α＝２５５の場合にはＲ＝Ｇ＝Ｂ＝２５５というように、α値を、その各値に応じた階調の色データ（ＲＧＢ）に設定して圧縮しておく。なお、α値とＲ、Ｇ、Ｂの値を同じ値にする必要性はなく、例えばα＝１２８の時にＲ＝Ｇ＝Ｂ＝２５５となるような設定にしてもよい。
【００９８】
このようにして圧縮されたデータを伸張することにより図６のＨ３に示すような伸張データが得られた場合には、例えばＨ４に示すように伸張データが含む色成分の階調に応じた値にα値を設定する。より具体的にはＨ５に示すように、例えば、Ｇ＝０の場合にはα＝０、Ｇ＝１の場合にはα＝１、Ｇ＝２の場合にはα＝２、・・・・・・Ｇ＝２５５の場合にはα＝２５５というように、伸張データが含む緑（Ｇ）成分をα値に設定する。
【００９９】
即ち、ＭＰＥＧやＪＰＥＧなどの圧縮方式では、ＲＧＢ表現がＹＣｒＣｂ（ＹＵＶ）表現に変換され、輝度成分Ｙ、色差成分Ｃｒ（ＲとＹの色差）色差成分、Ｃｂ（ＢとＹの色差）は別々に圧縮される。そして、人間の目は、輝度の変化には敏感だが色差の変化にはそれほど敏感ではないという性質がある。従って、ＭＰＥＧやＪＰＥＧでは、色差成分Ｃｒ、Ｃｂに比べて輝度成分Ｙの符号量が多くなるように圧縮している。そして、ＲＧＢ表現からＹＣｒＣｂ表現への変換式はその一例として下式（１）のように表すことができる。
【０１００】
Ｙ ＝ ０．２９９×Ｒ＋０．５８７×Ｇ＋０．１１５×Ｂ
Ｃｒ＝ ０．５００×Ｒ−０．４１８×Ｇ−０．０８２×Ｂ （１）
Ｃｂ＝−０．１６９×Ｒ−０．３３１×Ｇ＋０．５００×Ｂ
上式（１）から明らかなように、輝度成分Ｙに対する寄与が一番大きいのはＧ（緑）成分である。従って、輝度成分Ｙの圧縮時の符号量が多いということは、Ｇ成分の情報の劣化が最も少ないということを意味する。
【０１０１】
従って、図６のＨ５に示すように、伸張データのＧ成分をα値に設定するようにすれば、圧縮・伸張に伴うα値の情報劣化を最小限に抑えることが可能になり、より高品質な画像を生成できるようになる。
【０１０２】
２．４ 横方向、縦方向のサイズのスケーリング
さて、α値などの色データ以外のデータでは、色データに要求されるような高い精度の情報は必要とされない。そこで本実施形態では、この点に着目して、以下のような手法を採用している。
【０１０３】
即ち図７に示すように、α値の横方向、縦方向のサイズ（横、縦のいずれか一方のサイズでもよいし、両方のサイズでもよい）を縮小した後にエンコード部で圧縮することで、α値についての圧縮データＣＰ２を生成しておく。
【０１０４】
そして、この圧縮データＣＰ２をデコード部で伸張した後、得られた伸張データＥＸ２の横方向、縦方向のサイズ（横、縦のいずれか一方のサイズでもよいし、両方のサイズでもよい）を拡大して元のサイズに戻すようにする。
【０１０５】
このようにすれば、圧縮・伸張に伴うα値の情報劣化は増えるものの、圧縮データＣＰ２のデータ量を大幅に低減できる。例えば、横方向、縦方向の縮小率を共に１／２にした場合には、圧縮データのデータ量を１／４にすることができる。
【０１０６】
そして、α値の情報が劣化しても、色データの情報が劣化する場合とは異なり、生成される画像の品質はそれほど劣化しない。従って、図７に示す手法を採用すれば、画質をそれほど劣化させることなく、データの使用記憶容量を節約できるという利点を得ることができる。
【０１０７】
２．５ ヒットチェック、移動制御、画像制御のデータの圧縮・伸張
さて、以上では、色データとして圧縮・伸張される第１のデータがα値である場合を例にとり説明したが、このような第１のデータとしては、ヒットチェック用データ、オブジェクトの移動制御用データ、オブジェクトの画像制御用データ、又は奥行き値（Ｚ値）などの種々のデータを考えることができる。
【０１０８】
２．５．１ ヒットチェック用データ
例えば図８（Ａ）に示すように、移動オブジェクト２０がマップ上を移動する場合には、壁、建物などの障害物２２、２４、２６（進入禁止領域）と移動オブジェクト２０とのヒットチェックを行う必要がある。
【０１０９】
このような場合に、ヒットチェック用データである、障害物の位置や形状等を特定するためのデータを、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データをヒットチェック用データとして設定し直すようにする。そして、移動オブジェクト２０の各位置におけるヒットチェック用データの値を求め、求められた値に基づいて移動オブジェクト２０と障害物２２、２４、２６とのヒットチェック処理（広義には移動制御処理）を行う。このようにすれば、データの使用記憶容量を節約しながら、移動オブジェクト２０と障害物２２、２４、２６との間の適正なヒットチェック処理を実現できるようになる。
【０１１０】
また、シューティングゲームや格闘ゲームにおいては、ショット（弾）やキックやパンチがキャラクタにヒットしたか否かを判別し、キャラクタのダメージ量を計算する必要がある。この場合に図８（Ｂ）に示すように、キャラクタ３０の各部位毎にダメージ量を異ならせ、例えば頭にショット等がヒットした場合にはダメージ量を大きくし、手や足にヒットした場合にはダメージ量を少なくする。
【０１１１】
このような場合に、ヒットチェック用データである、各部位でのダメージ量のデータを、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データをヒットチェック用データとして設定し直すようにする。このようにすれば、データの使用記憶容量を節約しながら、キャラクタ３０とショット等の間の適正でリアルなヒットチェック処理を実現できるようになる。
【０１１２】
２．５．２ 移動制御用データ
図８（Ｃ）に示すように移動オブジェクト２０がマップ上を移動する場合には、移動オブジェクト２０が移動する領域に応じた移動制御を移動オブジェクト２０に対して施すことが望ましい。例えば、移動オブジェクト２０が沼地３２（速度変化領域）に進入した場合には、移動オブジェクト２０の速度を減少させるようにする。
【０１１３】
このような場合に、移動オブジェクト２０の移動制御用データを、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データを移動制御用データとして設定し直すようにする。そして、移動オブジェクト２０の各位置における移動制御用データの値を求め、求められた値に基づいて移動オブジェクト２０の移動制御処理を行う。このようにすれば、データの使用記憶容量を節約しながら、移動オブジェクト２０のリアルな移動制御を実現できるようになる。
【０１１４】
なお、移動オブジェクトの移動制御用データとしては、移動オブジェクトの位置、速度、加速度又は方向等を制御するための種々のデータを考えることができる。
【０１１５】
２．５．３ 画像制御用データ
図９（Ａ）では、光源ベクトルＬＣがＥ１の方向に向いていると想定されており、この想定に沿うように木４２の影領域４０（シェーディング演算変更領域）がマップ上に設定されている。そして、移動オブジェクト２０がこの影領域４０に進入したと判定すると、移動オブジェクト２０に対するシェーディング演算を変更し、移動オブジェクト２０の陰影づけが全体的に暗くなるようにする。このようにすれば、移動オブジェクト２０の陰影づけを変えるか否かを、移動オブジェクト２０の位置が影領域４０内にあるか否かを判別するだけで判断できる。従って、移動オブジェクト２０の陰影づけを変えるか否かを、３次元立体データに基づいて判断する手法に比べて、処理負担を格段に軽減できる。
【０１１６】
このような場合に、移動オブジェクトの画像制御用データである、影領域４０の位置や形状等を特定するためのデータを、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データを、移動オブジェクト２０の画像制御用データとして設定し直すようにする。そして、移動オブジェクト２０の各位置における画像制御用データの値を求め、求められた値に基づいて移動オブジェクト２０の画像制御処理を行う。このようにすれば、少ないデータの使用記憶容量で、移動オブジェクト２０のリアルなシェーディング処理を実現できるようになる。
【０１１７】
なお、よりリアルな表現を実現するためには、影領域４０（シェーディング演算変更領域）に対してシェーディング演算パラメータを設定しておくことが望ましい。例えば図９（Ｂ）に示すように、影領域４０の頂点ＶＥ０、ＶＥ１、ＶＥ２、ＶＥ３に対して、各々、シェーディング演算パラメータの１つである輝度パラメータＩ０、Ｉ１、Ｉ２、Ｉ３を設定する。そして、これらの輝度パラメータＩ０〜Ｉ３に基づいて、移動オブジェクト２０のシェーディング演算に使用される輝度パラメータを求め、求められた輝度パラメータに基づいて移動オブジェクト２０に対するシェーディング演算を行うようにする。このようにすれば、図９（Ｂ）に示すように、移動オブジェクト２０に施される陰影づけを影領域４０の各場所において様々に変化させることができるようになり、よりリアルな陰影づけ表現が可能になる。
【０１１８】
そして、この場合には、このシェーディング演算パラメータ（輝度パラメータ）についても、移動オブジェクトの画像制御用データとして圧縮・伸張することが望ましい。
【０１１９】
なお、移動オブジェクトの画像制御用データとしては、移動オブジェクトの色、輝度、α値又はテクスチャ等を制御するための種々のデータを考えることができる。
【０１２０】
２．５．４ 奥行き値
さて、ゲームシステムでは、ゲームのオープニング、幕間、エンディングなどにおいて、プレーヤのゲーム意欲を盛り上げたりプレーヤの感動を高めるために、いわゆるムービー（動画）と呼ばれるものが再生される場合が多い。このムービーでは、ＣＧツールにより制作された映像や実写映像が再生されるため、ポリゴン（プリミティブ面）により構成された３次元オブジェクトをリアルタイムに動かすことで生成される画像に比べて、よりリアルで写実的な表現が可能になる。
【０１２１】
しかしながら、これまでのゲームシステムでは、ムービー再生のためのデータであるムービーデータが、色データ（ＲＧＢ）しか含まなかった。従って、例えばムービーとキャラクタなどの移動オブジェクトが合成された画像を生成しようとすると、キャラクタがムービーの手前に常に表示されるようになり、リアル感に欠ける画像が生成されてしまうという問題が生じる。
【０１２２】
そこで、このような問題を解決するために、本実施形態では、ムービー再生のためのデータであるムービーデータに奥行き値Ｚ１を含ませている。そして、この奥行き値Ｚ１とキャラクタ（広義には移動オブジェクト）の奥行き値Ｚ２とに基づいて陰面消去を行いながら、ムービーとキャラクタが合成された画像を生成する。
【０１２３】
より具体的には例えば図１０に示すように、ムービーを構成する各フレーム画像の各ピクセルに対して、色データ（ＲＧＢ）の他に、奥行き値Ｚ１のデータを含ませる。そして、このＺ１とキャラクタの奥行き値Ｚ２とを比較し、Ｚバッファ法などのアルゴリズムにしたがって陰面消去を行い、ムービーとキャラクタが合成された画像を生成する。
【０１２４】
このようにすることで図１１（Ａ）に示すように、ムービーの絵の中にキャラクタ３０を割り込ませることができるようになる。即ち、ムービーで表現されるタンス５０（表示物）の物陰にキャラクタ３０が隠れたり、ムービーで表現される出入り口５２からキャラクタが出て行くなどの画像表現が可能になる。或いは、ムービーで表現される窓５４の向こう側からキャラクタ３０が覗き込むなどの画像表現も可能になる。
【０１２５】
即ち、これまでのムービーでは、ムービーデータが色データしか含まず、奥行き値のデータを含まなかった。従って、ムービーとキャラクタの合成画像を生成しようとすると、図１１（Ｂ）に示すようにキャラクタ３０が常に手前に表示されるようになってしまい、リアルが画像を生成できなかった。
【０１２６】
本実施形態によれば、図１１（Ａ）に示すように、キャラクタ３０の奥行き値Ｚ２の大きさに応じて、キャラクタ３０がムービーの中の表示物の物陰に隠れたり、隠れなかったりするようになるため、よりリアルで臨場感溢れる画像を生成できる。
【０１２７】
そして本実施形態では、図１０に示すような奥行き値Ｚ１を、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データを奥行き値Ｚ１として設定し直すようにする。このようにすれば、ムービーを構成する色データのみならず奥行き値Ｚ１についても、圧縮して情報記憶媒体に記憶しておくことができるようになる。従って、データの使用記憶容量を節約しながらも、キャラクタがムービーの中の表示物の物陰に隠れたりするようなリアルな画像を生成できるようになる。
【０１２８】
なお、本実施形態で圧縮・伸張の対象となる奥行き値は、図１０のようにムービーに関連づけられた奥行き値であることが特に望ましいが、これに限定されない。
【０１２９】
また、本実施形態におけるムービーは、ＣＧツールで制作した一連のセル画像により構成されるＣＧ映像でもよいし、カメラにより撮影した実写映像でもよい。
【０１３０】
ムービーとしてＣＧ映像を用いる場合には、ＣＧの作成時に生じた各ピクセルの奥行き値のデータを破棄せずにムービーデータの中に含ませるようにする。即ち、ＣＧツールのＺバッファに記憶される最終的な奥行き値のデータは、通常は破棄されるが、これを破棄せずに、色データ（ＲＧＢ）と共にムービーデータの中に含ませるようにする。このようにすることで、奥行き値のデータを含むムービーデータを、それほど手間をかけることなく用意することができるようになる。
【０１３１】
また、奥行き値は、全てのフレーム画像に設定しもよいし、一部のフレーム画像にのみ設定しもよい。また、奥行き値は、ムービーを構成するフレーム画像の全てのピクセルに対して設定しもよいし、一部のピクセルにのみ設定してもよい。
【０１３２】
また、ムービーは、図１１（Ａ）のように背景として用いてもよいが、敵ボス（移動オブジェクト）などの表現に用いてもよい。この場合には例えば、ムービー表示のための仮想的なスクリーンを用意し、この仮想スクリーンに、敵ボスのムービーを投影するようにする。或いは、ムービー表示のためのポリゴン（プリミティブ面）を用意し、ムービーをテクスチャとしてこのポリゴンにマッピングするようにしてもよい。
【０１３３】
２．６ インデックスカラーテクスチャマッピングの利用
さて、図５の圧縮データＣＰ２の伸張データＥＸ２をα値などの第１のデータに設定する処理は、例えば、インデックスカラー・テクスチャマッピングを利用した手法により実現することができる。
【０１３４】
インデックスカラーテクスチャーマッピングでは、テクスチャ記憶部の使用記憶容量を節約するために、図１２のＡ１に示すように、実際の色データ（ＲＧＢ）ではなくインデックス番号が、テクスチャの各テクセルに関連づけて記憶される。また、図１２のＡ２に示すように、インデックスカラー・テクスチャマッピング用のルックアップテーブルＬＵＴ（カラーパレット）には、インデックス番号により指定される色データやα値が記憶される。そして、オブジェクトに対してテクスチャマッピングを行う際には、テクスチャの各テクセルのインデックス番号に基づいてＬＵＴを参照し、対応する色データやα値をＬＵＴから読み出し、読み出された色データとα値に基づいて、フレームバッファに画像を描画する。
【０１３５】
このようなインデックスカラーモードのテクスチャマッピングでは、ＬＵＴを用いない通常モードのテクスチャマッピングに比べて、使用できる色数は少なくなる（例えば１６色）。しかしながら、テクスチャ記憶部に実際の色データ（例えば１６ビット）を記憶する必要が無くなるため、テクスチャ記憶部の使用記憶容量を大幅に節約できる。
【０１３６】
本実施形態は、このようなインデックスカラー・テクスチャマッピングを通常とは異なる形態で利用する。
【０１３７】
即ち、まず図１３のＢ１に示すように、伸張データが含むＧプレーン（他の色成分でもよい）の各ピクセルの色データを、ルックアップテーブルＬＵＴのインデックス番号として設定する（インデックス番号とみなす）。そしてＢ２に示すように、伸張データのＧプレーンの色データがインデックス番号として設定されたＬＵＴを用いて、仮想オブジェクトに対してインデックスカラー・テクスチャマッピングを行い、Ｇプレーンの色データをα値（αＯＵＴ）に変換して、フレームバッファ等に描画する。このようにすれば、Ｇプレーンの色データを、例えば１回のテクスチャマッピングで一括してα値に変換できるようになり、処理の効率化を図れる。
【０１３８】
しかも、インデックスカラー・テクスチャマッピングは、この種のゲームシステムが有する専用のハードウェアである描画プロセッサ（描画部）により高速に実行される。従って、Ｇプレーンの色データをα値に設定（変換）する処理を高速化できるようになる。
【０１３９】
なお、図１３では表示画面サイズのポリゴン（仮想オブジェクト）にテクスチャマッピングすることで、α値の設定処理を実現しているが、表示画面を分割したブロックのサイズのポリゴンにテクスチャマッピングするようにしてもよい。
【０１４０】
即ち、図１４のＣ１に示すように、フレームバッファ（表示画面）を複数のブロックに分割し、Ｃ２に示すように、各ブロックの色データを、ＬＵＴを用いて分割ブロックサイズのポリゴンにテクスチャマッピングする。
【０１４１】
このようにすれば、例えばテクスチャマッピングされたポリゴンをワークバッファ（別バッファ）に一時的に描画するような場合に、ＶＲＡＭ上でのワークバッファの占有領域を小さくできる。
【０１４２】
即ち、図１３のように表示画面サイズのポリゴンにテクスチャマッピングすると、この表示画面サイズのポリゴンを一時的に描画するために、表示画面サイズのワークバッファをＶＲＡＭ上に確保しなければならず、他の処理に支障を来すおそれがある。
【０１４３】
図１４のように、分割ブロックサイズのポリゴンにテクスチャマッピングするようにすれば、ＶＲＡＭ上には分割ブロックサイズのワークバッファを用意すれば済むため、ワークバッファの占有領域を小さくできる。従って、限られたハードウェア資源を有効利用することが可能になる。
【０１４４】
３．本実施形態の処理
次に、本実施形態の処理の詳細例について、図１５、図１６のフローチャートを用いて説明する。
【０１４５】
図１５は、圧縮時の処理についてのフローチャートである。
【０１４６】
まず、図１７に示すように、α付きの元画像データＩＯＲに基づき、ＩＯＲのＲＧＢプレーン（色データ）からなる画像データＩＣと、ＲＧＢプレーンが元画像データＩＯＲのαプレーンに置き換えられた画像データＩα（Ｒ＝Ｇ＝Ｂ＝α）を作成する（ステップＳ１）。
【０１４７】
次に、横（幅）方向、縦（高さ）方向の縮小率をＳＸ、ＳＹとした場合に（０．０＜ＳＸ＜１．０、０．０＜ＳＹ＜１．０）、ステップＳ１で得られた画像データＩαを横方向、縦方向にＳＸ倍、ＳＹ倍に縮小して、画像データＩαＲを生成する（ステップＳ２）。
【０１４８】
そして、ステップＳ１で得られた画像データＩＣと、ステップＳ２で得られた画像データＩαＲの各々を、ＭＰＥＧ、ＪＰＥＧ方式等で圧縮し、ビットストリームＢＣ、ＢαＲを生成する（ステップＳ３）。そして、このようにして生成されたビットストリームＢＣ、ＢαＲは、ゲームプログラムやゲームデータなどが格納される情報記憶媒体に書き込まれることになる（ネットワークを介して配信してもよい）。
【０１４９】
図１６は、伸張時の処理についてのフローチャートである。
【０１５０】
まず、図１８に示すように、図１５のステップＳ３で得られたビットストリームＢＣ、ＢαＲを伸張（展開）して、画像データＩＣ’、ＩαＲ’を得る（ステップＳ１１）。
【０１５１】
次に、図１５のステップＳ２で行ったスケーリングでの横方向、縦方向の縮小率をＳＸ、ＳＹとした場合に、画像データＩαＲ’を横方向、縦方向に１．０／ＳＸ倍、１．０／ＳＹ倍に拡大して、画像データＩα’を生成する（ステップＳ１２）。
【０１５２】
そして、ステップＳ１２で得られた画像データＩα’のＧ（緑）プレーンをαプレーンに設定し、このαプレーンと画像データＩＣ’のＲＧＢプレーンとにより、α付きの画像データＩＯＲ’を得る（ステップＳ１３）。そして、この画像データＩＯＲ’に基づいてα合成処理などが行われ、図２に示すようなゲーム画像が生成されることになる。
【０１５３】
４．ハードウェア構成
次に、本実施形態を実現できるハードウェアの構成の一例について図１９を用いて説明する。
【０１５４】
メインプロセッサ９００は、ＣＤ９８２（情報記憶媒体）に格納されたプログラム、通信インターフェース９９０を介して転送されたプログラム、或いはＲＯＭ９５０（情報記憶媒体の１つ）に格納されたプログラムなどに基づき動作し、ゲーム処理、画像処理、音処理などの種々の処理を実行する。
【０１５５】
コプロセッサ９０２は、メインプロセッサ９００の処理を補助するものであり、高速並列演算が可能な積和算器や除算器を有し、マトリクス演算（ベクトル演算）を高速に実行する。例えば、オブジェクトを移動させたり動作（モーション）させるための物理シミュレーションに、マトリクス演算などの処理が必要な場合には、メインプロセッサ９００上で動作するプログラムが、その処理をコプロセッサ９０２に指示（依頼）する。
【０１５６】
ジオメトリプロセッサ９０４は、座標変換、透視変換、光源計算、曲面生成などのジオメトリ処理を行うものであり、高速並列演算が可能な積和算器や除算器を有し、マトリクス演算（ベクトル演算）を高速に実行する。例えば、座標変換、透視変換、光源計算などの処理を行う場合には、メインプロセッサ９００で動作するプログラムが、その処理をジオメトリプロセッサ９０４に指示する。
【０１５７】
データ伸張プロセッサ９０６は、圧縮された画像データや音データを伸張するデコード処理を行ったり、メインプロセッサ９００のデコード処理をアクセレートする処理を行う。これにより、オープニング画面、インターミッション画面、エンディング画面、或いはゲーム画面などにおいて、ＭＰＥＧ方式等で圧縮された動画像を表示できるようになる。なお、デコード処理の対象となる画像データや音データは、ＲＯＭ９５０、ＣＤ９８２に格納されたり、或いは通信インターフェース９９０を介して外部から転送される。
【０１５８】
描画プロセッサ９１０は、ポリゴンや曲面などのプリミティブ面で構成されるオブジェクトの描画（レンダリング）処理を高速に実行するものである。オブジェクトの描画の際には、メインプロセッサ９００は、ＤＭＡコントローラ９７０の機能を利用して、オブジェクトデータを描画プロセッサ９１０に渡すと共に、必要であればテクスチャ記憶部９２４にテクスチャを転送する。すると、描画プロセッサ９１０は、これらのオブジェクトデータやテクスチャに基づいて、Ｚバッファなどを利用した陰面消去を行いながら、オブジェクトをフレームバッファ９２２に高速に描画する。また、描画プロセッサ９１０は、αブレンディング（半透明処理）、デプスキューイング、ミップマッピング、フォグ処理、バイリニア・フィルタリング、トライリニア・フィルタリング、アンチエリアシング、シェーディング処理なども行うことができる。そして、１フレーム分の画像がフレームバッファ９２２に書き込まれると、その画像はディスプレイ９１２に表示される。
【０１５９】
サウンドプロセッサ９３０は、多チャンネルのＡＤＰＣＭ音源などを内蔵し、ＢＧＭ、効果音、音声などの高品位のゲーム音を生成する。生成されたゲーム音は、スピーカ９３２から出力される。
【０１６０】
ゲームコントローラ９４２からの操作データや、メモリカード９４４からのセーブデータ、個人データは、シリアルインターフェース９４０を介してデータ転送される。
【０１６１】
ＲＯＭ９５０にはシステムプログラムなどが格納される。なお、業務用ゲームシステムの場合には、ＲＯＭ９５０が情報記憶媒体として機能し、ＲＯＭ９５０に各種プログラムが格納されることになる。なお、ＲＯＭ９５０の代わりにハードディスクを利用するようにしてもよい。
【０１６２】
ＲＡＭ９６０は、各種プロセッサの作業領域として用いられる。
【０１６３】
ＤＭＡコントローラ９７０は、プロセッサ、メモリ（ＲＡＭ、ＶＲＡＭ、ＲＯＭ等）間でのＤＭＡ転送を制御するものである。
【０１６４】
ＣＤドライブ９８０は、プログラム、画像データ、或いは音データなどが格納されるＣＤ９８２（情報記憶媒体）を駆動し、これらのプログラム、データへのアクセスを可能にする。
【０１６５】
通信インターフェース９９０は、ネットワークを介して外部との間でデータ転送を行うためのインターフェースである。この場合に、通信インターフェース９９０に接続されるネットワークとしては、通信回線（アナログ電話回線、ＩＳＤＮ）、高速シリアルバスなどを考えることができる。そして、通信回線を利用することでインターネットを介したデータ転送が可能になる。また、高速シリアルバスを利用することで、他のゲームシステムとの間でのデータ転送が可能になる。
【０１６６】
なお、本発明の各手段は、その全てを、ハードウェアのみにより実現（実行）してもよいし、情報記憶媒体に格納されるプログラムや通信インターフェースを介して配信されるプログラムのみにより実現してもよい。或いは、ハードウェアとプログラムの両方により実現してもよい。
【０１６７】
そして、本発明の各手段をハードウェアとプログラムの両方により実現する場合には、情報記憶媒体には、本発明の各手段をハードウェアを利用して実現するためのプログラムが格納されることになる。より具体的には、上記プログラムが、ハードウェアである各プロセッサ９０２、９０４、９０６、９１０、９３０等に処理を指示すると共に、必要であればデータを渡す。そして、各プロセッサ９０２、９０４、９０６、９１０、９３０等は、その指示と渡されたデータとに基づいて、本発明の各手段を実現することになる。
【０１６８】
図２０（Ａ）に、本実施形態を業務用ゲームシステムに適用した場合の例を示す。プレーヤは、ディスプレイ１１００上に映し出されたゲーム画像を見ながら、レバー１１０２、ボタン１１０４等を操作してゲームを楽しむ。内蔵されるシステムボード（サーキットボード）１１０６には、各種プロセッサ、各種メモリなどが実装される。そして、本発明の各手段を実現するためのプログラム（データ）は、システムボード１１０６上の情報記憶媒体であるメモリ１１０８に格納される。以下、このプログラムを格納プログラム（格納情報）と呼ぶ。
【０１６９】
図２０（Ｂ）に、本実施形態を家庭用のゲームシステムに適用した場合の例を示す。プレーヤはディスプレイ１２００に映し出されたゲーム画像を見ながら、ゲームコントローラ１２０２、１２０４を操作してゲームを楽しむ。この場合、上記格納プログラム（格納情報）は、本体システムに着脱自在な情報記憶媒体であるＣＤ１２０６、或いはメモリカード１２０８、１２０９等に格納されている。
【０１７０】
図２０（Ｃ）に、ホスト装置１３００と、このホスト装置１３００とネットワーク１３０２（ＬＡＮのような小規模ネットワークや、インターネットのような広域ネットワーク）を介して接続される端末１３０４-1〜１３０４-n（ゲーム機、携帯電話）とを含むシステムに本実施形態を適用した場合の例を示す。この場合、上記格納プログラム（格納情報）は、例えばホスト装置１３００が制御可能な磁気ディスク装置、磁気テープ装置、メモリ等の情報記憶媒体１３０６に格納されている。端末１３０４-1〜１３０４-nが、スタンドアロンでゲーム画像、ゲーム音を生成できるものである場合には、ホスト装置１３００からは、ゲーム画像、ゲーム音を生成するためのゲームプログラム等が端末１３０４-1〜１３０４-nに配送される。一方、スタンドアロンで生成できない場合には、ホスト装置１３００がゲーム画像、ゲーム音を生成し、これを端末１３０４-1〜１３０４-nに伝送し端末において出力することになる。
【０１７１】
なお、図２０（Ｃ）の構成の場合に、本発明の各手段を、ホスト装置（サーバー）と端末とで分散して実現するようにしてもよい。また、本発明の各手段を実現するための上記格納プログラム（格納情報）を、ホスト装置（サーバー）の情報記憶媒体と端末の情報記憶媒体に分散して格納するようにしてもよい。
【０１７２】
またネットワークに接続する端末は、家庭用ゲームシステムであってもよいし業務用ゲームシステムであってもよい。そして、業務用ゲームシステムをネットワークに接続する場合には、業務用ゲームシステムとの間で情報のやり取りが可能であると共に家庭用ゲームシステムとの間でも情報のやり取りが可能なセーブ用情報記憶装置（メモリカード、携帯型ゲーム装置）を用いることが望ましい。
【０１７３】
なお本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。
【０１７４】
例えば、本発明の圧縮又は伸張処理の対象となる第１のデータは、本実施形態で説明したようなデータが特に望ましいが、これに限定されるものではなく、例えば、ピクセル（テクセルも含む）に関連づけて設定される種々のデータをその対象とすることができる。
【０１７５】
また、伸張データを第１のデータに設定する処理は、インデックスカラー・テクスチャマッピングを利用して実現してもよいし、伸張データの各ピクセル（テクセル）のデータ（例えばＧ成分の色データ）を１つずつ第１のデータ（例えば当該ピクセルでのα値）に設定するソフトウェア処理により実現してもよい。
【０１７６】
また、本発明は、取り込んだ動画像をオブジェクトにそのままマッピングするムービーテクスチャのα値（広義には第１のデータ）の圧縮・伸張などにも適用できる。
【０１７７】
また、本発明のデコード部はハードウェアで実現してもよいし、ソフトウェアで実現してもよい。
【０１７８】
また、本発明のうち従属請求項に係る発明においては、従属先の請求項の構成要件の一部を省略する構成とすることもできる。また、本発明の１の独立請求項に係る発明の要部を、他の独立請求項に従属させることもできる。
【０１７９】
また、本発明は種々のゲーム（格闘ゲーム、シューティングゲーム、ロボット対戦ゲーム、スポーツゲーム、競争ゲーム、ロールプレイングゲーム、音楽演奏ゲーム、ダンスゲーム等）に適用できる。
【０１８０】
また本発明は、業務用ゲームシステム、家庭用ゲームシステム、多数のプレーヤが参加する大型アトラクションシステム、シミュレータ、マルチメディア端末、ゲーム画像を生成するシステムボード等の種々のゲームシステム（画像生成システム）に適用できる。
【符号の説明】
【０１８１】
２０ 移動オブジェクト
２２、２４、２６ 障害物（進入禁止領域）
３０ キャラクタ
３２ 沼地（速度変化領域）
４０ 影領域（シェーディング演算変更領域）
１００ 処理部
１１０ デコード（伸張）部
１２０ 伸張データ処理部
１２２ ヒットチェック部
１２４ 移動制御部
１２６ 画像制御部
１３０ テクスチャマッピング部
１３２ 陰面消去部
１３４ α合成部
１６０ 操作部
１７０ 記憶部
１７２ 主記憶部
１７４ 描画バッファ
１７６ テクスチャ記憶部
１７８ ＬＵＴ記憶部
１７９ Ｚバッファ
１８０ 情報記憶媒体
１９０ 表示部
１９２ 音出力部
１９４ 携帯型情報記憶装置
１９６ 通信部
【技術分野】
【０００１】
本発明は、ゲームシステム、情報記憶媒体及び圧縮データの生成方法に関する。
【背景技術】
【０００２】
従来より、仮想的な３次元空間であるオブジェクト空間内の所与の視点から見える画像を生成するゲームシステムが知られており、いわゆる仮想現実を体験できるものとして人気が高い。ロールプレイングゲーム（ＲＰＧ）を楽しむことができるゲームシステムを例にとれば、プレーヤは、自身の分身であるキャラクタ（オブジェクト）を操作してマップ上で移動させ、敵キャラクタと対戦したり、他のキャラクタと対話したり、様々な町を訪れたりすることでゲームを楽しむ。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開平１０−０９８７１９号公報
【特許文献２】特開平４−１６７１８９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
さて、このようなゲームシステムでは、プレーヤの仮想現実感の向上のために、よりリアルで高品質な画像を生成することが重要な技術的課題になっている。
【０００５】
一方、画像のリアル度や品質を向上させることの反射的効果として、画像生成に必要なデータの使用記憶容量が増加してしまうという課題が生じる。そして、このような課題を解決するために、この種のゲームシステムでは、色データ（ＲＧＢ）を圧縮してＤＶＤやＣＤなどの情報記憶媒体に記憶しておき、画像表示の際にこの圧縮された色データを伸張（展開）し、得られた色データに基づいて画像を生成する。このため、家庭用のゲームシステムなどでは、圧縮された色データを伸張するためのデコード部を備えているものが多い。
【０００６】
ところが、この種のゲームシステムが有する圧縮データのデコード部は、色データ（ＲＧＢ）のみを伸張処理の対象としており、表示物の半透明処理等に使用されるα値などの他のデータについては伸張処理の対象としていない。従って、色データについては圧縮して情報記憶媒体などに記憶しておくことができるが、α値などの他のデータについては圧縮して記憶しておくことができず、データの使用記憶容量が増加してしまうという課題がある。
【０００７】
本発明は、以上のような課題に鑑みてなされたものであり、その目的とするところは、データの使用記憶容量を抑えながらもリアルで高品質な画像を生成できるゲームシステム、情報記憶媒体及び圧縮方法を提供することにある。
【課題を解決するための手段】
【０００８】
（１）本発明は、圧縮された色データを伸張するデコード手段を有するゲームシステムであって、
色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを第１のデータに設定する伸長データ処理手段と、
設定された第１のデータを用いて、画像を生成するための所与の処理を行う手段とを含み、
前記第１のデータが、奥行き値であることを特徴とする。
【０００９】
また本発明は、コンピュータ読み取り可能な情報記憶媒体であって、上記各手段としてコンピュータを機能させるためのプログラムを記憶した情報記憶媒体に関する。
【００１０】
（２）また本発明に係るゲームシステム及び情報記憶媒体では、
前記所与の処理を行う手段が、
設定された奥行き値に基づき陰面消去を行うようにしてもよい。
【００１１】
（３）また本発明に係るゲームシステム及び情報記憶媒体では、
前記伸長データ処理手段が、
ムービーデータが含む奥行き値を色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを奥行き値に設定し、
前記所与の処理を行う手段が、
設定された奥行き値と、移動オブジェクトの奥行き値とに基づいて陰面消去を行い、ムービーと移動オブジェクトが合成された画像を生成するようにしてもよい。
【００１２】
（４）本発明は、圧縮された色データを伸張するデコード手段を有するゲームシステムに用いられる圧縮データについての生成方法であって、
前記デコード手段の伸張処理の対象となる色データとは異なる第１のデータを色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成し、
前記第１のデータが、奥行き値のデータであることを特徴とする。
【００１３】
（５）また本発明に係る圧縮データの生成方法では、
ムービーデータが含む奥行き値を色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成するようにしてもよい。
【図面の簡単な説明】
【００１４】
【図１】本実施形態のゲームシステムの機能ブロック図の例である。
【図２】本実施形態により生成されるゲーム画像の例である。
【図３】ゲーム画像を構成する各パーツの絵の例である。
【図４】各パーツの絵を構成する画像データの例である。
【図５】本実施形態の原理について説明するための図である。
【図６】伸張データが含む色成分の階調に応じた値に、α値を設定したり、伸張データが含む緑色成分をα値に設定する手法について説明するための図である。
【図７】α値のデータを横方向、縦方向にスケーリングする手法について説明するための図である。
【図８】図８（Ａ）、（Ｂ）、（Ｃ）は、第１のデータとしてヒットチェック用データ、移動制御用データを用いる手法について説明するための図である。
【図９】図９（Ａ）、（Ｂ）は、第１のデータとして画像制御用データを用いる手法につい説明するための図である。
【図１０】第１のデータとして奥行き値（Ｚ値）を用いる手法について説明するための図である。
【図１１】図１１（Ａ）、（Ｂ）も、第１のデータとして奥行き値（Ｚ値）を用いる手法について説明するための図である。
【図１２】インデックスカラー・テクスチャマッピングについて説明するための図である。
【図１３】インデックスカラー・テクスチャマッピング用のＬＵＴを有効利用して、Ｇプレーンの色データをα値に変換する手法について説明するための図である。
【図１４】ＬＵＴを用いて分割ブロックサイズのポリゴンにテクスチャマッピングする手法について説明するための図である。
【図１５】本実施形態の処理の詳細例について示すフローチャートである。
【図１６】本実施形態の処理の詳細例について示すフローチャートである。
【図１７】本実施形態の処理の詳細例について説明するための図である。
【図１８】本実施形態の処理の詳細例について説明するための図である。
【図１９】本実施形態を実現できるハードウェアの構成の一例を示す図である。
【図２０】図２０（Ａ）、（Ｂ）、（Ｃ）は、本実施形態が適用される種々の形態のシステムの例を示す図である。
【発明を実施するための形態】
【００１５】
上記課題を解決するために、本実施形態は、圧縮された色データを伸張するデコード手段を有するゲームシステムであって、色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを第１のデータに設定する手段と、設定された第１のデータを用いて、画像を生成するための所与の処理を行う手段とを含むことを特徴とする。また本実施形態に係る情報記憶媒体は、コンピュータにより使用可能な情報記憶媒体であって、上記手段をコンピュータに実現させるためのプログラムを含むことを特徴とする。また本実施形態に係るプログラムは、コンピュータにより使用可能なプログラム（情報記憶媒体又は搬送波に具現化されるプログラム）であって、上記手段をコンピュータに実現させるためのモジュールを含むことを特徴とする。
【００１６】
本実施形態では、色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データが用意される（例えば情報記憶媒体やネットワークから読み出される）。なお、ここで第１のデータは、α値、ヒットチェック用のデータ、オブジェクトの移動制御用のデータ、オブジェクトの画像制御用のデータ又は奥行き値などの色データ以外のデータであり、例えば、ピクセル（テクセル）に関連づけて設定されるデータである。
【００１７】
そして本実施形態では、この用意された圧縮データが、色データ用のデコード手段を用いて伸張され、得られた伸張データが第１のデータに設定（変換）される。そして、この設定された第１のデータを用いて、画像を生成するための種々の処理（α合成処理、ヒットチェック処理、オブジェクトの移動制御処理、オブジェクトの画像制御処理、陰面消去処理又はテクスチャマッピング等）が行われる。
【００１８】
このようにすることで、色データの伸張用に設けられたデコード手段を有効利用して、色データとは異なる第１のデータの圧縮データについても伸張できるようになる。この結果、データの使用記憶容量を抑えながらも、この第１のデータを用いたリアルで高品質な画像を生成できる。
【００１９】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記第１のデータがα値であり、画像データが含む色データを圧縮することで生成された第１の圧縮データを、前記デコード手段を用いて伸張し、色データを得ると共に、前記画像データが含むα値を色データに設定し圧縮することで生成された第２の圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データをα値に設定し、得られた色データとα値とを用いたα合成処理を行うことを特徴とする。このようにすれば、色データの伸張用に設けられたデコード手段を有効利用してα値の圧縮データを伸張できるようになり、色データとα値（例えば色データとα値を有するテクスチャ）を用いたリアルで高品質な画像を生成できるようになる。
【００２０】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記デコード手段により得られた伸張データが含む色成分の階調（グレースケール）に応じた値に、前記第１のデータを設定することを特徴とする。このようにすれば、その値が細かく変化する第１のデータを用いてリアルな画像を生成できるようになる。
【００２１】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記デコード手段により得られた伸張データが含む緑色成分を、前記第１のデータに設定することを特徴とする。このようにすれば、圧縮・伸張に伴う第１のデータの情報劣化を最小限に抑えながら、高品質な画像を生成できるようになる。
【００２２】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記圧縮データが、横方向及び縦方向の少なくとも一方のサイズが縮小された後に圧縮されることで生成され、前記デコード手段により得られた伸張データが、横方向及び縦方向の少なくとも一方のサイズが拡大されて元のサイズに戻されることを特徴とする。このようにすれば、例えば第１のデータが、情報の劣化がそれほど問題にならないようなデータである場合に、データの使用記憶容量を大幅に節約できるようになる。
【００２３】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記第１のデータが、ヒットチェック用のデータ、オブジェクトの移動制御用のデータ、オブジェクトの画像制御用のデータ及び奥行き値のデータの少なくとも１つであることを特徴とする。このようにすれば、データの使用記憶容量を節約しながら、適正なヒットチェック処理、オブジェクトの移動制御処理、オブジェクトの画像制御処理又は陰面消去処理などを実現できるようになる。
【００２４】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、オブジェクトの各位置における第１のデータの値を求め、求められた第１のデータの値に基づいてオブジェクトに対する処理を行うことを特徴とする。このようにすれば、例えばオブジェクトが移動するマップ上に第１のデータが設定されているような場合に、マップ上でのオブジェクトの位置に基づいて第１のデータの値を求め、求められた値に基づいて、移動制御、画像制御又はイベント制御などの種々の処理をオブジェクトに対して施すことができるようになる。
【００２５】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、オブジェクトに対する前記処理が、オブジェクトの移動を制御する処理及びオブジェクトの画像を制御する処理の少なくとも一方であることを特徴とする。このようにすれば、第１のデータの使用記憶容量を節約しながら、リアルで精度の高いオブジェクトの移動制御、画像制御を実現できるようになる。
【００２６】
また本実施形態に係るゲームシステム、情報記憶媒体及びプログラムは、前記圧縮データを伸張することにより得られた伸張データを、インデックスカラー・テクスチャマッピング用のルックアップテーブルのインデックス番号として設定し、伸張データがインデックス番号として設定された前記ルックアップテーブルを用いて、仮想オブジェクトに対してインデックスカラー・テクスチャマッピングを行い、伸張データを前記第１のデータに設定することを特徴とする。このようにすれば、伸張データを第１のデータに設定する処理を、例えば１回のテクスチャマッピングで一括して行うことができるようになり、処理を効率化できる。
【００２７】
なお、仮想オブジェクトは、ポリゴンなどのプリミティブ面であることが望ましいが、立体的なオブジェクトであってもよい。また、仮想オブジェクトは画面上に表示しないことが望ましいが、表示するようにしてもよい。
【００２８】
また本実施形態は、圧縮された色データを伸張するデコード手段を有するゲームシステムに用いられる圧縮データについての生成方法であって、前記デコード手段の伸張処理の対象となる色データとは異なる第１のデータを色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成することを特徴とする。
【００２９】
本実施形態にすれば、色データとは異なる第１のデータを圧縮し、生成された圧縮データを、情報記憶媒体やネットワークを介してゲームシステムに読み込ませ、色データ用のデコード手段を用いて伸張させることなどが可能になる。
【００３０】
なお、第１のデータの圧縮をゲーム処理中にリアルタイムに行うようにしてもよい。
【００３１】
また本実施形態は、前記第１のデータがα値であり、画像データが含む色データを圧縮して、第１の圧縮データを生成すると共に、前記画像データが含むα値を色データに設定し圧縮して、第２の圧縮データを生成することを特徴とする。このようにすれば、色データのみならずα値についても色データとみなして圧縮できるようになり、圧縮データのデータ量をより少なくすることができるようになる。
【００３２】
また本実施形態は、前記第１のデータが、前記第１のデータの値に応じた階調の色データに設定されて圧縮されることを特徴とする。このようにすれば、その値が細かく変化する第１のデータについても適正に圧縮できるようになる。
【００３３】
また本実施形態は、前記第１のデータが、横方向及び縦方向の少なくとも一方のサイズが縮小された後に圧縮されることを特徴とする。このようにすれば、例えば第１のデータが、情報の劣化がそれほど問題にならないようなデータである場合に、圧縮データのデータ量をより少なくすることができるようになる。
【００３４】
また本実施形態は、前記第１のデータが、ヒットチェック用のデータ、オブジェクトの移動制御用のデータ、オブジェクトの画像制御用のデータ及び奥行き値のデータの少なくとも１つであることを特徴とする。このようにすれば、色データのみならず、ヒットチェック用のデータ、オブジェクトの移動制御用のデータ、オブジェクトの画像制御用のデータ、奥行き値のデータなどについてもコンパクトに圧縮できるようになる。
【００３５】
以下、本発明の好適な実施形態について図面を用いて説明する。
【００３６】
１．構成
図１に、本実施形態のゲームシステム（画像生成システム）の機能ブロック図の一例を示す。なお同図において本実施形態は、少なくとも処理部１００を含めばよく（或いは処理部１００と記憶部１７０を含めばよく）、それ以外のブロックについては任意の構成要素とすることができる。
【００３７】
操作部１６０は、プレーヤが操作データを入力するためのものであり、その機能は、レバー、ボタン、マイク、或いは筺体などのハードウェアにより実現できる。
【００３８】
記憶部１７０は、処理部１００や通信部１９６などのワーク領域となるもので、その機能はＲＡＭなどのハードウェアにより実現できる。
【００３９】
情報記憶媒体１８０（コンピュータにより使用可能な記憶媒体）は、プログラムやデータなどの情報を格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）などのハードウェアにより実現できる。処理部１００は、この情報記憶媒体１８０に格納される情報に基づいて本発明（本実施形態）の種々の処理を行う。即ち情報記憶媒体１８０には、本発明（本実施形態）の手段（特に処理部１００に含まれるブロック）をコンピュータに実現（実行、機能）させるためのプログラムが格納され、このプログラムは、１又は複数のモジュール（オブジェクト指向におけるオブジェクトも含む）を含む。
【００４０】
なお、情報記憶媒体１８０に格納される情報の一部又は全部は、システムへの電源投入時等に記憶部１７０に転送されることになる。また情報記憶媒体１８０には、本発明の処理を行うためのプログラム、画像データ、音データ、表示物の形状データ、本発明の処理を指示するための情報、或いはその指示に従って処理を行うための情報などを含ませることができる。
【００４１】
表示部１９０は、本実施形態により生成された画像を出力するものであり、その機能は、ＣＲＴ、ＬＣＤ、或いはＨＭＤ（ヘッドマウントディスプレイ）などのハードウェアにより実現できる。
【００４２】
音出力部１９２は、本実施形態により生成された音を出力するものであり、その機能は、スピーカなどのハードウェアにより実現できる。
【００４３】
携帯型情報記憶装置１９４は、プレーヤの個人データやゲームのセーブデータなどが記憶されるものであり、この携帯型情報記憶装置１９４としては、メモリカードや携帯型ゲーム装置などを考えることができる。
【００４４】
通信部１９６は、外部（例えばホスト装置や他のゲームシステム）との間で通信を行うための各種の制御を行うものであり、その機能は、各種プロセッサ、或いは通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。
【００４５】
なお本発明（本実施形態）の各手段を実現するためのプログラム（データ）は、ホスト装置（サーバー）が有する情報記憶媒体からネットワーク及び通信部１９６を介して情報記憶媒体１８０に配信するようにしてもよい。このようなホスト装置（サーバー）の情報記憶媒体の使用も本発明の範囲内に含まれる。
【００４６】
処理部１００（プロセッサ）は、操作部１６０からの操作データやプログラムなどに基づいて、ゲーム処理、画像生成処理、或いは音生成処理などの各種の処理を行う。この場合、処理部１００は、記憶部１７０内の主記憶部１７２をワーク領域として使用して、各種の処理を行う。
【００４７】
ここで、処理部１００が行うゲーム処理としては、コイン（代価）の受け付け処理、各種モードの設定処理、ゲームの進行処理、選択画面の設定処理、オブジェクト（１又は複数のプリミティブ面）の位置や回転角度（Ｘ、Ｙ又はＺ軸回り回転角度）を求める処理、オブジェクトを動作させる処理（モーション処理）、視点の位置（仮想カメラの位置）や視線角度（仮想カメラの回転角度）を求める処理、マップオブジェクトなどのオブジェクトをオブジェクト空間へ配置する処理、ヒットチェック処理、ゲーム結果（成果、成績）を演算する処理、複数のプレーヤが共通のゲーム空間でプレイするための処理、或いはゲームオーバー処理などを考えることができる。
【００４８】
また、処理部１００は、上記のゲーム処理結果に基づいて各種の画像処理を行い、ゲーム画像を生成し、表示部１９０に出力する。例えば、いわゆる３次元のゲーム画像を生成する場合には、まず、座標変換、クリッピング処理、透視変換、或いは光源計算等のジオメトリ処理が行われ、その処理結果に基づいて、描画データ（プリミティブ面の構成点（頂点）に付与される位置座標、テクスチャ座標、色（輝度）データ、法線ベクトル或いはα値等）が作成される。そして、この描画データ（プリミティブ面データ）に基づいて、ジオメトリ処理後のオブジェクト（１又は複数プリミティブ面）の画像が、描画バッファ１７４（フレームバッファ、ワークバッファ等のピクセル単位で画像情報を記憶できるバッファ）に描画される。これにより、オブジェクト空間内において所与の視点（仮想カメラ）から見える画像が生成されるようになる。
【００４９】
更に、処理部１００は、上記のゲーム処理結果に基づいて各種の音処理を行い、ＢＧＭ、効果音、又は音声などのゲーム音を生成し、音出力部１９２に出力する。
【００５０】
なお、処理部１００の機能は、より好適には、ハードウェア（ＣＰＵ、ＤＳＰ等のプロセッサ又はゲートアレイ等のＡＳＩＣ）とプログラム（ゲームプログラム又はファームウェア等）との組み合わせにより実現される。但し、処理部１００の機能の全てを、ハードウェアにより実現してもよいし、その全てをプログラムにより実現してもよい。
【００５１】
処理部１００は、デコード（伸張）部１１０、伸張データ処理部１２０、ヒットチェック部１２２、移動制御部１２４、画像制御部１２６、テクスチャマッピング部１３０、陰面消去部１３２、α合成部１３４を含む。
【００５２】
ここで、デコード部１１０は、ＪＰＥＧ、ＭＰＥＧ等の圧縮方法で圧縮された色データを伸張（展開）する処理を行う。
【００５３】
例えば、データ圧縮は以下のようにして実現できる。
【００５４】
即ち、まずデータが複数のマクロブロックに分割される。そして、分割された各ブロックに対して、ＤＣＴ（離散コサイン変換。広義には、アダマール変換、固有値変換等を含む直交変換）が施される。これにより、データが周波数（空間周波数）分解される。次に、ＤＣＴにより得られた各ＤＣＴ係数（広義には直交変換係数）が量子化される。そして、ハフマン符号化（エントロピー符号化、可変長符号化）が行われ、これにより圧縮データが得られる。
【００５５】
一方、データの伸張は以下のようにして実現できる。
【００５６】
即ち、まず圧縮データが情報記憶媒体１８０から読み込まれる。或いは、圧縮データがネットワーク（伝送ライン、通信回線）、通信部１９６を介して外部から読み込まれる。デコード部１１０は、この読み込まれた圧縮データに対してハフマン復号化（エントロピー復号化、可変長復号化）を行う。次に、デコード部１１０は、ハフマン復号化後のデータに対して逆量子化を行う。そして、逆ＤＣＴを行い、これにより伸張データが得られる。
【００５７】
なおＭＰＥＧ（ＭＰＥＧ２、ＭＰＥＧ４等）の場合に、例えば時間的相関関係を利用した予測符号化、予測復号化（動き補償フレーム間予測）を行ってもよい。
【００５８】
そして本実施形態では、元の画像データが含む色データ（例えばＲＧＢ）を圧縮することで生成された圧縮データ（ビットストリーム）をデコード部１１０を用いて伸張（展開）し、色データを得る。更に本実施形態では、元画像のデータが含むα値（広義には色データとは異なる第１のデータ）を色データに設定し圧縮することで生成された圧縮データ（ビットストリーム）を、色データ用のデコード部１１０を用いて伸張し、得られた伸張データをα値（第１のデータ）として設定する。このようにすることで、色データとは異なるα値（第１のデータ）についても、圧縮された状態で情報記憶媒体１８０に記憶したりネットワーク、通信部１９６を介して外部から読み込んだりすることができるようになる。
【００５９】
伸張データ処理部１２０は、デコード部１１０により得られた伸張データに対して種々の処理を施す。
【００６０】
例えば伸張データ処理部１２０は、色データ用のデコード部１１０により伸張されたデータをα値（第１のデータ）に設定して後段の処理に渡す。より具体的には、伸張データが含む色成分（赤、緑又は青）の階調（グレースケール）に応じた値に、α値（第１のデータ）を設定する。更に具体的には、伸張データが含む緑色成分をα値（第１のデータ）に設定する。
【００６１】
なお、伸張後のα値にノイズが重畳され、例えば０〜１２８内の値になるべきα値が１２９以上の値になる場合がある。このような場合には、α値の値を上限値（所与の値）にクランプ（クリッピング）する補正を行うことが望ましい。
【００６２】
また本実施形態では、横方向及び縦方向の少なくとも一方のサイズが縮小された後に圧縮されることで圧縮データが生成されている。そして伸張データ処理部１２０は、デコード部１１０により得られた伸張データの横方向及び縦方向の少なくとも一方のサイズ（描画バッファ１７４でのサイズ）を拡大し、元のサイズに戻す処理を行う。
【００６３】
ヒットチェック部１２２は、オブジェクト間のヒットチェック処理を行う。
【００６４】
キャラクタや車などのオブジェクトがマップ上で移動するゲームを例にとれば、ヒットチェック部１２２は、移動するキャラクタや車とマップ上の障害物（壁、建物等）とが衝突したか否かを判定し、キャラクタや車が障害物の中に入り込まないようにする。
【００６５】
また、プレーヤが標的キャラクタを狙ってショット（弾）をヒットさせるシューティングゲームや、キャラクタ同士でキックやパンチをヒットさせる格闘ゲームを例にとれば、ヒットチェック部１２２は、ショットやキックやパンチがキャラクタにヒットしたか否かを判定する。そして、ヒットした場合にはヒットによるダメージ量を計算し、キャラクタの体力パラメータを減少させたりキャラクタを消滅させたりするなどの処理を行う。
【００６６】
そして本実施形態では、このようなヒットチェックに使用するデータについても、色データとして圧縮しておき、ゲーム処理時に色データ用のデコード部１１０を用いて伸張するようにしている。
【００６７】
移動制御部１２４は、マップ上で移動するオブジェクト（移動体）の移動を制御する処理を行う。即ち、プレーヤが操作部１６０を用いて入力した操作データやマップの地形データなどに基づいて各フレームでのオブジェクトの加速度や速度を求め、各フレームでのオブジェクトの位置や回転角度（方向）を求める。例えば、ヒットチェック用のデータや移動制御用のデータがマップ上に設定されている場合には、オブジェクトの各位置におけるヒットチェック用データの値や移動制御用データの値を求め、求められたデータの値に基づいてオブジェクトの移動を制御する処理を行う。
【００６８】
そして本実施形態では、このようなヒットチェック用データ、移動制御用データについても、色データとして圧縮しておき、ゲーム処理時に色データ用のデコード部１１０を用いて伸張するようにしている。
【００６９】
画像制御部１２６は、マップ上で移動するオブジェクト（移動体）の画像を制御する処理を行う。即ち、オブジェクトのマップ上での位置に応じてオブジェクトの画像（色、輝度、α値、又はテクスチャ等）を変化させる。例えば、オブジェクトの画像制御用データがマップ上に設定されている場合には、オブジェクトの各位置における画像制御用データの値を求め、求められたデータの値に基づいてオブジェクトの画像を制御する処理を行う。
【００７０】
そして本実施形態では、このようなオブジェクトの画像制御用データについても、色データとして圧縮しておき、ゲーム処理時に色データ用のデコード部１１０を用いて伸張するようにしている。
【００７１】
テクスチャマッピング部１３０は、テクスチャ記憶部１７６に記憶されるテクスチャをオブジェクトにマッピングするための処理を行う。この場合、テクスチャマッピング部１３０は、ＬＵＴ記憶部１７８に記憶されるインデックスカラー・テクスチャマッピング用のＬＵＴ（ルックアップテーブル）を用いたテクスチャマッピングを行うことができる。
【００７２】
陰面消去部１３２は、例えば、以下のような手法により陰面消去処理を実現している。
【００７３】
即ち、移動オブジェクトの第２の奥行き値を所与のルーチン（アルゴリズム）により求める。そして、求められた移動オブジェクトの第２の奥行き値（移動オブジェクトを他のオブジェクト間に割り込ませるための奥行き値）と、他のオブジェクト（２次元オブジェクト、立体的に見えるように表現された表示物の２次元画像が描かれたプリミティブ面）の第１の奥行き値とに基づいて、移動オブジェクトの陰面消去を行う。
【００７４】
この場合、移動オブジェクトの第２の奥行き値は、例えば、移動オブジェクトの位置（移動オブジェクトの最下部に設定された代表点の位置）と、他のオブジェクトの下側境界線（下側境界線を所与の距離だけ延長した延長境界線）とに基づいて求めることが望ましい。また、移動オブジェクトの方向や移動履歴（移動経路、移動順序）を考慮して第２の奥行き値を求めてもよい。
【００７５】
なお、陰面消去部１３２が行う陰面消去は、例えば、奥行き値（描画プライオリティ値）に応じてオブジェクト（２次元オブジェクト、プリミティブ面）をソーティングし、視点から見て奥側から順にオブジェクトを描画する奥行きソート法（Ｚソート法）により実現してもよいし、ピクセル毎に奥行き値を比較し、視点から見て手前側のピクセルを描画する奥行き比較法（例えばＺバッファ１７９を用いたＺバッファ法等）により実現してもよい。
【００７６】
α合成部１３４は、α値を用いたα合成処理（αブレンディング、α加算又はα減算等）を行う。なお、α値（Ａ値）は、各ピクセルに関連づけられて記憶されるデータであり、例えば色データ（ＲＧＢ）以外のプラスアルファのデータである。α値は、半透明度（透明度又は不透明度と等価）、マスクデータ、バンプデータなどとして使用できる。
【００７７】
なお、本実施形態のゲームシステムは、１人のプレーヤのみがプレイできるシングルプレーヤモード専用のシステムにしてもよいし、このようなシングルプレーヤモードのみならず、複数のプレーヤがプレイできるマルチプレーヤモードも備えるシステムにしてもよい。
【００７８】
また複数のプレーヤがプレイする場合に、これらの複数のプレーヤに提供するゲーム画像やゲーム音を、１つの端末を用いて生成してもよいし、ネットワーク（伝送ライン、通信回線）などで接続された複数の端末（ゲーム機、携帯電話）を用いて生成してもよい。
【００７９】
２．本実施形態の特徴
次に本実施形態の特徴について図面を用いて説明する。
【００８０】
なお本発明の第１のデータはα値には限定されないが、説明を簡素化するために、以下では第１のデータがα値である場合を主に例にとり説明する。
【００８１】
２．１ 画像データの構造
図２に、本実施形態により生成されたゲーム画像の例を示す。
【００８２】
このゲーム画像は、図３のＦ１、Ｆ２、Ｆ３に示すような３つのパーツの絵により構成されている。Ｆ１は背景の絵であり、Ｆ２は木（図２の画面左において上から下に横切る木）の絵であり、Ｆ３はキャラクタ（登場人物）の絵である。
【００８３】
そして、図３のＦ２に示す木の絵の画像データは、図４のＧ１に示すような色データ（ＲＧＢ）とＧ２に示すようなα値のデータとにより構成されている。また図３のＦ３に示すキャラクタの絵の画像データは、図４のＧ３に示すような色データとＧ４に示すようなα値のデータとにより構成されている。
【００８４】
より具体的には図３のＦ２の木の絵は、図４のＧ１の色データとＧ２のα値とをテクセルデータとして持つテクスチャを、例えば板状のポリゴン（広義にはプリミティブ面）にマッピングすることで表現されている。同様に、図３のＦ３のキャラクタの絵は、図４のＧ３の色データとＧ４のα値とをテクセルデータとして持つテクスチャを、例えば板状のポリゴン（プリミティブ面）にマッピングすることで表現されている。
【００８５】
そして図４のＧ２、Ｇ４に示すように、木やキャラクタの輪郭の外側領域では、α値が透明に設定されており、木やキャラクタの輪郭の内側領域では、α値が不透明又は半透明に設定されている。これにより、図３のＦ２、Ｆ３に示すような木やキャラクタの絵を表現できる。また、例えば木やキャラクタの輪郭付近においてα値を透明から不透明に徐々に変化させることで、木やキャラクタの輪郭をぼやかすアンチエリアシングを実現でき、ジャギーの発生等を低減できる。
【００８６】
２．２ α値の圧縮
さて、例えば家庭用のゲームシステムなどにおいては、圧縮データを効率よく伸張するために、ＭＰＥＧ、ＪＰＥＧ用のデコード部を専用のハードウェアとして内蔵しているものもある。
【００８７】
ところが、この種のゲームシステムが有するデコード部は、色データ（ＲＧＢ）のみを伸張処理の対象としており、α値などの色データ以外のデータについては伸張処理の対象としていないのが一般的である。その理由は以下の通りである。
【００８８】
即ち、この種のゲームシステムが有するデコード部は、ゲームのオープニング、幕間、エンディングで表示されるＣＧムービー（ＣＧ画像）のデータを伸張するために設けられているのが通常である。そして、このようなＣＧムービーのデータは、α合成などのレンダリング処理が既に完了した後のデータ（いわゆるベタ絵のデータ）であり、α値などを含まない色データ（ＲＧＢ）だけのデータになっている。従って、デコード部は、色データだけを伸張できれば十分であり、α値などの色データ以外のデータを伸張できる構成にはなっていない。
【００８９】
また、ＭＰＥＧ、ＪＰＥＧ方式では一般的に色データを圧縮及び伸張処理の対象としているため、これらのＭＰＥＧ、ＪＰＥＧ方式でデータを伸張するデコード部も、沿革的に色データのみを伸張処理の対象とするようになっている。
【００９０】
以上のように、この種のゲームシステムが有するデコード部は色データのみを伸張処理の対象としているため、図４のＧ２、Ｇ４に示すようなα値などのデータについては伸張できない。従って、α値を圧縮して情報記憶媒体などに記憶しておくことができず、データの使用記憶容量を今一つ節約できないという課題があった。
【００９１】
このような課題を解決するために、本実施形態では次のような手法を採用している。
【００９２】
即ち、色データとは異なる第１のデータ（α値、ヒットチェック用データ、オブジェクトの移動制御用データ、オブジェクトの画像制御用データ又は奥行き値のデータ等）を色データに設定し圧縮することで生成された圧縮データを、例えば情報記憶媒体やネットワークから読み込む。そして、読み込まれた圧縮データをデコード部を用いて伸張し、得られた伸張データを第１のデータに設定し直す。そして、設定された第１のデータを用いて、画像を生成するための種々の処理（α合成、ヒットチェック、オブジェクトの移動制御又はオブジェクトの画像制御の処理等）を行う。
【００９３】
より具体的には図５に示すように、元画像データが含む色データをエンコード部で圧縮することで生成される圧縮データＣＰ１（ビットストリーム）と、元画像データが含むα値（広義には第１のデータ）を色データに設定してエンコード部で圧縮することで生成された圧縮データＣＰ２とを用意する。
【００９４】
そして、圧縮データＣＰ１をデコード部で伸張したデータＥＸ１に基づき色データを得る。また、圧縮データＣＰ２をデコード部で伸張したデータＥＸ２をα値に設定することで、α値を得る。そして、得られた色データとα値とを用いてα合成処理を行うことで、図２に示すようなゲーム画像を生成する。
【００９５】
このようにすることで、デコード部の伸張処理の対象とはならないα値（第１のデータ）についても、情報記憶媒体に圧縮して記憶しておくことができるようになる。従って、データの使用記憶容量を節約できるようになり、より高品質な画像を少ないデータ使用記憶容量で生成できる。
【００９６】
２．３ α値の設定手法
さて本実施形態では、デコード部で得られた伸張データが含む色成分の階調（グレースケール）に応じた値に、α値（第１のデータ）を設定したり、伸張データが含む緑色成分を、α値（第１のデータ）に設定するようにしている。
【００９７】
例えば図６のＨ１に示すように、圧縮対象となるα値が０〜２５５の範囲のデータであったとする。この場合には例えば図６のＨ２に示すように、α＝０の場合はＲ＝Ｇ＝Ｂ＝０、α＝１の場合にはＲ＝Ｇ＝Ｂ＝１、α＝２の場合にはＲ＝Ｇ＝Ｂ＝２、・・・・α＝２５５の場合にはＲ＝Ｇ＝Ｂ＝２５５というように、α値を、その各値に応じた階調の色データ（ＲＧＢ）に設定して圧縮しておく。なお、α値とＲ、Ｇ、Ｂの値を同じ値にする必要性はなく、例えばα＝１２８の時にＲ＝Ｇ＝Ｂ＝２５５となるような設定にしてもよい。
【００９８】
このようにして圧縮されたデータを伸張することにより図６のＨ３に示すような伸張データが得られた場合には、例えばＨ４に示すように伸張データが含む色成分の階調に応じた値にα値を設定する。より具体的にはＨ５に示すように、例えば、Ｇ＝０の場合にはα＝０、Ｇ＝１の場合にはα＝１、Ｇ＝２の場合にはα＝２、・・・・・・Ｇ＝２５５の場合にはα＝２５５というように、伸張データが含む緑（Ｇ）成分をα値に設定する。
【００９９】
即ち、ＭＰＥＧやＪＰＥＧなどの圧縮方式では、ＲＧＢ表現がＹＣｒＣｂ（ＹＵＶ）表現に変換され、輝度成分Ｙ、色差成分Ｃｒ（ＲとＹの色差）色差成分、Ｃｂ（ＢとＹの色差）は別々に圧縮される。そして、人間の目は、輝度の変化には敏感だが色差の変化にはそれほど敏感ではないという性質がある。従って、ＭＰＥＧやＪＰＥＧでは、色差成分Ｃｒ、Ｃｂに比べて輝度成分Ｙの符号量が多くなるように圧縮している。そして、ＲＧＢ表現からＹＣｒＣｂ表現への変換式はその一例として下式（１）のように表すことができる。
【０１００】
Ｙ ＝ ０．２９９×Ｒ＋０．５８７×Ｇ＋０．１１５×Ｂ
Ｃｒ＝ ０．５００×Ｒ−０．４１８×Ｇ−０．０８２×Ｂ （１）
Ｃｂ＝−０．１６９×Ｒ−０．３３１×Ｇ＋０．５００×Ｂ
上式（１）から明らかなように、輝度成分Ｙに対する寄与が一番大きいのはＧ（緑）成分である。従って、輝度成分Ｙの圧縮時の符号量が多いということは、Ｇ成分の情報の劣化が最も少ないということを意味する。
【０１０１】
従って、図６のＨ５に示すように、伸張データのＧ成分をα値に設定するようにすれば、圧縮・伸張に伴うα値の情報劣化を最小限に抑えることが可能になり、より高品質な画像を生成できるようになる。
【０１０２】
２．４ 横方向、縦方向のサイズのスケーリング
さて、α値などの色データ以外のデータでは、色データに要求されるような高い精度の情報は必要とされない。そこで本実施形態では、この点に着目して、以下のような手法を採用している。
【０１０３】
即ち図７に示すように、α値の横方向、縦方向のサイズ（横、縦のいずれか一方のサイズでもよいし、両方のサイズでもよい）を縮小した後にエンコード部で圧縮することで、α値についての圧縮データＣＰ２を生成しておく。
【０１０４】
そして、この圧縮データＣＰ２をデコード部で伸張した後、得られた伸張データＥＸ２の横方向、縦方向のサイズ（横、縦のいずれか一方のサイズでもよいし、両方のサイズでもよい）を拡大して元のサイズに戻すようにする。
【０１０５】
このようにすれば、圧縮・伸張に伴うα値の情報劣化は増えるものの、圧縮データＣＰ２のデータ量を大幅に低減できる。例えば、横方向、縦方向の縮小率を共に１／２にした場合には、圧縮データのデータ量を１／４にすることができる。
【０１０６】
そして、α値の情報が劣化しても、色データの情報が劣化する場合とは異なり、生成される画像の品質はそれほど劣化しない。従って、図７に示す手法を採用すれば、画質をそれほど劣化させることなく、データの使用記憶容量を節約できるという利点を得ることができる。
【０１０７】
２．５ ヒットチェック、移動制御、画像制御のデータの圧縮・伸張
さて、以上では、色データとして圧縮・伸張される第１のデータがα値である場合を例にとり説明したが、このような第１のデータとしては、ヒットチェック用データ、オブジェクトの移動制御用データ、オブジェクトの画像制御用データ、又は奥行き値（Ｚ値）などの種々のデータを考えることができる。
【０１０８】
２．５．１ ヒットチェック用データ
例えば図８（Ａ）に示すように、移動オブジェクト２０がマップ上を移動する場合には、壁、建物などの障害物２２、２４、２６（進入禁止領域）と移動オブジェクト２０とのヒットチェックを行う必要がある。
【０１０９】
このような場合に、ヒットチェック用データである、障害物の位置や形状等を特定するためのデータを、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データをヒットチェック用データとして設定し直すようにする。そして、移動オブジェクト２０の各位置におけるヒットチェック用データの値を求め、求められた値に基づいて移動オブジェクト２０と障害物２２、２４、２６とのヒットチェック処理（広義には移動制御処理）を行う。このようにすれば、データの使用記憶容量を節約しながら、移動オブジェクト２０と障害物２２、２４、２６との間の適正なヒットチェック処理を実現できるようになる。
【０１１０】
また、シューティングゲームや格闘ゲームにおいては、ショット（弾）やキックやパンチがキャラクタにヒットしたか否かを判別し、キャラクタのダメージ量を計算する必要がある。この場合に図８（Ｂ）に示すように、キャラクタ３０の各部位毎にダメージ量を異ならせ、例えば頭にショット等がヒットした場合にはダメージ量を大きくし、手や足にヒットした場合にはダメージ量を少なくする。
【０１１１】
このような場合に、ヒットチェック用データである、各部位でのダメージ量のデータを、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データをヒットチェック用データとして設定し直すようにする。このようにすれば、データの使用記憶容量を節約しながら、キャラクタ３０とショット等の間の適正でリアルなヒットチェック処理を実現できるようになる。
【０１１２】
２．５．２ 移動制御用データ
図８（Ｃ）に示すように移動オブジェクト２０がマップ上を移動する場合には、移動オブジェクト２０が移動する領域に応じた移動制御を移動オブジェクト２０に対して施すことが望ましい。例えば、移動オブジェクト２０が沼地３２（速度変化領域）に進入した場合には、移動オブジェクト２０の速度を減少させるようにする。
【０１１３】
このような場合に、移動オブジェクト２０の移動制御用データを、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データを移動制御用データとして設定し直すようにする。そして、移動オブジェクト２０の各位置における移動制御用データの値を求め、求められた値に基づいて移動オブジェクト２０の移動制御処理を行う。このようにすれば、データの使用記憶容量を節約しながら、移動オブジェクト２０のリアルな移動制御を実現できるようになる。
【０１１４】
なお、移動オブジェクトの移動制御用データとしては、移動オブジェクトの位置、速度、加速度又は方向等を制御するための種々のデータを考えることができる。
【０１１５】
２．５．３ 画像制御用データ
図９（Ａ）では、光源ベクトルＬＣがＥ１の方向に向いていると想定されており、この想定に沿うように木４２の影領域４０（シェーディング演算変更領域）がマップ上に設定されている。そして、移動オブジェクト２０がこの影領域４０に進入したと判定すると、移動オブジェクト２０に対するシェーディング演算を変更し、移動オブジェクト２０の陰影づけが全体的に暗くなるようにする。このようにすれば、移動オブジェクト２０の陰影づけを変えるか否かを、移動オブジェクト２０の位置が影領域４０内にあるか否かを判別するだけで判断できる。従って、移動オブジェクト２０の陰影づけを変えるか否かを、３次元立体データに基づいて判断する手法に比べて、処理負担を格段に軽減できる。
【０１１６】
このような場合に、移動オブジェクトの画像制御用データである、影領域４０の位置や形状等を特定するためのデータを、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データを、移動オブジェクト２０の画像制御用データとして設定し直すようにする。そして、移動オブジェクト２０の各位置における画像制御用データの値を求め、求められた値に基づいて移動オブジェクト２０の画像制御処理を行う。このようにすれば、少ないデータの使用記憶容量で、移動オブジェクト２０のリアルなシェーディング処理を実現できるようになる。
【０１１７】
なお、よりリアルな表現を実現するためには、影領域４０（シェーディング演算変更領域）に対してシェーディング演算パラメータを設定しておくことが望ましい。例えば図９（Ｂ）に示すように、影領域４０の頂点ＶＥ０、ＶＥ１、ＶＥ２、ＶＥ３に対して、各々、シェーディング演算パラメータの１つである輝度パラメータＩ０、Ｉ１、Ｉ２、Ｉ３を設定する。そして、これらの輝度パラメータＩ０〜Ｉ３に基づいて、移動オブジェクト２０のシェーディング演算に使用される輝度パラメータを求め、求められた輝度パラメータに基づいて移動オブジェクト２０に対するシェーディング演算を行うようにする。このようにすれば、図９（Ｂ）に示すように、移動オブジェクト２０に施される陰影づけを影領域４０の各場所において様々に変化させることができるようになり、よりリアルな陰影づけ表現が可能になる。
【０１１８】
そして、この場合には、このシェーディング演算パラメータ（輝度パラメータ）についても、移動オブジェクトの画像制御用データとして圧縮・伸張することが望ましい。
【０１１９】
なお、移動オブジェクトの画像制御用データとしては、移動オブジェクトの色、輝度、α値又はテクスチャ等を制御するための種々のデータを考えることができる。
【０１２０】
２．５．４ 奥行き値
さて、ゲームシステムでは、ゲームのオープニング、幕間、エンディングなどにおいて、プレーヤのゲーム意欲を盛り上げたりプレーヤの感動を高めるために、いわゆるムービー（動画）と呼ばれるものが再生される場合が多い。このムービーでは、ＣＧツールにより制作された映像や実写映像が再生されるため、ポリゴン（プリミティブ面）により構成された３次元オブジェクトをリアルタイムに動かすことで生成される画像に比べて、よりリアルで写実的な表現が可能になる。
【０１２１】
しかしながら、これまでのゲームシステムでは、ムービー再生のためのデータであるムービーデータが、色データ（ＲＧＢ）しか含まなかった。従って、例えばムービーとキャラクタなどの移動オブジェクトが合成された画像を生成しようとすると、キャラクタがムービーの手前に常に表示されるようになり、リアル感に欠ける画像が生成されてしまうという問題が生じる。
【０１２２】
そこで、このような問題を解決するために、本実施形態では、ムービー再生のためのデータであるムービーデータに奥行き値Ｚ１を含ませている。そして、この奥行き値Ｚ１とキャラクタ（広義には移動オブジェクト）の奥行き値Ｚ２とに基づいて陰面消去を行いながら、ムービーとキャラクタが合成された画像を生成する。
【０１２３】
より具体的には例えば図１０に示すように、ムービーを構成する各フレーム画像の各ピクセルに対して、色データ（ＲＧＢ）の他に、奥行き値Ｚ１のデータを含ませる。そして、このＺ１とキャラクタの奥行き値Ｚ２とを比較し、Ｚバッファ法などのアルゴリズムにしたがって陰面消去を行い、ムービーとキャラクタが合成された画像を生成する。
【０１２４】
このようにすることで図１１（Ａ）に示すように、ムービーの絵の中にキャラクタ３０を割り込ませることができるようになる。即ち、ムービーで表現されるタンス５０（表示物）の物陰にキャラクタ３０が隠れたり、ムービーで表現される出入り口５２からキャラクタが出て行くなどの画像表現が可能になる。或いは、ムービーで表現される窓５４の向こう側からキャラクタ３０が覗き込むなどの画像表現も可能になる。
【０１２５】
即ち、これまでのムービーでは、ムービーデータが色データしか含まず、奥行き値のデータを含まなかった。従って、ムービーとキャラクタの合成画像を生成しようとすると、図１１（Ｂ）に示すようにキャラクタ３０が常に手前に表示されるようになってしまい、リアルが画像を生成できなかった。
【０１２６】
本実施形態によれば、図１１（Ａ）に示すように、キャラクタ３０の奥行き値Ｚ２の大きさに応じて、キャラクタ３０がムービーの中の表示物の物陰に隠れたり、隠れなかったりするようになるため、よりリアルで臨場感溢れる画像を生成できる。
【０１２７】
そして本実施形態では、図１０に示すような奥行き値Ｚ１を、図５等の手法により、色データとして圧縮しておき、ゲーム処理時にデコード部を用いて伸張し、伸張データを奥行き値Ｚ１として設定し直すようにする。このようにすれば、ムービーを構成する色データのみならず奥行き値Ｚ１についても、圧縮して情報記憶媒体に記憶しておくことができるようになる。従って、データの使用記憶容量を節約しながらも、キャラクタがムービーの中の表示物の物陰に隠れたりするようなリアルな画像を生成できるようになる。
【０１２８】
なお、本実施形態で圧縮・伸張の対象となる奥行き値は、図１０のようにムービーに関連づけられた奥行き値であることが特に望ましいが、これに限定されない。
【０１２９】
また、本実施形態におけるムービーは、ＣＧツールで制作した一連のセル画像により構成されるＣＧ映像でもよいし、カメラにより撮影した実写映像でもよい。
【０１３０】
ムービーとしてＣＧ映像を用いる場合には、ＣＧの作成時に生じた各ピクセルの奥行き値のデータを破棄せずにムービーデータの中に含ませるようにする。即ち、ＣＧツールのＺバッファに記憶される最終的な奥行き値のデータは、通常は破棄されるが、これを破棄せずに、色データ（ＲＧＢ）と共にムービーデータの中に含ませるようにする。このようにすることで、奥行き値のデータを含むムービーデータを、それほど手間をかけることなく用意することができるようになる。
【０１３１】
また、奥行き値は、全てのフレーム画像に設定しもよいし、一部のフレーム画像にのみ設定しもよい。また、奥行き値は、ムービーを構成するフレーム画像の全てのピクセルに対して設定しもよいし、一部のピクセルにのみ設定してもよい。
【０１３２】
また、ムービーは、図１１（Ａ）のように背景として用いてもよいが、敵ボス（移動オブジェクト）などの表現に用いてもよい。この場合には例えば、ムービー表示のための仮想的なスクリーンを用意し、この仮想スクリーンに、敵ボスのムービーを投影するようにする。或いは、ムービー表示のためのポリゴン（プリミティブ面）を用意し、ムービーをテクスチャとしてこのポリゴンにマッピングするようにしてもよい。
【０１３３】
２．６ インデックスカラーテクスチャマッピングの利用
さて、図５の圧縮データＣＰ２の伸張データＥＸ２をα値などの第１のデータに設定する処理は、例えば、インデックスカラー・テクスチャマッピングを利用した手法により実現することができる。
【０１３４】
インデックスカラーテクスチャーマッピングでは、テクスチャ記憶部の使用記憶容量を節約するために、図１２のＡ１に示すように、実際の色データ（ＲＧＢ）ではなくインデックス番号が、テクスチャの各テクセルに関連づけて記憶される。また、図１２のＡ２に示すように、インデックスカラー・テクスチャマッピング用のルックアップテーブルＬＵＴ（カラーパレット）には、インデックス番号により指定される色データやα値が記憶される。そして、オブジェクトに対してテクスチャマッピングを行う際には、テクスチャの各テクセルのインデックス番号に基づいてＬＵＴを参照し、対応する色データやα値をＬＵＴから読み出し、読み出された色データとα値に基づいて、フレームバッファに画像を描画する。
【０１３５】
このようなインデックスカラーモードのテクスチャマッピングでは、ＬＵＴを用いない通常モードのテクスチャマッピングに比べて、使用できる色数は少なくなる（例えば１６色）。しかしながら、テクスチャ記憶部に実際の色データ（例えば１６ビット）を記憶する必要が無くなるため、テクスチャ記憶部の使用記憶容量を大幅に節約できる。
【０１３６】
本実施形態は、このようなインデックスカラー・テクスチャマッピングを通常とは異なる形態で利用する。
【０１３７】
即ち、まず図１３のＢ１に示すように、伸張データが含むＧプレーン（他の色成分でもよい）の各ピクセルの色データを、ルックアップテーブルＬＵＴのインデックス番号として設定する（インデックス番号とみなす）。そしてＢ２に示すように、伸張データのＧプレーンの色データがインデックス番号として設定されたＬＵＴを用いて、仮想オブジェクトに対してインデックスカラー・テクスチャマッピングを行い、Ｇプレーンの色データをα値（αＯＵＴ）に変換して、フレームバッファ等に描画する。このようにすれば、Ｇプレーンの色データを、例えば１回のテクスチャマッピングで一括してα値に変換できるようになり、処理の効率化を図れる。
【０１３８】
しかも、インデックスカラー・テクスチャマッピングは、この種のゲームシステムが有する専用のハードウェアである描画プロセッサ（描画部）により高速に実行される。従って、Ｇプレーンの色データをα値に設定（変換）する処理を高速化できるようになる。
【０１３９】
なお、図１３では表示画面サイズのポリゴン（仮想オブジェクト）にテクスチャマッピングすることで、α値の設定処理を実現しているが、表示画面を分割したブロックのサイズのポリゴンにテクスチャマッピングするようにしてもよい。
【０１４０】
即ち、図１４のＣ１に示すように、フレームバッファ（表示画面）を複数のブロックに分割し、Ｃ２に示すように、各ブロックの色データを、ＬＵＴを用いて分割ブロックサイズのポリゴンにテクスチャマッピングする。
【０１４１】
このようにすれば、例えばテクスチャマッピングされたポリゴンをワークバッファ（別バッファ）に一時的に描画するような場合に、ＶＲＡＭ上でのワークバッファの占有領域を小さくできる。
【０１４２】
即ち、図１３のように表示画面サイズのポリゴンにテクスチャマッピングすると、この表示画面サイズのポリゴンを一時的に描画するために、表示画面サイズのワークバッファをＶＲＡＭ上に確保しなければならず、他の処理に支障を来すおそれがある。
【０１４３】
図１４のように、分割ブロックサイズのポリゴンにテクスチャマッピングするようにすれば、ＶＲＡＭ上には分割ブロックサイズのワークバッファを用意すれば済むため、ワークバッファの占有領域を小さくできる。従って、限られたハードウェア資源を有効利用することが可能になる。
【０１４４】
３．本実施形態の処理
次に、本実施形態の処理の詳細例について、図１５、図１６のフローチャートを用いて説明する。
【０１４５】
図１５は、圧縮時の処理についてのフローチャートである。
【０１４６】
まず、図１７に示すように、α付きの元画像データＩＯＲに基づき、ＩＯＲのＲＧＢプレーン（色データ）からなる画像データＩＣと、ＲＧＢプレーンが元画像データＩＯＲのαプレーンに置き換えられた画像データＩα（Ｒ＝Ｇ＝Ｂ＝α）を作成する（ステップＳ１）。
【０１４７】
次に、横（幅）方向、縦（高さ）方向の縮小率をＳＸ、ＳＹとした場合に（０．０＜ＳＸ＜１．０、０．０＜ＳＹ＜１．０）、ステップＳ１で得られた画像データＩαを横方向、縦方向にＳＸ倍、ＳＹ倍に縮小して、画像データＩαＲを生成する（ステップＳ２）。
【０１４８】
そして、ステップＳ１で得られた画像データＩＣと、ステップＳ２で得られた画像データＩαＲの各々を、ＭＰＥＧ、ＪＰＥＧ方式等で圧縮し、ビットストリームＢＣ、ＢαＲを生成する（ステップＳ３）。そして、このようにして生成されたビットストリームＢＣ、ＢαＲは、ゲームプログラムやゲームデータなどが格納される情報記憶媒体に書き込まれることになる（ネットワークを介して配信してもよい）。
【０１４９】
図１６は、伸張時の処理についてのフローチャートである。
【０１５０】
まず、図１８に示すように、図１５のステップＳ３で得られたビットストリームＢＣ、ＢαＲを伸張（展開）して、画像データＩＣ’、ＩαＲ’を得る（ステップＳ１１）。
【０１５１】
次に、図１５のステップＳ２で行ったスケーリングでの横方向、縦方向の縮小率をＳＸ、ＳＹとした場合に、画像データＩαＲ’を横方向、縦方向に１．０／ＳＸ倍、１．０／ＳＹ倍に拡大して、画像データＩα’を生成する（ステップＳ１２）。
【０１５２】
そして、ステップＳ１２で得られた画像データＩα’のＧ（緑）プレーンをαプレーンに設定し、このαプレーンと画像データＩＣ’のＲＧＢプレーンとにより、α付きの画像データＩＯＲ’を得る（ステップＳ１３）。そして、この画像データＩＯＲ’に基づいてα合成処理などが行われ、図２に示すようなゲーム画像が生成されることになる。
【０１５３】
４．ハードウェア構成
次に、本実施形態を実現できるハードウェアの構成の一例について図１９を用いて説明する。
【０１５４】
メインプロセッサ９００は、ＣＤ９８２（情報記憶媒体）に格納されたプログラム、通信インターフェース９９０を介して転送されたプログラム、或いはＲＯＭ９５０（情報記憶媒体の１つ）に格納されたプログラムなどに基づき動作し、ゲーム処理、画像処理、音処理などの種々の処理を実行する。
【０１５５】
コプロセッサ９０２は、メインプロセッサ９００の処理を補助するものであり、高速並列演算が可能な積和算器や除算器を有し、マトリクス演算（ベクトル演算）を高速に実行する。例えば、オブジェクトを移動させたり動作（モーション）させるための物理シミュレーションに、マトリクス演算などの処理が必要な場合には、メインプロセッサ９００上で動作するプログラムが、その処理をコプロセッサ９０２に指示（依頼）する。
【０１５６】
ジオメトリプロセッサ９０４は、座標変換、透視変換、光源計算、曲面生成などのジオメトリ処理を行うものであり、高速並列演算が可能な積和算器や除算器を有し、マトリクス演算（ベクトル演算）を高速に実行する。例えば、座標変換、透視変換、光源計算などの処理を行う場合には、メインプロセッサ９００で動作するプログラムが、その処理をジオメトリプロセッサ９０４に指示する。
【０１５７】
データ伸張プロセッサ９０６は、圧縮された画像データや音データを伸張するデコード処理を行ったり、メインプロセッサ９００のデコード処理をアクセレートする処理を行う。これにより、オープニング画面、インターミッション画面、エンディング画面、或いはゲーム画面などにおいて、ＭＰＥＧ方式等で圧縮された動画像を表示できるようになる。なお、デコード処理の対象となる画像データや音データは、ＲＯＭ９５０、ＣＤ９８２に格納されたり、或いは通信インターフェース９９０を介して外部から転送される。
【０１５８】
描画プロセッサ９１０は、ポリゴンや曲面などのプリミティブ面で構成されるオブジェクトの描画（レンダリング）処理を高速に実行するものである。オブジェクトの描画の際には、メインプロセッサ９００は、ＤＭＡコントローラ９７０の機能を利用して、オブジェクトデータを描画プロセッサ９１０に渡すと共に、必要であればテクスチャ記憶部９２４にテクスチャを転送する。すると、描画プロセッサ９１０は、これらのオブジェクトデータやテクスチャに基づいて、Ｚバッファなどを利用した陰面消去を行いながら、オブジェクトをフレームバッファ９２２に高速に描画する。また、描画プロセッサ９１０は、αブレンディング（半透明処理）、デプスキューイング、ミップマッピング、フォグ処理、バイリニア・フィルタリング、トライリニア・フィルタリング、アンチエリアシング、シェーディング処理なども行うことができる。そして、１フレーム分の画像がフレームバッファ９２２に書き込まれると、その画像はディスプレイ９１２に表示される。
【０１５９】
サウンドプロセッサ９３０は、多チャンネルのＡＤＰＣＭ音源などを内蔵し、ＢＧＭ、効果音、音声などの高品位のゲーム音を生成する。生成されたゲーム音は、スピーカ９３２から出力される。
【０１６０】
ゲームコントローラ９４２からの操作データや、メモリカード９４４からのセーブデータ、個人データは、シリアルインターフェース９４０を介してデータ転送される。
【０１６１】
ＲＯＭ９５０にはシステムプログラムなどが格納される。なお、業務用ゲームシステムの場合には、ＲＯＭ９５０が情報記憶媒体として機能し、ＲＯＭ９５０に各種プログラムが格納されることになる。なお、ＲＯＭ９５０の代わりにハードディスクを利用するようにしてもよい。
【０１６２】
ＲＡＭ９６０は、各種プロセッサの作業領域として用いられる。
【０１６３】
ＤＭＡコントローラ９７０は、プロセッサ、メモリ（ＲＡＭ、ＶＲＡＭ、ＲＯＭ等）間でのＤＭＡ転送を制御するものである。
【０１６４】
ＣＤドライブ９８０は、プログラム、画像データ、或いは音データなどが格納されるＣＤ９８２（情報記憶媒体）を駆動し、これらのプログラム、データへのアクセスを可能にする。
【０１６５】
通信インターフェース９９０は、ネットワークを介して外部との間でデータ転送を行うためのインターフェースである。この場合に、通信インターフェース９９０に接続されるネットワークとしては、通信回線（アナログ電話回線、ＩＳＤＮ）、高速シリアルバスなどを考えることができる。そして、通信回線を利用することでインターネットを介したデータ転送が可能になる。また、高速シリアルバスを利用することで、他のゲームシステムとの間でのデータ転送が可能になる。
【０１６６】
なお、本発明の各手段は、その全てを、ハードウェアのみにより実現（実行）してもよいし、情報記憶媒体に格納されるプログラムや通信インターフェースを介して配信されるプログラムのみにより実現してもよい。或いは、ハードウェアとプログラムの両方により実現してもよい。
【０１６７】
そして、本発明の各手段をハードウェアとプログラムの両方により実現する場合には、情報記憶媒体には、本発明の各手段をハードウェアを利用して実現するためのプログラムが格納されることになる。より具体的には、上記プログラムが、ハードウェアである各プロセッサ９０２、９０４、９０６、９１０、９３０等に処理を指示すると共に、必要であればデータを渡す。そして、各プロセッサ９０２、９０４、９０６、９１０、９３０等は、その指示と渡されたデータとに基づいて、本発明の各手段を実現することになる。
【０１６８】
図２０（Ａ）に、本実施形態を業務用ゲームシステムに適用した場合の例を示す。プレーヤは、ディスプレイ１１００上に映し出されたゲーム画像を見ながら、レバー１１０２、ボタン１１０４等を操作してゲームを楽しむ。内蔵されるシステムボード（サーキットボード）１１０６には、各種プロセッサ、各種メモリなどが実装される。そして、本発明の各手段を実現するためのプログラム（データ）は、システムボード１１０６上の情報記憶媒体であるメモリ１１０８に格納される。以下、このプログラムを格納プログラム（格納情報）と呼ぶ。
【０１６９】
図２０（Ｂ）に、本実施形態を家庭用のゲームシステムに適用した場合の例を示す。プレーヤはディスプレイ１２００に映し出されたゲーム画像を見ながら、ゲームコントローラ１２０２、１２０４を操作してゲームを楽しむ。この場合、上記格納プログラム（格納情報）は、本体システムに着脱自在な情報記憶媒体であるＣＤ１２０６、或いはメモリカード１２０８、１２０９等に格納されている。
【０１７０】
図２０（Ｃ）に、ホスト装置１３００と、このホスト装置１３００とネットワーク１３０２（ＬＡＮのような小規模ネットワークや、インターネットのような広域ネットワーク）を介して接続される端末１３０４-1〜１３０４-n（ゲーム機、携帯電話）とを含むシステムに本実施形態を適用した場合の例を示す。この場合、上記格納プログラム（格納情報）は、例えばホスト装置１３００が制御可能な磁気ディスク装置、磁気テープ装置、メモリ等の情報記憶媒体１３０６に格納されている。端末１３０４-1〜１３０４-nが、スタンドアロンでゲーム画像、ゲーム音を生成できるものである場合には、ホスト装置１３００からは、ゲーム画像、ゲーム音を生成するためのゲームプログラム等が端末１３０４-1〜１３０４-nに配送される。一方、スタンドアロンで生成できない場合には、ホスト装置１３００がゲーム画像、ゲーム音を生成し、これを端末１３０４-1〜１３０４-nに伝送し端末において出力することになる。
【０１７１】
なお、図２０（Ｃ）の構成の場合に、本発明の各手段を、ホスト装置（サーバー）と端末とで分散して実現するようにしてもよい。また、本発明の各手段を実現するための上記格納プログラム（格納情報）を、ホスト装置（サーバー）の情報記憶媒体と端末の情報記憶媒体に分散して格納するようにしてもよい。
【０１７２】
またネットワークに接続する端末は、家庭用ゲームシステムであってもよいし業務用ゲームシステムであってもよい。そして、業務用ゲームシステムをネットワークに接続する場合には、業務用ゲームシステムとの間で情報のやり取りが可能であると共に家庭用ゲームシステムとの間でも情報のやり取りが可能なセーブ用情報記憶装置（メモリカード、携帯型ゲーム装置）を用いることが望ましい。
【０１７３】
なお本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。
【０１７４】
例えば、本発明の圧縮又は伸張処理の対象となる第１のデータは、本実施形態で説明したようなデータが特に望ましいが、これに限定されるものではなく、例えば、ピクセル（テクセルも含む）に関連づけて設定される種々のデータをその対象とすることができる。
【０１７５】
また、伸張データを第１のデータに設定する処理は、インデックスカラー・テクスチャマッピングを利用して実現してもよいし、伸張データの各ピクセル（テクセル）のデータ（例えばＧ成分の色データ）を１つずつ第１のデータ（例えば当該ピクセルでのα値）に設定するソフトウェア処理により実現してもよい。
【０１７６】
また、本発明は、取り込んだ動画像をオブジェクトにそのままマッピングするムービーテクスチャのα値（広義には第１のデータ）の圧縮・伸張などにも適用できる。
【０１７７】
また、本発明のデコード部はハードウェアで実現してもよいし、ソフトウェアで実現してもよい。
【０１７８】
また、本発明のうち従属請求項に係る発明においては、従属先の請求項の構成要件の一部を省略する構成とすることもできる。また、本発明の１の独立請求項に係る発明の要部を、他の独立請求項に従属させることもできる。
【０１７９】
また、本発明は種々のゲーム（格闘ゲーム、シューティングゲーム、ロボット対戦ゲーム、スポーツゲーム、競争ゲーム、ロールプレイングゲーム、音楽演奏ゲーム、ダンスゲーム等）に適用できる。
【０１８０】
また本発明は、業務用ゲームシステム、家庭用ゲームシステム、多数のプレーヤが参加する大型アトラクションシステム、シミュレータ、マルチメディア端末、ゲーム画像を生成するシステムボード等の種々のゲームシステム（画像生成システム）に適用できる。
【符号の説明】
【０１８１】
２０ 移動オブジェクト
２２、２４、２６ 障害物（進入禁止領域）
３０ キャラクタ
３２ 沼地（速度変化領域）
４０ 影領域（シェーディング演算変更領域）
１００ 処理部
１１０ デコード（伸張）部
１２０ 伸張データ処理部
１２２ ヒットチェック部
１２４ 移動制御部
１２６ 画像制御部
１３０ テクスチャマッピング部
１３２ 陰面消去部
１３４ α合成部
１６０ 操作部
１７０ 記憶部
１７２ 主記憶部
１７４ 描画バッファ
１７６ テクスチャ記憶部
１７８ ＬＵＴ記憶部
１７９ Ｚバッファ
１８０ 情報記憶媒体
１９０ 表示部
１９２ 音出力部
１９４ 携帯型情報記憶装置
１９６ 通信部
【特許請求の範囲】
【請求項１】
圧縮された色データを伸張するデコード手段を有するゲームシステムであって、
色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを第１のデータに設定する伸長データ処理手段と、
設定された第１のデータを用いて、画像を生成するための所与の処理を行う手段とを含み、
前記第１のデータが、奥行き値であることを特徴とするゲームシステム。
【請求項２】
請求項１において、
前記所与の処理を行う手段が、
設定された奥行き値に基づき陰面消去を行うことを特徴とするゲームシステム。
【請求項３】
請求項２において、
前記伸長データ処理手段が、
ムービーデータが含む奥行き値を色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを奥行き値に設定し、
前記所与の処理を行う手段が、
設定された奥行き値と、移動オブジェクトの奥行き値とに基づいて陰面消去を行い、ムービーと移動オブジェクトが合成された画像を生成することを特徴とするゲームシステム。
【請求項４】
コンピュータ読み取り可能な情報記憶媒体であって、
色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データを、圧縮された色データを伸張するデコード手段を用いて伸張し、得られた伸張データを第１のデータに設定する伸長データ処理手段と、
設定された第１のデータを用いて、画像を生成するための所与の処理を行う手段としてコンピュータを機能させるためのプログラムを記憶し、
前記第１のデータが、奥行き値のデータであることを特徴とする情報記憶媒体。
【請求項５】
請求項４において、
前記所与の処理を行う手段が、
設定された奥行き値に基づき陰面消去を行うことを特徴とする情報記憶媒体。
【請求項６】
請求項５において、
前記伸長データ処理手段が、
ムービーデータが含む奥行き値を色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを奥行き値に設定し、
前記所与の処理を行う手段が、
設定された奥行き値と、移動オブジェクトの奥行き値とに基づいて陰面消去を行い、ムービーと移動オブジェクトが合成された画像を生成することを特徴とする情報記憶媒体。
【請求項７】
圧縮された色データを伸張するデコード手段を有するゲームシステムに用いられる圧縮データについての生成方法であって、
前記デコード手段の伸張処理の対象となる色データとは異なる第１のデータを色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成し、
前記第１のデータが、奥行き値のデータであることを特徴とする圧縮データの生成方法。
【請求項８】
請求項７において、
ムービーデータが含む奥行き値を色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成することを特徴とする圧縮データの生成方法。
【請求項１】
圧縮された色データを伸張するデコード手段を有するゲームシステムであって、
色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを第１のデータに設定する伸長データ処理手段と、
設定された第１のデータを用いて、画像を生成するための所与の処理を行う手段とを含み、
前記第１のデータが、奥行き値であることを特徴とするゲームシステム。
【請求項２】
請求項１において、
前記所与の処理を行う手段が、
設定された奥行き値に基づき陰面消去を行うことを特徴とするゲームシステム。
【請求項３】
請求項２において、
前記伸長データ処理手段が、
ムービーデータが含む奥行き値を色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを奥行き値に設定し、
前記所与の処理を行う手段が、
設定された奥行き値と、移動オブジェクトの奥行き値とに基づいて陰面消去を行い、ムービーと移動オブジェクトが合成された画像を生成することを特徴とするゲームシステム。
【請求項４】
コンピュータ読み取り可能な情報記憶媒体であって、
色データとは異なる第１のデータを色データに設定し圧縮することで生成された圧縮データを、圧縮された色データを伸張するデコード手段を用いて伸張し、得られた伸張データを第１のデータに設定する伸長データ処理手段と、
設定された第１のデータを用いて、画像を生成するための所与の処理を行う手段としてコンピュータを機能させるためのプログラムを記憶し、
前記第１のデータが、奥行き値のデータであることを特徴とする情報記憶媒体。
【請求項５】
請求項４において、
前記所与の処理を行う手段が、
設定された奥行き値に基づき陰面消去を行うことを特徴とする情報記憶媒体。
【請求項６】
請求項５において、
前記伸長データ処理手段が、
ムービーデータが含む奥行き値を色データに設定し圧縮することで生成された圧縮データを、前記デコード手段を用いて伸張し、得られた伸張データを奥行き値に設定し、
前記所与の処理を行う手段が、
設定された奥行き値と、移動オブジェクトの奥行き値とに基づいて陰面消去を行い、ムービーと移動オブジェクトが合成された画像を生成することを特徴とする情報記憶媒体。
【請求項７】
圧縮された色データを伸張するデコード手段を有するゲームシステムに用いられる圧縮データについての生成方法であって、
前記デコード手段の伸張処理の対象となる色データとは異なる第１のデータを色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成し、
前記第１のデータが、奥行き値のデータであることを特徴とする圧縮データの生成方法。
【請求項８】
請求項７において、
ムービーデータが含む奥行き値を色データに設定し圧縮して、ゲームシステムに用いられる圧縮データを生成することを特徴とする圧縮データの生成方法。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【公開番号】特開２０１０−２１８５７０（Ｐ２０１０−２１８５７０Ａ）
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願番号】特願２０１０−１０６５４４（Ｐ２０１０−１０６５４４）
【出願日】平成２２年５月６日（２０１０．５．６）
【分割の表示】特願２０００−２８４９８５（Ｐ２０００−２８４９８５）の分割
【原出願日】平成１２年９月２０日（２０００．９．２０）
【出願人】（０００１３４８５５）株式会社バンダイナムコゲームス (1,157)
【Ｆターム（参考）】
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願日】平成２２年５月６日（２０１０．５．６）
【分割の表示】特願２０００−２８４９８５（Ｐ２０００−２８４９８５）の分割
【原出願日】平成１２年９月２０日（２０００．９．２０）
【出願人】（０００１３４８５５）株式会社バンダイナムコゲームス (1,157)
【Ｆターム（参考）】
[ Back to top ]