JP3841210B2 - ゲーム装置、画像データの形成方法及び媒体 - Google Patents
ゲーム装置、画像データの形成方法及び媒体 Download PDFInfo
- Publication number
- JP3841210B2 JP3841210B2 JP2002258311A JP2002258311A JP3841210B2 JP 3841210 B2 JP3841210 B2 JP 3841210B2 JP 2002258311 A JP2002258311 A JP 2002258311A JP 2002258311 A JP2002258311 A JP 2002258311A JP 3841210 B2 JP3841210 B2 JP 3841210B2
- Authority
- JP
- Japan
- Prior art keywords
- mark
- data
- polygon
- tire
- game
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
【０００１】
【発明の属する技術分野】
本発明は、ビデオゲーム装置に関する。特に、アミューズメントセンターや家庭に設置されたゲーム装置でよりリアルな画像表現を行い得るようにしたゲーム装置に関する。
【０００２】
【従来の技術】
コンピュータ技術の進歩に伴い、コンピュータグラフィックス技術を用いたビデオゲーム装置が広く利用されるようになってきた。この種のビデオゲーム装置はユーザに広く受け入れられている。そして、多種多様なゲーム装置が数多く案出され、それ等に対応した様々なゲームソフトが供給されている。
【０００３】
【発明が解決しようとする課題】
ユーザがビデオゲームをより楽しむことができるようにするために、画像がよりリアルな表現で画面に表示されることが望まれる。例えば、カーレースのような車両競走においては、車両や背景の動きが自然に表現され、運転中に起こり得ること、例えば、フロントガラスでの光の反射等が特殊効果として画面に表現されることが望ましい。また、車両のタイヤスリップの痕跡等が現れれば面白い。しかも、その痕跡などはゲーム再開時に前回のゲームで生じた痕跡などが路面に残っていると、なお一層迫力のある画面になり、臨場感を高めることは容易に想像できる。
【０００４】
他方、三次元画面（３Ｄ）表示は、座標変換等の複雑な演算を繰返すため、ＣＰＵが負担する演算量が膨大になる。このため、画像表現の特殊効果等を行うと、これに使用される演算量の分だけ画面に表示するポリゴンの数を減らなければならない。
【０００５】
よって、本発明は、遊技者が光源によるまぶしさを体感できる画面を表現できるビデオゲーム装置を提供することを第１の目的とする。
【０００６】
また、本発明は、ビデオゲームにおいて移動するオブジェクト(object)の痕跡を画面に表現できるゲーム装置を提供することを第２の目的とする。
【０００７】
また、本発明は、ビデオゲームにおいて移動するオブジェクトの痕跡を画面に表現でき、かつ、その痕跡がゲーム実行中のみならず、次回のゲームにも反映させることができるビデオゲーム装置を提供することを第３の目的とする。
【０００８】
また、本発明は、三次元仮想空間におけるゲーム展開を二次元の画面に立体的に見えるように表示するに際し、描画ルーチンにおける演算量を減らすことのできる方法を提供することを第４の目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、本発明のゲーム装置は、三次元仮想空間で仮想カメラの視点(a visual point)を移動して、視野に入った場面(the scene came into the view)の画像を表示する(display)ゲーム装置において、視野内に光源が存在するときに、画像(picture)にフレア(flare)を形成するフレア処理手段（Ｓ１０２〜Ｓ１１８）を含む。上記フレア処理手段は、上記視点の視線方向を表す視線ベクトルを得る視線ベクトル生成手段（Ｓ１０６）と、上記視点から光源の方向を表す光線ベクトルを得る手段（Ｓ１０４）と、上記視線ベクトルと上記光線ベクトルとの内積(the inner product) を計算する内積計算手段（Ｓ１０８）と、上記画像に上記内積に応じた強度のフレアを形成するフレア形成手段（Ｓ１１２〜Ｓ１１８）と、を備えることを特徴とする。このようにすることによって、光源の視点からの位置及び／又は光源の強度に対応したフレアの形成が可能となる。そして、より実際のシーンに近い表現となり、映像効果の強化されたゲーム画像を形成することが可能となって、ゲームが面白くなる。
【００１０】
また、上記内積と基準値との比較結果に基づいて、上記フレア形成手段を活性化させる判別手段（Ｓ１１０）、を更に備えることを特徴とする。これにより、敢えてフレアを発生させる程の強さでない光源である場合に、フレア形成を回避してフレア処理を行うことによる画質の低下を防止することが可能となる。
【００１１】
また、上記フレア形成手段は、上記内積に応じて画像の白味の度合を増す（Ｓ１１２）、ことを特徴とする。これにより、フレアによる画像への影響（フレア効果）が表現される。
【００１２】
また、上記フレア形成手段は、上記内積に応じた透明度のフレアポリゴンの画像を形成する（Ｓ１１４、Ｓ１１８）、ことを特徴とする。これにより、カメラレンズのフレアを表現することが可能となる。
【００１３】
また、上記フレア形成手段は、予め定められた内積の上限値と下限値との間において、上記内積に応じた画像への白味の付加処理及び上記内積に応じた透明度のフレアポリゴンの形成処理の少なくともいずれかを行う、ことを特徴とする。これにより、強度の弱い光源によるフレア発生の回避と強度の強い光源よる過度のフレア処理の回避とが可能となる。
【００１４】
また、上記フレア形成手段は、上記視点と上記光源とを結ぶ直線上に上記フレアを形成する（Ｓ１１６，Ｓ１１８）、ことを特徴とする。これにより、仮想カメラへの光線の入射が表現される。
【００１５】
本発明のゲーム装置は、三次元仮想空間で視点を移動して視野に入った場面を画像として表示するゲーム装置において、上記視点の視野内に光源が存在するときに、上記画像にフレアを形成するフレア処理手段を含み、上記フレア処理手段は、上記光源の視野内の位置や光源の強度等に応じて上記フレアの程度を決定する、ことを特徴とする。この際に、テーブルや関数を用いてフレアの程度を上述した上限値や下限値等を考慮した適当な値に決定することができる。
【００１６】
フレアは、例えば、画面上に周囲よりも比較的に白味の度合いの高い平面形状若しくは中空の平面形状を表示することによって表現される。このフレアの表示、非表示を短時間内に繰り返す（フラッシング）ことにより、より実際のフレア発生の状態に似せることが可能となる。また、フレア（特に、中空でないフレア画像）によって背景の画像が継続的に遮られることを回避して、ゲーム操作に支障のないようにすることが可能となる。
【００１７】
フレアを入射光線に相当する直線上に複数表示する、ことによってよりフレアらしく見せることが可能となる。この際に、複数表示されるフレアを相似形によって形成することにより、演算の負担をより軽減することが可能となる。
【００１８】
また、上記光源は上記三次元仮想空間内に配置された仮想太陽であり、この仮想太陽が、所定の場面において上記画像にフレアを生ぜしめるために、上記三次元仮想空間内における上記仮想太陽の正規の配置位置から上記所定の場面の視野内に再配置される、ことを特徴とする。このようにすると、ゲーム場面中に光源を意図的に存在せしめてフレアを発生させて、ゲーム場面を演出することが可能となる。
【００１９】
本発明のゲーム装置は、ゲームの展開に従って移動するオブジェクトを画像として表示するゲーム装置において、上記オブジェクトの現在位置を読取る手段（Ｓ１３２）と、上記現在位置から所定範囲内の長さで痕跡マーク(trace mark)を描画すると共に、上記痕跡マークの後端側を時間経過と共に徐々に薄くして消滅させる痕跡マーク描画手段（Ｓ１３２〜Ｓ１５８）と、を備えることを特徴とする。これにより、タイヤ等の痕跡ポリゴンを減少して画像処理の演算量を減らすことが可能となる。
【００２０】
上記痕跡マークは、好ましくは、複数部分からなり、各部分は上記痕跡マークの先端部分から後端部分に向かって薄くなるパターンを分担する。各部分が分担する痕跡のパターンは予め形成されたパターンを使用することができる。また、基本となる痕跡のパターンの透明度を変えて各部分のパターンとして使用することが可能である。
【００２１】
また、上記痕跡マーク描画手段は、上記オブジェクトの現在位置が、描画された痕跡マークの先端位置(top position)から所定値以上離れる(spaced)までは（Ｓ１３４）、上記痕跡マークの先端部分のみを延長し（Ｓ１４２〜Ｓ１５２）、所定値以上離れたときは上記痕跡マーク全体を上記所定値だけ上記オブジェクトの現在位置に向って移動する（Ｓ１３６〜Ｓ１５８）、ことを特徴とする。これにより、遊技者に違和感のない痕跡マークを描画すると共に、痕跡マーク全体の長さを一定長に制限して、画像処理の演算量の増加を抑制することが可能となる。
【００２２】
また、上記痕跡マーク描画手段は、上記オブジェクトの移動速度に応じて描画された痕跡の消滅タイミングを加減する（Ｓ１３２〜Ｓ１５８）、ことを特徴とする。
【００２３】
また、上記痕跡マーク描画手段は、上記オブジェクトが停止しているときは描画された痕跡マークを消滅させず、上記オブジェクトが移動しているときは描画された痕跡マークをオブジェクトの移動速度に応じて早く消滅させる（Ｓ１３２〜Ｓ１５８）、ことを特徴とする。これにより、痕跡マークがオブジェクトの移動に追従する。
【００２４】
また、上記痕跡マーク描画手段は、好ましくは、上記オブジェクトが停止して所定時間を経過したときには、描画した痕跡マークを消去する。これにより、表示ポリゴン（スリップ痕跡）の数を減らしてＣＰＵの演算の負担を軽減することが可能となる。
【００２５】
上記痕跡マーク描画手段は、上記複数部分からなるマーク（図９）の各部分にそれぞれ対応する複数の記憶領域に上記マークの各部の位置を保持する巡回レジスタ（図１０）と、マークの先頭に対応する巡回レジスタの記憶領域を示すマーク先頭位置指示手段（図６、図８）と、を有することを特徴とする。
【００２６】
これに加えて、本発明の痕跡マークに関する別の特徴を得る構成は、ゲームの展開に伴って仮想空間を移動するオブジェクトを画像として表示するゲーム装置であって、前記ゲームの実行中の前記オブジェクトの移動に伴う痕跡マークおよび過去の痕跡マークを処理して表示させる処理表示手段（図２８〜図３１）と、前記ゲームの終了後に前記痕跡マークを記憶する第１の記憶手段（図３２）と、前記ゲームの開始前に前記第１の記憶手段から当該第１の記憶手段が記憶している前記痕跡マークを読み出して前記処理表示手段に前記過去の痕跡マークとして与える読出し手段（図２７）と、を備える。
【００２７】
例えば、前記処理表示手段（図２８〜図３１）は、前記オブジェクトの移動に伴う新規の前記痕跡マークを処理して表示させる第１の表示手段（Ｓ３００１〜Ｓ３００４）と、前記過去の痕跡マークを含む現在までに発生した痕跡マークを記憶する第２の記憶手段（Ｓ３００１、Ｓ３００５〜Ｓ３００８、Ｓ３０１１〜Ｓ３０１７）と、この第２の記憶手段に記憶した痕跡マークをソートするソート手段（Ｓ３０２１）と、このソート手段のソート結果に応じて前記痕跡マークを処理して表示させる第２の表示手段（Ｓ３０２２〜Ｓ３０２５）とを備える。
【００２８】
好適には、前記第２の記憶手段は、前記痕跡マークをその大きさに応じてソートする手段（Ｓ３０１１〜Ｓ３０１７）と、このソート結果による優先度の低い痕跡マークを消去して新規に発生した痕跡マークを記憶するメモリ手段（１０２）を備える。
【００２９】
また好適には、前記ソート手段（Ｓ３０２１）は、前記仮想空間内で仮想カメラから前記痕跡マークまでの距離に応じてソートする手段である。
【００３０】
さらに好適には、前記第２の表示手段（Ｓ３０２２〜Ｓ３０２５）は、前記痕跡マークのポリゴンを表示可能な最大数を加味して当該痕跡マークを表示させる手段である。
【００３１】
一方、前記第１の記憶手段（図３２）は、前記痕跡マークの表示価値を判断する判断手段（Ｓ３２１）と、この判断手段の判断結果に応じて前記痕跡マークをソートするソート手段（Ｓ３２２）と、このソート手段のソート結果による優先順位の高い痕跡マークからその所定数のみを保存するメモリ手段（Ｓ３２３〜Ｓ３２５、１９０）とを備えることができる。前記表示価値の判断条件には、前記痕跡マークの長さおよび位置の条件が含まれる。
【００３２】
前記処理表示手段（図２８〜図３１）は、前記オブジェクトの現在位置を読み取る手段と、前記現在位置から所定範囲内の長さで痕跡マークを描画すると共に、前記痕跡マークの後端側を時間経過と共に徐々に薄くして消滅させる痕跡マーク描画手段と、を備えることを特徴とする。
【００３３】
この構成により、ゲームが終了すると直ちに、ゲーム実行中のタイヤマークデータなどの痕跡マークデータの価値が判断され、メモリ（ＳＲＡＭ）に表示価値の高い順に選択的に保存され、次回のゲームにそれが表示される。このため、次回のゲーム時に前回のゲーム時のスリップ痕などのタイヤマークが残った状態で画面表示され、非常にリアル感があり、かつゲームの臨場感を高い。また、このタイヤマークデータはゲーム実行中は過去データの一部として扱われ、ソートされて、表示最大数やカメラ視野などに依る表示条件の元で極力その多くが表示される。
【００３４】
一方、ゲーム終了時に保存するタイヤマークデータ量はマークの表示価値に応じてソートされ、優先順位の高いデータから保存されるので、その記憶容量も少なくて済む。また、このソート及びデータ保存はゲーム実行中には行わずに、ゲームが終了した時点で行うようにしているから、ＣＰＵを中心とする演算要素に掛かる演算負荷を軽減できる。
【００３５】
本発明の媒体は、コンピュータシステムを上述したゲーム装置として機能させるプログラムを記録している。
【００３６】
本発明の画像データの形成方法は、ポリゴンによって構成されるオブジェクトを三次元仮想空間に配置する過程（Ｓ２０２）と、三次元仮想空間内に視点を設定し、この視点から見た表示領域内のポリゴンを投影面に投影して投影画像を形成する過程（Ｓ２５４）と、上記投影面に形成された投影画像から上記視点における各ポリゴンの可視又は不可視の識別を行う過程（Ｓ２５６）と、各ポリゴンの可視又は不可視を表すデータによってオブジェクトデータを形成する過程（Ｓ２１２）と、上記視点とオブジェクトデータとを関連付ける過程（Ｓ２１６）と、を含む。
【００３７】
本発明の画像データの形成方法は、ポリゴンによって構成される全てのオブジェクトを三次元仮想空間に配置する過程（Ｓ２０２）と、三次元仮想空間内に複数の視点を設定する過程（Ｓ２０４）と、各視点から見た表示領域内のポリゴンをそれぞれの投影面に投影して各視点毎に投影画像を形成する過程（Ｓ２５２、Ｓ２５４）と、上記投影面に形成された投影画像から各視点における各ポリゴンの可視又は不可視の識別を行う過程（Ｓ２５６）と、上記識別結果に基づいて、各視点における各ポリゴンの可視又は不可視を表すデータを形成する過程（Ｓ２５８）と、各視点における可視又は不可視を表す各ポリゴンのデータパターンによって同一又は類似のパターンをグループ化して複数のオブジェクトデータを形成する過程（Ｓ２１２）と、各視点から見えるオブジェクトデータを表すオブジェクトテーブルを形成する過程（Ｓ２１６）と、を含む。
【００３８】
本発明の媒体は、コンピュータシステムに、上述した画像データの形成方法の各過程を実行させるためのプログラムを記録している。
【００３９】
【発明の実施の形態】
以下、本発明の実施形態を図面を参照しながら説明する。
【００４０】
（第１の実施形態）
第１の実施形態に係るビデオゲーム装置を説明する。このビデオゲーム装置は、本発明の特殊効果画像のアルゴリズムを実行し得る構成を備えている。
【００４１】
図１は、ビデオゲーム装置の概要を表すブロック図である。この装置は、装置全体の制御を行うＣＰＵブロック１０、ゲーム画面の表示制御を行うビデオブロック１１、効果音等を生成するサウンドブロック１２、ＣＤ−ＲＯＭの読み出しを行うサブシステム１３等により構成されている。
【００４２】
ＣＰＵブロック１０は、ＳＣＵ（System Control Unit）１００、メインＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、カートリッジＩ／Ｆ１ａ、サブＣＰＵ１０４、ＣＰＵバス１０３等により構成されている。メインＣＰＵ１０１は、装置全体の制御を行うものである。このメインＣＰＵ１０１は、内部にＤＳＰ（Digital Signal Processor）と同様の演算機能を備え、アプリケーションソフトを高速に実行可能である。
【００４３】
ＲＡＭ１０２は、メインＣＰＵ１０１のワークエリアとして使用されるものである。ＲＯＭ１０３には、初期化処理用のイニシャルプログラム等が書き込まれている。ＳＣＵ１００は、バス１０５、１０６、１０７を制御することにより、メインＣＰＵ１０１、ＶＤＰ１２０、１３０、ＤＳＰ１４０、ＣＰＵ１４１等の間におけるデータ入出力を円滑に行うものである。また、ＳＣＵ１００は、内部にＤＭＡコントローラを備え、ゲーム中のオブジェクト（あるいはスプライト）データをビデオブロック１１内のＶＲＡＭに転送することができる。これにより、ゲーム等のアプリケーションソフトを高速に実行することが可能である。カートリッジＩ／Ｆ１ａは、ＲＯＭカートリッジの形態で供給されるアプリケーションソフトを入力するためのものである。
【００４４】
サブＣＰＵ１０４は、ＳＭＰＣ（System Manager & Peripheral Control）と呼ばれるもので、メインＣＰＵ１０１からの要求に応じて、入力装置２ｂからペリフェラルデータをコネクタ２ａを介して収集する機能等を備えている。メインＣＰＵ１０１はサブＣＰＵ１０４から受け取ったペリフェラルデータに基づき、例えばゲーム画面中の車両（オブジェクト）を移動させる等の処理を行うものである。コネクタ２ａには、ハンドル、アクセル及びブレーキ等からなる操縦装置が接続される。また、ＰＡＤ、ジョイスティック、キーボード等のうちの任意のペリフェラルも接続可能である。コネクタ２ａに２台の操縦装置２ｂを接続することによってカーレースの対戦を行うことが可能となる。サブＣＰＵ１０４は、コネクタ２ａ（本体側端子）に接続されたペリフェラルの種類を自動的に認識し、ペリフェラルの種類に応じた通信方式に従いペリフェラルデータ等を収集する機能を備えている。
【００４５】
ビデオブロック１１は、主に、ビデオゲームのポリゴンデータから成るオブジェクト等の描画を行うＶＤＰ（Video Display Processor）１２０、主に、背景画面の描画、ポリゴン画像データ（オブジェクト）および背景画像の合成、クリッピング処理等を行うＶＤＰ１３０とを備えている。
【００４６】
ＶＤＰ１２０には、ＶＲＡＭ１２１、複数のフレームバッファ（図示の例では、１２２、１２３の２つ）に接続される。ビデオゲーム装置のオブジェクトを表すポリゴンの描画コマンドはメインＣＰＵ１０１からＳＣＵ１００を介してＶＤＰ１２０に送られ、ＶＲＡＭ１２１に書き込まれる。ＶＤＰ１２０は、ＶＲＡＭから描画コマンドを内部のシステムレジスタに読込み、フレームバッファに描画データを書込む。描画されたフレームバッファ１２２または１２３のデータはＶＤＰ１３０に送られる。ＶＤＰ１２０は定形オブジェクト、拡縮オブジェクト、変形オブジェクト等を表示するテクスチャパーツ表示、四角形ポリゴン、ポリライン、ライン等を表示する非定形オブジェクト表示、パーツ同士の半透明演算、半輝度演算、シャドウ演算、ぼかし演算、メッシュ演算、シェーディング演算等の色演算、メッシュ処理、設定した表示領域以外の描画をしないようにするクリッピングを行う演算機能、等を備えている。また、行列演算を行うジオメタライザを備えており、拡大、縮小、回転、変形、座標変換等の演算をを素早く行うことができる。
【００４７】
ＶＤＰ１３０はＶＲＡＭ１３１に接続され、ＶＤＰ１３０から出力された画像データはメモリ１３２を介してエンコーダ１６０に出力される構成となっている。ＶＤＰ１３０は、ＶＤＰ１２０の持つ機能に加えて、スクロール画面表示を制御するスクロール機能と、オブジェクト及び画面の表示優先順位を決めるプライオリティ機能等を備える。
【００４８】
エンコーダ１６０は、この画像データに同期信号等を付加することにより映像信号を生成し、ＴＶ受像機５（あるいはプロジェクタ）に出力する。これにより、ＴＶ受像機５に各種ゲームの画面が表示される。
【００４９】
サウンドブロック１２は、ＰＣＭ方式あるいはＦＭ方式に従い音声合成を行うＤＳＰ１４０と、このＤＳＰ１４０の制御等を行うＣＰＵ１４１とにより構成されている。ＤＳＰ１４０により生成された音声データは、Ｄ／Ａコンバータ１７０により２チャンネルの信号に変換された後にスピーカ５ｂに出力される。
【００５０】
サブシステム１３は、ＣＤ−ＲＯＭドライブ１ｂ、ＣＤ Ｉ／Ｆ１８０、ＣＰＵ１８１、ＭＰＥＧ ＡＵＤＩＯ１８２、ＭＰＥＧ ＶＩＤＥＯ１８３等により構成されている。このサブシステム１３は、ＣＤ−ＲＯＭの形態で供給されるアプリケーションソフトの読み込み、動画の再生等を行う機能を備えている。ＣＤ−ＲＯＭドライブ１ｂはＣＤ−ＲＯＭからデータを読み取るものである。ＣＰＵ１８１は、ＣＤ−ＲＯＭドライブ１ｂの制御、読み取られたデータの誤り訂正等の処理を行うものである。ＣＤ−ＲＯＭから読み取られたデータは、ＣＤ Ｉ／Ｆ１８０、バス１０６、ＳＣＵ１００を介してメインＣＰＵ１０１に供給され、アプリケーションソフトとして利用される。また、ＭＰＥＧ ＡＵＤＩＯ１８２、ＭＰＥＧ ＶＩＤＥＯ１８３は、ＭＰＥＧ規格（Motion Picture Expert Group）により圧縮されたデータを復元するデバイスである。これらのＭＰＥＧ ＡＵＤＩＯ１８２、ＭＰＥＧ ＶＩＤＥＯ１８３を用いてＣＤ−ＲＯＭに書き込まれたＭＰＥＧ圧縮データの復元を行うことにより、動画の再生を行うことが可能となる。
【００５１】
次に、本発明に係る画像の第１の特殊効果の例について図２、図３及び図４を参照して説明する。
【００５２】
本実施形態では、ゲームの展開中に光源からいわゆる仮想カメラに光線が入射したときに、画像中に光線によるフレアを発生させて、よりリアリティのある画像を提供するものである。図２は、フレア形成のアルゴリズムを説明するフローチャート、図３は、フレア発生の条件判断を説明する説明図、図４は、フレアを生ぜしめた画像の例を示す説明図である。
【００５３】
まず、ＣＰＵ１０１は、図示しない主ゲームプログラム及び運転操作のデータに従って三次元仮想空間でカーレースゲームを展開する。主ゲームプログラムやデータはＲＯＭカートリッジやＣＤ−ＲＯＭ、フロッピー（登録商標）ディスク等の情報記録媒体によって供給され、予めメモリ内にロードされる。また、プログラムやデータは、インターネット、パソコン通信、衛星通信等の通信網や放送等の媒体を媒介としてダウンロードしても良い。ＣＰＵ１０１は、三次元仮想空間に車両や背景のオブジェクトを配置し、ＴＶ受像機のフレーム周期に同期してオブジェクトの位置・移動等を制御する。
【００５４】
図３は、三次元仮想空間を遊技者あるいは運転者等の視点に相当する仮想カメラで観察する様子を示すものであり、同図において、２１は仮想カメラ（視点）、２２はテレビモニタの画面に相当する投影面、２３はゲームが展開される三次元仮想空間、２４は三次元仮想空間に配置された仮想光源、２５は仮想カメラの視野範囲、Ａはカメラ位置と光源とを結ぶ線上にある単位ベクトル、Ｂは仮想カメラの向き方向に存在する単位ベクトル、θはベクトルＡとＢとのなす角度である。なお、後述するように、ベクトルは単位ベクトルに限定されない。
【００５５】
ＣＰＵ１０１は、主ゲームプログラムの実行中に、仮想カメラの視野（あるいは画面）２５内に、太陽、街路灯等の光源ポリゴン２４が入っているかどうかを判断する（Ｓ１０２）。これは、各シーン毎に仮想空間に配置されるオブジェクトが予めデータベース化され、該当シーンにリストアップされたオブジェクトの個別番号によって光源のオブジェクトの存在を知ることが可能である。
【００５６】
視野内に光源オブジェクトが存在しない場合は、フレアは発生しないので本画像処理は終了する。
【００５７】
視野内に光源オブジェクトが存在すると、ＣＰＵ１０１は、光源からの光線がカメラレンズに入射するかどうか、その影響の程度等を判断するべく、カメラが光源方向にどの程度向いているか、あるいは光源の視野内の位置関係等を判断する。このため、三次元仮想空間におけるカメラ位置と、光源オブジェクトとを結ぶ線分を求め、単位長のベクトルＡを得る（Ｓ１０４）。このシーンにおける三次元仮想空間でのカメラ２１の向きをデータベースから求め、カメラの向きを表す単位ベクトルＢを得る（Ｓ１０６）。単位ベクトルＡ及びＢの内積Ｃ、すなわち、Ｃ＝│Ａ│・│Ｂ│ｃｏｓθを計算する。両ベクトルの方向が一致すればθは０度となり、内積は１となる。逆に、両ベクトルの向きが離れるほど、内積は０に近づく（Ｓ１０８）。なお、光源の強度を内積Ｃに反映させる場合には、ベクトルＡの値を単位長「１」ではなく、光源の強度に対応した値とする。この場合のベクトルＡは、方向及び大きさ（光の強さ）を持つ入射光線に相当する。
【００５８】
ＣＰＵ１０１は、内積とフレアの発生条件として予め定められた基準値とを比較する。内積Ｃが、基準値（閾値）を越えるかどうかを判断する（Ｓ１１０）。越えない場合は、フレアは生じない、あるいはフレアを生じさせる程のものではないので、本画像処理を終了してメインプログラムに戻る。フレア処理は、光源によって画像が影響を受けたと遊技者が認識できる程度に行うべきである。さもなければ、フレア処理（例えば、後述のフォグ効果）が一種の画質の低下の原因とな得る。これを上記判断（Ｓ１１０）によって、回避可能である。
【００５９】
内積Ｃが基準値を越える場合、ＣＰＵ１０１はフレア処理を行う。まず、内積の値Ｃが大きいほど真っ直ぐに光源から光線がカメラレンズに入射することになるので、より強くフレアが発生する。そこで、値Ｃに比例して画像に白味をかけ、いわゆる「フォグ効果」を生ぜしめる。これは、ＶＤＰ１２０、１３０の色演算の輝度・色度パラメータを変えることによって実現可能である（Ｓ１１２）。次に、Ｃの値に比例した透明度Ｄを求める（Ｓ１１４）。カメラ位置と光源オブジェクトの位置とを結ぶ直線を２次元画面上の直線Ｅに変換し、スクリーン画像における光線のルートを特定する（Ｓ１１６）。直線Ｅに沿って、適当な位置に透明度Ｄのフレアポリゴンを描画する。例えば、透明度Ｄが半透明の場合には、下地の画像の輝度を半分にしたものとフレアポリゴンの輝度を半分にしたものを加算し、その結果をフレームバッファに描画する。それによって、フレア画像が得られる（Ｓ１１８）。視野内に光量の大なる複数の光源ポリゴンが存在する場合には、各ポリゴンに対して上述したフレア発生処理を行う。
【００６０】
なお、フォグ効果とフレアポリゴンの処理のうちいずれか一方のみを実施しても良い。また、視野内に光源が存在する場合（Ｓ１０２；Ｙｅｓ）、光源による影響をそれなりに受ける。影響の程度は内積Ｃにより制御される。従って、閾値を設定する（Ｓ１１０）ことは必須ではない。また、例えば、視野内に光源が存在する場合に、内積Ｃによってフレアポリゴンの透明度を調整し、内積Ｃ がしきい値を越えたときから、これに追加してフォグの効果を内積Ｃに比例して生ぜしめることとしても良い。更に、太陽、街灯等の光源の種類、光源の強度を加味して上記画像の白味や透明度を調整することが可能である。
【００６１】
図４は、レース中の画像にフレアが発生した様子を示している。この例では、光源オブジェクトは画面右上に存在し、表示しない直線Ｅに沿って環状のフレアポリゴン、円状のフレアポリゴンが表示されている。フレアポリゴンの形状は図示の輪郭が略円形状等のものに限定されない。例えば、輪郭が多角形のものであっても良い。フレアポリゴンは、半透明処理の他、予め形成されたフレアポリゴンを半透明処理することなくそのまま表示することとしても良い。このようなフレアポリゴンの表示と消滅とを繰り返して点滅（フラッシング）するような表現形態で表示すると、フレアポリゴンの後ろが間欠的に見えるので、中抜き（中空、あるいは環状）でない形状を中抜きとするのと同様の効果、あるいはフレアポリゴンを半透明としたのと同様の効果が得られ、背景が見えてゲーム操作の邪魔にならない。また、よりフレアらしく見せることができる。
【００６２】
フレアはフレアポリゴンによる表示に限られない。フレアを表す平面図形を用いて画像合成することとしても良い。上述のようにフレアを点滅表示する場合にも、周囲よりもフォグ効果を帯びた白味の度合いの高い色合いの平面形状（好ましくは中空形状、あるいはレンズフレアに対応した略円形や多角形の形状）により形成されたフレアを使用して画面合成を行い、その相似形を、入射光に相当する視点と光源を結ぶ直線上に複数並べて表示することができる。こうした場合には、比較的に演算の負担が少ない。
【００６３】
図５及び図６は、フレア処理の他の実施の形態を示している。この例では、図２に示されるフローチャートのステップ１１０を変更している。すなわち、内積の値Ｃを用いるに際し、図６に示すように、上限値ＣUと下限値ＣLとを設けている。内積Ｃが上限値ＣUを超える場合（Ｓ１１０ａ；ＣU＜Ｃ）、内積を値ＣUに設定する（Ｓ１１０ｄ）。これにより、フレアによって画像が白っぽくなりすぎるのを防止可能である。また、内積Ｃが下限値以下の場合（Ｓ１１０ａ；Ｃ＜ＣL）、一定のフレア効果を生ぜしめるべく、内積値をＣLに設定する（Ｓ１１０ｂ）。更に、内積Ｃが上限値ＣUと下限値ＣLとの間である場合（Ｓ１１０ａ；ＣL≦Ｃ≦ＣU)、修正関数ｆ（Ｃ）を用いて、修正値Ｃ’＝ｆ（Ｃ）を得る。このように、内積を適宜に修正して、用いてフレア処理をより効果的に行うことが可能となる。
【００６４】
図２に示した例では、フレアの程度を内積Ｃを利用して定めている。しかしながら、必ずしも内積Ｃを計算しなくとも類似の処理を行うことは可能である。
【００６５】
図７は、テーブルを参照してフレアの程度を決定する２つの例を示している。ここでは、便宜上、フレアの程度もＣで表す。
【００６６】
既述ステップＳ１０２において、画面内に仮想光源が入っている場合（Ｓ１０２；Ｙｅｓ）、仮想光源の位置（例えば、ベクトルＡ及びＢのなす角度θ）に対応したフレア値Ｃを図７（ａ）に示すテーブルを参照して決定することができる。仮想光源の位置は、画面上あるいは視野２５内の（ｘ，ｙ）座標値であっても良い。このようなテーブルは予めＣＤ−ＲＯＭ１ｂにデータベースとして記録しておき、ゲーム起動の際に読み込んでＲＡＭ１０２に保持することが可能である。
【００６７】
また、図７（ｂ）に示す、光源の視野内の位置（例えば、ベクトルＡ及びＢのなす角度θ）と、光源の強度とに対応したフレア強度を得るテーブルを参照して、光源の位置θn及び強度Ｐnに対応したフレア値Ｃnnを得ることができる。また、特に図示しないが、光源の強度によってフレアの程度を定めることとした場合には、光源の強度のみに対応したフレア値Ｃを保持するテーブルを使用することとしても良い。このようにして得られたフレア値Ｃを前述した、ステップ１１０以降の内積Ｃと同様に使用することが可能である。そして、同様のフレア処理を実行することが可能である。テーブルを参照してフレアの程度を定める場合には、上述した光源の位置やその強度の他、適当なもの（朝方・夕方、雨、霧、曇の存在等）をパラメータとして含めることが可能であり、テーブルの内容は図示のものに限定されない。
【００６８】
なお、上述したテーブルに変えてテーブルと同様に機能する関数Ｃ＝ｇ（θ，Ｐ）、Ｃ＝ｈ（θ）、Ｃ＝ｉ（Ｐ）あるいはＣ＝ｊ（ｘ，ｙ）を使用しても良い。
【００６９】
次に、フレアを活用する場合について説明する。いわゆるワールド座標系での仮想太陽の位置は本来定っている。しかしながら、レースゲームをやり易くするために、逆光が発生しないように適宜仮想太陽の位置を移動させることができる。逆に、ゲームの演出効果を高めるために、本来仮想太陽が存在しない場所に仮想太陽をおいて意図的に逆光状態とし、フレアを発生させることができる。
【００７０】
例えば、図８に示すように、仮想太陽を本来の仮想太陽の正規位置からゴール後に視界に入る位置に意図的に移動し、ゴール後に画像にフレアを発生させてゲームのクライマックスを演出することが可能である。
【００７１】
さらに、画像の第２の特殊効果の例に関するアルゴリズムについて図９乃至図１４を参照して説明する。これは、道路にタイヤの痕跡を残すことによって、車両のスピン、タイヤスリップ、悪路走行等をよりリアルに表現するものである。また、ある時間を経過した後にタイヤの痕跡を消すことによって、画面中のポリゴン（タイヤの痕跡）を減らして画像処理の演算量を減らす。また、タイヤの痕跡自体はゲームの運転情報としては不要であるので、違和感のないように、痕跡の後端より徐々に消して情報が過多にならないようにする。
【００７２】
図９は、タイヤの痕跡（タイヤマーク）を表示するアルゴリズムを説明するフローチャート、図１０乃至図１３は、データの読出し、タイヤマークの表示等を説明する説明図、図１４は、タイヤマークを描画した例を示す説明図である。
【００７３】
この実施の形態では、例えば、徐々に濃度が濃くなる５つの種類のタイヤマーク、すなわちパターン０〜パターン４がタイヤの痕跡をリアルに表現するために用いられる。各パターンはデータベース（ＲＯＭ）に記憶されている。また、車両のタイヤの移動にタイヤの痕跡を追従させると共に、痕跡を徐々に消すために、図１０に示すＲＡＭあるいはレジスタの５つの記憶領域が使用される。
【００７４】
まず、主プログラムにおいて、タイヤマークの表示条件が満たされているかどうかが判別される。すなわち、車両のスピンや急なアクセルの踏込みによるタイヤのスリップの発生、悪路の走行等を該当関数や走行条件を示すフラグを参照して判別することによってタイヤマークの表示ルーチンが行われる。
【００７５】
タイヤのスリップ等が始ると、ＣＰＵ１０１は、５つのＲＡＭのうちタイヤマークの先端位置を示す「先頭マークのフラグが設定された先頭マークのＲＡＭからタイヤの前回位置Ｘn-1を読出し、画面に表示されている現在のタイヤ位置Ｔｘ nとの距離Ｌ（＝Ｔｘ n−Ｘn-1）を計算し、新たなマーク長さＬとする（Ｓ１３２）。ここで、位置Ｘn-1、位置Ｔｘ nは、三次元仮想空間における座標値を表している。タイヤマークの長さＬがタイヤマークの基本パターンの最大長さｌを越えるかどうか、を判別する（Ｓ１３４）。
【００７６】
タイヤマークの長さＬが最大長さｌを越えない場合（Ｓ１３４；Ｎｏ）、ＣＰＵ１０１は、現在のタイヤ位置Ｔｘ nをタイヤマークの終了位置として先頭マークのＲＡＭに記憶する（Ｓ１４４）。タイヤマークの長さＬを先頭マークのＲＡＭに記憶する（Ｓ１４６）。ＣＰＵ１０１は先頭マークのフラグが設定されるべきＲＡＭの番号を記憶するフラグレジスタの内容を更新することなく、そのまま上記先頭マークのＲＡＭの番号を保持させる（Ｓ１４８）。
【００７７】
ＲＡＭ番号とパターンとは、図１３に示すように対応付けられており、先頭マークのＲＡＭから巡回するようにデータが読出されて、タイヤマークが描画される。すなわち、先頭マークのＲＡＭ Ｎｏ−０はパターン４に、先頭マークのＲＡＭ Ｎｏ−１はパターン３に、先頭マークのＲＡＭ Ｎｏ−２はパターン２に、先頭マークのＲＡＭ Ｎｏ−３はパターン１に、先頭マークのＲＡＭ Ｎｏ−４はパターン０に、それぞれ対応付けられる。パターン０からパターン４になるにつれてタイヤマークの濃さは薄い状態から濃い状態になっていく。先頭マークのＲＡＭ番号は時間的に最も新しいタイヤの痕跡を表す。
【００７８】
ＣＰＵ１０１は、最も濃いパターン（パターン４）を読出す（Ｓ１５０）。ＲＡＭからタイヤマークの出始め位置Ｘn-1、出終り位置Ｔｘn、長さＬを読出し、パターンを画面に表示する（Ｓ１５２）。ＲＡＭの個数分のパターン表示が終ったかを判別する（Ｓ１５４）。
【００７９】
先行するタイヤマーク処理によって、複数のＲＡＭにタイヤマークの出始め、出終り、長さが記憶されている場合（Ｓ１５４；Ｎｏ）、ＣＰＵ１０１は、ＲＡＭ番号を降順方向に巡回するように指定し（Ｓ１５６）、ＲＡＭ番号に対応付けられて、降順方向に段階的にあるいは徐々に薄くなるタイヤマークのパターンを読出す（Ｓ１５８）。ＲＡＭの個数分のパターン表示が終ると（Ｓ１５４；Ｙｅｓ）、ＣＰＵ１０１は一旦メインプログラムに戻る。
【００８０】
そして、タイヤマークの表示条件が満たされている間、タイヤマークの長さＬがタイヤマークの最大長ｌを越えるまで、ステップ１３２、１３４、１４４〜１５４を繰返して最も濃いパターンをタイヤに追従するように伸長して描画する。
【００８１】
次に、マーク長さＬがマーク最大長さｌを越える場合（Ｓ１３４；Ｙｅｓ）、マーク最大長さｌに相当するマークの場所Ｐe（＝Ｘn-1＋ｌ）をマーク終了位置として記憶する（Ｓ１３６）。先頭マークのＲＡＭ番号を１増加する。ＲＡＭ番号が最大値（この例の場合４）をオーバーしたときは、ＲＡＭ番号を０に戻す（Ｓ１３８）。マークの出始めの位置Ｐeを新たな先頭マークのＲＡＭに記憶する（Ｓ１４０）。現在のタイヤ位置Ｔｘ nと、タイヤマーク出始めの位置Ｐｅから、タイヤマークの長さＬ（＝Ｔｘ n−Ｐｅ）を計算して求める（Ｓ１４２）。現在のタイヤ位置Ｔｘ nをマーク終了位置として先頭マークのＲＡＭに記憶する（Ｓ１４４）。タイヤマークの長さＬを先頭マークのＲＡＭに記憶する（Ｓ１４６）。フラグレジスタに記憶すべきＲＡＭ番号をＳ１３８で更新された先頭マークのＲＡＭの番号とする（Ｓ１４８）。最も濃いパターン（パターン４）を読出す（Ｓ１５０）。ＲＡＭからタイヤマークの出始め位置Ｐｅ、出終り位置Ｔｘ n、長さＬを読出し、パターンを画面に表示する（Ｓ１５２）。ＲＡＭの個数分のパターン表示が終ったかを判別する（Ｓ１５４）。
【００８２】
先行するタイヤマーク処理によって、複数のＲＡＭにタイヤマークの出始め、出終り、長さが記憶されている場合（Ｓ１５４；Ｎｏ）、ＲＡＭ番号を降順方向に巡回するように指定し（Ｓ１５６）、ＲＡＭ番号に対応付けられて、降順方向に段階的にあるいは徐々に薄くなるタイヤマークのパターンを読出す（Ｓ１５８）。
【００８３】
上述したタイヤマーク描画処理は、メインプログラムの実行において、タイヤマークの表示条件が満たされている間中実行され、画面にタイヤマークが描かれる。
【００８４】
上記アルゴリズムによる、ＲＡＭ０〜ＲＡＭ４内の保持データとフラグレジスタ内の保持データの更新の様子を図１０（ａ）〜同（ｅ）を参照して説明する。
【００８５】
図１０（ａ）は、スリップによるタイヤマークの長さＬがマークの基準値ｌに満たないΔｌである場合（Ｓ１３４；Ｎｏ）を説明するものである。
【００８６】
まず、先頭マークがＲＡＭ０を示しているとする。ステップ１３２において、タイヤマークの出始め位置Ｘ0、現在位置Ｔｘ 1が読込まれ、距離Ｌ＝Δｌ（＝Ｔｘ 1−Ｘ0）が計算される。当初のタイヤマークの出始め位置Ｘ0は、スリップ開始時のタイヤ位置が該当する。これ等の値がＲＡＭ０に記憶される（Ｓ１４４〜Ｓ１４６）。ＲＡＭ０をフラグレジスタが保持すべき先頭マークのＲＡＭ番号とする（Ｓ１４８）。図１３に示すように、先頭マークのＲＡＭ番号は最も濃いパターン４に対応する。ＲＡＭ０からタイヤマークの出始め、出終り、長さが読出され、パターン４によるタイヤマークの描画が行われる（Ｓ１５２）。この場合、データが書込まれているＲＡＭは１個であるので（Ｓ１５４；Ｙｅｓ）、本ルーチンを終了して、メインプログラムに戻る。タイヤマークの表示条件が満たされていると、マークの長さＬが最大長ｌを越えるまで、上記処理を繰返してパターン４のタイヤマークを延長する。
【００８７】
図１０（ｂ）に示すように、現在のタイヤの位置がＴｘ 2となり、距離Ｌ（＝Ｔｘ 2−Ｘ0＝ｌ＋Δｌ）が、マーク最大長ｌを越える（Ｓ１３４；Ｙｅｓ）。ＲＡＭ０に、Ｘ1＝Ｘ0＋ｌ（＝Ｐｅ）を求め、位置Ｘ1をマーク終了位置として記憶する（Ｓ１３６）。先頭マークのＲＡＭをＲＡＭ１とする（Ｓ１３８）。現在のタイヤ位置Ｔｘ 2とマーク出始めの位置Ｘ1からマークの長さＬ（＝Δｌ＝Ｔｘ 2−Ｘ1）を計算する（Ｓ１４２）。現在のタイヤ位置Ｔｘ 2をマーク終了位置として、ＲＡＭ１に記憶する（Ｓ１４４）。マークの長さＬ（＝Δｌ＝Ｔｘ 2−Ｘ1）をＲＡＭ１に記憶する（Ｓ１４６）。フラグレジスタに保持される、サイクリック（巡回）に読出す際の先頭のＲＡＭの番号をＲＡＭ１に設定する（Ｓ１４８）。ＲＡＭ１にパターン４のデータを対応させ（Ｓ１５０）、ＲＡＭ１のデータでパターン４の濃いタイヤマークを描く（Ｓ１５２）、更に、ＲＡＭ０に記憶されたデータでパターン３のタイヤマークを描画する（Ｓ１５４、Ｓ１５６、Ｓ１５８、Ｓ１５２）。メインプログラムに戻る。
【００８８】
以下、同様に繰返すことによって、図１０（ｃ）〜同（ｅ）に示すように、ＲＡＭ０〜ＲＡＭ４にタイヤマークの描画データ（タイヤマークの出始め、出終り、距離）が保持される。
【００８９】
図１１は、ＲＡＭ０〜ＲＡＭ４へのデータの保存が一巡した状態の例を示している。ＲＡＭは、実施例では５個であるので、順次書換えが行われる。図１１（ａ）では、書換えが一巡し、ＲＡＭ２にタイヤマークの先頭位置が対応している。図１１（ｂ）では、書換えが一巡し、ＲＡＭ３に先頭位置がある状態を示している。書換えられた元のタイヤマークのデータ部分は表示されないので、画面に描画された該当パターンは消滅する。なお、位置の座標Ｘnが仮想カメラの視野外にある場合、いわゆるクリッピング(clipping)によって画像処理の対象外となり、画面に表示されない。
【００９０】
図１２（ａ）は、図１１（ａ）に示すデータがタイヤマークとして描画された場合を説明するものである。パターン４はΔｌのパターン長さで描かれ、パターン３〜同０の各々はｌのパターン長で描かれている。パターン４からパターン０に向って描画濃度が薄くなっていく。図１２（ｂ）は、図１１（ｂ）に示すデータによって描かれたタイヤマークを示すものである。タイヤマークの描画範囲が車両のタイヤオブジェクトに追従して図１２（ａ）の位置Ｘ3〜Ｔｘ 8から位置Ｘ4〜Ｔｘ 9にシフトしている。そして、位置Ｘ3〜Ｘ4の範囲のタイヤマークは消滅している。これにより、タイヤの痕跡を所定長に限定してタイヤマークの表示に要する演算量があまり増えないようにしている。
【００９１】
図９のフローチャートを参照して説明したアルゴリズムによれば、車両が停止している場合にはＲＡＭ０〜ＲＡＭ４内の位置情報は保持されるのでタイヤマークは画面に表示された状態にある。一方、車両が移動している場合にはタイヤに追従してタイヤマークが描画される。このタイヤマークは後端の方が薄くなっている。車両の移動速度が速いと、タイヤの前回サンプリングした位置からの移動量Ｌは短時間でマークの最大長さｌを越える。これにより、ＲＡＭ０〜ＲＡＭ４内の位置情報はシフトし、タイヤマークの後端も早く消滅する。その結果として、車両の移動速度に応じて描画されたタイヤの痕跡の消滅タイミングが加減されることになる。このような、画像の描画の仕方はタイヤの痕跡を描いた種々の画面を予め用意して（メモリ量を多大に要する）、その中から適当な画面を選択する従来法に比べてメモリ消費を節約することが可能である。また、レース車両は高速で移動するが、その際にコース上のタイヤマークがすぐ消滅するようにすると、自車や対戦相手の車両の視野内のポリゴンを減らし、画像を描画する演算処理の負担を軽減し得る。また、タイヤマークがいつまでも表示されていると、ゲームの邪魔になる場合があるが、本願では適当に消去されるので具合がよい。
【００９２】
上述した例では、予め濃度の異なるタイヤの痕跡パターン（痕跡のポリゴン）を複数用意して（図１３）、これ等から適宜に選択して全体の痕跡を描画しているが、他の方法を採用することもできる。例えば、徐々に薄くなるタイヤマークを描画するステップ（ステップＳ１５８）において、最も濃いタイヤの痕跡マーク（基本パターン）を半透明化する処理を行って所要の濃度の痕跡マークを得ることとしても良い。より具体的には、当該ステップにおける透明化処理の透明度を、ルーチンの（Ｓ１５２〜Ｓ１５８）の実行回数に対応して段階的に設定された複数の透明度から該当するものを選択する。この異なる透明度によって半透明化処理された各痕跡マークを組み合わせて全体の痕跡を形成する。そうすると、上述した、濃度の異なるタイヤの痕跡パターンを複数用意して濃度が先端から後端に向かって徐々に変わる全体の痕跡を形成する場合と同様の結果を得る。更に述べれば、図９に示すルーチンに従って表示された複数のポリゴンからなる痕跡マークを、半透明処理で最初に表示したポリゴンから徐々に薄くして消していき（薄くする過程ではポリゴンのサイズは変わらない）、最終的に見えなくなったらそのポリゴンそのそのものを処理対象から外す（ステップＳ１５４、図１２（ｂ））、ようにする。
【００９３】
図１４に、画面中に車両がスピンしてタイヤマーク（スリップの痕跡）が描画された例を示す。タイヤ近傍のマークは濃く描かれ、タイヤマークの初めの位置は薄く描かれる。
【００９４】
なお、車両（オブジェクト）のスピン等によってタイヤスリップが発生した場合、スリップ直後にタイヤのスリップ痕跡が画像表示されれば、遊技者はリアルな表現を体感する。しかし、それから一定時間を経過すれば、遊技者のスリップ痕跡への注目度も低下する。そこで、車両が移動を停止した後、所定時間を経過した場合には、積極的にスリップ痕跡を消滅させることとしても良い。これにより、表示ポリゴン（スリップ痕跡）の数を減らしてＣＰＵの演算の負担を軽減することが可能となる。
【００９５】
上述した発明の実施の形態では、タイヤマークについて説明したが、悪路を走行するラリーにおける走行痕跡、スキーの走行痕跡（シュプール）、ジェットスキーの痕跡、船舶の航跡等にも適用できるものである。
【００９６】
次に、本発明の第３の特徴に係るビデオゲーム装置における演算量の低減について説明する。いわゆる３Ｄグラフィックスによってモニタに映し出されるオブジェクトは、三次元仮想空間内へのオブジェクトの配置、オブジェクトを投影面に描画する投影変換、モデリング変換、ビューイング変換等の演算処理が行われて、モニタ画像となる。透視変換に際しては、視野ピラミッドを形成し、実際に投影面に投影される表示領域からはみ出した部分を取り去り、非表示とするクリッピングを行っている。このクリッピングは、演算量の減少に寄与している。
【００９７】
したがって、この実施形態において実現する本発明の第３の特徴は、表示領域内においてもクリッピングを行い、更に、演算量を低減せんとするものである。
【００９８】
まず、図１５乃至図１７を参照してその概略を説明する。図１５は、三次元仮想空間に配置されたオブジェクトＡ及びＢを示している。オブジェクトＡ及びＢは、それぞれ複数のポリゴンによって構成される。従来、表示領域内のオブジェクトはデータベースから読出して、該当位置にそのままの形状で配置される。ポリゴンの表面にはテクスチュア（模様）が張付けられる。
【００９９】
図１６は、投影変換のカメラ位置（視点）を後方左においた場合に、オブジェクトＢがオブジェクトＡの陰になる例を説明するものである。この場合、オブジェクトＢの一部（オブジェクトＡの陰になっている部分）はカメラ位置からは見えない。そこで、見えない部分のポリゴンを省略して、オブジェクトのデータベースを構築すれば、３Ｄグラフィックス表示における演算量は減少する。
【０１００】
図１７は、オブジェクトＢの一部のポリゴンを省略した例を示している。このようにしても、カメラから見える投影面の画像は、図１６と同様である。
【０１０１】
例えば、カーレースにおいては、車両は予め定められたコースに沿って走る。コースを単位長に区切って、各単位毎にカメラから見える場面は背景画、オブジェクトの集合等の形式で予めデータベース化され、車両位置に応じて該当場面のデータが読出されて背景等として画面表示される。従って、実際にカメラから見えないポリゴンを減らせばゲーム装置において演算量のより少なくて済むデータベースを提供することが可能となる。
【０１０２】
以下に、表示領域内においてカメラ位置から見えないポリゴンを削ったオブジェクトデータベースを構築する方法について図面を参照して説明する。
【０１０３】
まず、後述するアルゴリズムを実行する画像データ処理装置の概略を図１８を参照して説明する。画像データ処理装置は、コンピュータシステムによって構成され、大別して、データ処理部２００、操作部２０１、オブジェクトテーブルやポリゴンデータ等のデータベースを保持する記憶部２０２、画像を表示するＣＲＴ表示部２０３等によって構成される。データ処理部２００は、メモリ２１２に保持されるプログラムに従って各部を制御する演算処理制御部２１１、三次元仮想空間におけるカメラ（視点）位置の座標を、車両の移動やゲームプログラム等に従って設定するカメラ位置制御部２１３、カメラ位置を参照して、カメラ位置に対応するオブジェクトテーブルを決定するオブジェクトテーブル決定部２１４、カメラ位置に対応した座標変換の行列を生成する座標変換行列生成部２１５、オブジェクトテーブルを参照して該当するポリゴンを指定するポリゴンメモリ制御部２１６、指定されたポリゴンデータを出力するポリゴンメモリ２１７、ポリゴンに張付ける模様を保持するテクスチャメモリ２１８、三次元仮想空間に、ポリゴンを配置し、テクスチャを張付け、上記変換行列によって投影変換等を行って二次元のスクリーン面上の像に変換する座標変換部２１９、スクリーン画像を画像メモリ２２１に出力する描画部２２０、画像メモリ２２１に保持される画像データをＣＲＴ表示器に画像信号として出力する画像表示制御回路２２２、等によって構成される。
【０１０４】
図１９は、従来のオブジェクトデータベースから見えないポリゴンを削ったオブジェクトデータベースを構築するアルゴリズムを説明するフローチャートである。
【０１０５】
まず、従来手法によって３Ｄグラフィックスのデータベースが構成され、あるいは既に構成された３Ｄグラフィックスのデータベースが用意される。ＣＰＵのメモリのワークエリアにデータベースから全ポリゴンのデータをロードする。ポリゴンのデータには座標データ等が含まれる（Ｓ２０２）。各ポリゴンに識別のための番号（ポリゴンＩＤ）を付ける。例えば、ロードした順番に番号付を行う（Ｓ２０４）。
【０１０６】
カメラ位置のデータをワークエリアにロードする。カメラ位置のデータには、カメラの座標及び向き（ベクトル）が含まれる（Ｓ２０６）。カメラ位置のデータに識別のための番号（カメラＩＤ）を付ける。例えば、ロードした順番に番号付を行う（Ｓ２０８）。
【０１０７】
次に、全てのカメラ位置で、カメラ位置から各ポリゴンが見えるかどうかの可視判別処理（Ｓ２１０）を行う。
【０１０８】
図２０は、可視判別処理のアルゴリズムを示すフローチャートである。この処理では、コンピュータシステム内に形成される三次元仮想空間に全オブジェクトを配置し、全てのポリゴンを描画する。この際、各ポリゴンの画素に当該ポリゴンのＩＤ番号を付加する（Ｓ２５２）。各カメラ位置（カメラＩＤ）において座標変換等を行ってカメラから見える投影画像を描画する。この際、いわゆるＺバッファ法等を用いて、表示領域内で重なるポリゴンのうち手前のものを見えるポリゴンとして描画し、陰になるポリゴンは描画しない（Ｓ２５４）。各カメラ位置で、描画された画素に付されたポリゴンのＩＤから、画面に描かれるポリゴンと、描かれないポリゴンとを判別する（Ｓ２５６）。全カメラ位置（カメラＩＤ）において、どのポリゴンが見え、どのポリゴンが見えないかを表す可視不可視のテーブル（VISIBLE FLAG TABLE）を作成する（Ｓ２５８）。その後、元のルーチンに戻る。
【０１０９】
図２１は、可視不可視テーブルの一例を示している。全カメラ位置（カメラＩＤ）において、全てのポリゴンについて当該カメラ位置から見えるかどうかが示される。見える場合は「１」で、見えない場合は「０」でフラグ表示されている。
【０１１０】
次に、各カメラ位置において描画されるオブジェクトを表すデータベースを得るべく、可視不可視テーブルでフラグ（VISIBLE FLAG）のパターンが同一・類似のポリゴンをグループ化し、各グループをオブジェクトデータとする（Ｓ２１２）。各オブジェクトデータに識別番号（オブジェクトＩＤ）を付す（Ｓ２１４）。
【０１１１】
この手順を説明する。第１に、全て「０」のフラグパターンであるポリゴン（例えば、ＰＯＬＹ４）は画面から見えないので、描画の対象とする必要はない。このようなポリゴンは除去する。第２に、図２２（ａ）に示すように、最初のポリゴンＰＯＬＹ０を最初のオブジェクトデータＯＢＪ０に含める。第３に、ポリゴンＰＯＬＹ０のフラグパターンと一致するフラグパターンのポリゴンを全て抽出し、これをオブジェクトデータＯＢＪ０に追加する（図２２（ｂ））。残りのポリゴンについて、手順２、３を繰返して、同じフラグパターンを持つポリゴンを集めてグループ化し、各グループをオブジェクトデータＯＢＪ１，ＯＢＪ２，…とする。
【０１１２】
次に、オブジェクトデータに類似するフラグパターンを持つポリゴンを抽出し、該当するオブジェクトデータに組入れる（図２２（ｃ））。例えば、オブジェクトデータ内の各ポリゴンのフラグパターンを論理和したパターンと１ビット違いのフラグパターンを持つポリゴンを抽出し、オブジェクトデータに組入れる。同様の手順を繰返して、所定ビット値違いのフラグパターンまでグループ分け（オブジェクトデータ化）する。
【０１１３】
次に、各カメラ位置において描画される（見える）オブジェクトデータを表す変換テーブルをつくる（Ｓ２１６）。この例を、図２３に示す。このテーブルを参照することによって各カメラ位置（カメラＩＤ）で三次元仮想空間に配置すべきオブジェクトが直ちに判る。
【０１１４】
例えば、カメラ位置０では、オブジェクトデータＯＢＪ０，ＯＢＪ１，ＯＢＪ３，…が配置される。カメラ位置１では、オブジェクトデータＯＢＪ０，ＯＢＪ３，…画配置される。ゲーム装置では、ゲーム展開に応じてカメラ位置を選択し、変換テーブルから該当するオブジェクトデータ群を読出し、各オブジェクトを構成するポリゴンを描画することによって各場面が描画される。
【０１１５】
更に、オブジェクトデータをデータベースに保存する（Ｓ２１８）。オブジェクトの変換テーブルをデータベースに保存する（Ｓ２２０）。
【０１１６】
なお、上述したアルゴリズムをビデオゲーム装置とは別途の画像処理専用コンピュータシステムによって高速に実行し、その結果得られたオブジェクトデータのデータベースをゲームソフトウェアとして情報記録媒体にプログラムと共に記憶することができる。
【０１１７】
図２４及び図２５は、本発明による、表示領域内において見えないポリゴンを除いたオブジェクトデータによって描画した画面例を説明するものである。図２４は、仮想三次元空間に形成されたゲームフィールドにおいて、カーレースの走行中の通常のカメラ位置による一場面の例を示している。図２５は、この場面を上方から見た状態を示している。同図に斜線で示す領域にはポリゴンは描画されておらず、画像が存在しない。従って、その分の仮想空間の組立や画像を変換等するに要する演算量が低減されている。
【０１１８】
このような、視野領域内におけるオブジェクトのクリッピングの適用例は、実施例のようなビデオゲームに限られるものではない。例えば、仮想三次元空間の様子を二次元画像に変換して表示するもの、例えば、種々の仮想体験用のシミュレーション等にも適用できる。
【０１１９】
（第２の実施形態）
本発明の第２の実施形態に係るビデオゲーム装置を図面に基づき説明する。本実施形態は、第１の実施形態で説明した画像の第２の特殊効果処理であるタイヤマークをさらに発展させたもので、今回のゲーム実行時にタイヤマークを処理・表示することは勿論、そのタイヤマークを次回のゲームにも反映させるようにしたものである。
【０１２０】
これを実現するため、ビデオゲーム装置は図２６に示すように、ＣＰＵブロック１０にＳＲＡＭ１９０を備え、このＳＲＡＭ１９０を、バス１０５を介してＳＣＵ１００、メインＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、およびサブＣＰＵ１０４に接続している。このＳＲＡＭ（不揮発性メモリ）１９０は主にゲーム終了時にそのゲームで発生したタイヤマークのデータを保存するために設けられている。
【０１２１】
また、本実施形態のビデオゲーム装置が備えているＲＡＭ（揮発性メモリ）１０２は、ゲーム中のタイヤマークのデータを含む各種のデータを保存するメモリとして搭載されている。このタイヤマークデータは２種類用意される。１つは、現在のゲームで発生中のタイヤマークデータであり、これは常に表示されるデータである。もう１つは、過去に発生したタイヤマークデータであり、ここではリザーブデータと呼んでいる。
【０１２２】
そのほかの構成は前述した第１の実施形態のものと同一または同等である。
【０１２３】
メインＣＰＵ１０１は、ゲームの展開に必要なゲーム処理を含むデータ全体をコントロールするためのメインプログラムを実行すると同時に、その処理と並行して図２７〜図３３の処理を行うように予めＲＯＭ１０３にプログラムされている。これらの処理は全てタイヤマークデータに関するものである。この内、図２７に示す処理は各回のゲーム開始直前にメインＣＰＵ１０１により実行され、図２８〜図３１に示す処理はゲーム実行中にメインＣＰＵ１０１により実行され、さらに図３２に示す処理はゲーム終了後に各回毎にメインＣＰＵ１０１により実行される。
【０１２４】
まず、図２７に示す処理を説明する。この処理はゲーム開始直前に実施される。メインＣＰＵ１０１はメインプログラムを実行している中で、入力装置２ｂから操作情報を確認しながらゲーム開始直前のタイミングを判定し、そのタイミングが判定できたときに図２７の処理を実行する。最初に、メインＣＰＵ１０１は、ＳＲＡＭ１９０に前回のゲームでタイヤマークのデータが保存されているか否かを、例えばフラグが立っているか否かで判断する（ステップＳ３０１）。この判断でＮＯ（データが保存されていない）のときは、そのままメインプログラムに戻る。反対にＹＥＳ（データが保存されている）のときは、そのデータをＳＲＡＭ１９０から読み出し、ＲＡＭ１０２に展開してゲーム実行中に使用可能なデータに変換（解凍処理など）する（ステップＳ３０２）。これにより、ＲＡＭ１０２には過去に発生したタイヤマークのデータ（リザーブデータ）として保存される。
【０１２５】
また、メインＣＰＵ１０１はメインプログラムを実行する中で、ゲーム実行中の表示インターラプト毎に図２８〜図３１の処理を実行する。このゲーム実行中の処理は、図２８に示すように、ＳＴＥＰ１のルーチンと呼ぶことにする、新規タイヤマークデータの処理ルーチン（ステップＳ３１１）、ＳＴＥＰ２のルーチンと呼ぶことにする、リザーブデータのソート（ステップＳ３１２）、およびＳＴＥＰ３のルーチンと呼ぶことにする、ＲＡＭの保存データの表示（ステップＳ３１３）からなり、これらＳＴＥＰ１〜３のルーチンがこの順に順次実行される。
【０１２６】
最初のＳＴＥＰ１のルーチンでは、メインＣＰＵ１０１によって、現在、タイヤマークの発生状態にあるか否かが、車の走行状態や遊戯者からの操作情報に基づいて判断される（ステップＳ３００１）。
【０１２７】
この判断がＹＥＳ（発生状態にある）のときは、次いで、車のタイヤの現在位置から新たなタイヤマークを形成する各マークの座標位置（ｘ，ｙ，ｚ）、角度（ｘ-角度、ｙ-角度、ｚ-角度）、長さ、および濃さのデータが算出される（ステップＳ３００２）。次いで、この算出データが現在発生中のタイヤマークデータとしてＲＡＭ１０２の所定記憶領域に一時保存される（ステップＳ３００３）。次いで、この保存されたタイヤマークデータをリアルタイムに表示させて（ステップＳ３００４）、メインプログラムに戻る。上述のステップＳ３００１〜Ｓ３００４の処理の詳細は、前述した第１の実施形態のものと同様または同等である。
【０１２８】
しかし、ステップＳ３００１の処理判断を表示フレーム毎に繰り返している中でタイヤマークの発生状態ではないと認識できたときは、ステップＳ３００５〜Ｓ３００８の処理を経てメインプログラムに戻る。すなわち、前回フレームから今までに発生したタイヤマークデータが在るか否かが判断され（ステップＳ３００５）、ＮＯの場合はメインプログラムに戻る。
【０１２９】
タイヤマークデータが在るときは（ＹＥＳ）、次いで、ＲＡＭ１０２のリザーブデータの格納（保存）領域に新たなデータを格納すべき空き領域が在るか否かを判断する（ステップＳ３００６）。この判断がＹＥＳ（空き領域在り）となるときは、そのままメインプログラムに戻る。反対にＮＯ（空き領域無し）の判断となるときは、リザーブデータの最後に位置するデータを消去する（ステップＳ３００７）。リザーブデータの最後尾のデータは後述するように、ＳＴＥＰ２のルーチンによって常に、最も不要なデータになっているので、記憶領域に空き領域が無い場合、消去して構わないことになっている。
【０１３０】
この消去によって空いた領域に、次いで、現在までに発生していたタイヤマークデータがリザーブデータとしてＲＡＭ１０２のリザーブデータ格納領域に保存される。この後、メインプログラムに戻る。
【０１３１】
続いてＳＴＥＰ２に係るリザーブデータのソート処理を図３０に沿って説明する。メインＣＰＵ１０１は、リザーブデータがＲＡＭ１０２に格納されているか否かを判断する（ステップＳ３０１１）。格納されていない（ＮＯ）の場合にはそのままメインプログラムに戻るが、格納されている（ＹＥＳ）の場合にはステップＳ３０１２〜Ｓ３０１７のソート処理をサイクリックに行う。
【０１３２】
このソート処理は以下ようである。リザーブデータの先頭データをデータＡとして設定する（Ｓ３０１２）。次いで、データＡの次の位置に当たるデータが在るか否かを判断する（Ｓ３０１３）。この判断がＮＯの場合はソートを行う必要が無いからメインプログラムに戻る。これに対して、ＹＥＳの判断、すなわちデータＡに次に該当するデータが在るときは、その該当データをデータＢとして設定する（Ｓ３０１４）。
【０１３３】
次いで、データＡのタイヤマークの構成枚数はデータＢのそれよりも少ないかどうかを判断する（Ｓ３０１５）。データＡの方が少ない（ＹＥＳ）場合、データＡとＢの内容を入れ替え（Ｓ３０１６）、データＢをデータＡとして扱うようにする（Ｓ３０１７）。しかし、データＡの方が多い（ＮＯ）場合、ステップＳ３０１６の処理をスキップする。ステップＳ３０１７の後、その処理はステップＳ３０１３に戻される。これにより、ステップＳ３０１３でＮＯの判断になって、リザーブデータ全部のソートが終わるまで上述した一連のソート処理が周期的に続けられる。
【０１３４】
これにより、ＲＡＭ１０２に格納されているリザーブデータは表示フレーム毎に自動的にソートされて整列し、その最後尾のマークデータは常に最も重要度の低い（構成枚数の少ない）データであることが保証される。このソートは一番外側のループが毎フレーム・ループになっているバブルソートである。
【０１３５】
さらに、ＳＴＥＰ３に係るＲＡＭ保存データの表示処理を図３１に沿って説明する。メインＣＰＵ１０１は、ＲＡＭ１０２に格納しているリザーブデータに仮想カメラ（視点）からの距離に応じてソートを掛ける（ステップＳ３０２１）。このときカメラ後方は距離＝無限大と見做してソートされる。実際には「１／カメラからのＺ距離」をパラメータとしてヒープソートが実施される。この結果、「１／カメラからのＺ距離」の値が最大になるものが表示フレーム毎に得られる。
【０１３６】
次いで、表示していないタイヤマークの中から、カメラからの距離に近いマークのデータを抽出し、表示する（ステップＳ３０２２、Ｓ３０２３）。ここでの表示も前述した第１の実施形態のものと同様に実施される。
【０１３７】
次いで、全ての保存データに対し、表示処理が終わったかどうかを判断する（ステップＳ３０２４）。ＮＯの場合、予め設定してある表示可能最大数を表示タイヤマークが超えたかどうかを判断し（ステップＳ３０２５）、ＹＥＳの判断ならばそのまま現在フレームに対する表示処理を終わる。ＮＯの判断のときは、ステップＳ３０２２の処理に戻って、上述した処理を表示タイヤマーク数が表示可能最大数に達するまで続ける。
【０１３８】
これにより、現在発生中のタイヤマークデータに加えて、それまでに発生したタイヤマークのその後の経時的な変化状態を表すリザーブデータも許容される限り、画面上でカメラ視点に近い方から優先して極力多数のものがフレーム毎に表示される。この表示処理の際、リザーブデータの位置座標値如何によっては、カメラ視野に入らない場合など、実際には表示されないでクリッピングされるデータもある。また、この非表示のもう１つの条件として表示可能最大数が設定されているので、これを超えた数のリザーブデータも実際には表示されない。この表示可能最大数は、ゲームボードの性能上、それ以上表示すると、いわゆるポリゴン欠けの現象が発生する可能性があるという状況を回避するために設定してある、タイヤマークポリゴンの最大表示数である。この設定により、リザーブデータについても画面のリアル感を演出する上で重要度の高いタイヤマークを安定して表示できる。
【０１３９】
さらに、ゲーム終了後のデータ保存処理を図３２、３３を参照して説明する。メインＣＰＵ１０１は、ゲーム終了時点でこの処理に入り、同図に示すように、ＲＡＭ１０２にゲーム終了時点で保存されているゲーム実行中のタイヤマークデータ全てについて、そのタイヤマークとして次回のゲーム時に表示するほどのものであるかどうか、その価値を判断（計算）する（ステップＳ３２１）。
【０１４０】
この価値判断の一例を図３３（ａ），（ｂ）に示す。いま、タイヤマークを構成しているポリゴン１枚につき３点、車走行コースのコーナ内側から車の中心位置までの距離がｘのとき「４／ｘ」点のように点数付けすると、図３３（ａ）の場合はポリゴン枚数による点数＝５枚×３点、距離による点数＝（４／３）点×５枚となり、同図（ｂ）の方はそれぞれ５枚×３点、（４／５）点×３枚＋（４／７）点＋（４／８）点となる。この両者を比較すると、明らかに同図（ａ）のタイヤマークの方が同図（ｂ）よりも点数が高い。すなわち、ここでの点数付けの条件に関する限り、同図（ａ）の方が価値が高いと見做すことができる。
【０１４１】
次いで、メインＣＰＵ１０１は上述した価値判断結果に応じて、その高い方からソートを実行する。このソートそのものはヒープソートとして実行されるが、そのソーティング判断基準が上述したタイヤマークとしての表示価値である点に特徴がある。つまり、このソートは、どのタイヤマークを残すかを決めるためのソートである。そのための条件は、上述の例に一部示した如く、マークの全長（マークの構成ポリゴン枚数）、マークの色の濃さ、マークの密度（１個所に集中しているかどうか）、マークの位置（コースのベストラインに近いかどうか）、見栄えのするタイヤマーク（クリッピング・ポイントに近いなど）などである。これらの条件それぞれに数値を設定し、その合計値をソートの判断基準とすることで、複数の条件（パラメータ）を満足させる価値判断によるソートを掛けることができる。上述した図３３の場合、このソートによって、より長く、かつ、よりコーナー内側に位置するタイヤマークが選択され続ける。
【０１４２】
このようにソートが掛けられた後、ＳＲＡＭ１９０に未だ格納していないタイヤマークデータの中から最も価値の高いデータを抽出する（ステップＳ３２３）。次いで、この抽出データをＳＲＡＭ１９０に格納保存するだけの記憶領域が残っているかどうかを判断し（ステップＳ３２４）、ＹＥＳの判断のときにそのデータをＳＲＡＭ１９０に圧縮して格納する（ステップＳ３２５）。この保存情報は、タイヤマークポリゴンの表示位置座標（Ｘ，Ｙ，Ｚ）、その表示方向（Ｘ，Ｙ，Ｚ）、およびそのスケール（長さ）、さらに濃さの８種類の値である。ＳＲＡＭ１９０の記憶領域が一杯になると、格納を停止して処理をメインプログラムに戻す。
【０１４３】
この結果、遊戯者がゲームを終了すると直ちに、それまでのゲーム実行中に発生したタイヤマークデータの中から、次回のゲーム実行における表示価値が判断され、その価値が高いデータから順に所定数のデータがＳＲＡＭ１９０に保存される。このため、ゲーム装置の電源をオフ状態にしても、このＳＲＡＭ１９０のデータは保存され、ゲームを再び実行したときに前述した図２７の処理を介してＲＡＭ１０２に戻される。そして、図２９、３０、３１の処理を経て新たなゲーム画面に表示または反映される。
【０１４４】
本実施形態では以上ように、ゲームが終了すると直ちに、ゲーム実行中のタイヤマークデータの価値を判断し、バックアップメモリ（ＳＲＡＭ）に表示価値の面から選択的に保存し、次回のゲームまたはパワーオンリセット後のゲームにそれを表示できる。このため、次回のゲームを行ったり、ゲームを再開したときに前回のゲーム時のスリップ痕などのタイヤマークが残った状態で画面表示され、従来には無かった非常にリアル感があり、かつゲームの臨場感を高揚させる演出を行うことができる。
【０１４５】
そして、このタイヤマークデータはゲーム実行中はリザーブデータの一部として扱い、ソートして、表示数やカメラ視野などに依る表示条件の元で極力その多くが表示される。このため、現在発生中のタイヤマークのみならず、それまでに発生したタイヤマークの表示も加わって、タイヤマークに関して非常に豊かで迫力のある画面を提供できる。なお、第１の実施形態で説明したタイヤマークに関する作用効果も当然に合わせて享受することができる。
【０１４６】
また、バックアップメモリ（ＳＲＡＭ）の記憶容量は通常、例えば６４ＫＢと少ないため、これに保存するタイヤマークデータ量は制限される。これについても、表示価値に応じてソートして優先順位の高いデータから保存するようにしているので、かかる少ない記憶容量で間に合うことになる。しかも、このソート及びデータ保存はゲーム実行中には行わずに、ゲームが終了した時点で行うようにしているから、メインＣＰＵを中心とする演算要素に掛かる演算負荷を軽減できる。また、ゲーム実行中にもソートを行っても良い。このとき、ゲーム処理中のＣＰＵの処理負担を削減する観点から、ゲーム実行中のソートをゲーム終了後のソートに比較して、ＣＰＵの処理負担が軽い比較的簡単な内容のソートにとどめることもできる。
【０１４７】
【発明の効果】
以上述べたように、本発明によれば、画面に光源からの入射光線によるフレアが表現されるので、まぶしい場面や演出された場面を楽しむことが可能となる。
【０１４８】
また、本発明によれば、車両やスキー等の移動するオブジェクトの痕跡をポリゴン数を比較的増やさずに描画することが可能となって好ましい。加えて、一度ゲームを終了させても、演算負荷やメモリ容量の増大を抑えた状態で、オブジェクトの痕跡を次回のゲーム画面に的確に反映させることができ、臨場感やリアル感を一層高めることができる。
【０１４９】
また、本発明の画像形成方法は、表示領域内において不可視のポリゴンをクリップしてオブジェクトデータベースを形成するので、従来よりも少ない演算量で従来と同様の画面を描画することが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態のゲーム装置の機能ブロック図である。
【図２】フレア形成のアルゴリズムを説明するフローチャートである。
【図３】フレアの発生条件を説明する説明図である。
【図４】フレア発生画面の例を示す説明図である。
【図５】フレア形成の他のアルゴリズムを説明するフローチャートである。
【図６】図５に示すアルゴリズムを説明するグラフである。
【図７】フレアの程度をテーブルによって求める例を説明する説明図である。
【図８】光源の移動によってフレアを意図的に生ぜしめる例を説明する説明図である。
【図９】タイヤマークを表示するアルゴリズムを説明するフローチャートである。
【図１０】ＲＡＭの内容を説明する説明図である。
【図１１】書込みが一巡したＲＡＭの状態を説明する説明図である。
【図１２】図１１のＲＡＭによって描画されるタイヤマークを説明する説明図である。
【図１３】ＲＡＭ番号とタイヤマークのパターンの対応関係を説明する説明図である。
【図１４】スリップ痕が描かれた画面を説明する説明図である。
【図１５】三次元仮想空間に配置されたオブジェクトの例を説明する説明図である。
【図１６】表示領域内においてオブジェクトに見えない部分がある例を説明する説明図である。
【図１７】オブジェクトの見えない部分（ポリゴン）を削除した例を説明する説明図である。
【図１８】画像データ処理装置の概略を説明するブロック図である。
【図１９】表示領域でカメラから見えないポリゴンを削除してオブジェクトデータベースを形成する例を説明するフローチャートである。
【図２０】ポリゴンの可視、不可視を判別する例を説明するフローチャートである。
【図２１】ポリゴンの可視、不可視を表すテーブルを説明する説明図である。
【図２２】ポリゴンデータのオブジェクトグループ化を説明する説明図である。
【図２３】カメラＩＤによって描画するオブジェクトを選択する変換テーブルを説明する説明図である。
【図２４】通常の視点で３Ｄ描画した画面を説明する説明図である。
【図２５】図２４と同じ三次元仮想空間で視点を上方に移動した場合の画像を説明する説明図である。
【図２６】本発明の第２の実施形態に係るゲーム装置を示す機能ブロック図である。
【図２７】ゲーム開始直前のタイヤマークデータの読出し処理を示す概略フローチャートである。
【図２８】ゲーム実行中のタイヤマークデータの処理を示す概略フローチャートである。
【図２９】図２８に示す処理のＳＴＥＰ１の処理ルーチンをより詳細に示す概略フローチャートである。
【図３０】図２８に示す処理のＳＴＥＰ２の処理ルーチンをより詳細に示す概略フローチャートである。
【図３１】図２８に示す処理のＳＴＥＰ３の処理ルーチンをより詳細に示す概略フローチャートである。
【図３２】ゲーム終了後のタイヤマークデータの保存処理を示す概略フローチャートである。
【図３３】ゲーム終了後のタイヤマークデータの保存処理に伴う価値判断の一例を説明する図である。
【符号の説明】
１ ビデオゲーム装置本体
１ａ カートリッジＩ／Ｆ
１ｂ ＣＤ−ＲＯＭドライブ
２ａ コネクタ
２ｂ ゲーム操作用のパッド
２ｃ ケーブル
３ａ コネクタ
３ｂ フロッピー（登録商標）ディスクドライブ（ＦＤＤ）
３ｃ ケーブル
４ａ、４ｂ ケーブル
５ ＴＶ受像機
１０ ＣＰＵブロック
１１ ビデオブロック
１２ サウンドブロック
１３ サブシステム
１００ ＳＣＵ（System Control Unit）
１０１ メインＣＰＵ
１０２ ＲＡＭ
１０３ ＲＯＭ
１０４ サブＣＰＵ
１０５ ＣＰＵバス
１０６、１０７ バス
１２０、１３０ ＶＤＰ
１２１ ＶＲＡＭ
１２２、１２３ フレームバッファ
１３１ ＶＲＡＭ
１３２ メモリ
１４０ ＤＳＰ
１４１ ＣＰＵ
１６０ エンコーダ
１８０ ＣＤ Ｉ／Ｆ
１８１ ＣＰＵ
１８２ ＭＰＥＧ ＡＵＤＩＯ
１８３ ＭＰＥＧ ＶＩＤＥＯ
１９０ ＳＲＡＭ
【発明の属する技術分野】
本発明は、ビデオゲーム装置に関する。特に、アミューズメントセンターや家庭に設置されたゲーム装置でよりリアルな画像表現を行い得るようにしたゲーム装置に関する。
【０００２】
【従来の技術】
コンピュータ技術の進歩に伴い、コンピュータグラフィックス技術を用いたビデオゲーム装置が広く利用されるようになってきた。この種のビデオゲーム装置はユーザに広く受け入れられている。そして、多種多様なゲーム装置が数多く案出され、それ等に対応した様々なゲームソフトが供給されている。
【０００３】
【発明が解決しようとする課題】
ユーザがビデオゲームをより楽しむことができるようにするために、画像がよりリアルな表現で画面に表示されることが望まれる。例えば、カーレースのような車両競走においては、車両や背景の動きが自然に表現され、運転中に起こり得ること、例えば、フロントガラスでの光の反射等が特殊効果として画面に表現されることが望ましい。また、車両のタイヤスリップの痕跡等が現れれば面白い。しかも、その痕跡などはゲーム再開時に前回のゲームで生じた痕跡などが路面に残っていると、なお一層迫力のある画面になり、臨場感を高めることは容易に想像できる。
【０００４】
他方、三次元画面（３Ｄ）表示は、座標変換等の複雑な演算を繰返すため、ＣＰＵが負担する演算量が膨大になる。このため、画像表現の特殊効果等を行うと、これに使用される演算量の分だけ画面に表示するポリゴンの数を減らなければならない。
【０００５】
よって、本発明は、遊技者が光源によるまぶしさを体感できる画面を表現できるビデオゲーム装置を提供することを第１の目的とする。
【０００６】
また、本発明は、ビデオゲームにおいて移動するオブジェクト(object)の痕跡を画面に表現できるゲーム装置を提供することを第２の目的とする。
【０００７】
また、本発明は、ビデオゲームにおいて移動するオブジェクトの痕跡を画面に表現でき、かつ、その痕跡がゲーム実行中のみならず、次回のゲームにも反映させることができるビデオゲーム装置を提供することを第３の目的とする。
【０００８】
また、本発明は、三次元仮想空間におけるゲーム展開を二次元の画面に立体的に見えるように表示するに際し、描画ルーチンにおける演算量を減らすことのできる方法を提供することを第４の目的とする。
【０００９】
【課題を解決するための手段】
上記目的を達成するため、本発明のゲーム装置は、三次元仮想空間で仮想カメラの視点(a visual point)を移動して、視野に入った場面(the scene came into the view)の画像を表示する(display)ゲーム装置において、視野内に光源が存在するときに、画像(picture)にフレア(flare)を形成するフレア処理手段（Ｓ１０２〜Ｓ１１８）を含む。上記フレア処理手段は、上記視点の視線方向を表す視線ベクトルを得る視線ベクトル生成手段（Ｓ１０６）と、上記視点から光源の方向を表す光線ベクトルを得る手段（Ｓ１０４）と、上記視線ベクトルと上記光線ベクトルとの内積(the inner product) を計算する内積計算手段（Ｓ１０８）と、上記画像に上記内積に応じた強度のフレアを形成するフレア形成手段（Ｓ１１２〜Ｓ１１８）と、を備えることを特徴とする。このようにすることによって、光源の視点からの位置及び／又は光源の強度に対応したフレアの形成が可能となる。そして、より実際のシーンに近い表現となり、映像効果の強化されたゲーム画像を形成することが可能となって、ゲームが面白くなる。
【００１０】
また、上記内積と基準値との比較結果に基づいて、上記フレア形成手段を活性化させる判別手段（Ｓ１１０）、を更に備えることを特徴とする。これにより、敢えてフレアを発生させる程の強さでない光源である場合に、フレア形成を回避してフレア処理を行うことによる画質の低下を防止することが可能となる。
【００１１】
また、上記フレア形成手段は、上記内積に応じて画像の白味の度合を増す（Ｓ１１２）、ことを特徴とする。これにより、フレアによる画像への影響（フレア効果）が表現される。
【００１２】
また、上記フレア形成手段は、上記内積に応じた透明度のフレアポリゴンの画像を形成する（Ｓ１１４、Ｓ１１８）、ことを特徴とする。これにより、カメラレンズのフレアを表現することが可能となる。
【００１３】
また、上記フレア形成手段は、予め定められた内積の上限値と下限値との間において、上記内積に応じた画像への白味の付加処理及び上記内積に応じた透明度のフレアポリゴンの形成処理の少なくともいずれかを行う、ことを特徴とする。これにより、強度の弱い光源によるフレア発生の回避と強度の強い光源よる過度のフレア処理の回避とが可能となる。
【００１４】
また、上記フレア形成手段は、上記視点と上記光源とを結ぶ直線上に上記フレアを形成する（Ｓ１１６，Ｓ１１８）、ことを特徴とする。これにより、仮想カメラへの光線の入射が表現される。
【００１５】
本発明のゲーム装置は、三次元仮想空間で視点を移動して視野に入った場面を画像として表示するゲーム装置において、上記視点の視野内に光源が存在するときに、上記画像にフレアを形成するフレア処理手段を含み、上記フレア処理手段は、上記光源の視野内の位置や光源の強度等に応じて上記フレアの程度を決定する、ことを特徴とする。この際に、テーブルや関数を用いてフレアの程度を上述した上限値や下限値等を考慮した適当な値に決定することができる。
【００１６】
フレアは、例えば、画面上に周囲よりも比較的に白味の度合いの高い平面形状若しくは中空の平面形状を表示することによって表現される。このフレアの表示、非表示を短時間内に繰り返す（フラッシング）ことにより、より実際のフレア発生の状態に似せることが可能となる。また、フレア（特に、中空でないフレア画像）によって背景の画像が継続的に遮られることを回避して、ゲーム操作に支障のないようにすることが可能となる。
【００１７】
フレアを入射光線に相当する直線上に複数表示する、ことによってよりフレアらしく見せることが可能となる。この際に、複数表示されるフレアを相似形によって形成することにより、演算の負担をより軽減することが可能となる。
【００１８】
また、上記光源は上記三次元仮想空間内に配置された仮想太陽であり、この仮想太陽が、所定の場面において上記画像にフレアを生ぜしめるために、上記三次元仮想空間内における上記仮想太陽の正規の配置位置から上記所定の場面の視野内に再配置される、ことを特徴とする。このようにすると、ゲーム場面中に光源を意図的に存在せしめてフレアを発生させて、ゲーム場面を演出することが可能となる。
【００１９】
本発明のゲーム装置は、ゲームの展開に従って移動するオブジェクトを画像として表示するゲーム装置において、上記オブジェクトの現在位置を読取る手段（Ｓ１３２）と、上記現在位置から所定範囲内の長さで痕跡マーク(trace mark)を描画すると共に、上記痕跡マークの後端側を時間経過と共に徐々に薄くして消滅させる痕跡マーク描画手段（Ｓ１３２〜Ｓ１５８）と、を備えることを特徴とする。これにより、タイヤ等の痕跡ポリゴンを減少して画像処理の演算量を減らすことが可能となる。
【００２０】
上記痕跡マークは、好ましくは、複数部分からなり、各部分は上記痕跡マークの先端部分から後端部分に向かって薄くなるパターンを分担する。各部分が分担する痕跡のパターンは予め形成されたパターンを使用することができる。また、基本となる痕跡のパターンの透明度を変えて各部分のパターンとして使用することが可能である。
【００２１】
また、上記痕跡マーク描画手段は、上記オブジェクトの現在位置が、描画された痕跡マークの先端位置(top position)から所定値以上離れる(spaced)までは（Ｓ１３４）、上記痕跡マークの先端部分のみを延長し（Ｓ１４２〜Ｓ１５２）、所定値以上離れたときは上記痕跡マーク全体を上記所定値だけ上記オブジェクトの現在位置に向って移動する（Ｓ１３６〜Ｓ１５８）、ことを特徴とする。これにより、遊技者に違和感のない痕跡マークを描画すると共に、痕跡マーク全体の長さを一定長に制限して、画像処理の演算量の増加を抑制することが可能となる。
【００２２】
また、上記痕跡マーク描画手段は、上記オブジェクトの移動速度に応じて描画された痕跡の消滅タイミングを加減する（Ｓ１３２〜Ｓ１５８）、ことを特徴とする。
【００２３】
また、上記痕跡マーク描画手段は、上記オブジェクトが停止しているときは描画された痕跡マークを消滅させず、上記オブジェクトが移動しているときは描画された痕跡マークをオブジェクトの移動速度に応じて早く消滅させる（Ｓ１３２〜Ｓ１５８）、ことを特徴とする。これにより、痕跡マークがオブジェクトの移動に追従する。
【００２４】
また、上記痕跡マーク描画手段は、好ましくは、上記オブジェクトが停止して所定時間を経過したときには、描画した痕跡マークを消去する。これにより、表示ポリゴン（スリップ痕跡）の数を減らしてＣＰＵの演算の負担を軽減することが可能となる。
【００２５】
上記痕跡マーク描画手段は、上記複数部分からなるマーク（図９）の各部分にそれぞれ対応する複数の記憶領域に上記マークの各部の位置を保持する巡回レジスタ（図１０）と、マークの先頭に対応する巡回レジスタの記憶領域を示すマーク先頭位置指示手段（図６、図８）と、を有することを特徴とする。
【００２６】
これに加えて、本発明の痕跡マークに関する別の特徴を得る構成は、ゲームの展開に伴って仮想空間を移動するオブジェクトを画像として表示するゲーム装置であって、前記ゲームの実行中の前記オブジェクトの移動に伴う痕跡マークおよび過去の痕跡マークを処理して表示させる処理表示手段（図２８〜図３１）と、前記ゲームの終了後に前記痕跡マークを記憶する第１の記憶手段（図３２）と、前記ゲームの開始前に前記第１の記憶手段から当該第１の記憶手段が記憶している前記痕跡マークを読み出して前記処理表示手段に前記過去の痕跡マークとして与える読出し手段（図２７）と、を備える。
【００２７】
例えば、前記処理表示手段（図２８〜図３１）は、前記オブジェクトの移動に伴う新規の前記痕跡マークを処理して表示させる第１の表示手段（Ｓ３００１〜Ｓ３００４）と、前記過去の痕跡マークを含む現在までに発生した痕跡マークを記憶する第２の記憶手段（Ｓ３００１、Ｓ３００５〜Ｓ３００８、Ｓ３０１１〜Ｓ３０１７）と、この第２の記憶手段に記憶した痕跡マークをソートするソート手段（Ｓ３０２１）と、このソート手段のソート結果に応じて前記痕跡マークを処理して表示させる第２の表示手段（Ｓ３０２２〜Ｓ３０２５）とを備える。
【００２８】
好適には、前記第２の記憶手段は、前記痕跡マークをその大きさに応じてソートする手段（Ｓ３０１１〜Ｓ３０１７）と、このソート結果による優先度の低い痕跡マークを消去して新規に発生した痕跡マークを記憶するメモリ手段（１０２）を備える。
【００２９】
また好適には、前記ソート手段（Ｓ３０２１）は、前記仮想空間内で仮想カメラから前記痕跡マークまでの距離に応じてソートする手段である。
【００３０】
さらに好適には、前記第２の表示手段（Ｓ３０２２〜Ｓ３０２５）は、前記痕跡マークのポリゴンを表示可能な最大数を加味して当該痕跡マークを表示させる手段である。
【００３１】
一方、前記第１の記憶手段（図３２）は、前記痕跡マークの表示価値を判断する判断手段（Ｓ３２１）と、この判断手段の判断結果に応じて前記痕跡マークをソートするソート手段（Ｓ３２２）と、このソート手段のソート結果による優先順位の高い痕跡マークからその所定数のみを保存するメモリ手段（Ｓ３２３〜Ｓ３２５、１９０）とを備えることができる。前記表示価値の判断条件には、前記痕跡マークの長さおよび位置の条件が含まれる。
【００３２】
前記処理表示手段（図２８〜図３１）は、前記オブジェクトの現在位置を読み取る手段と、前記現在位置から所定範囲内の長さで痕跡マークを描画すると共に、前記痕跡マークの後端側を時間経過と共に徐々に薄くして消滅させる痕跡マーク描画手段と、を備えることを特徴とする。
【００３３】
この構成により、ゲームが終了すると直ちに、ゲーム実行中のタイヤマークデータなどの痕跡マークデータの価値が判断され、メモリ（ＳＲＡＭ）に表示価値の高い順に選択的に保存され、次回のゲームにそれが表示される。このため、次回のゲーム時に前回のゲーム時のスリップ痕などのタイヤマークが残った状態で画面表示され、非常にリアル感があり、かつゲームの臨場感を高い。また、このタイヤマークデータはゲーム実行中は過去データの一部として扱われ、ソートされて、表示最大数やカメラ視野などに依る表示条件の元で極力その多くが表示される。
【００３４】
一方、ゲーム終了時に保存するタイヤマークデータ量はマークの表示価値に応じてソートされ、優先順位の高いデータから保存されるので、その記憶容量も少なくて済む。また、このソート及びデータ保存はゲーム実行中には行わずに、ゲームが終了した時点で行うようにしているから、ＣＰＵを中心とする演算要素に掛かる演算負荷を軽減できる。
【００３５】
本発明の媒体は、コンピュータシステムを上述したゲーム装置として機能させるプログラムを記録している。
【００３６】
本発明の画像データの形成方法は、ポリゴンによって構成されるオブジェクトを三次元仮想空間に配置する過程（Ｓ２０２）と、三次元仮想空間内に視点を設定し、この視点から見た表示領域内のポリゴンを投影面に投影して投影画像を形成する過程（Ｓ２５４）と、上記投影面に形成された投影画像から上記視点における各ポリゴンの可視又は不可視の識別を行う過程（Ｓ２５６）と、各ポリゴンの可視又は不可視を表すデータによってオブジェクトデータを形成する過程（Ｓ２１２）と、上記視点とオブジェクトデータとを関連付ける過程（Ｓ２１６）と、を含む。
【００３７】
本発明の画像データの形成方法は、ポリゴンによって構成される全てのオブジェクトを三次元仮想空間に配置する過程（Ｓ２０２）と、三次元仮想空間内に複数の視点を設定する過程（Ｓ２０４）と、各視点から見た表示領域内のポリゴンをそれぞれの投影面に投影して各視点毎に投影画像を形成する過程（Ｓ２５２、Ｓ２５４）と、上記投影面に形成された投影画像から各視点における各ポリゴンの可視又は不可視の識別を行う過程（Ｓ２５６）と、上記識別結果に基づいて、各視点における各ポリゴンの可視又は不可視を表すデータを形成する過程（Ｓ２５８）と、各視点における可視又は不可視を表す各ポリゴンのデータパターンによって同一又は類似のパターンをグループ化して複数のオブジェクトデータを形成する過程（Ｓ２１２）と、各視点から見えるオブジェクトデータを表すオブジェクトテーブルを形成する過程（Ｓ２１６）と、を含む。
【００３８】
本発明の媒体は、コンピュータシステムに、上述した画像データの形成方法の各過程を実行させるためのプログラムを記録している。
【００３９】
【発明の実施の形態】
以下、本発明の実施形態を図面を参照しながら説明する。
【００４０】
（第１の実施形態）
第１の実施形態に係るビデオゲーム装置を説明する。このビデオゲーム装置は、本発明の特殊効果画像のアルゴリズムを実行し得る構成を備えている。
【００４１】
図１は、ビデオゲーム装置の概要を表すブロック図である。この装置は、装置全体の制御を行うＣＰＵブロック１０、ゲーム画面の表示制御を行うビデオブロック１１、効果音等を生成するサウンドブロック１２、ＣＤ−ＲＯＭの読み出しを行うサブシステム１３等により構成されている。
【００４２】
ＣＰＵブロック１０は、ＳＣＵ（System Control Unit）１００、メインＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、カートリッジＩ／Ｆ１ａ、サブＣＰＵ１０４、ＣＰＵバス１０３等により構成されている。メインＣＰＵ１０１は、装置全体の制御を行うものである。このメインＣＰＵ１０１は、内部にＤＳＰ（Digital Signal Processor）と同様の演算機能を備え、アプリケーションソフトを高速に実行可能である。
【００４３】
ＲＡＭ１０２は、メインＣＰＵ１０１のワークエリアとして使用されるものである。ＲＯＭ１０３には、初期化処理用のイニシャルプログラム等が書き込まれている。ＳＣＵ１００は、バス１０５、１０６、１０７を制御することにより、メインＣＰＵ１０１、ＶＤＰ１２０、１３０、ＤＳＰ１４０、ＣＰＵ１４１等の間におけるデータ入出力を円滑に行うものである。また、ＳＣＵ１００は、内部にＤＭＡコントローラを備え、ゲーム中のオブジェクト（あるいはスプライト）データをビデオブロック１１内のＶＲＡＭに転送することができる。これにより、ゲーム等のアプリケーションソフトを高速に実行することが可能である。カートリッジＩ／Ｆ１ａは、ＲＯＭカートリッジの形態で供給されるアプリケーションソフトを入力するためのものである。
【００４４】
サブＣＰＵ１０４は、ＳＭＰＣ（System Manager & Peripheral Control）と呼ばれるもので、メインＣＰＵ１０１からの要求に応じて、入力装置２ｂからペリフェラルデータをコネクタ２ａを介して収集する機能等を備えている。メインＣＰＵ１０１はサブＣＰＵ１０４から受け取ったペリフェラルデータに基づき、例えばゲーム画面中の車両（オブジェクト）を移動させる等の処理を行うものである。コネクタ２ａには、ハンドル、アクセル及びブレーキ等からなる操縦装置が接続される。また、ＰＡＤ、ジョイスティック、キーボード等のうちの任意のペリフェラルも接続可能である。コネクタ２ａに２台の操縦装置２ｂを接続することによってカーレースの対戦を行うことが可能となる。サブＣＰＵ１０４は、コネクタ２ａ（本体側端子）に接続されたペリフェラルの種類を自動的に認識し、ペリフェラルの種類に応じた通信方式に従いペリフェラルデータ等を収集する機能を備えている。
【００４５】
ビデオブロック１１は、主に、ビデオゲームのポリゴンデータから成るオブジェクト等の描画を行うＶＤＰ（Video Display Processor）１２０、主に、背景画面の描画、ポリゴン画像データ（オブジェクト）および背景画像の合成、クリッピング処理等を行うＶＤＰ１３０とを備えている。
【００４６】
ＶＤＰ１２０には、ＶＲＡＭ１２１、複数のフレームバッファ（図示の例では、１２２、１２３の２つ）に接続される。ビデオゲーム装置のオブジェクトを表すポリゴンの描画コマンドはメインＣＰＵ１０１からＳＣＵ１００を介してＶＤＰ１２０に送られ、ＶＲＡＭ１２１に書き込まれる。ＶＤＰ１２０は、ＶＲＡＭから描画コマンドを内部のシステムレジスタに読込み、フレームバッファに描画データを書込む。描画されたフレームバッファ１２２または１２３のデータはＶＤＰ１３０に送られる。ＶＤＰ１２０は定形オブジェクト、拡縮オブジェクト、変形オブジェクト等を表示するテクスチャパーツ表示、四角形ポリゴン、ポリライン、ライン等を表示する非定形オブジェクト表示、パーツ同士の半透明演算、半輝度演算、シャドウ演算、ぼかし演算、メッシュ演算、シェーディング演算等の色演算、メッシュ処理、設定した表示領域以外の描画をしないようにするクリッピングを行う演算機能、等を備えている。また、行列演算を行うジオメタライザを備えており、拡大、縮小、回転、変形、座標変換等の演算をを素早く行うことができる。
【００４７】
ＶＤＰ１３０はＶＲＡＭ１３１に接続され、ＶＤＰ１３０から出力された画像データはメモリ１３２を介してエンコーダ１６０に出力される構成となっている。ＶＤＰ１３０は、ＶＤＰ１２０の持つ機能に加えて、スクロール画面表示を制御するスクロール機能と、オブジェクト及び画面の表示優先順位を決めるプライオリティ機能等を備える。
【００４８】
エンコーダ１６０は、この画像データに同期信号等を付加することにより映像信号を生成し、ＴＶ受像機５（あるいはプロジェクタ）に出力する。これにより、ＴＶ受像機５に各種ゲームの画面が表示される。
【００４９】
サウンドブロック１２は、ＰＣＭ方式あるいはＦＭ方式に従い音声合成を行うＤＳＰ１４０と、このＤＳＰ１４０の制御等を行うＣＰＵ１４１とにより構成されている。ＤＳＰ１４０により生成された音声データは、Ｄ／Ａコンバータ１７０により２チャンネルの信号に変換された後にスピーカ５ｂに出力される。
【００５０】
サブシステム１３は、ＣＤ−ＲＯＭドライブ１ｂ、ＣＤ Ｉ／Ｆ１８０、ＣＰＵ１８１、ＭＰＥＧ ＡＵＤＩＯ１８２、ＭＰＥＧ ＶＩＤＥＯ１８３等により構成されている。このサブシステム１３は、ＣＤ−ＲＯＭの形態で供給されるアプリケーションソフトの読み込み、動画の再生等を行う機能を備えている。ＣＤ−ＲＯＭドライブ１ｂはＣＤ−ＲＯＭからデータを読み取るものである。ＣＰＵ１８１は、ＣＤ−ＲＯＭドライブ１ｂの制御、読み取られたデータの誤り訂正等の処理を行うものである。ＣＤ−ＲＯＭから読み取られたデータは、ＣＤ Ｉ／Ｆ１８０、バス１０６、ＳＣＵ１００を介してメインＣＰＵ１０１に供給され、アプリケーションソフトとして利用される。また、ＭＰＥＧ ＡＵＤＩＯ１８２、ＭＰＥＧ ＶＩＤＥＯ１８３は、ＭＰＥＧ規格（Motion Picture Expert Group）により圧縮されたデータを復元するデバイスである。これらのＭＰＥＧ ＡＵＤＩＯ１８２、ＭＰＥＧ ＶＩＤＥＯ１８３を用いてＣＤ−ＲＯＭに書き込まれたＭＰＥＧ圧縮データの復元を行うことにより、動画の再生を行うことが可能となる。
【００５１】
次に、本発明に係る画像の第１の特殊効果の例について図２、図３及び図４を参照して説明する。
【００５２】
本実施形態では、ゲームの展開中に光源からいわゆる仮想カメラに光線が入射したときに、画像中に光線によるフレアを発生させて、よりリアリティのある画像を提供するものである。図２は、フレア形成のアルゴリズムを説明するフローチャート、図３は、フレア発生の条件判断を説明する説明図、図４は、フレアを生ぜしめた画像の例を示す説明図である。
【００５３】
まず、ＣＰＵ１０１は、図示しない主ゲームプログラム及び運転操作のデータに従って三次元仮想空間でカーレースゲームを展開する。主ゲームプログラムやデータはＲＯＭカートリッジやＣＤ−ＲＯＭ、フロッピー（登録商標）ディスク等の情報記録媒体によって供給され、予めメモリ内にロードされる。また、プログラムやデータは、インターネット、パソコン通信、衛星通信等の通信網や放送等の媒体を媒介としてダウンロードしても良い。ＣＰＵ１０１は、三次元仮想空間に車両や背景のオブジェクトを配置し、ＴＶ受像機のフレーム周期に同期してオブジェクトの位置・移動等を制御する。
【００５４】
図３は、三次元仮想空間を遊技者あるいは運転者等の視点に相当する仮想カメラで観察する様子を示すものであり、同図において、２１は仮想カメラ（視点）、２２はテレビモニタの画面に相当する投影面、２３はゲームが展開される三次元仮想空間、２４は三次元仮想空間に配置された仮想光源、２５は仮想カメラの視野範囲、Ａはカメラ位置と光源とを結ぶ線上にある単位ベクトル、Ｂは仮想カメラの向き方向に存在する単位ベクトル、θはベクトルＡとＢとのなす角度である。なお、後述するように、ベクトルは単位ベクトルに限定されない。
【００５５】
ＣＰＵ１０１は、主ゲームプログラムの実行中に、仮想カメラの視野（あるいは画面）２５内に、太陽、街路灯等の光源ポリゴン２４が入っているかどうかを判断する（Ｓ１０２）。これは、各シーン毎に仮想空間に配置されるオブジェクトが予めデータベース化され、該当シーンにリストアップされたオブジェクトの個別番号によって光源のオブジェクトの存在を知ることが可能である。
【００５６】
視野内に光源オブジェクトが存在しない場合は、フレアは発生しないので本画像処理は終了する。
【００５７】
視野内に光源オブジェクトが存在すると、ＣＰＵ１０１は、光源からの光線がカメラレンズに入射するかどうか、その影響の程度等を判断するべく、カメラが光源方向にどの程度向いているか、あるいは光源の視野内の位置関係等を判断する。このため、三次元仮想空間におけるカメラ位置と、光源オブジェクトとを結ぶ線分を求め、単位長のベクトルＡを得る（Ｓ１０４）。このシーンにおける三次元仮想空間でのカメラ２１の向きをデータベースから求め、カメラの向きを表す単位ベクトルＢを得る（Ｓ１０６）。単位ベクトルＡ及びＢの内積Ｃ、すなわち、Ｃ＝│Ａ│・│Ｂ│ｃｏｓθを計算する。両ベクトルの方向が一致すればθは０度となり、内積は１となる。逆に、両ベクトルの向きが離れるほど、内積は０に近づく（Ｓ１０８）。なお、光源の強度を内積Ｃに反映させる場合には、ベクトルＡの値を単位長「１」ではなく、光源の強度に対応した値とする。この場合のベクトルＡは、方向及び大きさ（光の強さ）を持つ入射光線に相当する。
【００５８】
ＣＰＵ１０１は、内積とフレアの発生条件として予め定められた基準値とを比較する。内積Ｃが、基準値（閾値）を越えるかどうかを判断する（Ｓ１１０）。越えない場合は、フレアは生じない、あるいはフレアを生じさせる程のものではないので、本画像処理を終了してメインプログラムに戻る。フレア処理は、光源によって画像が影響を受けたと遊技者が認識できる程度に行うべきである。さもなければ、フレア処理（例えば、後述のフォグ効果）が一種の画質の低下の原因とな得る。これを上記判断（Ｓ１１０）によって、回避可能である。
【００５９】
内積Ｃが基準値を越える場合、ＣＰＵ１０１はフレア処理を行う。まず、内積の値Ｃが大きいほど真っ直ぐに光源から光線がカメラレンズに入射することになるので、より強くフレアが発生する。そこで、値Ｃに比例して画像に白味をかけ、いわゆる「フォグ効果」を生ぜしめる。これは、ＶＤＰ１２０、１３０の色演算の輝度・色度パラメータを変えることによって実現可能である（Ｓ１１２）。次に、Ｃの値に比例した透明度Ｄを求める（Ｓ１１４）。カメラ位置と光源オブジェクトの位置とを結ぶ直線を２次元画面上の直線Ｅに変換し、スクリーン画像における光線のルートを特定する（Ｓ１１６）。直線Ｅに沿って、適当な位置に透明度Ｄのフレアポリゴンを描画する。例えば、透明度Ｄが半透明の場合には、下地の画像の輝度を半分にしたものとフレアポリゴンの輝度を半分にしたものを加算し、その結果をフレームバッファに描画する。それによって、フレア画像が得られる（Ｓ１１８）。視野内に光量の大なる複数の光源ポリゴンが存在する場合には、各ポリゴンに対して上述したフレア発生処理を行う。
【００６０】
なお、フォグ効果とフレアポリゴンの処理のうちいずれか一方のみを実施しても良い。また、視野内に光源が存在する場合（Ｓ１０２；Ｙｅｓ）、光源による影響をそれなりに受ける。影響の程度は内積Ｃにより制御される。従って、閾値を設定する（Ｓ１１０）ことは必須ではない。また、例えば、視野内に光源が存在する場合に、内積Ｃによってフレアポリゴンの透明度を調整し、内積Ｃ がしきい値を越えたときから、これに追加してフォグの効果を内積Ｃに比例して生ぜしめることとしても良い。更に、太陽、街灯等の光源の種類、光源の強度を加味して上記画像の白味や透明度を調整することが可能である。
【００６１】
図４は、レース中の画像にフレアが発生した様子を示している。この例では、光源オブジェクトは画面右上に存在し、表示しない直線Ｅに沿って環状のフレアポリゴン、円状のフレアポリゴンが表示されている。フレアポリゴンの形状は図示の輪郭が略円形状等のものに限定されない。例えば、輪郭が多角形のものであっても良い。フレアポリゴンは、半透明処理の他、予め形成されたフレアポリゴンを半透明処理することなくそのまま表示することとしても良い。このようなフレアポリゴンの表示と消滅とを繰り返して点滅（フラッシング）するような表現形態で表示すると、フレアポリゴンの後ろが間欠的に見えるので、中抜き（中空、あるいは環状）でない形状を中抜きとするのと同様の効果、あるいはフレアポリゴンを半透明としたのと同様の効果が得られ、背景が見えてゲーム操作の邪魔にならない。また、よりフレアらしく見せることができる。
【００６２】
フレアはフレアポリゴンによる表示に限られない。フレアを表す平面図形を用いて画像合成することとしても良い。上述のようにフレアを点滅表示する場合にも、周囲よりもフォグ効果を帯びた白味の度合いの高い色合いの平面形状（好ましくは中空形状、あるいはレンズフレアに対応した略円形や多角形の形状）により形成されたフレアを使用して画面合成を行い、その相似形を、入射光に相当する視点と光源を結ぶ直線上に複数並べて表示することができる。こうした場合には、比較的に演算の負担が少ない。
【００６３】
図５及び図６は、フレア処理の他の実施の形態を示している。この例では、図２に示されるフローチャートのステップ１１０を変更している。すなわち、内積の値Ｃを用いるに際し、図６に示すように、上限値ＣUと下限値ＣLとを設けている。内積Ｃが上限値ＣUを超える場合（Ｓ１１０ａ；ＣU＜Ｃ）、内積を値ＣUに設定する（Ｓ１１０ｄ）。これにより、フレアによって画像が白っぽくなりすぎるのを防止可能である。また、内積Ｃが下限値以下の場合（Ｓ１１０ａ；Ｃ＜ＣL）、一定のフレア効果を生ぜしめるべく、内積値をＣLに設定する（Ｓ１１０ｂ）。更に、内積Ｃが上限値ＣUと下限値ＣLとの間である場合（Ｓ１１０ａ；ＣL≦Ｃ≦ＣU)、修正関数ｆ（Ｃ）を用いて、修正値Ｃ’＝ｆ（Ｃ）を得る。このように、内積を適宜に修正して、用いてフレア処理をより効果的に行うことが可能となる。
【００６４】
図２に示した例では、フレアの程度を内積Ｃを利用して定めている。しかしながら、必ずしも内積Ｃを計算しなくとも類似の処理を行うことは可能である。
【００６５】
図７は、テーブルを参照してフレアの程度を決定する２つの例を示している。ここでは、便宜上、フレアの程度もＣで表す。
【００６６】
既述ステップＳ１０２において、画面内に仮想光源が入っている場合（Ｓ１０２；Ｙｅｓ）、仮想光源の位置（例えば、ベクトルＡ及びＢのなす角度θ）に対応したフレア値Ｃを図７（ａ）に示すテーブルを参照して決定することができる。仮想光源の位置は、画面上あるいは視野２５内の（ｘ，ｙ）座標値であっても良い。このようなテーブルは予めＣＤ−ＲＯＭ１ｂにデータベースとして記録しておき、ゲーム起動の際に読み込んでＲＡＭ１０２に保持することが可能である。
【００６７】
また、図７（ｂ）に示す、光源の視野内の位置（例えば、ベクトルＡ及びＢのなす角度θ）と、光源の強度とに対応したフレア強度を得るテーブルを参照して、光源の位置θn及び強度Ｐnに対応したフレア値Ｃnnを得ることができる。また、特に図示しないが、光源の強度によってフレアの程度を定めることとした場合には、光源の強度のみに対応したフレア値Ｃを保持するテーブルを使用することとしても良い。このようにして得られたフレア値Ｃを前述した、ステップ１１０以降の内積Ｃと同様に使用することが可能である。そして、同様のフレア処理を実行することが可能である。テーブルを参照してフレアの程度を定める場合には、上述した光源の位置やその強度の他、適当なもの（朝方・夕方、雨、霧、曇の存在等）をパラメータとして含めることが可能であり、テーブルの内容は図示のものに限定されない。
【００６８】
なお、上述したテーブルに変えてテーブルと同様に機能する関数Ｃ＝ｇ（θ，Ｐ）、Ｃ＝ｈ（θ）、Ｃ＝ｉ（Ｐ）あるいはＣ＝ｊ（ｘ，ｙ）を使用しても良い。
【００６９】
次に、フレアを活用する場合について説明する。いわゆるワールド座標系での仮想太陽の位置は本来定っている。しかしながら、レースゲームをやり易くするために、逆光が発生しないように適宜仮想太陽の位置を移動させることができる。逆に、ゲームの演出効果を高めるために、本来仮想太陽が存在しない場所に仮想太陽をおいて意図的に逆光状態とし、フレアを発生させることができる。
【００７０】
例えば、図８に示すように、仮想太陽を本来の仮想太陽の正規位置からゴール後に視界に入る位置に意図的に移動し、ゴール後に画像にフレアを発生させてゲームのクライマックスを演出することが可能である。
【００７１】
さらに、画像の第２の特殊効果の例に関するアルゴリズムについて図９乃至図１４を参照して説明する。これは、道路にタイヤの痕跡を残すことによって、車両のスピン、タイヤスリップ、悪路走行等をよりリアルに表現するものである。また、ある時間を経過した後にタイヤの痕跡を消すことによって、画面中のポリゴン（タイヤの痕跡）を減らして画像処理の演算量を減らす。また、タイヤの痕跡自体はゲームの運転情報としては不要であるので、違和感のないように、痕跡の後端より徐々に消して情報が過多にならないようにする。
【００７２】
図９は、タイヤの痕跡（タイヤマーク）を表示するアルゴリズムを説明するフローチャート、図１０乃至図１３は、データの読出し、タイヤマークの表示等を説明する説明図、図１４は、タイヤマークを描画した例を示す説明図である。
【００７３】
この実施の形態では、例えば、徐々に濃度が濃くなる５つの種類のタイヤマーク、すなわちパターン０〜パターン４がタイヤの痕跡をリアルに表現するために用いられる。各パターンはデータベース（ＲＯＭ）に記憶されている。また、車両のタイヤの移動にタイヤの痕跡を追従させると共に、痕跡を徐々に消すために、図１０に示すＲＡＭあるいはレジスタの５つの記憶領域が使用される。
【００７４】
まず、主プログラムにおいて、タイヤマークの表示条件が満たされているかどうかが判別される。すなわち、車両のスピンや急なアクセルの踏込みによるタイヤのスリップの発生、悪路の走行等を該当関数や走行条件を示すフラグを参照して判別することによってタイヤマークの表示ルーチンが行われる。
【００７５】
タイヤのスリップ等が始ると、ＣＰＵ１０１は、５つのＲＡＭのうちタイヤマークの先端位置を示す「先頭マークのフラグが設定された先頭マークのＲＡＭからタイヤの前回位置Ｘn-1を読出し、画面に表示されている現在のタイヤ位置Ｔｘ nとの距離Ｌ（＝Ｔｘ n−Ｘn-1）を計算し、新たなマーク長さＬとする（Ｓ１３２）。ここで、位置Ｘn-1、位置Ｔｘ nは、三次元仮想空間における座標値を表している。タイヤマークの長さＬがタイヤマークの基本パターンの最大長さｌを越えるかどうか、を判別する（Ｓ１３４）。
【００７６】
タイヤマークの長さＬが最大長さｌを越えない場合（Ｓ１３４；Ｎｏ）、ＣＰＵ１０１は、現在のタイヤ位置Ｔｘ nをタイヤマークの終了位置として先頭マークのＲＡＭに記憶する（Ｓ１４４）。タイヤマークの長さＬを先頭マークのＲＡＭに記憶する（Ｓ１４６）。ＣＰＵ１０１は先頭マークのフラグが設定されるべきＲＡＭの番号を記憶するフラグレジスタの内容を更新することなく、そのまま上記先頭マークのＲＡＭの番号を保持させる（Ｓ１４８）。
【００７７】
ＲＡＭ番号とパターンとは、図１３に示すように対応付けられており、先頭マークのＲＡＭから巡回するようにデータが読出されて、タイヤマークが描画される。すなわち、先頭マークのＲＡＭ Ｎｏ−０はパターン４に、先頭マークのＲＡＭ Ｎｏ−１はパターン３に、先頭マークのＲＡＭ Ｎｏ−２はパターン２に、先頭マークのＲＡＭ Ｎｏ−３はパターン１に、先頭マークのＲＡＭ Ｎｏ−４はパターン０に、それぞれ対応付けられる。パターン０からパターン４になるにつれてタイヤマークの濃さは薄い状態から濃い状態になっていく。先頭マークのＲＡＭ番号は時間的に最も新しいタイヤの痕跡を表す。
【００７８】
ＣＰＵ１０１は、最も濃いパターン（パターン４）を読出す（Ｓ１５０）。ＲＡＭからタイヤマークの出始め位置Ｘn-1、出終り位置Ｔｘn、長さＬを読出し、パターンを画面に表示する（Ｓ１５２）。ＲＡＭの個数分のパターン表示が終ったかを判別する（Ｓ１５４）。
【００７９】
先行するタイヤマーク処理によって、複数のＲＡＭにタイヤマークの出始め、出終り、長さが記憶されている場合（Ｓ１５４；Ｎｏ）、ＣＰＵ１０１は、ＲＡＭ番号を降順方向に巡回するように指定し（Ｓ１５６）、ＲＡＭ番号に対応付けられて、降順方向に段階的にあるいは徐々に薄くなるタイヤマークのパターンを読出す（Ｓ１５８）。ＲＡＭの個数分のパターン表示が終ると（Ｓ１５４；Ｙｅｓ）、ＣＰＵ１０１は一旦メインプログラムに戻る。
【００８０】
そして、タイヤマークの表示条件が満たされている間、タイヤマークの長さＬがタイヤマークの最大長ｌを越えるまで、ステップ１３２、１３４、１４４〜１５４を繰返して最も濃いパターンをタイヤに追従するように伸長して描画する。
【００８１】
次に、マーク長さＬがマーク最大長さｌを越える場合（Ｓ１３４；Ｙｅｓ）、マーク最大長さｌに相当するマークの場所Ｐe（＝Ｘn-1＋ｌ）をマーク終了位置として記憶する（Ｓ１３６）。先頭マークのＲＡＭ番号を１増加する。ＲＡＭ番号が最大値（この例の場合４）をオーバーしたときは、ＲＡＭ番号を０に戻す（Ｓ１３８）。マークの出始めの位置Ｐeを新たな先頭マークのＲＡＭに記憶する（Ｓ１４０）。現在のタイヤ位置Ｔｘ nと、タイヤマーク出始めの位置Ｐｅから、タイヤマークの長さＬ（＝Ｔｘ n−Ｐｅ）を計算して求める（Ｓ１４２）。現在のタイヤ位置Ｔｘ nをマーク終了位置として先頭マークのＲＡＭに記憶する（Ｓ１４４）。タイヤマークの長さＬを先頭マークのＲＡＭに記憶する（Ｓ１４６）。フラグレジスタに記憶すべきＲＡＭ番号をＳ１３８で更新された先頭マークのＲＡＭの番号とする（Ｓ１４８）。最も濃いパターン（パターン４）を読出す（Ｓ１５０）。ＲＡＭからタイヤマークの出始め位置Ｐｅ、出終り位置Ｔｘ n、長さＬを読出し、パターンを画面に表示する（Ｓ１５２）。ＲＡＭの個数分のパターン表示が終ったかを判別する（Ｓ１５４）。
【００８２】
先行するタイヤマーク処理によって、複数のＲＡＭにタイヤマークの出始め、出終り、長さが記憶されている場合（Ｓ１５４；Ｎｏ）、ＲＡＭ番号を降順方向に巡回するように指定し（Ｓ１５６）、ＲＡＭ番号に対応付けられて、降順方向に段階的にあるいは徐々に薄くなるタイヤマークのパターンを読出す（Ｓ１５８）。
【００８３】
上述したタイヤマーク描画処理は、メインプログラムの実行において、タイヤマークの表示条件が満たされている間中実行され、画面にタイヤマークが描かれる。
【００８４】
上記アルゴリズムによる、ＲＡＭ０〜ＲＡＭ４内の保持データとフラグレジスタ内の保持データの更新の様子を図１０（ａ）〜同（ｅ）を参照して説明する。
【００８５】
図１０（ａ）は、スリップによるタイヤマークの長さＬがマークの基準値ｌに満たないΔｌである場合（Ｓ１３４；Ｎｏ）を説明するものである。
【００８６】
まず、先頭マークがＲＡＭ０を示しているとする。ステップ１３２において、タイヤマークの出始め位置Ｘ0、現在位置Ｔｘ 1が読込まれ、距離Ｌ＝Δｌ（＝Ｔｘ 1−Ｘ0）が計算される。当初のタイヤマークの出始め位置Ｘ0は、スリップ開始時のタイヤ位置が該当する。これ等の値がＲＡＭ０に記憶される（Ｓ１４４〜Ｓ１４６）。ＲＡＭ０をフラグレジスタが保持すべき先頭マークのＲＡＭ番号とする（Ｓ１４８）。図１３に示すように、先頭マークのＲＡＭ番号は最も濃いパターン４に対応する。ＲＡＭ０からタイヤマークの出始め、出終り、長さが読出され、パターン４によるタイヤマークの描画が行われる（Ｓ１５２）。この場合、データが書込まれているＲＡＭは１個であるので（Ｓ１５４；Ｙｅｓ）、本ルーチンを終了して、メインプログラムに戻る。タイヤマークの表示条件が満たされていると、マークの長さＬが最大長ｌを越えるまで、上記処理を繰返してパターン４のタイヤマークを延長する。
【００８７】
図１０（ｂ）に示すように、現在のタイヤの位置がＴｘ 2となり、距離Ｌ（＝Ｔｘ 2−Ｘ0＝ｌ＋Δｌ）が、マーク最大長ｌを越える（Ｓ１３４；Ｙｅｓ）。ＲＡＭ０に、Ｘ1＝Ｘ0＋ｌ（＝Ｐｅ）を求め、位置Ｘ1をマーク終了位置として記憶する（Ｓ１３６）。先頭マークのＲＡＭをＲＡＭ１とする（Ｓ１３８）。現在のタイヤ位置Ｔｘ 2とマーク出始めの位置Ｘ1からマークの長さＬ（＝Δｌ＝Ｔｘ 2−Ｘ1）を計算する（Ｓ１４２）。現在のタイヤ位置Ｔｘ 2をマーク終了位置として、ＲＡＭ１に記憶する（Ｓ１４４）。マークの長さＬ（＝Δｌ＝Ｔｘ 2−Ｘ1）をＲＡＭ１に記憶する（Ｓ１４６）。フラグレジスタに保持される、サイクリック（巡回）に読出す際の先頭のＲＡＭの番号をＲＡＭ１に設定する（Ｓ１４８）。ＲＡＭ１にパターン４のデータを対応させ（Ｓ１５０）、ＲＡＭ１のデータでパターン４の濃いタイヤマークを描く（Ｓ１５２）、更に、ＲＡＭ０に記憶されたデータでパターン３のタイヤマークを描画する（Ｓ１５４、Ｓ１５６、Ｓ１５８、Ｓ１５２）。メインプログラムに戻る。
【００８８】
以下、同様に繰返すことによって、図１０（ｃ）〜同（ｅ）に示すように、ＲＡＭ０〜ＲＡＭ４にタイヤマークの描画データ（タイヤマークの出始め、出終り、距離）が保持される。
【００８９】
図１１は、ＲＡＭ０〜ＲＡＭ４へのデータの保存が一巡した状態の例を示している。ＲＡＭは、実施例では５個であるので、順次書換えが行われる。図１１（ａ）では、書換えが一巡し、ＲＡＭ２にタイヤマークの先頭位置が対応している。図１１（ｂ）では、書換えが一巡し、ＲＡＭ３に先頭位置がある状態を示している。書換えられた元のタイヤマークのデータ部分は表示されないので、画面に描画された該当パターンは消滅する。なお、位置の座標Ｘnが仮想カメラの視野外にある場合、いわゆるクリッピング(clipping)によって画像処理の対象外となり、画面に表示されない。
【００９０】
図１２（ａ）は、図１１（ａ）に示すデータがタイヤマークとして描画された場合を説明するものである。パターン４はΔｌのパターン長さで描かれ、パターン３〜同０の各々はｌのパターン長で描かれている。パターン４からパターン０に向って描画濃度が薄くなっていく。図１２（ｂ）は、図１１（ｂ）に示すデータによって描かれたタイヤマークを示すものである。タイヤマークの描画範囲が車両のタイヤオブジェクトに追従して図１２（ａ）の位置Ｘ3〜Ｔｘ 8から位置Ｘ4〜Ｔｘ 9にシフトしている。そして、位置Ｘ3〜Ｘ4の範囲のタイヤマークは消滅している。これにより、タイヤの痕跡を所定長に限定してタイヤマークの表示に要する演算量があまり増えないようにしている。
【００９１】
図９のフローチャートを参照して説明したアルゴリズムによれば、車両が停止している場合にはＲＡＭ０〜ＲＡＭ４内の位置情報は保持されるのでタイヤマークは画面に表示された状態にある。一方、車両が移動している場合にはタイヤに追従してタイヤマークが描画される。このタイヤマークは後端の方が薄くなっている。車両の移動速度が速いと、タイヤの前回サンプリングした位置からの移動量Ｌは短時間でマークの最大長さｌを越える。これにより、ＲＡＭ０〜ＲＡＭ４内の位置情報はシフトし、タイヤマークの後端も早く消滅する。その結果として、車両の移動速度に応じて描画されたタイヤの痕跡の消滅タイミングが加減されることになる。このような、画像の描画の仕方はタイヤの痕跡を描いた種々の画面を予め用意して（メモリ量を多大に要する）、その中から適当な画面を選択する従来法に比べてメモリ消費を節約することが可能である。また、レース車両は高速で移動するが、その際にコース上のタイヤマークがすぐ消滅するようにすると、自車や対戦相手の車両の視野内のポリゴンを減らし、画像を描画する演算処理の負担を軽減し得る。また、タイヤマークがいつまでも表示されていると、ゲームの邪魔になる場合があるが、本願では適当に消去されるので具合がよい。
【００９２】
上述した例では、予め濃度の異なるタイヤの痕跡パターン（痕跡のポリゴン）を複数用意して（図１３）、これ等から適宜に選択して全体の痕跡を描画しているが、他の方法を採用することもできる。例えば、徐々に薄くなるタイヤマークを描画するステップ（ステップＳ１５８）において、最も濃いタイヤの痕跡マーク（基本パターン）を半透明化する処理を行って所要の濃度の痕跡マークを得ることとしても良い。より具体的には、当該ステップにおける透明化処理の透明度を、ルーチンの（Ｓ１５２〜Ｓ１５８）の実行回数に対応して段階的に設定された複数の透明度から該当するものを選択する。この異なる透明度によって半透明化処理された各痕跡マークを組み合わせて全体の痕跡を形成する。そうすると、上述した、濃度の異なるタイヤの痕跡パターンを複数用意して濃度が先端から後端に向かって徐々に変わる全体の痕跡を形成する場合と同様の結果を得る。更に述べれば、図９に示すルーチンに従って表示された複数のポリゴンからなる痕跡マークを、半透明処理で最初に表示したポリゴンから徐々に薄くして消していき（薄くする過程ではポリゴンのサイズは変わらない）、最終的に見えなくなったらそのポリゴンそのそのものを処理対象から外す（ステップＳ１５４、図１２（ｂ））、ようにする。
【００９３】
図１４に、画面中に車両がスピンしてタイヤマーク（スリップの痕跡）が描画された例を示す。タイヤ近傍のマークは濃く描かれ、タイヤマークの初めの位置は薄く描かれる。
【００９４】
なお、車両（オブジェクト）のスピン等によってタイヤスリップが発生した場合、スリップ直後にタイヤのスリップ痕跡が画像表示されれば、遊技者はリアルな表現を体感する。しかし、それから一定時間を経過すれば、遊技者のスリップ痕跡への注目度も低下する。そこで、車両が移動を停止した後、所定時間を経過した場合には、積極的にスリップ痕跡を消滅させることとしても良い。これにより、表示ポリゴン（スリップ痕跡）の数を減らしてＣＰＵの演算の負担を軽減することが可能となる。
【００９５】
上述した発明の実施の形態では、タイヤマークについて説明したが、悪路を走行するラリーにおける走行痕跡、スキーの走行痕跡（シュプール）、ジェットスキーの痕跡、船舶の航跡等にも適用できるものである。
【００９６】
次に、本発明の第３の特徴に係るビデオゲーム装置における演算量の低減について説明する。いわゆる３Ｄグラフィックスによってモニタに映し出されるオブジェクトは、三次元仮想空間内へのオブジェクトの配置、オブジェクトを投影面に描画する投影変換、モデリング変換、ビューイング変換等の演算処理が行われて、モニタ画像となる。透視変換に際しては、視野ピラミッドを形成し、実際に投影面に投影される表示領域からはみ出した部分を取り去り、非表示とするクリッピングを行っている。このクリッピングは、演算量の減少に寄与している。
【００９７】
したがって、この実施形態において実現する本発明の第３の特徴は、表示領域内においてもクリッピングを行い、更に、演算量を低減せんとするものである。
【００９８】
まず、図１５乃至図１７を参照してその概略を説明する。図１５は、三次元仮想空間に配置されたオブジェクトＡ及びＢを示している。オブジェクトＡ及びＢは、それぞれ複数のポリゴンによって構成される。従来、表示領域内のオブジェクトはデータベースから読出して、該当位置にそのままの形状で配置される。ポリゴンの表面にはテクスチュア（模様）が張付けられる。
【００９９】
図１６は、投影変換のカメラ位置（視点）を後方左においた場合に、オブジェクトＢがオブジェクトＡの陰になる例を説明するものである。この場合、オブジェクトＢの一部（オブジェクトＡの陰になっている部分）はカメラ位置からは見えない。そこで、見えない部分のポリゴンを省略して、オブジェクトのデータベースを構築すれば、３Ｄグラフィックス表示における演算量は減少する。
【０１００】
図１７は、オブジェクトＢの一部のポリゴンを省略した例を示している。このようにしても、カメラから見える投影面の画像は、図１６と同様である。
【０１０１】
例えば、カーレースにおいては、車両は予め定められたコースに沿って走る。コースを単位長に区切って、各単位毎にカメラから見える場面は背景画、オブジェクトの集合等の形式で予めデータベース化され、車両位置に応じて該当場面のデータが読出されて背景等として画面表示される。従って、実際にカメラから見えないポリゴンを減らせばゲーム装置において演算量のより少なくて済むデータベースを提供することが可能となる。
【０１０２】
以下に、表示領域内においてカメラ位置から見えないポリゴンを削ったオブジェクトデータベースを構築する方法について図面を参照して説明する。
【０１０３】
まず、後述するアルゴリズムを実行する画像データ処理装置の概略を図１８を参照して説明する。画像データ処理装置は、コンピュータシステムによって構成され、大別して、データ処理部２００、操作部２０１、オブジェクトテーブルやポリゴンデータ等のデータベースを保持する記憶部２０２、画像を表示するＣＲＴ表示部２０３等によって構成される。データ処理部２００は、メモリ２１２に保持されるプログラムに従って各部を制御する演算処理制御部２１１、三次元仮想空間におけるカメラ（視点）位置の座標を、車両の移動やゲームプログラム等に従って設定するカメラ位置制御部２１３、カメラ位置を参照して、カメラ位置に対応するオブジェクトテーブルを決定するオブジェクトテーブル決定部２１４、カメラ位置に対応した座標変換の行列を生成する座標変換行列生成部２１５、オブジェクトテーブルを参照して該当するポリゴンを指定するポリゴンメモリ制御部２１６、指定されたポリゴンデータを出力するポリゴンメモリ２１７、ポリゴンに張付ける模様を保持するテクスチャメモリ２１８、三次元仮想空間に、ポリゴンを配置し、テクスチャを張付け、上記変換行列によって投影変換等を行って二次元のスクリーン面上の像に変換する座標変換部２１９、スクリーン画像を画像メモリ２２１に出力する描画部２２０、画像メモリ２２１に保持される画像データをＣＲＴ表示器に画像信号として出力する画像表示制御回路２２２、等によって構成される。
【０１０４】
図１９は、従来のオブジェクトデータベースから見えないポリゴンを削ったオブジェクトデータベースを構築するアルゴリズムを説明するフローチャートである。
【０１０５】
まず、従来手法によって３Ｄグラフィックスのデータベースが構成され、あるいは既に構成された３Ｄグラフィックスのデータベースが用意される。ＣＰＵのメモリのワークエリアにデータベースから全ポリゴンのデータをロードする。ポリゴンのデータには座標データ等が含まれる（Ｓ２０２）。各ポリゴンに識別のための番号（ポリゴンＩＤ）を付ける。例えば、ロードした順番に番号付を行う（Ｓ２０４）。
【０１０６】
カメラ位置のデータをワークエリアにロードする。カメラ位置のデータには、カメラの座標及び向き（ベクトル）が含まれる（Ｓ２０６）。カメラ位置のデータに識別のための番号（カメラＩＤ）を付ける。例えば、ロードした順番に番号付を行う（Ｓ２０８）。
【０１０７】
次に、全てのカメラ位置で、カメラ位置から各ポリゴンが見えるかどうかの可視判別処理（Ｓ２１０）を行う。
【０１０８】
図２０は、可視判別処理のアルゴリズムを示すフローチャートである。この処理では、コンピュータシステム内に形成される三次元仮想空間に全オブジェクトを配置し、全てのポリゴンを描画する。この際、各ポリゴンの画素に当該ポリゴンのＩＤ番号を付加する（Ｓ２５２）。各カメラ位置（カメラＩＤ）において座標変換等を行ってカメラから見える投影画像を描画する。この際、いわゆるＺバッファ法等を用いて、表示領域内で重なるポリゴンのうち手前のものを見えるポリゴンとして描画し、陰になるポリゴンは描画しない（Ｓ２５４）。各カメラ位置で、描画された画素に付されたポリゴンのＩＤから、画面に描かれるポリゴンと、描かれないポリゴンとを判別する（Ｓ２５６）。全カメラ位置（カメラＩＤ）において、どのポリゴンが見え、どのポリゴンが見えないかを表す可視不可視のテーブル（VISIBLE FLAG TABLE）を作成する（Ｓ２５８）。その後、元のルーチンに戻る。
【０１０９】
図２１は、可視不可視テーブルの一例を示している。全カメラ位置（カメラＩＤ）において、全てのポリゴンについて当該カメラ位置から見えるかどうかが示される。見える場合は「１」で、見えない場合は「０」でフラグ表示されている。
【０１１０】
次に、各カメラ位置において描画されるオブジェクトを表すデータベースを得るべく、可視不可視テーブルでフラグ（VISIBLE FLAG）のパターンが同一・類似のポリゴンをグループ化し、各グループをオブジェクトデータとする（Ｓ２１２）。各オブジェクトデータに識別番号（オブジェクトＩＤ）を付す（Ｓ２１４）。
【０１１１】
この手順を説明する。第１に、全て「０」のフラグパターンであるポリゴン（例えば、ＰＯＬＹ４）は画面から見えないので、描画の対象とする必要はない。このようなポリゴンは除去する。第２に、図２２（ａ）に示すように、最初のポリゴンＰＯＬＹ０を最初のオブジェクトデータＯＢＪ０に含める。第３に、ポリゴンＰＯＬＹ０のフラグパターンと一致するフラグパターンのポリゴンを全て抽出し、これをオブジェクトデータＯＢＪ０に追加する（図２２（ｂ））。残りのポリゴンについて、手順２、３を繰返して、同じフラグパターンを持つポリゴンを集めてグループ化し、各グループをオブジェクトデータＯＢＪ１，ＯＢＪ２，…とする。
【０１１２】
次に、オブジェクトデータに類似するフラグパターンを持つポリゴンを抽出し、該当するオブジェクトデータに組入れる（図２２（ｃ））。例えば、オブジェクトデータ内の各ポリゴンのフラグパターンを論理和したパターンと１ビット違いのフラグパターンを持つポリゴンを抽出し、オブジェクトデータに組入れる。同様の手順を繰返して、所定ビット値違いのフラグパターンまでグループ分け（オブジェクトデータ化）する。
【０１１３】
次に、各カメラ位置において描画される（見える）オブジェクトデータを表す変換テーブルをつくる（Ｓ２１６）。この例を、図２３に示す。このテーブルを参照することによって各カメラ位置（カメラＩＤ）で三次元仮想空間に配置すべきオブジェクトが直ちに判る。
【０１１４】
例えば、カメラ位置０では、オブジェクトデータＯＢＪ０，ＯＢＪ１，ＯＢＪ３，…が配置される。カメラ位置１では、オブジェクトデータＯＢＪ０，ＯＢＪ３，…画配置される。ゲーム装置では、ゲーム展開に応じてカメラ位置を選択し、変換テーブルから該当するオブジェクトデータ群を読出し、各オブジェクトを構成するポリゴンを描画することによって各場面が描画される。
【０１１５】
更に、オブジェクトデータをデータベースに保存する（Ｓ２１８）。オブジェクトの変換テーブルをデータベースに保存する（Ｓ２２０）。
【０１１６】
なお、上述したアルゴリズムをビデオゲーム装置とは別途の画像処理専用コンピュータシステムによって高速に実行し、その結果得られたオブジェクトデータのデータベースをゲームソフトウェアとして情報記録媒体にプログラムと共に記憶することができる。
【０１１７】
図２４及び図２５は、本発明による、表示領域内において見えないポリゴンを除いたオブジェクトデータによって描画した画面例を説明するものである。図２４は、仮想三次元空間に形成されたゲームフィールドにおいて、カーレースの走行中の通常のカメラ位置による一場面の例を示している。図２５は、この場面を上方から見た状態を示している。同図に斜線で示す領域にはポリゴンは描画されておらず、画像が存在しない。従って、その分の仮想空間の組立や画像を変換等するに要する演算量が低減されている。
【０１１８】
このような、視野領域内におけるオブジェクトのクリッピングの適用例は、実施例のようなビデオゲームに限られるものではない。例えば、仮想三次元空間の様子を二次元画像に変換して表示するもの、例えば、種々の仮想体験用のシミュレーション等にも適用できる。
【０１１９】
（第２の実施形態）
本発明の第２の実施形態に係るビデオゲーム装置を図面に基づき説明する。本実施形態は、第１の実施形態で説明した画像の第２の特殊効果処理であるタイヤマークをさらに発展させたもので、今回のゲーム実行時にタイヤマークを処理・表示することは勿論、そのタイヤマークを次回のゲームにも反映させるようにしたものである。
【０１２０】
これを実現するため、ビデオゲーム装置は図２６に示すように、ＣＰＵブロック１０にＳＲＡＭ１９０を備え、このＳＲＡＭ１９０を、バス１０５を介してＳＣＵ１００、メインＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、およびサブＣＰＵ１０４に接続している。このＳＲＡＭ（不揮発性メモリ）１９０は主にゲーム終了時にそのゲームで発生したタイヤマークのデータを保存するために設けられている。
【０１２１】
また、本実施形態のビデオゲーム装置が備えているＲＡＭ（揮発性メモリ）１０２は、ゲーム中のタイヤマークのデータを含む各種のデータを保存するメモリとして搭載されている。このタイヤマークデータは２種類用意される。１つは、現在のゲームで発生中のタイヤマークデータであり、これは常に表示されるデータである。もう１つは、過去に発生したタイヤマークデータであり、ここではリザーブデータと呼んでいる。
【０１２２】
そのほかの構成は前述した第１の実施形態のものと同一または同等である。
【０１２３】
メインＣＰＵ１０１は、ゲームの展開に必要なゲーム処理を含むデータ全体をコントロールするためのメインプログラムを実行すると同時に、その処理と並行して図２７〜図３３の処理を行うように予めＲＯＭ１０３にプログラムされている。これらの処理は全てタイヤマークデータに関するものである。この内、図２７に示す処理は各回のゲーム開始直前にメインＣＰＵ１０１により実行され、図２８〜図３１に示す処理はゲーム実行中にメインＣＰＵ１０１により実行され、さらに図３２に示す処理はゲーム終了後に各回毎にメインＣＰＵ１０１により実行される。
【０１２４】
まず、図２７に示す処理を説明する。この処理はゲーム開始直前に実施される。メインＣＰＵ１０１はメインプログラムを実行している中で、入力装置２ｂから操作情報を確認しながらゲーム開始直前のタイミングを判定し、そのタイミングが判定できたときに図２７の処理を実行する。最初に、メインＣＰＵ１０１は、ＳＲＡＭ１９０に前回のゲームでタイヤマークのデータが保存されているか否かを、例えばフラグが立っているか否かで判断する（ステップＳ３０１）。この判断でＮＯ（データが保存されていない）のときは、そのままメインプログラムに戻る。反対にＹＥＳ（データが保存されている）のときは、そのデータをＳＲＡＭ１９０から読み出し、ＲＡＭ１０２に展開してゲーム実行中に使用可能なデータに変換（解凍処理など）する（ステップＳ３０２）。これにより、ＲＡＭ１０２には過去に発生したタイヤマークのデータ（リザーブデータ）として保存される。
【０１２５】
また、メインＣＰＵ１０１はメインプログラムを実行する中で、ゲーム実行中の表示インターラプト毎に図２８〜図３１の処理を実行する。このゲーム実行中の処理は、図２８に示すように、ＳＴＥＰ１のルーチンと呼ぶことにする、新規タイヤマークデータの処理ルーチン（ステップＳ３１１）、ＳＴＥＰ２のルーチンと呼ぶことにする、リザーブデータのソート（ステップＳ３１２）、およびＳＴＥＰ３のルーチンと呼ぶことにする、ＲＡＭの保存データの表示（ステップＳ３１３）からなり、これらＳＴＥＰ１〜３のルーチンがこの順に順次実行される。
【０１２６】
最初のＳＴＥＰ１のルーチンでは、メインＣＰＵ１０１によって、現在、タイヤマークの発生状態にあるか否かが、車の走行状態や遊戯者からの操作情報に基づいて判断される（ステップＳ３００１）。
【０１２７】
この判断がＹＥＳ（発生状態にある）のときは、次いで、車のタイヤの現在位置から新たなタイヤマークを形成する各マークの座標位置（ｘ，ｙ，ｚ）、角度（ｘ-角度、ｙ-角度、ｚ-角度）、長さ、および濃さのデータが算出される（ステップＳ３００２）。次いで、この算出データが現在発生中のタイヤマークデータとしてＲＡＭ１０２の所定記憶領域に一時保存される（ステップＳ３００３）。次いで、この保存されたタイヤマークデータをリアルタイムに表示させて（ステップＳ３００４）、メインプログラムに戻る。上述のステップＳ３００１〜Ｓ３００４の処理の詳細は、前述した第１の実施形態のものと同様または同等である。
【０１２８】
しかし、ステップＳ３００１の処理判断を表示フレーム毎に繰り返している中でタイヤマークの発生状態ではないと認識できたときは、ステップＳ３００５〜Ｓ３００８の処理を経てメインプログラムに戻る。すなわち、前回フレームから今までに発生したタイヤマークデータが在るか否かが判断され（ステップＳ３００５）、ＮＯの場合はメインプログラムに戻る。
【０１２９】
タイヤマークデータが在るときは（ＹＥＳ）、次いで、ＲＡＭ１０２のリザーブデータの格納（保存）領域に新たなデータを格納すべき空き領域が在るか否かを判断する（ステップＳ３００６）。この判断がＹＥＳ（空き領域在り）となるときは、そのままメインプログラムに戻る。反対にＮＯ（空き領域無し）の判断となるときは、リザーブデータの最後に位置するデータを消去する（ステップＳ３００７）。リザーブデータの最後尾のデータは後述するように、ＳＴＥＰ２のルーチンによって常に、最も不要なデータになっているので、記憶領域に空き領域が無い場合、消去して構わないことになっている。
【０１３０】
この消去によって空いた領域に、次いで、現在までに発生していたタイヤマークデータがリザーブデータとしてＲＡＭ１０２のリザーブデータ格納領域に保存される。この後、メインプログラムに戻る。
【０１３１】
続いてＳＴＥＰ２に係るリザーブデータのソート処理を図３０に沿って説明する。メインＣＰＵ１０１は、リザーブデータがＲＡＭ１０２に格納されているか否かを判断する（ステップＳ３０１１）。格納されていない（ＮＯ）の場合にはそのままメインプログラムに戻るが、格納されている（ＹＥＳ）の場合にはステップＳ３０１２〜Ｓ３０１７のソート処理をサイクリックに行う。
【０１３２】
このソート処理は以下ようである。リザーブデータの先頭データをデータＡとして設定する（Ｓ３０１２）。次いで、データＡの次の位置に当たるデータが在るか否かを判断する（Ｓ３０１３）。この判断がＮＯの場合はソートを行う必要が無いからメインプログラムに戻る。これに対して、ＹＥＳの判断、すなわちデータＡに次に該当するデータが在るときは、その該当データをデータＢとして設定する（Ｓ３０１４）。
【０１３３】
次いで、データＡのタイヤマークの構成枚数はデータＢのそれよりも少ないかどうかを判断する（Ｓ３０１５）。データＡの方が少ない（ＹＥＳ）場合、データＡとＢの内容を入れ替え（Ｓ３０１６）、データＢをデータＡとして扱うようにする（Ｓ３０１７）。しかし、データＡの方が多い（ＮＯ）場合、ステップＳ３０１６の処理をスキップする。ステップＳ３０１７の後、その処理はステップＳ３０１３に戻される。これにより、ステップＳ３０１３でＮＯの判断になって、リザーブデータ全部のソートが終わるまで上述した一連のソート処理が周期的に続けられる。
【０１３４】
これにより、ＲＡＭ１０２に格納されているリザーブデータは表示フレーム毎に自動的にソートされて整列し、その最後尾のマークデータは常に最も重要度の低い（構成枚数の少ない）データであることが保証される。このソートは一番外側のループが毎フレーム・ループになっているバブルソートである。
【０１３５】
さらに、ＳＴＥＰ３に係るＲＡＭ保存データの表示処理を図３１に沿って説明する。メインＣＰＵ１０１は、ＲＡＭ１０２に格納しているリザーブデータに仮想カメラ（視点）からの距離に応じてソートを掛ける（ステップＳ３０２１）。このときカメラ後方は距離＝無限大と見做してソートされる。実際には「１／カメラからのＺ距離」をパラメータとしてヒープソートが実施される。この結果、「１／カメラからのＺ距離」の値が最大になるものが表示フレーム毎に得られる。
【０１３６】
次いで、表示していないタイヤマークの中から、カメラからの距離に近いマークのデータを抽出し、表示する（ステップＳ３０２２、Ｓ３０２３）。ここでの表示も前述した第１の実施形態のものと同様に実施される。
【０１３７】
次いで、全ての保存データに対し、表示処理が終わったかどうかを判断する（ステップＳ３０２４）。ＮＯの場合、予め設定してある表示可能最大数を表示タイヤマークが超えたかどうかを判断し（ステップＳ３０２５）、ＹＥＳの判断ならばそのまま現在フレームに対する表示処理を終わる。ＮＯの判断のときは、ステップＳ３０２２の処理に戻って、上述した処理を表示タイヤマーク数が表示可能最大数に達するまで続ける。
【０１３８】
これにより、現在発生中のタイヤマークデータに加えて、それまでに発生したタイヤマークのその後の経時的な変化状態を表すリザーブデータも許容される限り、画面上でカメラ視点に近い方から優先して極力多数のものがフレーム毎に表示される。この表示処理の際、リザーブデータの位置座標値如何によっては、カメラ視野に入らない場合など、実際には表示されないでクリッピングされるデータもある。また、この非表示のもう１つの条件として表示可能最大数が設定されているので、これを超えた数のリザーブデータも実際には表示されない。この表示可能最大数は、ゲームボードの性能上、それ以上表示すると、いわゆるポリゴン欠けの現象が発生する可能性があるという状況を回避するために設定してある、タイヤマークポリゴンの最大表示数である。この設定により、リザーブデータについても画面のリアル感を演出する上で重要度の高いタイヤマークを安定して表示できる。
【０１３９】
さらに、ゲーム終了後のデータ保存処理を図３２、３３を参照して説明する。メインＣＰＵ１０１は、ゲーム終了時点でこの処理に入り、同図に示すように、ＲＡＭ１０２にゲーム終了時点で保存されているゲーム実行中のタイヤマークデータ全てについて、そのタイヤマークとして次回のゲーム時に表示するほどのものであるかどうか、その価値を判断（計算）する（ステップＳ３２１）。
【０１４０】
この価値判断の一例を図３３（ａ），（ｂ）に示す。いま、タイヤマークを構成しているポリゴン１枚につき３点、車走行コースのコーナ内側から車の中心位置までの距離がｘのとき「４／ｘ」点のように点数付けすると、図３３（ａ）の場合はポリゴン枚数による点数＝５枚×３点、距離による点数＝（４／３）点×５枚となり、同図（ｂ）の方はそれぞれ５枚×３点、（４／５）点×３枚＋（４／７）点＋（４／８）点となる。この両者を比較すると、明らかに同図（ａ）のタイヤマークの方が同図（ｂ）よりも点数が高い。すなわち、ここでの点数付けの条件に関する限り、同図（ａ）の方が価値が高いと見做すことができる。
【０１４１】
次いで、メインＣＰＵ１０１は上述した価値判断結果に応じて、その高い方からソートを実行する。このソートそのものはヒープソートとして実行されるが、そのソーティング判断基準が上述したタイヤマークとしての表示価値である点に特徴がある。つまり、このソートは、どのタイヤマークを残すかを決めるためのソートである。そのための条件は、上述の例に一部示した如く、マークの全長（マークの構成ポリゴン枚数）、マークの色の濃さ、マークの密度（１個所に集中しているかどうか）、マークの位置（コースのベストラインに近いかどうか）、見栄えのするタイヤマーク（クリッピング・ポイントに近いなど）などである。これらの条件それぞれに数値を設定し、その合計値をソートの判断基準とすることで、複数の条件（パラメータ）を満足させる価値判断によるソートを掛けることができる。上述した図３３の場合、このソートによって、より長く、かつ、よりコーナー内側に位置するタイヤマークが選択され続ける。
【０１４２】
このようにソートが掛けられた後、ＳＲＡＭ１９０に未だ格納していないタイヤマークデータの中から最も価値の高いデータを抽出する（ステップＳ３２３）。次いで、この抽出データをＳＲＡＭ１９０に格納保存するだけの記憶領域が残っているかどうかを判断し（ステップＳ３２４）、ＹＥＳの判断のときにそのデータをＳＲＡＭ１９０に圧縮して格納する（ステップＳ３２５）。この保存情報は、タイヤマークポリゴンの表示位置座標（Ｘ，Ｙ，Ｚ）、その表示方向（Ｘ，Ｙ，Ｚ）、およびそのスケール（長さ）、さらに濃さの８種類の値である。ＳＲＡＭ１９０の記憶領域が一杯になると、格納を停止して処理をメインプログラムに戻す。
【０１４３】
この結果、遊戯者がゲームを終了すると直ちに、それまでのゲーム実行中に発生したタイヤマークデータの中から、次回のゲーム実行における表示価値が判断され、その価値が高いデータから順に所定数のデータがＳＲＡＭ１９０に保存される。このため、ゲーム装置の電源をオフ状態にしても、このＳＲＡＭ１９０のデータは保存され、ゲームを再び実行したときに前述した図２７の処理を介してＲＡＭ１０２に戻される。そして、図２９、３０、３１の処理を経て新たなゲーム画面に表示または反映される。
【０１４４】
本実施形態では以上ように、ゲームが終了すると直ちに、ゲーム実行中のタイヤマークデータの価値を判断し、バックアップメモリ（ＳＲＡＭ）に表示価値の面から選択的に保存し、次回のゲームまたはパワーオンリセット後のゲームにそれを表示できる。このため、次回のゲームを行ったり、ゲームを再開したときに前回のゲーム時のスリップ痕などのタイヤマークが残った状態で画面表示され、従来には無かった非常にリアル感があり、かつゲームの臨場感を高揚させる演出を行うことができる。
【０１４５】
そして、このタイヤマークデータはゲーム実行中はリザーブデータの一部として扱い、ソートして、表示数やカメラ視野などに依る表示条件の元で極力その多くが表示される。このため、現在発生中のタイヤマークのみならず、それまでに発生したタイヤマークの表示も加わって、タイヤマークに関して非常に豊かで迫力のある画面を提供できる。なお、第１の実施形態で説明したタイヤマークに関する作用効果も当然に合わせて享受することができる。
【０１４６】
また、バックアップメモリ（ＳＲＡＭ）の記憶容量は通常、例えば６４ＫＢと少ないため、これに保存するタイヤマークデータ量は制限される。これについても、表示価値に応じてソートして優先順位の高いデータから保存するようにしているので、かかる少ない記憶容量で間に合うことになる。しかも、このソート及びデータ保存はゲーム実行中には行わずに、ゲームが終了した時点で行うようにしているから、メインＣＰＵを中心とする演算要素に掛かる演算負荷を軽減できる。また、ゲーム実行中にもソートを行っても良い。このとき、ゲーム処理中のＣＰＵの処理負担を削減する観点から、ゲーム実行中のソートをゲーム終了後のソートに比較して、ＣＰＵの処理負担が軽い比較的簡単な内容のソートにとどめることもできる。
【０１４７】
【発明の効果】
以上述べたように、本発明によれば、画面に光源からの入射光線によるフレアが表現されるので、まぶしい場面や演出された場面を楽しむことが可能となる。
【０１４８】
また、本発明によれば、車両やスキー等の移動するオブジェクトの痕跡をポリゴン数を比較的増やさずに描画することが可能となって好ましい。加えて、一度ゲームを終了させても、演算負荷やメモリ容量の増大を抑えた状態で、オブジェクトの痕跡を次回のゲーム画面に的確に反映させることができ、臨場感やリアル感を一層高めることができる。
【０１４９】
また、本発明の画像形成方法は、表示領域内において不可視のポリゴンをクリップしてオブジェクトデータベースを形成するので、従来よりも少ない演算量で従来と同様の画面を描画することが可能となる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態のゲーム装置の機能ブロック図である。
【図２】フレア形成のアルゴリズムを説明するフローチャートである。
【図３】フレアの発生条件を説明する説明図である。
【図４】フレア発生画面の例を示す説明図である。
【図５】フレア形成の他のアルゴリズムを説明するフローチャートである。
【図６】図５に示すアルゴリズムを説明するグラフである。
【図７】フレアの程度をテーブルによって求める例を説明する説明図である。
【図８】光源の移動によってフレアを意図的に生ぜしめる例を説明する説明図である。
【図９】タイヤマークを表示するアルゴリズムを説明するフローチャートである。
【図１０】ＲＡＭの内容を説明する説明図である。
【図１１】書込みが一巡したＲＡＭの状態を説明する説明図である。
【図１２】図１１のＲＡＭによって描画されるタイヤマークを説明する説明図である。
【図１３】ＲＡＭ番号とタイヤマークのパターンの対応関係を説明する説明図である。
【図１４】スリップ痕が描かれた画面を説明する説明図である。
【図１５】三次元仮想空間に配置されたオブジェクトの例を説明する説明図である。
【図１６】表示領域内においてオブジェクトに見えない部分がある例を説明する説明図である。
【図１７】オブジェクトの見えない部分（ポリゴン）を削除した例を説明する説明図である。
【図１８】画像データ処理装置の概略を説明するブロック図である。
【図１９】表示領域でカメラから見えないポリゴンを削除してオブジェクトデータベースを形成する例を説明するフローチャートである。
【図２０】ポリゴンの可視、不可視を判別する例を説明するフローチャートである。
【図２１】ポリゴンの可視、不可視を表すテーブルを説明する説明図である。
【図２２】ポリゴンデータのオブジェクトグループ化を説明する説明図である。
【図２３】カメラＩＤによって描画するオブジェクトを選択する変換テーブルを説明する説明図である。
【図２４】通常の視点で３Ｄ描画した画面を説明する説明図である。
【図２５】図２４と同じ三次元仮想空間で視点を上方に移動した場合の画像を説明する説明図である。
【図２６】本発明の第２の実施形態に係るゲーム装置を示す機能ブロック図である。
【図２７】ゲーム開始直前のタイヤマークデータの読出し処理を示す概略フローチャートである。
【図２８】ゲーム実行中のタイヤマークデータの処理を示す概略フローチャートである。
【図２９】図２８に示す処理のＳＴＥＰ１の処理ルーチンをより詳細に示す概略フローチャートである。
【図３０】図２８に示す処理のＳＴＥＰ２の処理ルーチンをより詳細に示す概略フローチャートである。
【図３１】図２８に示す処理のＳＴＥＰ３の処理ルーチンをより詳細に示す概略フローチャートである。
【図３２】ゲーム終了後のタイヤマークデータの保存処理を示す概略フローチャートである。
【図３３】ゲーム終了後のタイヤマークデータの保存処理に伴う価値判断の一例を説明する図である。
【符号の説明】
１ ビデオゲーム装置本体
１ａ カートリッジＩ／Ｆ
１ｂ ＣＤ−ＲＯＭドライブ
２ａ コネクタ
２ｂ ゲーム操作用のパッド
２ｃ ケーブル
３ａ コネクタ
３ｂ フロッピー（登録商標）ディスクドライブ（ＦＤＤ）
３ｃ ケーブル
４ａ、４ｂ ケーブル
５ ＴＶ受像機
１０ ＣＰＵブロック
１１ ビデオブロック
１２ サウンドブロック
１３ サブシステム
１００ ＳＣＵ（System Control Unit）
１０１ メインＣＰＵ
１０２ ＲＡＭ
１０３ ＲＯＭ
１０４ サブＣＰＵ
１０５ ＣＰＵバス
１０６、１０７ バス
１２０、１３０ ＶＤＰ
１２１ ＶＲＡＭ
１２２、１２３ フレームバッファ
１３１ ＶＲＡＭ
１３２ メモリ
１４０ ＤＳＰ
１４１ ＣＰＵ
１６０ エンコーダ
１８０ ＣＤ Ｉ／Ｆ
１８１ ＣＰＵ
１８２ ＭＰＥＧ ＡＵＤＩＯ
１８３ ＭＰＥＧ ＶＩＤＥＯ
１９０ ＳＲＡＭ
Claims (3)
- 三次元仮想空間内に配置されたオブジェクトの表示領域内において、該オブジェクトを構成するポリゴンのクリッピング処理を行う画像データの形成方法であって、
コンピュータシステムの演算処理制御部が、メモリに保持されたプログラムを実行することにより、画像データ処理部を、
前記三次元仮想空間に視点を設定するカメラ位置制御手段として機能させる過程と、
前記視点から見た表示領域内のポリゴンを投影面に投影するための投影変換を行う座標変換行列生成手段として機能させる過程と、
前記投影変換の結果に基づいて、前記視点における前記ポリゴンの可視又は不可視を決定し、前記ポリゴンの可視又は不可視を表すオブジェクトテーブルを作成するオブジェクトテーブル決定手段として機能させる過程と、
前記オブジェクトテーブルを参照して、前記三次元仮想空間に配置するポリゴンを指定するポリゴンメモリ制御手段として機能させる過程と、
指定されたポリゴンを前記三次元仮想空間内に配置する座標変換手段として機能させる過程と、
を含む画像データの形成方法。 - 三次元仮想空間内に配置されたオブジェクトの表示領域内において、該オブジェクトを構成するポリゴンのクリッピング処理を行う画像データの形成方法であって、
コンピュータシステムの演算処理制御部が、メモリに保持されたプログラムを実行することにより、画像データ処理部を、
前記三次元仮想空間に複数の視点を設定するカメラ位置制御手段として機能させる過程と、
前記複数の視点から見た表示領域内のすべてのポリゴンを投影面に投影するための投影変換を行う座標変換行列生成手段として機能させる過程と、
前記投影変換の結果に基づいて、各視点における前記ポリゴンの可視又は不可視を決定し、各ポリゴンの可視又は不可視を表す各ポリゴンのデータパターンによって同一又は類似のパターンをグループ化して、各視点から見えるオブジェクトテーブルを作成するオブジェクトテーブル決定手段として機能させる過程と、
前記オブジェクトテーブルを参照して、前記三次元仮想空間に配置する前記ポリゴンのグループを指定するポリゴンメモリ制御手段として機能させる過程と、
指定されたポリゴンのグループを前記三次元仮想空間内に配置する座標変換手段として機能させる過程と、
を含む画像データの形成方法。 - コンピュータシステムに、請求項１又は２に記載の各過程を実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002258311A JP3841210B2 (ja) | 1996-11-22 | 2002-09-03 | ゲーム装置、画像データの形成方法及び媒体 |
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP31245996 | 1996-11-22 | ||
| JP8-312459 | 1996-11-22 | ||
| JP2002258311A JP3841210B2 (ja) | 1996-11-22 | 2002-09-03 | ゲーム装置、画像データの形成方法及び媒体 |
Related Parent Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000078128A Division JP3379702B2 (ja) | 1996-11-22 | 2000-03-21 | ゲーム装置、画像データの形成方法及び媒体 |
Publications (3)
| Publication Number | Publication Date |
|---|---|
| JP2003103046A JP2003103046A (ja) | 2003-04-08 |
| JP2003103046A5 JP2003103046A5 (ja) | 2005-07-14 |
| JP3841210B2 true JP3841210B2 (ja) | 2006-11-01 |
Family
ID=26567178
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002258311A Expired - Fee Related JP3841210B2 (ja) | 1996-11-22 | 2002-09-03 | ゲーム装置、画像データの形成方法及び媒体 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3841210B2 (ja) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP6446079B2 (ja) * | 2017-03-09 | 2018-12-26 | 株式会社カプコン | ゲームプログラム及びゲームシステム |
-
2002
- 2002-09-03 JP JP2002258311A patent/JP3841210B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003103046A (ja) | 2003-04-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3379702B2 (ja) | ゲーム装置、画像データの形成方法及び媒体 | |
| JP3415416B2 (ja) | ゲーム装置、画像データの形成方法及び媒体 | |
| US7338373B2 (en) | Method and apparatus for generating sounds in a video game | |
| EP0844587B1 (en) | Image processor, image processing method, game machine and recording medium | |
| US20060046844A1 (en) | Video game device and image processing program | |
| US6738061B2 (en) | Method, apparatus, storage medium, program, and program product for generating image data of virtual three-dimensional space | |
| JP2001273517A (ja) | ゲームシステム及びゲーム用プログラムを記録したコンピュータ読み取り可能な記録媒体 | |
| US8133117B2 (en) | Game apparatus, game message displaying method and storage medium storing game program | |
| KR100816622B1 (ko) | 화상 처리 장치 및 화상 처리 방법 | |
| US7479961B2 (en) | Program, information storage medium, and image generation system | |
| US6917371B1 (en) | Game device, picture data forming method and medium | |
| JP3352982B2 (ja) | レンダリング方法及び装置、ゲーム装置、並びに立体モデルをレンダリングするプログラムを格納するコンピュータ読み取り可能な記録媒体 | |
| US6717575B2 (en) | Image drawing method, image drawing apparatus, recording medium, and program | |
| JP2009129167A (ja) | プログラム、情報記憶媒体、及び画像生成システム | |
| JP3841210B2 (ja) | ゲーム装置、画像データの形成方法及び媒体 | |
| US7245298B2 (en) | Game system, image drawing method for game system, and computer-readable storage medium storing game program | |
| US6882342B2 (en) | Image processing method, image processing program, and image processing apparatus | |
| US20050119049A1 (en) | Program for projecting an image onto a character in a game, game machine incorporating the program, and storage medium having the program stored thereon | |
| JP3727098B2 (ja) | 画像合成方法及び装置 | |
| JP2002251625A (ja) | 画像処理装置、画像処理方法、及びコンピュータ上で動作する画像処理プログラムを記録した記録媒体 | |
| JP4089291B2 (ja) | プログラム及び記録媒体及び画像処理装置 | |
| JPH1071272A (ja) | ゲーム装置、これに用いられる表示方法及びコンピュータ可読媒体 | |
| JP3655555B2 (ja) | 画像の表現方法及びそれに用いるプログラム | |
| JP2009064086A (ja) | 画像処理用プログラム、当該プログラムを記録したコンピュータ読み取り可能な記録媒体、画像処理装置、画像処理方法 | |
| CN115888084A (zh) | 特效展示方法、装置、电子设备及存储介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20041122 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20041122 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060417 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060616 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20060720 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20060802 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090818 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100818 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110818 Year of fee payment: 5 |
|
| S111 | Request for change of ownership or part of ownership |
Free format text: JAPANESE INTERMEDIATE CODE: R313113 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110818 Year of fee payment: 5 |
|
| R350 | Written notification of registration of transfer |
Free format text: JAPANESE INTERMEDIATE CODE: R350 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120818 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120818 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130818 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130818 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130818 Year of fee payment: 7 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| R250 | Receipt of annual fees |
Free format text: JAPANESE INTERMEDIATE CODE: R250 |
|
| LAPS | Cancellation because of no payment of annual fees |