(57)【要約】【課題】リプレイデータの量を抑えることができる画像生成システム等の提供。【解決手段】ゲームコントローラからの入力値データを圧縮してリプレイデータとして記憶する。今回と前回にサンプリングされた入力値データの差分値を演算し、絶対値が基準差分値幅よりも小さい差分値は、差分値とその連続数をペアにして符号化し、絶対値が基準差分値幅よりも大きい差分値は、連続数をペアにせずに差分値を符号化する。今回のサンプリングでの差分値の絶対値が基準差分値幅よりも小さく、今回と前回のサンプリングでの差分値が等しい場合、符号化処理を行うことなく差分値の連続数をインクリメントし、それ以外の場合に符号化処理を行う。差分値の連続数Ｎが所定数Ｋよりも大きい場合に、差分値とＫをペアにした符号化処理を行い、連続数をＮ−Ｋに設定する。リプレイデータとして入力値データと入力種データを書き込み、リプレイ処理を行う。【選択図】　　　　図１１
2004141352.tif 000002
【特許請求の範囲】
【請求項１】
画像生成を行う画像生成システムであって、
リプレイデータを記憶するリプレイデータ記憶部と、
ゲームコントローラにより入力された入力値データを圧縮し、圧縮後の入力値データをリプレイデータとして前記リプレイデータ記憶部に書き込むリプレイデータ書き込み部とを含み、
前記リプレイデータ書き込み部が、
今回にサンプリングされた入力値データと前回にサンプリングされた入力値データの差分値を演算し、その絶対値が基準差分値幅よりも小さい差分値については、差分値とその連続数をペアにした符号化処理を行い、その絶対値が基準差分値幅よりも大きい差分値については、連続数をペアにすることなく差分値の符号化処理を行うことを特徴とする画像生成システム。
【請求項２】
請求項１において、
前記リプレイデータ書き込み部が、
今回のサンプリングでの差分値の絶対値が基準差分値幅よりも小さく、且つ、今回のサンプリングでの差分値と前回のサンプリングでの差分値とが等しい場合には、符号化処理を行うことなく差分値の連続数をインクリメントし、
今回のサンプリングでの差分値の絶対値が基準差分値幅よりも大きい場合、又は、今回のサンプリングでの差分値と前回のサンプリングでの差分値とが等しくない場合に、符号化処理を行うことを特徴とする画像生成システム。
【請求項３】
請求項１又は２において、
前記リプレイデータ書き込み部が、
差分値の連続数Ｎが所定数Ｋよりも大きい場合には、その差分値と所定数Ｋをペアにした符号化処理を行い、その差分値についての連続数をＮ−Ｋに設定することを特徴とする画像生成システム。
【請求項４】
請求項１乃至３のいずれかにおいて、
リプレイデータ記憶部から読み出したリプレイデータに基づいて、リプレイ画像生成のためのリプレイ処理を行うリプレイ処理部を含み、
前記リプレイデータ書き込み部が、
ゲームコントローラにより入力された入力値データと、その入力値データの入力デバイス及び入力モードの少なくとも一方を特定するための入力種データとを圧縮して、リプレイデータとしてリプレイデータ記憶部に書き込み、
前記リプレイ処理部が、
リプレイデータ記憶部から、リプレイデータである入力値データと入力種データを読み出し、読み出した入力値データと入力種データを伸長し、伸長後の入力値データと入力種データに基づいて、リプレイ処理を行うことを特徴とする画像生成システム。
【請求項５】
請求項４において、
前記リプレイデータ書き込み部が、
入力種データを、入力値データの圧縮方式と同一の圧縮方式で圧縮することを特徴とする画像生成システム。
【請求項６】
請求項４又は５において、
前記リプレイデータ書き込み部が、
ゲームコントローラの種類、及びゲームコントローラのキー・コンフィギュレーション設定の少なくとも一方に基づいて、入力種データを求めることを特徴とする画像生成システム。
【請求項７】
請求項４乃至６のいずれかにおいて、
ゲームコントローラにより入力された入力値データに基づいてゲーム画像生成のためのゲーム処理を行うゲーム処理部を含み、
前記ゲーム処理部が、
ゲームコントローラにより入力された入力値データの入力種が第１の入力種である場合には、入力値データに対して第１の変換処理を行って、ゲーム処理を行い、
ゲームコントローラにより入力された入力値データの入力種が第２の入力種である場合には、入力値データに対して変換処理を行わずに或いは第２の変換処理を行って、ゲーム処理を行い、
前記リプレイ処理部が、
リプレイデータの入力種データが第１の入力種のデータである場合には、入力値データに対して前記第１の変換処理を行って、リプレイ処理を行い、
リプレイデータの入力種データが第２の入力種のデータである場合には、入力値データに対して変換処理を行わずに或いは前記第２の変換処理を行って、リプレイ処理を行うことを特徴とする画像生成システム。
【請求項８】
請求項７において、
第１の入力種により特定される入力モードが、入力値データのビット長が短い第１の入力モードであり、
第２の入力種により特定される入力モードが、入力値データのビット長が長い第２の入力モードであり、
前記第１、第２の変換処理が、入力値データの平滑化処理であることを特徴とする画像生成システム。
【請求項９】
画像を生成するためのプログラムであって、
リプレイデータを記憶するリプレイデータ記憶部と、
ゲームコントローラにより入力された入力値データを圧縮し、圧縮後の入力値データをリプレイデータとして前記リプレイデータ記憶部に書き込むリプレイデータ書き込み部としてコンピュータを機能させ、
前記リプレイデータ書き込み部が、
今回にサンプリングされた入力値データと前回にサンプリングされた入力値データの差分値を演算し、その絶対値が基準差分値幅よりも小さい差分値については、差分値とその連続数をペアにした符号化処理を行い、その絶対値が基準差分値幅よりも大きい差分値については、連続数をペアにすることなく差分値の符号化処理を行うことを特徴とするプログラム。
【請求項１０】
請求項９において、
前記リプレイデータ書き込み部が、
今回のサンプリングでの差分値の絶対値が基準差分値幅よりも小さく、且つ、今回のサンプリングでの差分値と前回のサンプリングでの差分値とが等しい場合には、符号化処理を行うことなく差分値の連続数をインクリメントし、
今回のサンプリングでの差分値の絶対値が基準差分値幅よりも大きい場合、又は、今回のサンプリングでの差分値と前回のサンプリングでの差分値とが等しくない場合に、符号化処理を行うことを特徴とするプログラム。
【請求項１１】
請求項９又は１０において、
前記リプレイデータ書き込み部が、
差分値の連続数Ｎが所定数Ｋよりも大きい場合には、その差分値と所定数Ｋをペアにした符号化処理を行い、その差分値についての連続数をＮ−Ｋに設定することを特徴とするプログラム。
【請求項１２】
請求項９乃至１１のいずれかにおいて、
リプレイデータ記憶部から読み出したリプレイデータに基づいて、リプレイ画像生成のためのリプレイ処理を行うリプレイ処理部としてコンピュータを機能させ、
前記リプレイデータ書き込み部が、
ゲームコントローラにより入力された入力値データと、その入力値データの入力デバイス及び入力モードの少なくとも一方を特定するための入力種データとを圧縮して、リプレイデータとしてリプレイデータ記憶部に書き込み、
前記リプレイ処理部が、
リプレイデータ記憶部から、リプレイデータである入力値データと入力種データを読み出し、読み出した入力値データと入力種データを伸長し、伸長後の入力値データと入力種データに基づいて、リプレイ処理を行うことを特徴とするプログラム。
【請求項１３】
請求項１２において、
前記リプレイデータ書き込み部が、
入力種データを、入力値データの圧縮方式と同一の圧縮方式で圧縮することを特徴とするプログラム。
【請求項１４】
請求項１２又は１３において、
前記リプレイデータ書き込み部が、
ゲームコントローラの種類、及びゲームコントローラのキー・コンフィギュレーション設定の少なくとも一方に基づいて、入力種データを求めることを特徴とするプログラム。
【請求項１５】
請求項１２乃至１４のいずれかにおいて、
ゲームコントローラにより入力された入力値データに基づいてゲーム画像生成のためのゲーム処理を行うゲーム処理部としてコンピュータを機能させ、
前記ゲーム処理部が、
ゲームコントローラにより入力された入力値データの入力種が第１の入力種である場合には、入力値データに対して第１の変換処理を行って、ゲーム処理を行い、
ゲームコントローラにより入力された入力値データの入力種が第２の入力種である場合には、入力値データに対して変換処理を行わずに或いは第２の変換処理を行って、ゲーム処理を行い、
前記リプレイ処理部が、
リプレイデータの入力種データが第１の入力種のデータである場合には、入力値データに対して前記第１の変換処理を行って、リプレイ処理を行い、
リプレイデータの入力種データが第２の入力種のデータである場合には、入力値データに対して変換処理を行わずに或いは前記第２の変換処理を行って、リプレイ処理を行うことを特徴とするプログラム。
【請求項１６】
請求項１５において、
第１の入力種により特定される入力モードが、入力値データのビット長が短い第１の入力モードであり、
第２の入力種により特定される入力モードが、入力値データのビット長が長い第２の入力モードであり、
前記第１、第２の変換処理が、入力値データの平滑化処理であることを特徴とするプログラム。
【請求項１７】
コンピュータ読み取り可能な情報記憶媒体であって、請求項９乃至１６のいずれかのプログラムを記憶したことを特徴とする情報記憶媒体。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、画像生成システム、プログラム及び情報記憶媒体に関する。
【０００２】
【従来技術】
従来より、仮想的な３次元空間であるオブジェクト空間内において所与の視点（仮想カメラ）から見える画像を生成する画像生成システム（ゲームシステム）が知られており、いわゆる仮想現実を体験できるものとして人気が高い。競争ゲーム（カーゲーム）を楽しむことができる画像生成システムを例にとれば、プレーヤは、操作部（ステアリング、シフトレバー、アクセルペダル、ブレーキペダル等）を用いて移動オブジェクト（自プレーヤ移動オブジェクト、自車）を操作し、他のプレーヤ（コンピュータプレーヤ又は他の人間プレーヤ）が操作する移動オブジェクト（他プレーヤ移動オブジェクト、他車）と競争することでゲームを楽しむ。
【０００３】
さて、このような画像生成システムには、通常、リプレイ機能と呼ばれる機能が設けられており、プレーヤは、このリプレイ機能を利用することで、自身のゲームプレイの様子を、ゲーム終了後に、ゲーム中とは異なった視点で見ることができる。このようなリプレイ機能については、種々の従来技術がある。
【０００４】
【特許文献１】
国際公開第９６／００６０１号公報
【０００５】
【発明が解決しようとする課題】
しかしながら、この従来技術では、オブジェクトの位置データや角度データをリプレイデータとして記憶する必要があるため、リプレイデータのデータ量を抑えることに限界がある。
【０００６】
また、家庭用のゲームシステムなどでは、本体装置に接続可能なゲームコントローラ（パッド）として種々のものが存在する。従って、これらの様々なゲームコントローラが本体装置に接続された場合にも、適正なリプレイ処理を実現できることが望まれる。
【０００７】
本発明は、以上のような課題に鑑みてなされたものであり、その目的とするところは、リプレイデータの量を抑えることができる画像生成システム、プログラム及び情報記憶媒体を提供することにある。
【０００８】
また本発明の他の目的は、様々なゲームコントローラに対応したリプレイ処理を実現できる画像生成システム、プログラム及び情報記憶媒体を提供することにある。
【０００９】
【課題を解決するための手段】
本発明は、画像生成を行う画像生成システムであって、リプレイデータを記憶するリプレイデータ記憶部と、ゲームコントローラにより入力された入力値データを圧縮し、圧縮後の入力値データをリプレイデータとして前記リプレイデータ記憶部に書き込むリプレイデータ書き込み部とを含み、前記リプレイデータ書き込み部が、今回にサンプリングされた入力値データと前回にサンプリングされた入力値データの差分値を演算し、その絶対値が基準差分値幅よりも小さい差分値については、差分値とその連続数をペアにした符号化処理を行い、その絶対値が基準差分値幅よりも大きい差分値については、連続数をペアにすることなく差分値の符号化処理を行う画像生成システムに関係する。また本発明は、上記各部としてコンピュータを機能させるプログラムに関係する。また本発明は、コンピュータ読み取り可能な情報記憶媒体であって、上記各部としてコンピュータを機能させるプログラムを記憶（記録）した情報記憶媒体に関係する。
【００１０】
本発明によれば、ゲームコントローラからの入力値データがサンプリングされ、今回にサンプリングされた入力値データ（例えば今回のフレームでの入力値データ）と前回にサンプリングされた入力値データ（例えば前回のフレームでの入力値データ）の差分値が演算される。そして、差分値の絶対値が基準差分値幅よりも小さい場合には、差分値と連続数をペアにした符号化処理が行われる。一方、差分値の絶対値が基準差分値幅よりも大きい場合には、連続数をペアにせずに、差分値の符号処理が行われる。これにより入力値データを効率的に圧縮できる。なお、入力種データについても、同一の圧縮方式で圧縮できる。
【００１１】
また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記リプレイデータ書き込み部が、今回のサンプリングでの差分値の絶対値が基準差分値幅よりも小さく、且つ、今回のサンプリングでの差分値と前回のサンプリングでの差分値とが等しい場合には、符号化処理を行うことなく差分値の連続数をインクリメントし、今回のサンプリングでの差分値の絶対値が基準差分値幅よりも大きい場合、又は、今回のサンプリングでの差分値と前回のサンプリングでの差分値とが等しくない場合に、符号化処理を行ってもよい。
【００１２】
本発明によれば、今回のサンプリングでの差分値の絶対値が基準差分値幅よりも小さく、且つ、今回と前回のサンプリングでの差分値が等しい場合には、符号化処理は行われず、連続数がインクリメントされるだけであるため、処理負荷を軽減できる。また本発明によれば、今回のサンプリングでの差分値の絶対値が基準差分値幅よりも大きい場合、又は、今回と前回のサンプリングでの差分値が等しくない場合には、符号化処理が行われる。そして、この符号化処理は連続数をデクリメントしながら行われ、例えば連続数が「０」になると符号化処理が終了する。
【００１３】
なお、今回のサンプリングでの差分値とは、今回にサンプリングされた入力値データと、前回にサンプリングされた入力値データとの差分値であり、前回のサンプリングでの差分値とは、前回にサンプリングされた入力値データと、前回の更に前回にサンプリングされた入力値データとの差分値である。また、符号化処理は、差分値と連続数をペアにした符号化処理や、連続数をペアにしない差分値の符号化処理である。
【００１４】
また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記リプレイデータ書き込み部が、差分値の連続数Ｎが所定数Ｋよりも大きい場合には、その差分値と所定数Ｋをペアにした符号化処理を行い、その差分値についての連続数をＮ−Ｋに設定してもよい。
【００１５】
なお、連続数をＮ−Ｋに設定（変更）した後は、差分値と連続数Ｎ−Ｋに基づいて符号化処理を行ってもよい。そして例えば、Ｎ−Ｋが所定数Ｋよりも大きい場合には、その差分値と所定数Ｋをペアにした符号化処理を行い、連続数をＮ−Ｋ−Ｋに設定し、Ｎ−Ｋが所定数Ｋ以下の場合には、その差分値とＮ−Ｋをペアにした符号化処理を行ってもよい。
【００１６】
また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、リプレイデータ記憶部から読み出したリプレイデータに基づいて、リプレイ画像生成のためのリプレイ処理を行うリプレイ処理部を含み（該リプレイ処理部として機能させるプログラム又は該プログラムを記憶した情報記憶媒体であって）、前記リプレイデータ書き込み部が、ゲームコントローラにより入力された入力値データと、その入力値データの入力デバイス及び入力モードの少なくとも一方を特定するための入力種データとを圧縮して、リプレイデータとしてリプレイデータ記憶部に書き込み、前記リプレイ処理部が、リプレイデータ記憶部から、リプレイデータである入力値データと入力種データを読み出し、読み出した入力値データと入力種データを伸長し、伸長後の入力値データと入力種データに基づいて、リプレイ処理を行ってもよい。
【００１７】
本発明では、入力値データと入力種データがリプレイデータ記憶部に圧縮されて書き込まれ、この書き込まれた入力値データと入力種データが読み出されて、リプレイ処理が行われる。例えば、入力種データに基づいて、入力値データの入力種が特定され、入力種が特定された入力値データに基づいて、リプレイ処理が行われる。具体的には、例えば、リプレイ処理の際に、入力種に応じた処理が入力値データに対して施される。これにより、様々なゲームコントローラに対応したリプレイ処理を行うことが可能になる。
【００１８】
また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記リプレイデータ書き込み部が、入力種データを、入力値データの圧縮方式と同一の圧縮方式で圧縮してもよい。
【００１９】
ここで同一の圧縮方式としては、入力値データの差分値、入力種データの差分値を求めて行う方式がある。また、求められた差分値を符号化する方式がある。更に、差分値と差分値の連続数をペアにして符号化する方式がある。なお、全ての差分値について、差分値と連続数とをペアにして符号化する必要はなく、一部の差分値（例えばその絶対値が基準差分値幅よりも小さい差分値）だけを、連続数とペアにして符号化してもよい。
【００２０】
また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記リプレイデータ書き込み部が、ゲームコントローラの種類、及びゲームコントローラのキー・コンフィギュレーション設定の少なくとも一方に基づいて、入力種データを求めてもよい。
【００２１】
なお、ゲームコントローラの種類、キー・コンフィギュレーション設定以外の要素に基づいて、入力種データを求めてもよい。また、入力種データは、ゲームコントローラの種類の違いやキー・コンフィギュレーション設定の違いを区別するための所与のビット数のコードに、コード化してもよい。
【００２２】
また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、ゲームコントローラにより入力された入力値データに基づいてゲーム画像生成のためのゲーム処理を行うゲーム処理部を含み（該ゲーム処理部として機能させるプログラム又は該プログラムを記憶した情報記憶媒体であって）、前記ゲーム処理部が、ゲームコントローラにより入力された入力値データの入力種が第１の入力種である場合には、入力値データに対して第１の変換処理を行って、ゲーム処理を行い、ゲームコントローラにより入力された入力値データの入力種が第２の入力種である場合には、入力値データに対して変換処理を行わずに或いは第２の変換処理を行って、ゲーム処理を行い、前記リプレイ処理部が、リプレイデータの入力種データが第１の入力種のデータである場合には、入力値データに対して前記第１の変換処理を行って、リプレイ処理を行い、リプレイデータの入力種データが第２の入力種のデータである場合には、入力値データに対して変換処理を行わずに或いは前記第２の変換処理を行って、リプレイ処理を行うようにしてもよい。
【００２３】
なお、入力種は、第１、第２の入力種だけには限定されず、他の入力種があってもよい。また、変換処理も、第１、第２の変換処理だけには限定されず、他の変換処理があってもよい。
【００２４】
また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、第１の入力種により特定される入力モードが、入力値データのビット長が短い第１の入力モードであり、第２の入力種により特定される入力モードが、入力値データのビット長が長い第２の入力モードであり、前記第１、第２の変換処理が、入力値データの平滑化処理であってもよい。
【００２５】
なお、ビット長が短い第１の入力モードとしては、例えばビット長が１ビット（２値）となる入力モードが考えることができ、ビット長が長い第２の入力モードとしては、例えばビット長が４ビット以上となる入力モードを考えることができる。或いは、第１の入力モードが、ビット長がＫビットとなる入力モードであり、第２の入力モードが、ビット長がＬ（Ｋ＞Ｌ）ビットとなる入力モードであってもよい。
【００２６】
【発明の実施の形態】
以下、本実施形態について図面を用いて説明する。
【００２７】
なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。
【００２８】
１．構成
図１に、本実施形態の画像生成システム（ゲームシステム）の機能ブロック図の一例を示す。なお、本実施形態の画像生成システムは、図１の各部（機能ブロック）を全て含む必要はなく、その一部（例えば操作部１６０、携帯型情報記憶装置１９４又は通信部１９６等）を省略した構成としてもよい。
【００２９】
操作部１６０は、プレーヤが操作データ（入力値データ）を入力するためのものであり、その機能は、レバー、ボタン、ステアリング、シフトレバー、アクセルペダル、ブレーキペダル、マイク、センサー、タッチパネル、或いは筺体などのハードウェアにより実現できる。
【００３０】
記憶部１７０は、処理部１００や通信部１９６などのワーク領域となるもので、その機能はＲＡＭなどのハードウェアにより実現できる。
【００３１】
情報記憶媒体１８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、光磁気ディスク（ＭＯ）、磁気ディスク、ハードディスク、磁気テープ、或いはメモリ（ＲＯＭ）などのハードウェアにより実現できる。処理部１００は、この情報記憶媒体１８０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体１８０には、本実施形態の各部としてコンピュータを機能させるためのプログラム（各部をコンピュータに実現させるためのプログラム）が記憶（記録、格納）される。
【００３２】
表示部１９０は、本実施形態により生成された画像を出力するものであり、その機能は、ＣＲＴ、ＬＣＤ、タッチパネル、或いはＨＭＤ（ヘッドマウントディスプレイ）などのハードウェアにより実現できる。
【００３３】
音出力部１９２は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどのハードウェアにより実現できる。
【００３４】
携帯型情報記憶装置１９４は、プレーヤの個人データやゲームのセーブデータなどが記憶されるものであり、この携帯型情報記憶装置１９４としては、メモリカードや携帯型ゲーム装置などを考えることができる。
【００３５】
通信部１９６は、外部（例えばホスト装置や他の画像生成システム）との間で通信を行うための各種の制御を行うものであり、その機能は、各種プロセッサ又は通信用ＡＳＩＣなどのハードウェアや、プログラムなどにより実現できる。
【００３６】
なお本実施形態の各部としてコンピュータを機能させるためのプログラム（データ）は、ホスト装置（サーバー）が有する情報記憶媒体からネットワーク及び通信部１９６を介して情報記憶媒体１８０（記憶部１７０）に配信するようにしてもよい。このようなホスト装置（サーバー）の情報記憶媒体の使用も本発明の範囲内に含まれる。
【００３７】
処理部１００（プロセッサ）は、操作部１６０からの操作データやプログラムなどに基づいて、ゲーム処理、画像生成処理、或いは音生成処理などの各種の処理を行う。この場合、処理部１００は、記憶部１７０内の主記憶部１７２をワーク領域として使用して、各種の処理を行う。この処理部１００の機能は、各種プロセッサ（ＣＰＵ、ＤＳＰ等）又はＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラム（ゲームプログラム）により実現できる。
【００３８】
処理部１００は、ゲーム処理部１１０、リプレイデータ書き込み部（リプレイデータ記録部）１１２、リプレイ処理部（リプレイデータ読み出し部、リプレイデータ再生部）１１４、画像生成部１２０、音生成部１３０を含む。なお、処理部１００は、これらの各部（機能ブロック）を全て含む必要はなく、その一部を省略してもよい。
【００３９】
ゲーム処理部１１０は、ゲームコントローラ（操作部）１６０からの操作データ（入力値データ）に基づいて、ゲーム画像を生成するための種々のゲーム処理を行う。このゲーム処理は、例えば、ゲームに登場するオブジェクト（表示物）を配置する処理、オブジェクトを移動させる処理、オブジェクトを動作させる処理（モーション再生処理）、オブジェクトを表示する処理、ゲームを進行させる処理、或いはゲーム結果を演算する処理などである。
【００４０】
具体的には、ゲーム処理部１１０は、オブジェクト（移動オブジェクト）の移動情報（位置情報、方向情報、速度情報或いは加速度情報）を求める処理を行う。即ち、ゲームコントローラ１６０によりプレーヤが入力した入力値データ（操作データ）やゲームプログラムなどに基づいて、オブジェクトをオブジェクト空間内で移動させる処理を行う。また、ゲーム処理部１１０は、オブジェクトの動作情報（オブジェクトの各パーツの位置情報、方向情報）を求める処理を行う。即ち、ゲームコントローラ１６０によりプレーヤが入力した入力値データやゲームプログラムなどに基づいて、オブジェクトを動作（モーション、アニメーション）させる処理を行う。この場合のオブジェクトの動作は、オブジェクト（モデルオブジェクト、キャラクタ）を構成する各パーツオブジェクトの位置又は回転角度（方向）等を含むモーションデータを再生することで実現できる。
【００４１】
リプレイデータ書き込み部（リプレイデータ記録部）１１２は、リプレイデータ記憶部１７６にリプレイデータ（オブジェクトの移動又は動作等を再現するためのデータ）を書き込む処理を行う。具体的には、リプレイデータ書き込み部１１２は、リプレイデータを圧縮（符号化）してリプレイデータ記憶部１７６に書き込む（記録する）。
【００４２】
この場合にリプレイデータ書き込み部１１２は、ゲームコントローラ（操作部）１６０により入力された入力値データと入力種データとを、リプレイデータとしてリプレイデータ記憶部１７６に書き込む。ここで、入力値データは、ゲームコントローラ１６０の入力デバイス（ボタン、スティック、十字キー、レバー、ステアリング、アクセルペダル、ブレーキペダル又はゲームコントローラ自体）をプレーヤが操作することで得られるデータである。具体的には、入力デバイスの操作量（ボタンや十字キーを押した深さ、スティックやレバーを倒した角度等）に応じてその値が決まるデータである。また、入力種データは、入力値データの種類を特定するためのデータである。具体的には、その入力値データの入力に使用した入力デバイス及びその入力値データを入力した際の入力モード（デジタル入力モード、アナログ入力モード等）の少なくとも一方を特定するためのデータである。
【００４３】
なお、入力種データは、入力デバイスだけを特定するものであってもよいし、入力モードだけを特定するものであってもよいし、両方を特定するものであってもよい。また入力種データは、入力デバイスや入力モード以外の要素を特定するものであってもよい。また、入力デバイスの入力モードが、ゲームコントローラに設けられた入力モード切替ボタン（デジタル入力モード、アナログ入力モードの切り替えボタン）に基づいて切り替えられるようにしてもよい。また、入力モードは、入力デバイスにより入力される入力値データの例えばビット長の違いなどにより区別されるモードであり、ビット長が短い第１の入力モード、ビット長が長い第２の入力モードなど、種々の入力モードがある。
【００４４】
リプレイデータ書き込み部１１２は、入力値データのみならず、入力種データも、圧縮してリプレイデータ記憶部１７６に書き込む。この場合、入力種データについても、例えば入力値データの圧縮方式と同一の圧縮方式で圧縮する。
【００４５】
リプレイデータの圧縮は、入力値データ（入力種データ）の差分値（今回にサンプリングされた入力値データと前回にサンプリングされた入力値データとの差分値）を用いることで実現できる。更に具体的には、その差分値と差分値の連続数をペアにして符号化する処理（ランレングス・エンコーディング等）により実現できる。また、差分値や、差分値と連続数のペアを、コードに置き換える符号化処理（ハフマン・エンコーディング等）により実現できる。
【００４６】
特に本実施形態では、リプレイデータ書き込み部１１２が、今回（現在）のサンプリング（フレーム）での入力値データと前回（例えば１回前）のサンプリング（フレーム）での入力値データの差分値を演算する。そして、差分値の絶対値が基準差分値幅（所与の差分値幅）よりも小さい場合には、差分値と連続数をペアにして符号化する。一方、差分値の絶対値が基準差分値幅よりも大きい場合には、差分値だけを符号化する。
【００４７】
なお、差分値の絶対値が基準差分値幅と等しい場合（差分値の絶対値が基準差分値幅以上の場合）に、差分値と連続数をペアにして符号化するようにしてもよい。或いは、差分値の絶対値が基準差分値幅と等しい場合（差分値の絶対値が基準差分値幅以下の場合）に、連続数をペアにすることなく差分値だけを符号化するようにしてもよい。
【００４８】
また、サンプリングは、ゲームコントローラからの入力値データをゲーム処理部１１０等が取り込むタイミングである。別の言い方をすれば、１つの単位のゲーム処理が行われるタイミングである。具体的には、ゲームコントローラの入力値データは、例えばフレーム更新のタイミングで取り込まれ、このフレーム更新のタイミングがサンプリングのタイミングとなる。なお、フレームは、画像表示（ゲーム処理）の基準となる周期的なタイミングであり、例えば垂直同期信号がアクティブになる毎にフレーム更新が行われる。
【００４９】
リプレイ処理部１１４は、リプレイ画像生成のためのリプレイ処理を行う。より具体的には、リプレイデータ記憶部１７６から読み出した入力値データ及び入力種データ（リプレイデータ）に基づいてリプレイ処理を行う。更に具体的には、リプレイ処理部１１４は、圧縮（符号化）された入力値データと入力種データ（リプレイデータ）をリプレイデータ記憶部１７６から読み出して伸長（復号化）し、伸長後の入力値データと入力種データ（リプレイデータ）に基づいて、リプレイ処理を行う。
【００５０】
例えばゲーム中においては、プレーヤの操作により移動するオブジェクトに追従するように、仮想カメラ（視点）の位置や角度がゲーム処理部１１０により制御され、この仮想カメラから見えるゲーム画像が生成される。一方、リプレイ中においては、例えば複数のリプレイ用の仮想カメラ（仮想カメラ処理ルーチン）の中から１つの仮想カメラが選択（ランダム選択）される。そして、選択されたリプレイ用の仮想カメラの位置や角度がリプレイ処理部１１４により制御され、このリプレイ用の仮想カメラから見えるリプレイ画像が生成される。これにより、プレーヤは、自身のゲームプレイの様子を、ゲーム終了後に、ゲーム中とは異なった視点（同じ視点でもよい）で見ることが可能になる。
【００５１】
なお、リプレイ画像はプレーヤのゲームプレイ中に表示してもよい。例えば、現実世界に存在するレーサー等がゲームプレイを行い、そのゲームプレイで得られたリプレイデータ（入力値データ、入力種データ）をリプレイデータ記憶部１７６に記憶しておく。そして、リプレイ処理部１１４が、このリプレイデータを読み出し、プレーヤのプレイ中に、このリプレイデータに基づいて、そのレーサの敵移動オブジェクト（ゴースト・カー）を走行させる。このような敵移動オブジェクト（ゴースト・カー）のリプレイ画像にも本実施形態のリプレイ処理は適用できる。
【００５２】
画像生成部１２０は、処理部１００で行われる種々の処理の結果に基づいて描画処理を行い、これにより画像を生成し、表示部１９０に出力する。即ち、いわゆる３次元のゲーム画像を生成する場合には、まず、座標変換、クリッピング処理、透視変換或いは光源処理等のジオメトリ処理が行われ、その処理結果に基づいて、描画データ（プリミティブ面の頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等）が作成される。そして、この描画データ（プリミティブ面データ）に基づいて、透視変換後（ジオメトリ処理後）のオブジェクト（１又は複数プリミティブ面）が、描画バッファ１７４（フレームバッファ、ワークバッファ等のピクセル単位で画像情報を記憶できるバッファ）に描画される。これにより、オブジェクト空間内において仮想カメラ（所与の視点）から見える画像が生成されるようになる。
【００５３】
音生成部１３０は、処理部１００で行われる種々の処理の結果に基づいて音処理を行い、ＢＧＭ、効果音、又は音声などのゲーム音を生成し、音出力部１９２に出力する。
【００５４】
なお、本実施形態の画像生成システムは、１人のプレーヤのみがプレイできるシングルプレーヤモード専用のシステムにしてもよいし、このようなシングルプレーヤモードのみならず、複数のプレーヤがプレイできるマルチプレーヤモードも備えるシステムにしてもよい。
【００５５】
また複数のプレーヤがプレイする場合に、これらの複数のプレーヤに提供するゲーム画像やゲーム音を、１つの端末を用いて生成してもよいし、ネットワーク（伝送ライン、通信回線）などで接続された複数の端末（ゲーム機、携帯電話）を用いて生成してもよい。
【００５６】
２．本実施形態の手法
次に本実施形態の手法について図面を用いて説明する。
【００５７】
２．１　入力種の記憶
本実施形態では、プレーヤがゲーム中にゲームコントローラにより入力した入力値データをリプレイデータとして記憶し、この記憶されたリプレイデータに基づいて、リプレイ画像（リプレイ用の仮想カメラから見える画像）を生成している。
【００５８】
ところが、家庭用ゲームシステムなどでは、本体装置に接続可能なゲームコントローラとして、図２（Ａ）、（Ｂ）、（Ｃ）、図３（Ａ）、（Ｂ）に示すような種々のゲームコントローラが存在する。そして、これらのゲームコントローラでは、設けられている入力デバイス（十字キー、ボタン、スティック又はレバー等）やその入力モードが異なっており、入力値データの入力種も、これらの入力デバイスや入力モードに応じて異なったものになる。
【００５９】
例えば図２（Ａ）のゲームコントローラでは、十字キー（方向キー）１０、ボタン（操作ボタン）１１、１２、１３、１４、１５、１６、１７、１８などの入力デバイスが設けられている。そして、これらの入力デバイスの入力モードは、全て、デジタル（２値）の入力モード（広義には、入力値データのビット長が短い第１の入力モード）になっている。
【００６０】
例えば、図２（Ａ）のゲームコントローラの十字キー１０の上側キーをプレーヤが押すと、その入力値データは「１」になり、上側キーを押さないと、その入力値データは「０」になる。十字キー１０の下側、左側、右側キーについても同様である。この十字キー１０を用いることで、図４（Ａ）に示すように、移動オブジェクト（車、バイク、キャラクタ）のステアリング（方向指示）操作などが可能になる。
【００６１】
また、ボタン１１を押すと、その入力値データは「１」となり、ボタン１１を押さなければ、その入力値データは「０」になる。ボタン１２〜１８も同様である。これらのボタン１１〜１８を用いることで、図４（Ｂ）に示すように、移動オブジェクト（車、バイク）のアクセル、ブレーキ、ギアチェンジ操作などが可能になる。
【００６２】
図２（Ｂ）のゲームコントローラでは、図２（Ａ）のゲームコントローラに比べて、更に、スティック（アナログスティック）１９、２０という入力デバイスが設けられている。そして、これらのスティック１９、２０の入力モードは、アナログ（多値）の入力モード（広義には、入力値データのビット長が長い第２の入力モード）になっている。
【００６３】
例えば、スティック１９又は２０の傾けた角度に応じて、その入力値データが−１２８〜１２７の範囲で変化する。即ち、スティック１９又は２０を、右側に完全に傾けると、その入力値データ（Ｘ座標値）は「１２７」になり、左側に完全に傾けると、その入力値データ（Ｘ座標値）は「−１２８」になる。また、中立（ニュートラル）状態では、その入力値データは「０」になる。これらのスティック１９又は２０を用いることで、図４（Ｃ）に示すように、移動オブジェクトのステアリング操作などが可能になる。
【００６４】
図２（Ｃ）のゲームコントローラでは、図２（Ｂ）のゲームコントローラと異なり、十字キー１０、ボタン１１〜１８（感圧ボタン）の入力モードが、アナログ入力モード（広義には第２の入力モード）になっている。
【００６５】
例えば、ボタン１１を押した深さ（距離）に応じて、その入力値データが０〜２５５の範囲で変化する。即ち、ボタン１１を押さないと、その入力値データは「０」になり、ボタン１１を最も深く押すと、その入力値データは「２５５」になる。ボタン１２〜１８も同様である。これらのボタン１１〜１８を用いることで、図４（Ｄ）に示すように、移動オブジェクトのアクセル、ブレーキ、ギアチェンジ操作などが可能になる。
【００６６】
なお、図３（Ａ）のゲームコントローラでは、ゲームコントローラの左側の把持部材２０と右側の把持部材２１を相対的にねじることで、方向指示のための入力値データを、アナログ入力モードで入力できる。また、図３（Ｂ）のゲームコントローラでは、ステアリング３０を左右に回転することで、方向指示のための入力値データを、アナログ入力モードで入力できる。また、アクセルペダル３１、ブレーキペダル３２を踏むことで、アクセルやブレーキ操作のための入力値データを、アナログ入力モードで入力できる。
【００６７】
このように、ゲームコントローラとしては種々のものが存在する。従って、ゲームコントローラによりプレーヤが入力した入力値データを記憶し、リプレイ処理を行う場合には、図３（Ａ）〜図４（Ｂ）のような種々のゲームコントローラが本体装置に接続された場合にも、適正なリプレイ処理を実現できることが望ましい。
【００６８】
そこで本実施形態では、ゲームコントローラにより入力された入力値データと、入力種データ（入力デバイスやその入力モードを特定するためのデータ）とを、リプレイデータとして記憶する。そして、この記憶された入力値データと入力種データに基づいてリプレイ処理を行うようにしている。
【００６９】
具体的には図５（Ａ）に示すように、十字キーによりデジタル入力モード（広義には第１の入力モード）で入力値が入力された場合には、リプレイデータ書き込み部１１２が、入力値データ（−１、０、１）と入力種データ（十字キー、デジタル入力モード）を関連づけてリプレイデータ記憶部１７６に書き込む。そして、リプレイ処理部１１４は、書き込まれた入力種データに基づいて、入力値データの入力種を判断して、その入力種に応じたリプレイ処理を行う。例えば、入力値データが「−１」の場合（十字キーの左側キーが押された場合）には、プレーヤが左側にステアリングを切る操作を行ったと判断する。そして移動オブジェクト（車、バイク）が左に曲がるリプレイ画像を生成する。また入力値データが「１」の場合（十字キーの右側キーが押された場合）には、プレーヤが右側にステアリングを切る操作を行ったと判断する。そして移動オブジェクトが右に曲がるリプレイ画像を生成する。また入力値データが「０」の場合（十字キーの左側キーも右側キーも押されていない場合）は、ステアリングがニュートラル状態であると判断し、移動オブジェクトが直進するリプレイ画像を生成する。
【００７０】
また図５（Ｂ）に示すように、スティックによりアナログ入力モード（広義には第２の入力モード）で入力値が入力された場合には、リプレイデータ書き込み部１１２が、スティックを倒した角度に応じた入力値データ（−１２８〜１２７）と、入力種データ（スティック、アナログ入力モード）を関連づけてリプレイデータ記憶部１７６に書き込む。そして、リプレイ処理部１１４は、書き込まれた入力種データに基づいて、入力値データの入力種を判断して、その入力種に応じたリプレイ処理を行う。例えば、入力値データが「−１２８」の場合（スティックが左側に倒された場合）には、プレーヤが左側にステアリングを切る操作を行ったと判断する。そして移動オブジェクトが左に曲がるリプレイ画像を生成する。また入力値データが「１２７」の場合（スティックが右側に倒された場合）には、プレーヤが右側にステアリングを切る操作を行ったと判断する。そして移動オブジェクトが右に曲がるリプレイ画像を生成する。また入力値データが「０」の場合は、ステアリングがニュートラル状態であると判断し、移動オブジェクトが直進するリプレイ画像を生成する。
【００７１】
また図５（Ｃ）に示すように、ボタンによりデジタル入力モードで入力値が入力された場合には、リプレイデータ書き込み部１１２が、入力値データ（０、１）と入力種データ（ボタン、デジタル入力モード）を関連づけてリプレイデータ記憶部１７６に書き込む。そして、リプレイ処理部１１４は、書き込まれた入力種データに基づいて、入力値データの入力種を判断して、その入力種に応じたリプレイ処理を行う。例えば、入力値データが「１」の場合（ボタンが押された場合）には、プレーヤがアクセル（ブレーキ）を踏む操作を行ったと判断する。そして移動オブジェクトが加速（減速）するリプレイ画像を生成する。また入力値データが「０」の場合（ボタンが押されていない場合）には、プレーヤがアクセル（ブレーキ）を踏んでいないと判断する。そしてこの場合には移動オブジェクトの加速（減速）を行わない。
【００７２】
また図５（Ｄ）に示すように、ボタンによりアナログ入力モードで入力値が入力された場合には、リプレイデータ書き込み部１１２が、ボタンを押した深さに応じて変化する入力値データ（０〜２５５）と、入力種データ（ボタン、アナログ入力モード）とを関連づけてリプレイデータ記憶部１７６に書き込む。そして、リプレイ処理部１１４は、書き込まれた入力種データに基づいて、入力値データの入力種を判断して、その入力種に応じたリプレイ処理を行う。例えば、入力値データが「２５５」の場合（ボタンが最も深く押された場合）には、プレーヤがアクセル（ブレーキ）を目一杯に踏んだと判断する。そして移動オブジェクトが最大限に加速（減速）するリプレイ画像を生成する。また入力値データが「０」の場合（ボタンが押されていない場合）には、プレーヤがアクセル（ブレーキ）を踏んでいないと判断する。そしてこの場合には移動オブジェクトの加速（減速）を行わない。
【００７３】
このようにすることで、本実施形態によれば、本体装置にどのようなゲームコントローラが接続されても、そのゲームコントローラに応じた最適なリプレイ処理を行い、リプレイ画像を生成できる。
【００７４】
なお、図５（Ａ）の十字キーの場合には、左側キーが押された時には入力値データは「−１」になり、右側キーが押された時には入力値データは「１」になり、左側キーも右側キーも押されていない場合には入力値データは「０」になる。
【００７５】
また、入力種データは例えば８ビット（広義にはＪビット）のコードとしてリプレイデータ記憶部１７６に記憶される。具体的には、入力デバイスがボタンで入力モードがデジタル入力モードの場合には「００ｈ」、入力デバイスがボタンで入力モードがアナログ入力モードの場合には「０１ｈ」、入力デバイスがスティックの場合には「０２ｈ」というように、入力種データはコード化されて記憶される。
【００７６】
また、入力種は、ゲームコントローラの種類、及びゲームコントローラのキー・コンフィギュレーション設定（オプション設定）の少なくとも一方に基づいて、決定することができる。ここでキー・コンフィギュレーション設定は、画面調整、音声調整、難易度調整、又はゲーム設定などを行うためのオプション設定画面（オプションメニュー）において行われる。
【００７７】
例えば図６（Ａ）では、図２（Ａ）のタイプのゲームコントローラが本体装置４０に接続されている。また、キー・コンフィギュレーション設定画面は図６（Ａ）のＣ１に示すようになっている。図６（Ａ）のＣ１に示すように、ステアリング操作（方向）については図２（Ａ）のデジタル入力モードの十字キー１０で行われることが固定されており、他の選択枝はない。またアクセル操作については、デジタル入力モードのボタン１１、１５のいずれで行うかをプレーヤは選択できる。またブレーキ操作については、デジタル入力モードのボタン１２、１７のいずれで行うかをプレーヤは選択できる。そして、これらのキー・コンフィギュレーション設定（プレーヤの選択操作）の情報と、接続されたゲームコントローラの種類に基づいて、入力種が決定される。
【００７８】
図６（Ｂ）では、図２（Ｂ）のタイプのゲームコントローラが本体装置４０に接続されている。また、キー・コンフィギュレーション設定画面は図６（Ｂ）のＣ２に示すようになっている。図６（Ｂ）のＣ２に示すように、ステアリング操作については図２（Ｂ）のアナログ入力モードのスティック１９、デジタル入力モードの十字キー１０のいずれで行うのかをプレーヤは選択できる。またアクセル操作については、デジタル入力モードのボタン１１、１５のいずれで行うかをプレーヤは選択できる。またブレーキ操作については、デジタル入力モードのボタン１２、１７のいずれで行うかをプレーヤは選択できる。そして、これらのキー・コンフィギュレーション設定の情報と、接続されたゲームコントローラの種類に基づいて、入力種が決定される。
【００７９】
図７では、図２（Ｃ）のタイプのゲームコントローラが本体装置４０に接続されている。また、キー・コンフィギュレーション設定画面は図７のＣ３に示すようになっている。図７のＣ３に示すように、ステアリング操作については図２（Ｃ）のアナログ入力モードのスティック１９、アナログ入力モードの十字キー１０のいずれで行うのかをプレーヤは選択できる。またアクセル操作については、デジタル入力モードでのボタン１１、アナログ入力モードでのボタン１１、デジタル入力モードでのボタン１５、アナログ入力モードでのボタン１５のいずれで行うかをプレーヤは選択できる。またブレーキ操作については、デジタル入力モードでのボタン１２、アナログ入力モードでのボタン１２、デジタル入力モードでのボタン１７、アナログ入力モードでのボタン１７のいずれで行うかをプレーヤは選択できる。そして、これらのキー・コンフィギュレーション設定の情報と、接続されたゲームコントローラの種類に基づいて、入力種が決定される。
【００８０】
なお、入力種を、ゲームコントローラの種類だけで決定したり、キー・コンフィギュレーション設定だけで決定したり、ゲームコントローラの種類やキー・コンフィギュレーション設定以外の要素に基づいて決定しもよい。
【００８１】
また、接続されたゲームコントローラの種類は、ゲームコントローラ内に設けられるレジスタからゲームコントローラの属性情報を読み出すことで得ることができる。
【００８２】
２．２　変換処理
本実施形態では、ゲームコントローラからの入力値データに対して変換（加工）処理を行い、変換処理後の入力値データに基づいてゲーム処理部１１０がゲーム処理を行う。そして、リプレイの際にも、リプレイデータとして読み出された入力値データに変換処理を行い、変換処理後の入力値データに基づいて、リプレイ処理を行っている。この場合に本実施形態では、リプレイ処理の際に入力値データに対してどのような変換処理を行うかを、リプレイデータとして記憶された入力種データに基づいて判別している。
【００８３】
例えば図８（Ａ）のＤ１では、ゲーム処理の際に、デジタル入力モード（入力値データのビット長が短い入力モード）のボタンという第１の入力種で、入力値データが入力されている。この場合にはＤ２に示すように、入力値データに対して第１の変換処理（広義には第１の平滑化処理）が行われる。具体的には、「０」から「１」に離散的に変化（２値で変化）する入力値データを、「０」から「１」に滑らかに変化（多値で変化）させる平滑化処理が行われる。このような平滑化処理を行えば、「０」から「１」への入力値データの離散変化に起因する急激なアクセル操作やステアリング操作により、移動オブジェクトの動きが不自然になってしまう事態を防止できる。
【００８４】
そして本実施形態では図８（Ａ）のＤ３に示すように、リプレイ処理の際にも、ゲーム処理の時と同じ第１の変換処理（広義には第１の平滑化処理）を、入力値データに対して施す。具体的には、リプレイデータ記憶部１７６から読み出された入力値データの入力種が、リプレイデータ記憶部１７６から読み出された入力種データに基づき第１の入力種（デジタル入力モードのボタン）であると判断されると、読み出された入力値データに対して第１の変換処理を行って、リプレイ処理を行う。このようにすることで、リプレイ処理の際にも、急激なアクセル操作やステアリング操作により移動オブジェクトの動きが不自然になってしまう事態を防止できる。
【００８５】
また図８（Ｂ）のＤ４では、ゲーム処理の際に、アナログ入力モード（入力値データのビット長が長い入力モード）のボタンという第２の入力種で、入力値データが入力されており、この場合には、入力値データに対して第２の変換処理（第２の平滑化処理）が行われる。具体的には、入力値データを、より滑らかに変化させる平滑化処理が行われる。このような平滑化処理を行えば、移動オブジェクトの動きを、より滑らかにすることができる。
【００８６】
そして本実施形態では図８（Ｂ）のＤ５に示すように、リプレイ処理の際にも、ゲーム処理の時と同じ第２の変換処理（第２の平滑化処理）を、読み出された入力値データに対して施す。具体的には、リプレイデータ記憶部１７６から読み出された入力値データの入力種が、リプレイデータ記憶部１７６から読み出された入力種データに基づき第２の入力種（アナログ入力モードのボタン）であると判断されると、読み出された入力値データに対して第２の変換処理を行って、リプレイ処理を行う。このようにすることで、リプレイ処理の際にも、移動オブジェクトの動きを滑らかにすることができる。
【００８７】
なお、入力種が第２の入力種（アナログ入力モードのボタン）である場合に、変換処理（広義には平滑化処理）自体を行わないようにしてもよい。
【００８８】
以上のような手法で変換処理を行えば、変換処理後の入力値データをリプレイデータとして記憶する必要がなくなり、変換処理前の入力値データをリプレイデータとして記憶すればよいことになる。例えば、図８（Ａ）のＤ１の場合には、「０」又は「１」をリプレイデータとして記憶すれば済むようになる。これにより、リプレイデータの量の削減を図れ、メモリの有効利用を図れる。また、リプレイデータとして記憶された入力種データに基づいて、入力値データに施すべき変換処理が選択されるため、誤りのない変換処理を実現できる。また、ゲーム処理の際の動きと同様の動きを、リプレイ処理の際にオブジェクトに行わせることができ、リアルなリプレイ画像を生成できる。
【００８９】
なお、本実施形態の手法により入力値データに施される変換処理は、図８（Ａ）、（Ｂ）に示す平滑化処理に限定されない。即ち、入力値データをそのまま使用するのが好ましくない場合に行われるべき種々の変換（加工）処理を考えることができる。
【００９０】
２．３　リプレイデータの圧縮
本実施形態では図９（Ａ）に示すように、リプレイデータ書き込み部１１２が、入力値データを圧縮してリプレイデータ記憶部１７６に書き込んでいる。更に本実施形態では、入力値データのみならず入力種データについても圧縮してリプレイデータ記憶部１７６に書き込んでいる。
【００９１】
そして本実施形態では、リプレイ処理部１１４が、リプレイデータ記憶部１７６に圧縮されて記憶された入力値データと入力種データを読み出し、伸長する。そして、伸長後の入力値データと入力種データに基づいて、リプレイ処理を行っている。
【００９２】
このように入力値データのみならず入力種データについても圧縮して記憶することで、リプレイデータの量を更に削減できる。
【００９３】
なお、この場合、入力種データを、入力値データと同一の圧縮方式で圧縮することが望ましい。例えば、入力値データも入力種データも共に８ビット（Ｊビット）のデータに設定し、同じ圧縮方式に圧縮する。
【００９４】
また、圧縮方式としては、図９（Ｂ）に示すように、今回のサンプリング（フレーム）で得られた入力値データと、前回のサンプリング（フレーム）で得られた入力値データの差分値を求め、この差分値を符号化する方式が望ましい。この場合には、例えば、求められた差分値とその連続数をペアにして符号化する（ランレングス・エンコーディング）。なお、後述するように、差分値の絶対値が基準差分値幅よりも小さいことを条件に、差分値とその連続数をペアにして符号化するようにしてもよい。また、出現頻度が高い差分値又は出現頻度が高いと予想される差分値ほど、より短いコードが割り当てられるように符号化してもよい（ハフマン・エンコーディング）。
【００９５】
ゲームコントローラのスティックがニュートラル状態の場合や、スティックの傾き角度が所定の角度で固定されている場合や、ボタンが押されていない場合には、入力値データの値はほとんど変化しなくなる。従って、入力値データの差分値を求め、差分値とその連続数をペアにして圧縮する方式は、入力値データの圧縮率向上のために有効である。同様に、入力種データは、ゲーム処理中やリプレイ処理中に、その値が変化することはほとんどないと考えられる。従って、入力種データの差分値を求め、差分値とその連続数をペアにして圧縮する方式（入力値データと同一の圧縮方式）は、入力種データの圧縮率向上のために有効である。
【００９６】
２．４　圧縮方式
次に本実施形態の圧縮方式について詳しく説明する。
【００９７】
図１０（Ａ）に示すように、入力デバイスであるスティック１９がニュートラル状態（いずれの方向にも倒されていない状態）である場合には、入力値データは「０」付近の値になる。従って、今回（今回のサンプリング、フレーム）の入力値データと前回（前回のサンプリング、フレーム）の入力値データの差分値を求めると、その差分値の出現頻度は、「０」が最も多くなり、その次に、「−１」や「１」が多くなる。
【００９８】
また図１０（Ｂ）に示すように、プレーヤがスティック１９を倒し、一定の倒し角度で固定している状態（例えばハンドルを切った状態で固定している状態）でも、入力値データの差分値の出現頻度は、「０」が最も多くなり、その次に、「−１」や「１」が多くなる。
【００９９】
このように、スティック１９などの入力デバイスを用いる入力手法では、スティック１９の倒し角度等に依存せずに、その絶対値が小さい差分値ほど、より多くの頻度で出現するということが判明した。
【０１００】
本実施形態では、このようなゲームコントローラの入力値データの性質に着目し、次のような圧縮（符号化）方式を採用している。
【０１０１】
具体的には、まず、図１１（Ａ）に示すように、今回（現在）の入力値データと前回（１回前）の入力値データの差分値を求める。
【０１０２】
次に、差分値の絶対値と基準差分値幅を比較する。そして図１１（Ｂ）のＥ１に示すように、その絶対値が基準差分値幅よりも小さい差分値については、差分値とその連続数をペアにして符号化する。一方、図１１（Ｂ）のＥ２に示すように、その絶対値が基準差分値幅よりも大きい差分値については、差分値だけを符号化する。なお、その絶対値が基準差分値幅と等しい差分値については、差分値と連続数をペアにして符合化するようにしてもよいし、差分値だけを符号化するようにしてもよい。
【０１０３】
例えば図１１（Ｃ）のＥ４に示すような入力値データが入力された場合には、Ｅ５〜Ｅ１１に示すように、差分値が「０」で連続数が「３」の符号、差分値が「８」の符号、差分値が「８」の符号、差分値が「１」で連続数が「４」の符号、差分値が「０」で連続数が「５」の符号、差分値が「−２」で連続数が「２」の符号、差分値が「−１６」の符号が生成されることになる。
【０１０４】
図１０（Ａ）、（Ｂ）に示すように、ゲームコントローラの入力値データの差分値では、その絶対値が小さい差分値の出現頻度が多くなる。即ち、「０」、「１」、「−１」、「２」、「−２」など、その絶対値が基準差分値幅よりも小さい差分値の出現頻度が多くなり、連続して続くようになる。従って、その絶対値が基準差分値幅よりも小さい差分値については、図１１（Ｃ）のＥ５、Ｅ８、Ｅ９、Ｅ１０に示すように、連続数とペアにして符号化することで、圧縮率を向上できる。
【０１０５】
一方、その絶対値が基準差分値幅よりも大きい差分値については、連続数とペアにして符号化してしまうと、用意しなければならない符号長が長くなり、圧縮率がかえって悪化するおそれがある。従って、その絶対値が基準差分値幅よりも大きい差分値については、図１１（Ｃ）のＥ６、Ｅ７、Ｅ１１に示すように、連続数とペアにせずに、差分値を単独で符号化する。これにより、圧縮率を向上できる。
【０１０６】
なお、基準差分値幅の大きさは任意である。例えば、基準差分値幅の大きさを「１」に設定し、「０」となる差分値だけを、連続数とペアにして符号化するようにしてもよい。
【０１０７】
また、符号化手法としては、出現頻度が多い或いは出現頻度が多いと予想される値に、より短いコードを割り当てる符号化手法（ハフマン・エンコーディング）が望ましい。
【０１０８】
例えば図１２に静的なハフマン・エンコーディングの例を示す。
【０１０９】
図１２では、「００」には「０」の差分値、「０１」には「１」の差分値、「１００」には「−１」の差分値、「１０１」には差分値が「０」で連続数が「２」のペア、「１１００」には差分値が「０」で連続数が「３」のペア、「１１０１」には「２」の差分値、「１１１０００」には差分値が「１」で連続数が「２」のペア・・・・というようにコードの割り当てが行われている。このような符号化を行うことで、出現頻度が多い値に短いコードが割り当てられるようになり、圧縮率を向上できる。
【０１１０】
なお、図１２のような静的なハフマン・エンコーディングではなく、動的なハフマン・エンコーディングを行ってもよい。即ち、出現頻度が多い値を検索し、その出現頻度が多い値に短いコードを動的に割り当てる。この動的なハフマン・エンコーディングは、静的なハフマン・エンコーディングよりも処理負荷は重くなるが、圧縮率を向上できる。
【０１１１】
また、差分値の連続数Ｎが所定数Ｋよりも大きい場合には、その差分値と所定数Ｋをペアにして符号化し、その差分値についての連続数をＮ−Ｋに設定（デクリメント）することが望ましい。
【０１１２】
例えば図１３（Ａ）では、差分値が「０」で、連続数が「６９」になっており、連続数が所定数「６４」よりも大きい。従って、この場合には、所定数「６４」を連続数とみなし、差分値「０」と所定数「６４」をペアにして符号化すると共に、連続数を６９−６４＝５に変更（設定）する。そして、差分値「０」と変更後の連続数「５」をペアにして符号化する。
【０１１３】
また図１３（Ｂ）では、差分値が「０」で、連続数が「１３１」になっており、連続数が所定数「６４」よりも大きい。従って、この場合には、差分値「０」と所定数「６４」をペアにして符号化すると共に、連続数を１３１−６４＝６７に変更（設定）する。すると、この連続数「６７」は所定数「６４」よりも大きいため、差分値「０」と連続数「６４」をペアにして符号化すると共に、連続数を６７−６４＝３に変更（設定）する。そして、差分値「０」と連続数「３」をペアにして符号化する。
【０１１４】
このように、所定数Ｋの単位で区切って符号化すれば、ペア符号化のコードが不必要に長くなってしまう事態を防止できる。即ち、ゲームコントローラでは、その絶対値が小さい差分値、例えば「０」が長期に亘って連続する可能性が高い。従って、「０」とペアとなる連続数の範囲が大きくなってしまい、用意すべきコードの長さが長くなってしまう。
【０１１５】
図１３（Ａ）、（Ｂ）に示すように、所定数Ｋの単位で区切って符号化するようにすれば、「０」とペアとなる連続数としては、２〜Ｋの範囲のものを用意すれば済む。従って、用意すべきコードの長さを短くでき、圧縮率を向上できる。
【０１１６】
なお、所定数Ｋは任意であり、例えばＫ＝８、１６、３２、６４、１２８、２５６など、種々の値を採用できる。
【０１１７】
３．本実施形態の処理
次に、本実施形態の処理の詳細例について、図１４（Ａ）〜図２０のフローチャートを用いて説明する。
【０１１８】
図１４（Ａ）は、ゲーム時の処理のフローチャートである。まず、入力情報の取得処理を行い（ステップＳ１）、入力種（入力モード）の書き込み（記録）処理を行う（ステップＳ２）。次に、入力値の書き込み（記録）処理を行い（ステップＳ３）、入力種に応じた入力値の変換（加工）処理を行う（ステップＳ４）。そして、最後にゲーム処理を行う（ステップＳ５）。即ち、プレーヤのゲームを開始し、ゲームを進行させ、入力値データに応じて移動オブジェクトを移動、動作させ、プレーヤのゲーム成績（得点）を演算する処理を行う。
【０１１９】
図１４（Ｂ）はリプレイ時の処理のフローチャートである。まず、入力種（入力モード）の読み出し（再生）処理を行い（ステップＳ１１）、入力値の読み出し（再生）処理を行う（ステップＳ１２）。次に、入力種に応じた入力値の変換（加工）処理を行う（ステップＳ１３）、そして、最後にリプレイ処理を行う（ステップＳ１４）。即ち、プレーヤが自分のプレイのリプレイ画像を見ることを選択したり、リプレイ画像の表示モードになると、リプレイ用の仮想カメラから見えるリプレイ画像を表示する。或いは、プレーヤが操作する移動オブジェクトと競争する敵移動オブジェクト（ゴースト・カー）のリプレイ画像を表示する。
【０１２０】
図１５は、図１４（Ａ）のステップＳ１の入力情報の取得処理のフローチャートである。まず、接続されたゲームコントローラ（パッド）の種類を取得する（ステップＳ２１）。これは、ゲームコントローラのレジスタに記憶されるゲームコントローラ情報を読み出すことで実現できる。次に、ステップＳ２１で取得したゲームコントローラの種類と、そのゲームコントローラについてプレーヤが設定したキー・コンフィギュレーション（図６（Ａ）〜図７参照）に基づき、入力種を特定して取得する（ステップＳ２２）。そして、特定された入力種に基づき入力値（入力値の種類）を特定して取得する（ステップＳ２３）。
【０１２１】
図１６（Ａ）は、図１４（Ａ）のステップＳ２の入力値の書き込み（記録）処理のフローチャートである。まず、図１１（Ａ）で説明したように、今回（現在）の入力値データと前回（１回前）の入力値データの差分値を求める（ステップＳ３１）。そして、求められた差分値を、図１１（Ｂ）、（Ｃ）、図１２、図１３（Ａ）、（Ｂ）等で説明した手法で符号化（圧縮）して、リプレイデータ記憶部に書き込む（ステップＳ３２）。
【０１２２】
図１６（Ｂ）は、図１４（Ａ）のステップＳ３の入力種の書き込み（記録）処理のフローチャートである。まず、今回（現在）の入力種データ（例えばＪビットのコード）と前回（１回前）の入力種データの差分値を求める（ステップＳ４１）。そして、求められた差分値を符号化（圧縮）して、リプレイデータ記憶部に書き込む（ステップＳ４２）。なお、入力種データの圧縮方式（差分値を求めて符号化する処理）は、図１１（Ａ）〜図１３（Ｂ）で説明した入力値データの圧縮方式と同一方式で実現できる。
【０１２３】
図１７は、図１４（Ａ）のステップＳ４の入力種に応じた入力値の変換（加工）処理のフローチャートである。なお、図１４（Ｂ）のステップＳ１３も図１７の処理で実現できる。
【０１２４】
まず、入力種を判別する（ステップＳ５１）。そして、入力種が、デジタル入力モードの十字キー（図４（Ａ）、図５（Ａ））である場合には、−１、０、１の入力値を−１．０〜１．０に変換し、変換後の値を変数ａに設定する（ステップＳ５２）。そして、図８（Ａ）、（Ｂ）で説明したように、ａ＝０．２×（ａ−ｂ）＋ｂという平滑化処理を実行する（ステップＳ５３）。
【０１２５】
一方、入力種が、アナログ入力モードの十字キーである場合には、−２５５〜２５５の入力値を−１．０〜１．０に変換し、変換後の値を変数ａに設定する（ステップＳ５４）。そして、ａ＝０．５×（ａ−ｂ）＋ｂという平滑化処理を実行する（ステップＳ５５）。
【０１２６】
また、入力種が、アナログ入力モードのスティック（図４（Ｂ）、図５（Ｂ））である場合には、−１２８〜１２７の入力値を−１．０〜１．０に変換し、変換後の値を変換ａに設定する（ステップＳ５６）。そして、ａ＝０．７×（ａ−ｂ）＋ｂという平滑化処理を実行する（ステップＳ５７）。
【０１２７】
次に、ｂ＝ａに設定する（ステップＳ５８）。そして、変数ａの値をゲーム処理部に渡す（ステップＳ５９）。
【０１２８】
なお、ステップＳ５３、Ｓ５５、Ｓ５７では、ステップＳ５３の平滑化処理が、入力値を最も滑らかに変化させている。但し、ステップＳ５３、Ｓ５５、Ｓ５７の平滑化処理の係数（０．２、０．５、０．７）は一例であり、任意の値をとることができる。また、例えばステップＳ５３では平滑化処理を行う一方で、ステップＳ５５、Ｓ５７では平滑化処理を行わないようにしてもよい。
【０１２９】
図１８（Ａ）は、図１４（Ｂ）のステップＳ１１の入力種（入力モード）の読み出し（再生）処理のフローチャートである。
【０１３０】
まず、リプレイデータ記憶部から、符号化された今回（現在）の入力種の差分値を読み出し、復号化する（ステップＳ６１）。次に、復号化後の今回（現在）の差分値に、復号化後の前回（１回前）の差分値を加算し、今回の入力種を求める（ステップＳ６２）。
【０１３１】
図１８（Ａ）は、図１４（Ｂ）のステップＳ１２の入力値の読み出し（再生）処理のフローチャートである。
【０１３２】
まず、リプレイデータ記憶部から、符号化された今回（現在）の入力値の差分値を読み出し、復号化する（ステップＳ７１）。次に、復号化後の今回（現在）の差分値に、復号化後の前回（１回前）の差分値を加算し、今回の入力値を求める（ステップＳ７２）。
【０１３３】
図１９は、本実施形態の圧縮方式の詳細について説明するためのフローチャートである。
【０１３４】
まず、今回（現在）の入力値ＩＰから前回（１回前）の入力値ＩＬを引き、今回の差分値ＤＰ＝ＩＰ−ＩＬを求める（ステップＳ８１）。そして、図１１（Ｂ）で説明したように、基準差分値幅ＤＲと、差分値ＤＰの絶対値を比較する（ステップＳ８２）。即ち｜ＤＰ｜＜ＤＲか否かを判断する。
【０１３５】
そして、｜ＤＰ｜＜ＤＲの場合には、今回の差分値ＤＰと前回の差分値ＤＬが等しいか否かを判断する（ステップＳ８３）。そして、ＤＰ＝ＤＬの場合には、連続数をＮ＝Ｎ＋１にインクリメントする（ステップＳ８４）。
【０１３６】
一方、ステップＳ８２で、｜ＤＰ｜≧ＤＲと判断された場合、或いは、ステップＳ８３でＤＰとＤＬが等しくないと判断された場合には、符号化処理に移行する（ステップＳ８５）。そして、今回のサンプリング（フレーム）での符号化処理が終了すると連続数をＮ＝１に設定（リセット）する（ステップＳ８６）。
【０１３７】
このように本実施形態の圧縮方式では、今回のサンプリング（フレーム）での差分値ＤＰの絶対値が基準差分値幅ＤＲよりも小さく、且つ、今回のサンプリング（フレーム）での差分値ＤＰと前回のサンプリング（フレーム）での差分値ＤＬとが等しい場合には、符号化処理を行うことなく差分値の連続数をインクリメントする（ステップＳ８２、Ｓ８３、Ｓ８４）。一方、今回のサンプリング（フレーム）での差分値ＤＰの絶対値が基準差分値幅ＤＲよりも大きい場合（ＤＰがＤＲ以上の場合）、又は、今回のサンプリング（フレーム）での差分値ＤＰと前回のサンプリング（フレーム）での差分値ＤＬとが等しくない場合に、符号化処理を行うようにしている（ステップＳ８２、Ｓ８３、Ｓ８５）。
【０１３８】
図２０は、図１９のステップＳ８５の符号化処理のフローチャートである。
【０１３９】
まず、連続数Ｎ＝０か否かを判断する（ステップＳ９１）。そして、Ｎ＝０の場合には符号化処理を終了する。一方、Ｎ＝０でない場合には、連続数Ｎ＞所定数Ｋか否かを判断する（ステップＳ９２）。そして、Ｎ＞Ｋの場合には、差分値がＤＰで連続数がＫのハフマンコード（図１２参照）を求めて出力する（ステップＳ９３）。そして、Ｎ＝Ｎ−Ｋに設定（デクリメント）して（ステップＳ９４）、ステップＳ９１に戻る。
【０１４０】
一方、ステップＳ９２でＮ≦Ｋであると判断された場合には、差分値がＤＰで連続数がＮのハフマンコードを求めて出力し（ステップＳ９５）、ステップＳ９１に戻る。
【０１４１】
図２０のように処理を行うことで、図１３（Ａ）、（Ｂ）で説明したように、所定数Ｋの単位で区切って行う符号化処理を実現できる。
【０１４２】
４．ハードウェア構成
次に、本実施形態を実現できるハードウェアの構成の一例について図２１を用いて説明する。
【０１４３】
メインプロセッサ９００は、ＣＤ９８２（情報記憶媒体）に格納されたプログラム、通信インターフェース９９０を介して転送されたプログラム、或いはＲＯＭ９５０（情報記憶媒体の１つ）に格納されたプログラムなどに基づき動作し、ゲーム処理、画像処理、音処理などの種々の処理を実行する。
【０１４４】
コプロセッサ９０２は、メインプロセッサ９００の処理を補助するものであり、高速並列演算が可能な積和算器や除算器を有し、マトリクス演算（ベクトル演算）を高速に実行する。例えば、オブジェクトを移動させたり動作（モーション）させるための物理シミュレーションに、マトリクス演算などの処理が必要な場合には、メインプロセッサ９００上で動作するプログラムが、その処理をコプロセッサ９０２に指示（依頼）する。
【０１４５】
ジオメトリプロセッサ９０４は、座標変換、透視変換、光源計算、曲面生成などのジオメトリ処理を行うものであり、高速並列演算が可能な積和算器や除算器を有し、マトリクス演算（ベクトル演算）を高速に実行する。例えば、座標変換、透視変換、光源計算などの処理を行う場合には、メインプロセッサ９００で動作するプログラムが、その処理をジオメトリプロセッサ９０４に指示する。
【０１４６】
データ伸張プロセッサ９０６は、圧縮された画像データや音データを伸張するデコード処理を行ったり、メインプロセッサ９００のデコード処理をアクセレートする処理を行う。これにより、オープニング画面、インターミッション画面、エンディング画面、或いはゲーム画面などにおいて、ＭＰＥＧ方式等で圧縮された動画像を表示できるようになる。なお、デコード処理の対象となる画像データや音データは、ＲＯＭ９５０、ＣＤ９８２に格納されたり、或いは通信インターフェース９９０を介して外部から転送される。
【０１４７】
描画プロセッサ９１０は、ポリゴンや曲面などのプリミティブ（プリミティブ面）で構成されるオブジェクトの描画（レンダリング）処理を高速に実行するものである。オブジェクトの描画の際には、メインプロセッサ９００は、ＤＭＡコントローラ９７０の機能を利用して、オブジェクトデータを描画プロセッサ９１０に渡すと共に、必要であればテクスチャ記憶部９２４にテクスチャを転送する。すると、描画プロセッサ９１０は、これらのオブジェクトデータやテクスチャに基づいて、Ｚバッファなどを利用した隠面消去を行いながら、オブジェクトをフレームバッファ９２２に高速に描画する。また、描画プロセッサ９１０は、αブレンディング（半透明処理）、デプスキューイング、ミップマッピング、フォグ処理、バイリニア・フィルタリング、トライリニア・フィルタリング、アンチエリアシング、シェーディング処理なども行うことができる。そして、１フレーム分の画像がフレームバッファ９２２に書き込まれると、その画像はディスプレイ９１２に表示される。
【０１４８】
サウンドプロセッサ９３０は、多チャンネルのＡＤＰＣＭ音源などを内蔵し、ＢＧＭ、効果音、音声などの高品位のゲーム音を生成する。生成されたゲーム音は、スピーカ９３２から出力される。
【０１４９】
ゲームコントローラ９４２（レバー、ボタン、筺体、パッド型コントローラ又はガン型コントローラ等）からの操作データや、メモリカード９４４からのセーブデータ、個人データは、シリアルインターフェース９４０を介してデータ転送される。
【０１５０】
ＲＯＭ９５０にはシステムプログラムなどが格納される。なお、業務用ゲームシステムの場合には、ＲＯＭ９５０が情報記憶媒体として機能し、ＲＯＭ９５０に各種プログラムが格納されることになる。なお、ＲＯＭ９５０の代わりにハードディスクを利用するようにしてもよい。
【０１５１】
ＲＡＭ９６０は、各種プロセッサの作業領域として用いられる。
【０１５２】
ＤＭＡコントローラ９７０は、プロセッサ、メモリ（ＲＡＭ、ＶＲＡＭ、ＲＯＭ等）間でのＤＭＡ転送を制御するものである。
【０１５３】
ＣＤドライブ９８０は、プログラム、画像データ、或いは音データなどが格納されるＣＤ９８２（情報記憶媒体）を駆動し、これらのプログラム、データへのアクセスを可能にする。
【０１５４】
通信インターフェース９９０は、ネットワークを介して外部との間でデータ転送を行うためのインターフェースである。この場合に、通信インターフェース９９０に接続されるネットワークとしては、通信回線（アナログ電話回線、ＩＳＤＮ）、高速シリアルバスなどを考えることができる。そして、通信回線を利用することでインターネットを介したデータ転送が可能になる。また、高速シリアルバスを利用することで、他の画像生成システムとの間でのデータ転送が可能になる。
【０１５５】
なお、本実施形態の各部（各手段）は、その全てを、ハードウェアのみにより実現してもよいし、情報記憶媒体に格納されるプログラムや通信インターフェースを介して配信されるプログラムのみにより実現してもよい。或いは、ハードウェアとプログラムの両方により実現してもよい。
【０１５６】
そして、本実施形態の各部をハードウェアとプログラムの両方により実現する場合には、情報記憶媒体には、ハードウェア（コンピュータ）を本実施形態の各部として機能させるためのプログラムが格納されることになる。より具体的には、上記プログラムが、ハードウェアである各プロセッサ９０２、９０４、９０６、９１０、９３０等に処理を指示すると共に、必要であればデータを渡す。そして、各プロセッサ９０２、９０４、９０６、９１０、９３０等は、その指示と渡されたデータとに基づいて、本発明の各部を実現することになる。
【０１５７】
図２２（Ａ）に、本実施形態を業務用ゲームシステム（画像生成システム）に適用した場合の例を示す。プレーヤは、ディスプレイ１１００上に映し出されたゲーム画像を見ながら、操作部１１０２（レバー、ボタン）を操作してゲームを楽しむ。内蔵されるシステムボード（サーキットボード）１１０６には、各種プロセッサ、各種メモリなどが実装される。そして、本実施形態の各部を実現するためのプログラム（データ）は、システムボード１１０６上の情報記憶媒体であるメモリ１１０８に格納される。以下、このプログラムを格納プログラム（格納情報）と呼ぶ。
【０１５８】
図２２（Ｂ）に、本実施形態を家庭用のゲームシステム（画像生成システム）に適用した場合の例を示す。プレーヤはディスプレイ１２００に映し出されたゲーム画像を見ながら、コントローラ１２０２、１２０４などを操作してゲームを楽しむ。この場合、上記格納プログラム（格納情報）は、本体システムに着脱自在な情報記憶媒体であるＣＤ１２０６、或いはメモリカード１２０８、１２０９などに格納されている。
【０１５９】
図２２（Ｃ）に、ホスト装置１３００と、このホスト装置１３００とネットワーク１３０２（ＬＡＮのような小規模ネットワークや、インターネットのような広域ネットワーク）を介して接続される端末１３０４−１〜１３０４−ｎ（ゲーム機、携帯電話）とを含むシステムに本実施形態を適用した場合の例を示す。この場合、上記格納プログラム（格納情報）は、例えばホスト装置１３００が制御可能な磁気ディスク装置、磁気テープ装置、メモリなどの情報記憶媒体１３０６に格納されている。端末１３０４−１〜１３０４−ｎが、スタンドアロンでゲーム画像、ゲーム音を生成できるものである場合には、ホスト装置１３００からは、ゲーム画像、ゲーム音を生成するためのゲームプログラム等が端末１３０４−１〜１３０４−ｎに配送される。一方、スタンドアロンで生成できない場合には、ホスト装置１３００がゲーム画像、ゲーム音を生成し、これを端末１３０４−１〜１３０４−ｎに伝送し端末において出力することになる。
【０１６０】
なお、図２２（Ｃ）の構成の場合に、本実施形態の各部を、ホスト装置（サーバー）と端末とで分散して実現するようにしてもよい。また、本実施形態の各部を実現するための上記格納プログラム（格納情報）を、ホスト装置（サーバー）の情報記憶媒体と端末の情報記憶媒体に分散して格納するようにしてもよい。
【０１６１】
またネットワークに接続する端末は、家庭用ゲームシステムであってもよいし業務用ゲームシステムであってもよい。
【０１６２】
なお本発明は、上記実施形態で説明したものに限らず、種々の変形実施が可能である。
【０１６３】
例えば、明細書又は図面中の記載において広義な用語（入力値データのビット長が短い第１の入力モード、入力値データのビット長が長い第２の入力モード、サンプリング、変換処理、入力デバイス等）として引用された用語（デジタル入力モード、アナログ入力モード、フレーム、平滑化処理、十字キー・スティック・ボタン・レバー等）は、明細書又は図面中の他の記載においても広義な用語に置き換えることができる。
【０１６４】
また、本発明の圧縮方式（符号化処理）、伸長方式（復号化処理）は、本実施形態で説明したものに限定されず、種々の方式を採用できる。例えばハフマン・エンコーディング、ランレングス・エンコーディング以外の方式を採用してもよい。
【０１６５】
また入力種を求める手法も、本実施形態で説明した手法に限定されない。また、リプレイデータとして記憶するものは入力値データや入力種データに限定されない。
【０１６６】
また本発明は、圧縮処理は行わずに、圧縮後のリプレイデータ（入力値データ、入力種データ）の伸長処理だけを行う画像生成システムやプログラムにも適用できる。
【０１６７】
また、本発明のうち従属請求項に係る発明においては、従属先の請求項の構成要件の一部を省略する構成とすることもできる。また、本発明の１の独立請求項に係る発明の要部を、他の独立請求項に従属させることもできる。
【０１６８】
また、本発明は種々のゲーム（格闘ゲーム、競争ゲーム、シューティングゲーム、ロボット対戦ゲーム、スポーツゲーム、ロールプレイングゲーム等）に適用できる。
【０１６９】
また本発明は、業務用ゲームシステム、家庭用ゲームシステム、多数のプレーヤが参加する大型アトラクションシステム、シミュレータ、マルチメディア端末、ゲーム画像を生成するシステムボード等の種々の画像生成システム（ゲームシステム）に適用できる。
【図面の簡単な説明】
【図１】本実施形態の画像生成システムの機能ブロック図である。
【図２】図２（Ａ）〜（Ｃ）は種々のゲームコントローラの説明図である。
【図３】図３（Ａ）（Ｂ）も種々のゲームコントローラの説明図である。
【図４】図４（Ａ）〜（Ｄ）は入力種についての説明図である。
【図５】図５（Ａ）〜（Ｄ）は本実施形態の手法の説明図である。
【図６】図６（Ａ）（Ｂ）は入力種の決定手法の説明図である。
【図７】入力種の決定手法の説明図である。
【図８】図８（Ａ）（Ｂ）は入力種に応じた変換処理の説明図である。
【図９】図９（Ａ）（Ｂ）は圧縮、伸長方式の説明図である。
【図１０】図１０（Ａ）（Ｂ）はゲームコントローラの入力値の性質の説明図である。
【図１１】図１１（Ａ）（Ｂ）（Ｃ）は本実施形態の圧縮方式の説明図である。
【図１２】静的なハフマン・エンコーディングの説明図である。
【図１３】図１３（Ａ）（Ｂ）は所定数単位で区切って行う符号化処理の説明図である。
【図１４】図１４（Ａ）（Ｂ）は本実施形態のフローチャート例である。
【図１５】本実施形態のフローチャート例である。
【図１６】図１６（Ａ）（Ｂ）は本実施形態のフローチャート例である。
【図１７】本実施形態のフローチャート例である。
【図１８】図１８（Ａ）（Ｂ）は本実施形態のフローチャート例である。
【図１９】本実施形態のフローチャート例である。
【図２０】本実施形態のフローチャート例である。
【図２１】ハードウェア構成例である。
【図２２】図２２（Ａ）〜（Ｃ）は種々の形態のシステム例である。
【符号の説明】
１００　処理部、１１０　ゲーム処理部、１１２　リプレイデータ書き込み部、
１１４　リプレイ処理部、１２０　画像生成部、１３０　音生成部
１６０　操作部、１７０　記憶部、１７２　主記憶部、１７４　描画バッファ
１７６　リプレイデータ記憶部、１８０　情報記憶媒体、１９０　表示部
１９２　音出力部、１９４　携帯型情報記憶装置、１９６　通信部
【図１】
2004141352.tif 000003
【図２】
2004141352.tif 000004
【図３】
2004141352.tif 000005
【図４】
2004141352.tif 000006
【図５】
2004141352.tif 000007
【図６】
2004141352.tif 000008
【図７】
2004141352.tif 000009
【図８】
2004141352.tif 000010
【図９】
2004141352.tif 000011
【図１０】
2004141352.tif 000012
【図１１】
2004141352.tif 000013
【図１２】
2004141352.tif 000014
【図１３】
2004141352.tif 000015
【図１４】
2004141352.tif 000016
【図１５】
2004141352.tif 000017
【図１６】
2004141352.tif 000018
【図１７】
2004141352.tif 000019
【図１８】
2004141352.tif 000020
【図１９】
2004141352.tif 000021
【図２０】
2004141352.tif 000022
【図２１】
2004141352.tif 000023
【図２２】
2004141352.tif 000024