JP4782631B2 - プログラム、情報記憶媒体及び画像生成システム - Google Patents

Description

本発明は、プログラム、情報記憶媒体及び画像生成システムに関する。

従来より、戦闘機、車、キャラクタなどのオブジェクトが配置設定されるオブジェクト空間内（仮想的な３次元空間）において仮想カメラ（所与の視点）から見える画像を生成する画像生成システム（ゲームシステム）が知られており、いわゆる仮想現実を体験できるものとして人気が高い。戦闘機ゲームを楽しめる画像生成システムを例にとれば、プレーヤは、スクリーン上に映し出された戦闘機を操作し、敵の戦闘機や基地を攻撃したりしてゲームを楽しむ。

このような画像生成システムでは、例えば自機が発射した弾（ミサイル等）と敵の戦闘機との間のヒットチェック処理が行われる。この場合に、よりリアルな画像をプレーヤに提供するためには、弾が敵の戦闘機に当たった場合に、その弾痕についても表示することが望ましい。

しかしながら、このような弾痕を表示する処理では、弾の正確なヒット位置を求める処理等が必要になるため、処理負荷が重くなる。従って、このような弾痕表示を行うと、その代償として、他の処理が間に合わなくなるなどの問題が生じる。
特開２００１−２０４９５７号公報

本発明は、以上のような課題に鑑みてなされたものであり、その目的とするところは、効率的なヒットチェック処理を実現できるプログラム、情報記憶媒体及び画像生成システムを提供することにある。

本発明は、画像を生成する画像生成システムであって、ゲームを進行させるゲーム処理を、第１のハードウェアスレッド処理として行う第１のハードウェアスレッド処理部と、前記第１のハードウェアスレッド処理と並列に第２のハードウェアスレッド処理を行う第２のハードウェアスレッド処理部とを含み、前記第１のハードウェアスレッド処理部は、第１、第２のオブジェクトについての第１のヒットチェック処理を行い、前記第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、前記第２のハードウェアスレッド処理部は、前記第１のハードウェアスレッド処理部からヒットイベントの発生が通知された場合に、第１、第２のオブジェクトのヒットチェック処理として、前記第１のヒットチェック処理と異なる第２のヒットチェック処理を行う画像生成システムに関係する。また本発明は、上記各部として画像生成システムを機能させるプログラム、又は該プログラムを記憶したコンピュータ読み取り可能な情報記憶媒体に関係する。

本発明では、ゲーム処理を行う第１のハードウェアスレッド処理部が、第１、第２のオブジェクトの第１のヒットチェック処理を行い、ヒットイベントの発生を第２のハードウェアスレッド処理部に通知する。すると第２のハードウェアスレッド処理部は、第１、第２のオブジェクトのヒットチェック処理として、第１のヒットチェック処理と異なる第２のヒットチェック処理を行う。このようにすれば第１のハードウェアスレッド処理部は、第２のヒットチェック処理を行わなくても済むようになり、ヒットチェック処理を、役割分担して実行できる。従って、第２のヒットチェック処理が原因となって、他のゲーム処理が間に合わなくなるなどの事態を防止でき、効率的なヒットチェック処理を実現できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部は、前記第１のハードウェアスレッド処理部からヒットイベントの発生が通知された場合に、第１、第２のオブジェクトのヒットチェック処理として、前記第１のヒットチェック処理よりも処理負荷が重い第２のヒットチェック処理を行うようにしてもよい。

このようにすれば第１のハードウェアスレッド処理部は、処理負荷が重い第２のヒットチェック処理を行わなくても済むようになる。従って、処理負荷が重い第２のヒットチェック処理が原因となって、他のゲーム処理が間に合わなくなるなどの事態を防止できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部は、前記第２のヒットチェック処理のヒットチェック結果情報を、前記第１のハードウェアスレッド処理部に通知するようにしてもよい。

このようにすれば、第１のハードウェアスレッド処理部は、通知された第２のヒットチェック処理のヒットチェック結果情報に基づいて、種々の処理を実行できるようになる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、前記第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、前記第１のヒットチェック処理の結果に基づいてゲーム結果を演算するゲーム処理を行うようにしてもよい。

このようにすれば、第１のヒットチェック処理の結果に基づいて、ゲーム結果を演算できるようになり、スムーズなゲーム処理を実現できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、画像を描画する描画部を含み（描画部としてコンピュータを機能させ）、前記第１のハードウェアスレッド処理部は、前記第２のハードウェアスレッド処理部から前記第２のヒットチェック処理のヒットチェック結果情報が通知された場合に、前記ヒットチェック結果情報に応じた画像の描画を、前記描画部に対して指示するゲーム処理を行うようにしてもよい。

このようにすれば、詳細な第２のヒットチェック処理でのヒットチェック結果情報を反映した画像を生成できるため、プレーヤの仮想現実感を向上できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、第Ｋのフレームにおいて、第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、前記 第２のハードウェアスレッド処理部は、第Ｋのフレームでのヒットイベントの発生が通知された場合に、第Ｋのフレームの後の第Ｍ（Ｍ＞Ｋ）のフレームにおいて、前記第２のヒットチェック処理のヒットチェック結果情報を前記第１のハードウェアスレッド処理部に通知するようにしてもよい。

このようにすれば、第２のヒットチェック処理を、複数フレームの時間を使って実行できるようになり、詳細なヒットチェック処理の実現が可能になる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、第Ｍのフレームにおいて前記第２のハードウェアスレッド処理部から前記ヒットチェック結果情報が通知された場合に、第Ｍのフレームの後の第Ｎのフレーム（Ｎ＞Ｍ）において、前記ヒットチェック結果情報に応じたゲーム処理を行うようにしてもよい。

このようにすれば、ヒットチェック結果情報が原因となって、生成される画像に矛盾等が生じる事態を防止できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、画像の描画指示の前に、前記第２のハードウェアスレッド処理部からの前記ヒットチェック結果情報の監視処理を行うようにしてもよい。

このようにすれば、ヒットチェック結果情報が原因となって、生成される画像に矛盾等が生じる事態を確実に防止できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、前記第１のヒットチェック処理として、第１のオブジェクトの形状を簡素化した第１の簡易オブジェクトに対して、第２のオブジェクト又は第２のオブジェクトの形状を簡素化した第２の簡易オブジェクトがヒットしたか否かを判断する処理を行い、前記第２のハードウェアスレッド処理部は、前記第２のヒットチェック処理として、第１のオブジェクト自体に対して第２のオブジェクトがヒットしたか否かを判断する処理を行うようにしてもよい。

このようにすれば、第１のヒットチェック処理において、簡素で大雑把なヒットチェックを行い、第２のヒットチェック処理において、詳細で正確なヒットチェックを行うことが可能になる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、第１の簡易オブジェクトに対して第２のオブジェクト又は第２の簡易オブジェクトがヒットしたと判断した場合に、第１のヒットイベントフラグをオンにすることで、前記第１のヒットチェック処理でのヒットイベントの発生を前記第２のハードウェアスレッド処理部に対して通知し、前記第２のハードウェアスレッド処理部は、第１のオブジェクト自体に対して第２のオブジェクトがヒットしたと判断した場合に、第２のヒットイベントフラグをオンにすることで、前記第２のヒットチェック処理でのヒットイベントの発生を前記第１のハードウェアスレッド処理部に対して通知するようにしてもよい。

このような第１、第２のヒットイベントフラグを利用すれば、第１のハードウェアスレッド処理におけるヒットイベントの発生を第２のハードウェアスレッド処理部に通知し、第２のハードウェアスレッド処理におけるヒットイベントの発生を第１のハードウェアスレッド処理部に通知できるようになる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、前記第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、前記第２のヒットチェック処理に必要な第１、第２のオブジェクトの情報を記憶部に保存し、前記第２のハードウェアスレッド処理部は、保存された第１、第２のオブジェクトの情報に基づいて、前記第２のヒットチェック処理を行うようにしてもよい。

このようにすれば、第２のハードウェアスレッド処理部は、保存された第１、第２のオブジェクトの情報を活用して、詳細で正確な第２のヒットチェック処理を実行できるようになる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部は、前記第２のヒットチェック処理として、第１のオブジェクトに対する第２のオブジェクトのヒット位置を求める処理を行うようにしてもよい。

このようにすれば、ヒット位置の取得処理を、第２のハードウェアスレッド処理部に分担させて、効率的に実行できるようになる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部は、前記第２のヒットチェック処理により求められたヒット位置の情報を記憶部に保存し、前記第１のハードウェアスレッド処理部は、保存された前記ヒット位置の情報に基づいて、ゲーム処理を行うようにしてもよい。

このようにすれば、第１のハードウェアスレッド処理部は、ヒット位置の取得処理を、自分自身で実行しなくても済むようになり、第２のハードウェアスレッド処理部からのヒット位置に基づいてゲーム処理を実行できるようになる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、前記第２のハードウェアスレッド処理部により求められた前記ヒット位置の情報に基づいて、前記ヒット位置の画像を変化させる処理を行うようにしてもよい。

このようにすれば、第２のハードウェアスレッド処理部からのヒット位置の情報に基づいて、ヒット位置の画像を変化させることが可能になり、よりリアルな画像表現を実現できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、第１のオブジェクトに対して第２のオブジェクトがヒットした事を表す装飾画像を、前記ヒット位置に表示する処理を行うようにしてもよい。

このようにすれば、ヒットイベントの発生を表現するための装飾画像の生成が可能になる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部は、第１のオブジェクトに対する第２のオブジェクトのヒット位置を含む領域での第１のオブジェクトの形状を変形する処理を行うようにしてもよい。

このようにすれば、ヒット位置での第１のオブジェクトの形状が変化した画像を生成でき、プレーヤの仮想現実感を更に向上できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部は、形状変形処理のために予め細分化された第１のオブジェクトの表面の頂点の位置を変化させることで、前記ヒット位置を含む領域での第１のオブジェクトの形状を変形する処理を行うようにしてもよい。

このようにすれば、簡素な処理で形状変形処理を実現できるようになる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部は、前記第２のヒットチェック処理として、第１のオブジェクトの表面の領域のうち、第１のオブジェクトに対する第２のオブジェクトのヒットにより画像が変化する領域を特定する処理を行うようにしてもよい。

このようにすれば、特定された領域の画像を、ヒットイベントに応じた画像に変化させることが可能になり、生成される画像のリアル度を向上できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部は、第１のオブジェクトに対する第２のオブジェクトのヒット位置に応じて、第１のオブジェクトを回転させる処理を行うようにしてもよい。

このようにすれば、ヒット位置に応じた第１のオブジェクトの回転も表現することが可能になる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、第Ｋのフレームにおいて、第１のオブジェクトに対して第２のオブジェクトがヒットする第１のヒットイベントが発生した場合に、前記第１のヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、第Ｋのフレームの後の第Ｌ（Ｌ＞Ｋ）のフレームにおいて、第１のオブジェクトに対して第３のオブジェクトがヒットする第２のヒットイベントが発生した場合に、前記第２のヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、前記第２のハードウェアスレッド処理部は、前記第１のヒットイベントに対応する第２のヒットチェック処理と前記第２のヒットイベントに対応する第２のヒットチェック処理とを、所与の処理単位で交互に行うようにしてもよい。

このようにすれば、ヒットチェック処理の更なる効率化を図れる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部又は前記第１のハードウェアスレッド処理部は、前記第２のヒットチェック処理のヒットチェック結果情報を、リプレイデータとして保存するようにしてもよい。

このようにすれば、リプレイに最適な精細で高品質な画像の生成が可能になる。

また本発明は、ゲームを進行させるゲーム処理を、第１のハードウェアスレッド処理として行う第１のハードウェアスレッド処理部と、前記第１のハードウェアスレッド処理と並列に第２のハードウェアスレッド処理を行う第２のハードウェアスレッド処理部とを含み、前記第１のハードウェアスレッド処理部は、第１、第２のオブジェクトについての第１のヒットチェック処理を行い、前記第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知すると共に、前記第１のヒットチェック処理の結果に基づいてゲーム結果を演算するゲーム処理を行い、前記第２のハードウェアスレッド処理部は、前記第１のハードウェアスレッド処理部からヒットイベントの発生が通知された場合に、第１のオブジェクトに対する第２のオブジェクトのヒット位置を求める第２のヒットチェック処理を行う画像生成システムに関係する。

本発明では、ゲーム処理を行う第１のハードウェアスレッド処理部が、第１、第２のオブジェクトの第１のヒットチェック処理を行い、ヒットイベントの発生を第２のハードウェアスレッド処理部に通知すると共にゲーム結果の演算処理を行う。すると第２のハードウェアスレッド処理部は、第１のオブジェクトに対する第２のオブジェクトのヒット位置を求める処理を行う。このようにすれば第１のハードウェアスレッド処理部は、ヒット位置の取得処理を行わなくても済むようになる。従って、第２のヒットチェック処理が原因となって、他のゲーム処理が間に合わなくなるなどの事態を防止でき、効率的なヒットチェック処理を実現できる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第２のハードウェアスレッド処理部は、求められたヒット位置を、前記第２のヒットチェック処理のヒットチェック結果情報として前記第１のハードウェアスレッド処理部に通知するようにしてもよい。

このようにすれば、第１のハードウェアスレッド処理部は、第２のハードウェアスレッド処理部からのヒット位置に基づいて、種々の処理を実行できるようになる。

また本発明に係る画像生成システム、プログラム及び情報記憶媒体では、前記第１のハードウェアスレッド処理部は、前記第２のハードウェアスレッド処理部から前記ヒット位置が通知された場合に、前記ヒット位置の画像を変化させる処理を行うようにしてもよい。

このようにすれば、第２のハードウェアスレッド処理部からのヒット位置の情報に基づいて、ヒット位置の画像を変化させることが可能になり、よりリアルな画像表現を実現できる。

以下、本実施形態について説明する。なお、以下に説明する本実施形態は、特許請求の範囲に記載された本発明の内容を不当に限定するものではない。また本実施形態で説明される構成の全てが、本発明の必須構成要件であるとは限らない。

１．構成
図１に本実施形態の画像生成システム（ゲームシステム）のブロック図の例を示す。なお本実施形態の画像生成システムは図１の構成要素（各部）の一部を省略した構成としてもよい。

操作部１６０は、プレーヤが操作データを入力するためのものであり、その機能は、方向キー、操作ボタン、アナログスティック、レバー、ステアリング、アクセル、ブレーキ、マイク、或いはタッチパネル型ディスプレイなどにより実現できる。

記憶部１７０は、処理部１００や通信部１９６などのワーク領域となるもので、その機能はＲＡＭ（ＤＲＡＭ、ＶＲＡＭ）などにより実現できる。この記憶部１７０は、電源を切るとデータが消えてしまう揮発性のメモリにより構成できるが、補助記憶装置１９４よりも高速な記憶装置になっている。そしてゲームプログラムや、ゲームプログラムの実行に必要なゲームデータは、この記憶部１７０に保持される。

情報記憶媒体１８０（コンピュータにより読み取り可能な媒体）は、プログラムやデータなどを格納するものであり、その機能は、光ディスク（ＣＤ、ＤＶＤ）、或いはメモリ（ＲＯＭ等）などにより実現できる。処理部１００は、情報記憶媒体１８０に格納されるプログラム（データ）に基づいて本実施形態の種々の処理を行う。即ち情報記憶媒体１８０には、本実施形態の各部としてコンピュータ（操作部、処理部、記憶部、出力部を備える装置）を機能させるためのプログラム（各部の処理をコンピュータに実行させるためのプログラム）が記憶される。

表示部１９０は、本実施形態により生成された画像を出力するものであり、その機能は、ＣＲＴ、ＬＣＤ、タッチパネル型ディスプレイ、或いはＨＭＤ（ヘッドマウントディスプレイ）などにより実現できる。音出力部１９２は、本実施形態により生成された音を出力するものであり、その機能は、スピーカ、或いはヘッドフォンなどにより実現できる。

補助記憶装置１９４（補助メモリ、２次メモリ）は、記憶部１７０の容量を補うために使用される大容量の記憶装置であり、ＳＤメモリーカード、マルチメディアカードなどのメモリーカードや、ＨＤＤ（ハードディスクドライブ）などにより実現できる。この補助記憶装置１９４は脱着自在になっているが、内蔵されるものであってもよい。この補助記憶装置１９４は、ゲームの途中結果などのセーブデータや、プレーヤ（ユーザ）の個人的が画像データや音楽データなどを保存するために使用される。

通信部１９６は、有線や無線のネットワークを介して外部（例えば他の画像生成システム、サーバ、ホスト装置）との間で通信を行うものであり、その機能は、通信用ＡＳＩＣ又は通信用プロセッサなどのハードウェアや、通信用ファームウェアにより実現できる。

なお本実施形態の各部としてコンピュータを機能させるためのプログラム（データ）は、サーバ（ホスト装置）が有する情報記憶媒体からネットワーク及び通信部１９６を介して情報記憶媒体１８０（あるいは記憶部１７０、補助記憶装置１９４）に配信してもよい。このようなサーバ（ホスト装置）による情報記憶媒体の使用も本発明の範囲内に含めることができる。

処理部１００（プロセッサ）は、操作部１６０からの操作データやプログラムなどに基づいて、ゲーム処理、画像生成処理、或いは音生成処理などを行う。処理部１００は記憶部１７０（主記憶部１７２）をワーク領域として各種処理を行う。この処理部１００の機能は、各種プロセッサ（ＣＰＵ、ＧＰＵ等）、ＡＳＩＣ（ゲートアレイ等）などのハードウェアや、プログラムにより実現できる。

処理部１００は、Ｈ／Ｗスレッド処理部１０１、Ｈ／Ｗスレッド処理部１０２、描画部１２０、音生成部１３０を含む。なおこれらの一部を省略する構成としてもよい。

Ｈ／Ｗスレッド処理部１０１（第１のハードウェアスレッド処理部）は、ゲームを進行させるゲーム処理（ゲーム演算）を、第１のＨ／Ｗ（ハードウェア）スレッド処理として行う。ここでＨ／Ｗスレッド処理部１０１により実行されるゲーム処理としては、ゲーム開始条件が満たされた場合にゲームを開始する処理、ゲームを進行させる処理、操作部１６０からの操作データ（入力データ）を取得（モニタ）する処理、移動体やマップなどのオブジェクトを配置設定する処理、移動体を移動させたり動作させる処理、仮想カメラを制御する処理、ヒットチェック処理、ゲーム結果（ゲーム成績、ゲームポイント）を演算する処理、或いはゲーム終了条件が満たされた場合にゲームを終了する処理などがある。

Ｈ／Ｗスレッド処理部１０２（第２のハードウェアスレッド処理部）は、Ｈ／Ｗスレッド処理部１０１による第１のＨ／Ｗスレッド処理と並列に（並行して）、第２のＨ／Ｗスレッド処理を行う。

Ｈ／Ｗスレッド処理部１０１は、いわゆるゲームのメインループの処理を行い、ゲームスレッド処理を行う。一方、Ｈ／Ｗスレッド処理部１０２は、メインループとは異なる処理を、メインループの処理と並列に行う。例えば本実施形態では、Ｈ／Ｗスレッド処理部１０１は、処理負荷が軽いヒットチェック処理（簡易ヒットチェック）を行う一方で、Ｈ／Ｗスレッド処理部１０２は、処理負荷が重いヒットチェック処理（詳細ヒットチェック）を行う。これらのＨ／Ｗスレッド処理部１０１、１０２の機能は、いわゆるマルチスレッドプロセッサのハードウェアと、このマルチスレッドプロセッサにより実行される第１のＨ／Ｗスレッド処理プログラム（ゲームのメインプログラム）、第２のＨ／Ｗスレッド処理プログラム（詳細なヒットチェック処理用プログラム）のソフトウェアとにより実現できる。

なお図１では２つのＨ／Ｗスレッド処理部を設けた場合について示しているが、３つ以上のＨ／Ｗスレッド処理部を設けてもよい。例えばモーションデータを再生して移動体を動作させるモーション処理や、処理負荷が重いエフェクトやパーティクルなどの物理シミュレーション処理や、補助記憶装置１９４（ＨＤＤ）への書き込み・読み出し処理や、通信部１９６を制御して行うネットワーク通信処理などについては、その各々についてＨ／Ｗスレッド処理部を設けて、Ｈ／Ｗスレッド処理により実現してもよい。

Ｈ／Ｗスレッド処理部１０１は、オブジェクト空間設定部１１０、移動体演算部１１２、仮想カメラ制御部１１４、第１のヒットチェック処理部１１６、ゲーム結果演算部１１７を含むことができる。なお、これらの構成要素の一部を省略したり、他の構成要素を追加する変形実施も可能である。

オブジェクト空間設定部１１０は、モデルオブジェクト（戦闘機、車、人、ロボット、ミサイル、弾等）、マップ（地形）、建物、コース（道路）、樹木、壁などの表示物を表す各種オブジェクト（ポリゴン、自由曲面又はサブディビジョンサーフェイスなどのプリミティブ面で構成されるオブジェクト）をオブジェクト空間に配置設定する処理を行う。即ちワールド座標系でのオブジェクトの位置や回転角度（向き、方向と同義）を決定し、その位置（Ｘ、Ｙ、Ｚ）にその回転角度（Ｘ、Ｙ、Ｚ軸回りでの回転角度）でオブジェクトを配置する。具体的には、記憶部１７０のモデルデータ記憶部１７６には、移動体（戦闘機、キャラクタ）等のモデルデータが記憶されている。そしてオブジェクト空間設定部１１０は、このモデルデータを用いてオブジェクト空間へのオブジェクトの設定（配置）処理を行う。

移動体演算部１１２は、移動体を移動させるための演算を行う。また移動体を動作させるための演算も行う。即ち操作部１６０によりプレーヤが入力した操作データや、プログラム（移動・動作アルゴリズム）や、各種データ（モーションデータ）などに基づいて、移動体（オブジェクト、モデルオブジェクト）をオブジェクト空間内で移動させたり、移動体を動作（モーション、アニメーション）させる処理を行う。具体的には、移動体の移動情報（位置、回転角度、速度、或いは加速度）や動作情報（パーツオブジェクトの位置、或いは回転角度）を、１フレーム（１／６０秒）毎に順次求めるシミュレーション処理を行う。なおフレームは、移動体の移動・動作処理（シミュレーション処理）や画像生成処理を行う時間の単位である。

仮想カメラ制御部１１４は、オブジェクト空間内の所与（任意）の視点から見える画像を生成するための仮想カメラ（視点）の制御処理を行う。具体的には、仮想カメラの位置（Ｘ、Ｙ、Ｚ）又は回転角度（Ｘ、Ｙ、Ｚ軸回りでの回転角度）を制御する処理（視点位置、視線方向あるいは画角を制御する処理）を行う。

例えば仮想カメラにより戦闘機、車、キャラクタなどの移動体を後方から撮影する場合には、移動体の位置又は回転の変化に仮想カメラが追従するように、仮想カメラの位置又は回転角度（仮想カメラの向き）を制御する。この場合には、移動体演算部１１２で得られた移動体の位置、回転角度又は速度などの情報に基づいて、仮想カメラを制御できる。或いは、仮想カメラを、予め決められた回転角度で回転させたり、予め決められた移動経路で移動させる制御を行ってもよい。この場合には、仮想カメラの位置（移動経路）又は回転角度を特定するための仮想カメラデータに基づいて仮想カメラを制御する。

なお本実施形態の移動体は、画面に表示されるオブジェクトであってもよいし、画面に表示されない仮想的なオブジェクトであってもよい。例えば１人称視点等の場合には、仮想カメラの位置を移動体位置と見なすことができる。

第１のヒットチェック処理部１１６は、第１、第２のオブジェクト（モデルオブジェクト）についての第１のヒットチェック処理を行う。そして第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生をＨ／Ｗスレッド処理部１０２に通知する（知らせる）。この通知は、例えば記憶部１７０のレジスタの第１のヒットイベントフラグをオンにすることで実現できる。

ゲーム結果演算部１１７はゲーム結果（ゲーム成果度）の演算処理を行う。即ちゲームの得点、ゲーム成績、獲得ポイント、倒した対戦相手の数、勝ち抜き数、ステージクリア数、試合の勝敗、問題の正答数、クリア時間、順位、或いはラップタイムなどの種々のゲーム結果の演算処理を行う。このゲーム結果は、ゲーム処理における各種の判定処理や各種フラグに基づいて演算される。

Ｈ／Ｗスレッド処理部１０２は、第２のヒットチェック処理部１１８、画像変化処理部１１９を含む。なお、これらの構成要素の一部を省略したり、他の構成要素を追加する変形実施も可能である。

第２のヒットチェック処理部１１８は、Ｈ／Ｗスレッド処理部１０２からヒットイベントの発生が通知された場合（第１のヒットイベントフラグがオンになったことが検出された場合）に、第１、第２のオブジェクトのヒットチェック処理として、第１のヒットチェック処理とは異なる第２のヒットチェック処理を行う。即ち第１のヒットチェック処理と第２のヒットチェック処理は、同じ第１、第２のオブジェクトに関するヒットチェック処理ではあるが、その処理内容（プログラム記述、関数）が異なる。

具体的には、第２のヒットチェック処理は、第１のヒットチェック処理よりも処理負荷が重いヒットチェック処理である。或いは、第１のヒットチェック処理は、ゲーム進行（ゲーム結果演算）に不可欠（必要）なヒットチェック処理であり、第２のヒットチェック処理は、ゲーム進行（ゲーム結果演算）に影響を与えないヒットチェック処理（ゲーム進行に不可欠ではないヒットチェック処理）である。

なお処理負荷が重いとは、例えばその処理を実現する関数及び変数の少なくとも一方のプログラムでの記述量（ステップ数）が多い場合や、その関数が複雑（次数が多い。或いは線形関数）である場合等をいう。一方、処理負荷が軽いとは、例えばその処理を実現する関数及び変数の少なくとも一方のプログラムでの記述量が少ない場合や、その関数が簡素（次数が少ない。或いは非線形関数）である場合等をいう。

画像変化処理部１１９は、ヒットチェック処理に応じて画像を変化させる処理を行う。具体的には、第２のヒットチェック処理部１１８により求められたヒット位置の情報（座標）に基づいて、ヒット位置の画像を変化させるための処理を行う。例えば第１のオブジェクトに対して第２のオブジェクトがヒットした事を表す装飾画像（弾痕画像等）を、ヒット位置に表示するための処理を行う。またヒット位置を含む領域での第１のオブジェクトの形状を変形する処理を行い、ヒット位置での画像を変化させる。具体的には、この形状変形処理のために予め細分化された第１のオブジェクトの表面の頂点の位置を変化させることで、ヒット位置を含む領域（ヒット位置の周辺領域）での第１のオブジェクトの形状（頂点）を変形する処理を行う。

描画部１２０は、処理部１００で行われる種々の処理（ゲーム処理）の結果に基づいて描画処理を行い、これにより画像を生成し、表示部１９０に出力する。いわゆる３次元ゲーム画像を生成する場合には、まずモデル（オブジェクト）の各頂点の頂点データ（頂点の位置座標、テクスチャ座標、色データ、法線ベクトル或いはα値等）を含むモデルデータが入力され、入力されたモデルデータに含まれる頂点データに基づいて、頂点処理（頂点シェーダによるシェーディング）が行われる。なお頂点処理を行うに際して、必要に応じてポリゴンを再分割するための頂点生成処理（テッセレーション、曲面分割、ポリゴン分割）を行うようにしてもよい。

頂点処理では、頂点処理プログラム（頂点シェーダプログラム、第１のシェーダプログラム）に従って、頂点の移動処理や、座標変換（ワールド座標変換、カメラ座標変換）、クリッピング処理、あるいは透視変換等のジオメトリ処理が行われ、その処理結果に基づいて、オブジェクトを構成する頂点群について与えられた頂点データを変更（更新、調整）する。そして、頂点処理後の頂点データに基づいてラスタライズ（走査変換）が行われ、ポリゴン（プリミティブ）の面とピクセルとが対応づけられる。そしてラスタライズに続いて、画像を構成するピクセル（表示画面を構成するフラグメント）を描画するピクセル処理（ピクセルシェーダによるシェーディング、フラグメント処理）が行われる。

ピクセル処理では、ピクセル処理プログラム（ピクセルシェーダプログラム、第２のシェーダプログラム）に従って、テクスチャの読出し（テクスチャマッピング）、色データの設定／変更、半透明合成、アンチエイリアス等の各種処理を行って、画像を構成するピクセルの最終的な描画色を決定し、透視変換されたモデルの描画色を描画バッファ１７４（ピクセル単位で画像情報を記憶できるバッファ。ＶＲＡＭ、レンダリングターゲット）に出力（描画）する。即ち、ピクセル処理では、画像情報（色、法線、輝度、α値等）をピクセル単位で設定あるいは変更するパーピクセル処理を行う。これにより、オブジェクト空間内において仮想カメラ（所与の視点）から見える画像が生成される。

なお頂点処理やピクセル処理は、シェーディング言語によって記述されたシェーダプログラムによって、ポリゴン（プリミティブ）の描画処理をプログラム可能にするハードウェア、いわゆるプログラマブルシェーダ（頂点シェーダやピクセルシェーダ）により実現できる。プログラマブルシェーダでは、頂点単位の処理やピクセル単位の処理がプログラム可能になることで描画処理内容の自由度が高く、従来のハードウェアによる固定的な描画処理に比べて表現力を大幅に向上させることができる。

描画部１２０は、オブジェクトを描画する際にジオメトリ処理、隠面消去処理、αブレンディング、テクスチャマッピング処理等を行う。

ジオメトリ処理では、オブジェクトに対して、座標変換、クリッピング処理、透視投影変換、或いは光源計算等の処理が行われる。そして、ジオメトリ処理後（透視投影変換後）のモデルデータ（オブジェクトの頂点の位置座標、テクスチャ座標、色データ、法線ベクトル、或いはα値等）は、記憶部１７０に保存される。

隠面消去処理としては、描画ピクセルのＺ値（奥行き情報）が格納されるＺバッファ（奥行きバッファ）を用いたＺバッファ法（奥行き比較法、Ｚテスト）による隠面消去処理がある。即ちオブジェクトのプリミティブに対応する描画ピクセルを描画する際に、Ｚバッファ（描画バッファのＺプレーン）に格納されるＺ値を参照する。そして参照されたＺバッファのＺ値と、プリミティブの描画ピクセルでのＺ値とを比較し、描画ピクセルでのＺ値が、仮想カメラから見て手前側となるＺ値（例えば小さなＺ値）である場合には、その描画ピクセルの描画処理を行うとともにＺバッファのＺ値を新たなＺ値に更新する。

αブレンディング（α合成）は、α値（Ａ値）に基づいて行う処理であり、通常αブレンディング、加算αブレンディング或いは減算αブレンディングなどがある。なおα値は、各ピクセル（テクセル、ドット）に関連づけて記憶できる情報であり、例えば色情報以外のプラスアルファの情報である。α値は、半透明度（透明度、不透明度と等価）情報、マスク情報、或いはバンプ情報などとして使用できる。

テクスチャマッピング（テクスチャフェッチ、テクスチャサンプリング）処理は、テクスチャ記憶部１７８に記憶されるテクスチャ（テクセル値）をオブジェクトにマッピングする処理である。具体的には、オブジェクト（プリミティブ面）の頂点等に設定（付与）されるテクスチャ座標等を用いてテクスチャ記憶部１７８からテクスチャ（色、α値などの表面プロパティ）を読み出す。そして、２次元の画像又はパターンであるテクスチャをオブジェクトにマッピングする。この場合に、ピクセルとテクセルとを対応づける処理やバイリニア補間（広義にはテクセル補間）などを行う。

音生成部１３０は、処理部１００で行われる種々の処理の結果に基づいて音処理を行い、ＢＧＭ、効果音、又は音声などのゲーム音を生成し、音出力部１９２に出力する。

本実施形態ではＨ／Ｗスレッド処理部１０１は、第１、第２のオブジェクトについての第１のヒットチェック処理を行い、第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生をＨ／Ｗスレッド処理部１０２に通知する。また第１のヒットチェック処理の結果（ヒットチェックの判定結果）に基づいてゲーム結果を演算するゲーム処理を行う。

一方、Ｈ／Ｗスレッド処理部１０２は、ヒットイベントの発生が通知されると、第１のヒットチェック処理よりも例えば処理負荷が重い第２のヒットチェック処理を行う。具体的には。第１のオブジェクトに対する第２のオブジェクトのヒット位置を求める。

そしてＨ／Ｗスレッド処理部１０２は、第２のヒットチェック処理のヒットチェック結果情報（第２のヒットイベントフラグ又はヒット位置等）を、Ｈ／Ｗスレッド処理部１０１に通知する（知らせる）。するとＨ／Ｗスレッド処理部１０１は、通知されたヒット位置での画像を変化させる処理を行う。具体的にはＨ／Ｗスレッド処理部１０１は、Ｈ／Ｗスレッド処理部１０２からヒットチェック結果情報が通知されると、ヒットチェック結果情報に基づく画像の描画を、描画部１２０に対して指示する。例えば描画データを転送すると共に描画コマンドを発行する。

この場合にＨ／Ｗスレッド処理部１０２は、例えば第Ｋのフレームにおいてヒットイベントの発生が通知されると、第Ｋのフレームの後の第Ｍ（Ｍ＞Ｋ。Ｋ、Ｍは自然数）のフレームにおいて、第２のヒットチェック処理のヒットチェック結果情報をＨ／Ｗスレッド処理部１０１に通知する。そしてＨ／Ｗスレッド処理部１０１は、第ＭのフレームにおいてＨ／Ｗスレッド処理部１０２からヒットチェック結果情報が通知されると、第Ｍのフレームの後の第Ｎのフレーム（Ｎ＞Ｍ。Ｎは自然数）において、ヒットチェック結果情報に応じたゲーム処理（ヒット位置の画像を変化させる処理等）を行う。具体的にはＨ／Ｗスレッド処理部１０１は、描画部１２０への画像の描画指示の前のステップで、Ｈ／Ｗ処理部１０２からのヒットチェック結果情報（第２のヒットイベントフラグ）の監視処理を行う。

またＨ／Ｗスレッド処理部１０１は、第２のヒットチェック処理よりも処理負荷が軽い第１のヒットチェック処理として、第１のオブジェクトの形状を簡素化した第１の簡易オブジェクトに対して、第２のオブジェクト又は第２のオブジェクトの形状を簡素化した第２の簡易オブジェクトがヒットしたか否かを判断する処理を行う。そしてヒットしたと判断された場合には、第１のヒットイベントフラグをオンにすることで、第１のヒットチェック処理でのヒットイベントの発生を通知する。なお、この第１、第２の簡易オブジェクトは、第１、第２のオブジェクトよりもポリゴン数（プリミティブ面数）が少ないオブジェクトである。

またＨ／Ｗスレッド処理部１０２は、処理負荷が重い第２のヒットチェック処理として、第１の簡易オブジェクトではなく、実際に表示される第１のオブジェクト自体に対して第２のオブジェクトがヒットしたか否かを判断する。そしてヒットしたと判断された場合には、第２のヒットイベントフラグをオンにすることで、第２のヒットチェック処理でのヒットイベントの発生をＨ／Ｗスレッド処理部１０１に通知する。

なおＨ／Ｗスレッド処理部１０１は、第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、第２のヒットチェック処理に必要な第１、第２のオブジェクトの情報（モデル情報、位置、ベクトル等）を記憶部１７０に保存する。するとＨ／Ｗスレッド処理部１０２は、保存された第１、第２のオブジェクトの情報に基づいて、第２のヒットチェック処理を行う。そしてＨ／Ｗスレッド処理部１０２は、第１のオブジェクトに対する第２のオブジェクトのヒット位置を求め、求められたヒット位置の情報を記憶部１７０に保存する。するとＨ／Ｗスレッド処理部１０１は、保存されたヒット位置の情報に基づいて、ゲーム処理を行う。

なお、本実施形態の画像生成システムは、１人のプレーヤのみがプレイできるシングルプレーヤモード専用のシステムにしてもよいし、複数のプレーヤがプレイできるマルチプレーヤモードも備えるシステムにしてもよい。また複数のプレーヤがプレイする場合に、これらの複数のプレーヤに提供するゲーム画像やゲーム音を、１つの端末を用いて生成してもよいし、ネットワーク（伝送ライン、通信回線）などで接続された複数の端末（ゲーム機、携帯電話）を用いて分散処理により生成してもよい。

２．本実施形態の手法
２．１ Ｈ／Ｗスレッドによるヒットチェック
コンピュータのプログラムは、記述された命令コードが順次実行されながら動作する。通常、プログラムに分岐やループがあっても、プログラム全体は１つの流れになっており、このような一連のプログラムの流れがスレッドと呼ばれる。このスレッドは、並列処理の実行単位でもある。

そして、近年、複数のスレッドを並列的に処理可能なマルチスレッドプロセッサが、ゲーム装置などの画像生成システムに採用されるようになってきている。このマルチスレッドプロセッサでは、例えばレジスタファイルや演算器などのハードウェア資源をスレッドごとに用意することで、複数のスレッドの並列処理を実現する。そしてスレッド単位で処理を並列化することによりハードウェア資源を有効に活用し、全体としての処理を効率化する。

Ｈ／Ｗ（ハードウェア）スレッド処理は、このようなマルチスレッドプロセッサにより並列実行されるスレッド処理である。そしてＨ／Ｗスレッドは、マルチスレッドプロセッサが備える複数のハードウェアリソースの全部又は一部を区分し、実行されるスレッドごとに割り当てられた仮想的な単位である。

本実施形態では、このＨ／Ｗスレッド処理を有効活用する手法を採用することで、オブジェクト間のヒットチェック処理の効率化を図っている。

例えば図２において、ステップＳ１〜Ｓ６は、ゲームスレッドである第１のＨ／Ｗスレッド処理ＨＳ１の処理である。一方、ステップＳ１１、Ｓ１２は、コリジョン（衝突）スレッドである第２のＨ／Ｗスレッド処理ＨＳ２の処理である。

ステップＳ１〜Ｓ６はゲームのメインのループ処理である。即ち、まずフレームが更新されたか否かを判断し（ステップＳ１）、フレームが更新された場合には操作データを取得する（ステップＳ２）。そして、移動体演算やゲーム進行処理などのゲーム処理を行う（ステップＳ３）。次に、簡易ヒットチェックである第１のヒットチェック処理ＣＨ１を行う（ステップＳ４）。そしてこのヒットチェック処理ＣＨ１の結果に基づいて、得点やゲーム成績などのゲーム結果を演算する（ステップＳ５）。次に、描画データ（ポリゴンデータ）を送信し、描画コマンドを発行して、描画部に描画を指示する（ステップＳ６）。

ステップＳ９の簡易的なヒットチェック処理ＣＨ１において、第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断されると、ヒットイベントの発生がヒットイベントフラグなどを用いて、Ｈ／Ｗスレッド処理ＨＳ２に通知される。するとＨ／Ｗスレッド処理ＨＳ２では、詳細なヒットチェックである第２のヒットチェック処理ＣＨ２が行われる（ステップＳ１１）。そしてヒットチェック処理ＣＨ２のヒットチェック結果情報（ヒットイベントフラグ、ヒット位置等）が取得されて（ステップＳ１２）、Ｈ／Ｗスレッド処理ＨＳ１に通知される。

このように図２の本実施形態の手法では、ステップＳ１〜Ｓ６のＨ／Ｗスレッド処理ＨＳ１のヒットチェック処理ＣＨ１においてヒットイベントの発生が検出されると、ＨＳ１とは異なるＨ／Ｗスレッド処理ＨＳ２がスタートし、ＣＨ１よりも処理負荷が重く詳細なヒットチェック処理ＣＨ２が実行される。そしてこのヒットチェック処理ＣＨ２において第１、第２のオブジェクトがヒットした判断されると、そのヒットチェック結果情報がＨ／Ｗスレッド処理ＨＳ１に伝えられる。

図３に、本実施形態の手法を戦闘機ゲームに適用した場合の例を示す。例えばフレーム１では、Ｈ／Ｗスレッド処理ＨＳ１において、戦闘機を表すオブジェクトＯＢ１とミサイルや機関銃の弾を表すオブジェクトＯＢ２との間の簡易的なヒットチェック処理ＣＨ１が行われる。具体的には、第１のオブジェクトＯＢ１の形状を簡素化した第１の簡易オブジェクトＳＰ１（球オブジェクト）と、第２のオブジェクトＯＢ２の形状を簡素化した第２の簡易オブジェクトＳＰ２（球オブジェクト）を用いてヒットチェック処理ＣＨ１が行われる。なお、第２の簡易オブジェクトＳＰ２ではなく、第２のオブジェクトＯＢ２自体を用いてもよい。

そしてフレーム１では、簡易オブジェクトＳＰ１、ＳＰ２は交差していないため、オブジェクトＯＢ１、ＯＢ２はヒットしていないと判断される。

一方、フレーム２（広義には第Ｋのフレーム）では、簡易オブジェクトＳＰ１、ＳＰ２は交差しているため、オブジェクトＯＢ１、ＯＢ２はヒットしたと判断される。すると第１のヒットイベントフラグがオンになり、ヒットイベントが通知され、Ｈ／Ｗスレッド処理ＨＳ２がスタートする。またＯＢ１で表される戦闘機に対して、ＯＢ２で表されるミサイルや弾が当たったと判断され、このヒットチェック処理の結果に応じたゲーム結果の演算が行われる。即ち、ミサイルや弾による破壊により戦闘機の耐久力を減少させる演算が行われる。

Ｈ／Ｗスレッド処理ＨＳ２では、ＯＢ１とＯＢ２のヒットイベントが通知されると、第１のヒットチェック処理ＣＨ１よりも処理が重く詳細な第２のヒットチェック処理ＣＨ２が行われる。このヒットチェック処理ＣＨ２では、簡易オブジェクトＳＰ１、ＳＰ２を用いずに、オブジェクトＯＢ１自体に対してオブジェクトＯＢ２がヒットしたか否かが判断される。即ちミサイルや弾が戦闘機に本当にヒットしたか否かのチェックが行われる。

そしてフレーム４（広義には第Ｋのフレームの後の第Ｍのフレーム）では、ミサイルや弾が戦闘機に本当にヒットしたと判断されたため、ミサイルや弾のヒット位置が求められる。そしてヒットチェック結果情報としてヒット位置の座標がＨ／Ｗスレッド処理ＨＳ１に通知される。また第２のヒットイベントフラグがオンになり、戦闘機にミサイルや弾が本当にヒットしたことが知らされる。

するとフレーム５（広義には第Ｍのフレームの後の第Ｎのフレーム）では、ヒットチェック結果情報に応じたゲーム処理が行われる。具体的には、ヒット位置にミサイルや弾の弾痕を表示する処理が行われる。即ちヒットチェック結果情報（ヒット位置）に応じた画像の描画が描画部に指示されて、弾痕表示の画像が生成される。

例えば敵の戦闘機にミサイルや弾が当たって戦闘機にダメージを与える処理は、即座に行うことが望ましい。即ちミサイルや弾が当たったことで、その戦闘機が墜落したり、操縦不能になったりする。ところが、戦闘機にミサイルや弾が当たったか否かの判断を、負荷の重い詳細なヒットチェック処理で実現すると、このヒットチェック処理に時間がかかってしまい、ゲーム結果の演算処理や描画処理が間に合わなくなるおそれがある。

そこで図３のＨ／Ｗスレッド処理ＨＳ１では、戦闘機にミサイルや弾が当たったか否かの判断を、簡易オブジェクトＳＰ１、ＳＰ２を用いた簡易なヒットチェック処理ＣＨ１で実現する。そして、この簡易なヒットチェック処理ＣＨ１で、戦闘機にミサイルや弾が当たったと判断されると、戦闘機の耐久力を下げるなどのゲーム結果演算処理を、メインのＨ／Ｗスレッド処理ＨＳ１において即座に行う。このようにすれば、処理が間に合わなくなり、戦闘機の墜落が遅れて、プレーヤに不自然感を与えるなどの事態を防止できる。

一方、このようなＨ／ＷスレッドＨＳ１における簡易なヒットチェック処理ＣＨ１により、戦闘機にミサイルや弾が当たったと仮判断されると、Ｈ／ＷスレッドＨＳ２が立ち上がって、オブジェクトＯＢ１、ＯＢ２自体を用いた詳細なヒットチェック処理ＣＨ２が行われる。そして戦闘機にミサイルや弾が本当に当たったか否かが判断され、当たったと判断されると、そのヒット位置に弾痕が表示される。

戦闘機にミサイルや弾が当たったか否かは、ゲーム進行に大きな影響を与えるため、Ｈ／Ｗスレッド処理ＨＳ１において即座に行う必要がある。一方、弾痕表示は、ゲームの進行には影響を与えず、単なる演出効果である。従って、この弾痕表示の処理は、即座に行う必要はないため、Ｈ／Ｗスレッド処理ＨＳ２が実行する。そしてＨ／Ｗスレッド処理ＨＳ２は、メインのゲーム処理であるＨ／Ｗスレッド処理ＨＳ１と並列に実行され、ヒットチェック処理ＣＨ２に時間がかかったとしても、ＨＳ１の処理に悪影響を与えることはない。そして、十分に時間をかけてヒット位置を正確に求め、そのヒット位置に弾痕を表示する。この場合に図３に示すように、弾痕表示が行われるタイミングが遅れたとしても、ゲーム結果には影響を与えず、プレーヤも不自然さをそれほど感じない。従って、ゲーム結果については即座に求めてゲーム処理をスムーズに進行できると共に、ヒット位置に弾痕が表示されたリアルな画像を生成して、プレーヤに提供できるようになる。即ちスムーズなゲーム進行処理と、生成される画像のリアル度の向上を両立できる。

なお図３では、フレーム２（広義には第Ｋのフレーム）において、オブジェクトＯＢ１（ＳＰ１）に対してオブジェクトＯＢ２がヒットしたと判断されると、ヒットイベントの発生がＨ／Ｗスレッド処理ＨＳ２に通知される。そしてフレーム２（第Ｋのフレーム）の後のフレーム４（広義には第Ｍのフレーム）において、ヒットチェック処理ＣＨ２のヒットチェック結果情報がＨ／Ｗスレッド処理ＨＳ１に通知される。そして、ヒットチェック結果情報が通知されると、フレーム４（第Ｍのフレーム）の後のフレーム５（広義には第Ｎのフレーム）において、ヒットチェック結果情報に応じたゲーム処理である弾痕の表示処理が行われる。

この場合、図３において、フレーム５（第Ｎのフレーム）ではなく、前のフレーム４（第Ｍのフレーム）で弾痕表示を行おうとすると、弾痕表示の処理が間に合わなくなり、弾痕の一部の画像が欠けたりするなどの不具合が生じる可能性がある。

この点、図３では、フレーム４（第Ｍのフレーム）ではなく、次のフレーム５（第Ｎのフレーム）において弾痕表示が行われる。これは、例えば画像の描画開始の指示の前に、Ｈ／Ｗスレッド処理ＨＳ２からのヒットチェック結果情報である第２のヒットイベントフラグの監視処理を行うことで、実現できる。

また図３から明らかなように、Ｈ／Ｗスレッド処理ＨＳ２において、ヒット位置を求める詳細なヒットチェック処理ＣＨ２を行うと、実際にヒットイベントが発生してから例えば数フレーム後に、ヒットチェック処理ＣＨ２が完了して、弾痕が表示されるようになる。しかしながら、このように弾痕表示のタイミングが遅れても、ミサイルや弾のヒットによるゲーム結果の演算処理については遅れないため、ゲーム進行には悪影響は及ばさない。

なお図３では、フレーム４（第Ｍのフレーム）の後のフレーム５（第Ｎのフレーム）で、弾痕表示等のヒットチェック結果情報に応じたゲーム処理を行っている。しかしながら、処理時間に余裕がある場合には、フレーム４（第Ｍのフレーム）においてヒットチェック結果情報に応じたゲーム処理を行うようにしてもよく、Ｎ≧Ｍであってもよい。

２．２ ヒットチェック処理
次にヒットチェック処理の詳細例を説明する。例えば図４（Ａ）の大雑把な当たり判定であるヒットチェック処理ＣＨ１では、戦闘機のオブジェクトＯＢ１には、例えばＯＢ１の代表点を中心点とする球の簡易オブジェクトＳＰ１（ヒットチェック用オブジェクト）が設定される。同様に、ミサイルや弾のオブジェクトＯＢ２には、例えばＯＢ２の代表点を中心点とする球の簡易オブジェクトＳＰ２（ヒットチェック用オブジェクト）が設定される。そして、球の簡易オブジェクトＳＰ１、ＳＰ２の半径をＲ１、Ｒ２とし、オブジェクトＯＢ１、ＯＢ２間の距離（代表点間の距離）をＲとした場合に、簡易ヒットチェック処理ＣＨ１では、Ｒ≦Ｒ１＋Ｒ２か否かが判断される。そしてＲ≦Ｒ１＋Ｒ２であれば、戦闘機にミサイルや弾がヒットしたと判断し、戦闘機の耐久力を減らす。

一方、図４（Ｂ）のヒットチェック処理ＣＨ２では、図１（Ａ）のような簡易オブジェクトＳＰ１、ＳＰ２を使用せずに、多数のポリゴンで構成される戦闘機のオブジェクトＯＢ１自体に、オブジェクトＯＢ２がヒットしたか否かが判断される。具体的には図４（Ｃ）に示すように、オブジェクトＯＢ１を構成する各ポリゴンについて、オブジェクトＯＢ２のベクトルＶ２が交差したか否かを判断し、交差した場合には、そのヒット位置ＨＰを求める。そして求められたヒット位置ＨＰに弾痕を表示する。

例えば戦闘機のオブジェクトＯＢ１は、画像のリアル度を向上するために、多数のポリゴンで構成される。従って、このようなオブジェクトＯＢ１を構成する各ポリゴンについて行うヒットチェック処理ＣＨ２は、処理負荷が非常に重い。従って、このヒットチェック処理ＣＨ２を、ゲームスレッドであるＨ／Ｗスレッド処理ＨＳ１において行うと、他の処理が１フレーム以内に完了しないなどの問題が生じるおそれがある。

本実施形態によれば、このヒットチェック処理ＣＨ２は、Ｈ／Ｗスレッド処理ＨＳ１とは別のＨ／Ｗスレッド処理ＨＳ２で行われるため、このような問題の発生を防止できる。

なお図４（Ａ）では、オブジェクトＯＢ１の形状を、１つの簡易オブジェクトＳＰ１（球）で近似しているが、２つ以上の簡易オブジェクト（球）で近似してもよい。また簡易オブジェクトＳＰ１、ＳＰ２は、球の形状であることが処理負荷の軽減のためには好ましいが、これに限定されず、球以外の形状（例えば円柱、四角錐等）であってもよい。

図５（Ａ）に、ヒットチェック処理ＣＨ１において保存される情報の例を示す。図５（Ａ）に示すように、ヒットチェック処理ＣＨ１においてオブジェクトＯＢ１（ＳＰ１）にＯＢ２（ＳＰ２）がヒットした判断されると、ヒットイベントフラグＦ１がオンにされる。このヒットイベントフラグＦ１は、フラグ用のレジスタに設定される。

またオブジェクトＯＢ１にＯＢ２がヒットした判断されると、詳細なヒットチェック処理ＣＨ２に必要なオブジェクトＯＢ１、ＯＢ２の情報が記憶部（レジスタ）に保存される。例えば図５（Ａ）では、戦闘機のオブジェクトＯＢ１の情報として、ＯＢ１を指定するためのオブジェクト番号（モデル番号）ＯＢＮが記憶部に保存される。またオブジェクトＯＢ１の代表点の位置Ｐ１（Ｘ１、Ｙ１、Ｚ１）と、ＯＢ１の方向ＤＲ１（θＸ１、θＹ１、θＺ１）が保存される。なお方向ＤＲ１は、オブジェクトＯＢ１の姿勢を表すものであり、θＸ１、θＹ１、θＺ１は、各々、Ｘ、Ｙ、Ｚ軸回りの回転角度である。

また図５（Ｂ）では、ミサイルや弾のオブジェクトＯＢ２の情報として、位置（Ｘ２、Ｙ２、Ｚ２）と、ミサイルや弾の向きと長さを表すベクトルＶ２（ＶＸ２、ＶＹ２、ＶＺ２）が保存される。

図５（Ｂ）に、ヒットチェック処理ＣＨ２において保存されるヒットチェック結果情報の例を示す。図５（Ｂ）に示すように、ヒットチェック処理ＣＨ２においてオブジェクトＯＢ１にＯＢ２がヒットしたと判断されると、ヒットイベントフラグＦ２がオンにされる。このヒットイベントフラグＦ２は、フラグ用のレジスタに設定される。

またオブジェクトＯＢ１にＯＢ２がヒットしたと判断されると、そのヒット位置ＨＰ（ＸＨ１、ＹＨ１、ＺＨ１）が求められる。即ちオブジェクトＯＢ１を構成するポリゴンのうち、オブジェクトＯＢ２のベクトルＶ２に交差するポリゴンが検索され、そのポリゴンにＶ２が交差する点が、ヒット位置ＨＰとして求められる。

そしてヒット位置ＨＰが求められると、そのヒット位置の情報（座標）が、ヒットチェック結果情報として保存される。そしてＨ／Ｗスレッド処理ＨＳ１は、保存されたヒット位置の情報に基づいて、ゲーム処理（描画処理）を行う。具体的には、ヒット位置の画像を変化させる処理を行う。例えば図６（Ａ）に示すように、オブジェクトＯＢ１に対してＯＢ２がヒットした事を表す弾痕画像（広義には装飾画像）がヒット位置に表示される。

この弾痕画像の表示処理（画像を変化させる処理）は、例えば図６（Ｂ）に示すように、弾痕を表すポリゴンを、ヒット位置に配置設定することで実現できる。或いは図６（Ｃ）に示すように、ヒット位置付近のテクスチャを、元絵のテクスチャ（戦闘機の通常の表面を表すテクスチャ）から、弾痕が表現された弾痕テクスチャに切り替えることで、実現してもよい。なお図６（Ｂ）、図６（Ｃ）とは異なる手法で、弾痕などの装飾画像を表現してもよい。また本実施形態で実現される装飾画像は、弾痕には限定されない。例えばゴミや塵のオブジェクトが車体のオブジェクトにヒット（接触）したことで生成される汚れ画像などであってもよい。

２．３ 形状変形処理
Ｈ／Ｗスレッド処理ＨＳ２で行われる処理は、オブジェクトＯＢ１に対するＯＢ２のヒット位置を求める処理に限定されない。例えば、Ｈ／Ｗスレッド処理ＨＳ２において、ヒット位置を含む領域でのオブジェクトＯＢ１の形状を変形する処理を行ってもよい。

例えば格闘技ゲームにおいて、キャラクタの顔や体に他のキャラクタのパンチやキックがヒットした場合に、パンチやキックによりヒット位置の部分の形状を変形させて、その部分が腫れて膨らんで見える画像を生成できれば、プレーヤの仮想現実感を向上できる。

しかしながら、このような形状変形処理を、ゲームのメインのループであるＨ／Ｗスレッド処理ＨＳ１で行うと、形状変形処理は処理負荷が重いため、他の処理（例えば描画処理）を１フレーム内で完了できなくなるなどの問題が生じるおそれがある。

一方、パンチやキックがキャラクタにヒットした場合に、そのキャラクタの耐久力を減らすゲーム結果の演算処理については、即座に行うことが望ましい。

そこで例えば図７（Ａ）のように、キャラクタの顔を表すオブジェクトＯＢ１に対して、他のキャラクタの拳などを表すオブジェクトＯＢ２が当たった場合に、ＯＢ１にＯＢ２がヒットしたか否かの判断処理については、ゲームスレッドであるＨ／Ｗスレッド処理ＨＳ１において行う。そしてヒットした判断した場合に、ヒットイベントの発生をＨ／Ｗスレッド処理ＨＳ２に通知すると共に、キャラクタの耐久力を減らすなどのゲーム結果の演算処理を行う。

そしてヒットイベントの発生が通知されると、Ｈ／Ｗスレッド処理ＨＳ２では、顔のオブジェクトＯＢ１に対する拳のオブジェクトＯＢ２のヒット位置ＨＰを求める処理を行う。そしてヒット位置ＨＰを含む領域ＳＦ１でのオブジェクトＯＢ１の形状を変形する処理を行う。これにより、ヒット位置ＨＰの部分がパンチにより腫れて膨らんで見える画像を生成できるため、プレーヤの仮想現実感を向上できる。

この場合、図３から明らかなように、Ｈ／Ｗスレッド処理ＨＳ２において形状変形処理を行うと、実際にヒットイベントが発生してから例えば数フレーム後に、形状変形処理が完了する。しかしながら、このように形状変形処理の完了が遅れても、パンチのヒットによるゲーム結果の演算処理については遅れないため、ゲーム進行には悪影響は及ばさない。そして、形状変形処理の完了が遅れると、パンチのヒット後、ある程度時間が経ってから、キャラクタの顔が徐々に膨らんで行くように見えるため、画像のリアル度を逆に向上できる。

なお形状変形処理は例えば以下のようにして実現できる。例えば図７（Ａ）に示すように、オブジェクトＯＢ１の表面を形状変化処理のために予め細分化しておく。即ち、オブジェクトＯＢ１の表面である例えば頬の部分が平らであり少ないポリゴン分割数で表現できる場合にも、わざと多数のポリゴンで表面を分割して細分化しておく。そして図７（Ｂ）に示すように、このように細分化されたオブジェクトＯＢ１の表面の頂点の位置を変化させることで、ヒット位置ＨＰを含む領域ＳＦ１でのＯＢ１の形状変形処理を実現する。

例えばオブジェクトＯＢ１に対するＯＢ２のヒットイベントが発生した場合に、オブジェクトＯＢ１の領域ＳＦ１を構成するポリゴンの頂点データリストを、図７（Ｃ）のように変更する。即ち頂点データリストに設定されるポリゴンの頂点のＸ、Ｙ、Ｚ座標を変更する。

この場合に、例えば拳がヒットした時のパンチの威力の大小に応じて、形状変形の度合いを変化させてもよい。具体的には、拳を表すオブジェクトＯＢ２の速度情報や運動エネルギー情報などを例えばＨ／Ｗスレッド処理ＨＳ１において演算し、記憶部に保存する。そしてＨ／Ｗスレッド処理ＨＳ２では、この保存された速度情報や運動エネルギー情報などに基づいて、形状変形（頂点の変位）の度合いを変化させる。こうすることで、パンチの威力に応じて領域ＳＦ１での表面の膨らみ具合が変化するようになり、プレーヤの仮想現実感を更に向上できる。

２．４ 領域特定処理
Ｈ／Ｗスレッド処理ＨＳ２で行われる処理として、オブジェクトＯＢ１に対するオブジェクトＯＢ２のヒットにより画像が変化する領域を特定する処理を行ってもよい。即ち、ヒット位置を含む領域のうち、ヒットにより画像が変化すべき領域を特定する。

例えば図８（Ａ）では、サッカー選手のキャラクタを表すオブジェクトＯＢ２がスライディングを行っている。この場合に、このスライディングによりグラウンドの芝が削れる領域を特定し、この特定された領域の画像が変化したように見える画像を生成できれば、プレーヤの仮想現実感を向上できる。

しかしながら、このようなスライディングの領域特定処理を、ゲームのメインのループであるＨ／Ｗスレッド処理ＨＳ１で行うと、処理負荷が重いため、他の処理を１フレーム内で完了できなくなるなどの問題が生じるおそれがある。

一方、このようなスライディングが行われた場合に、そのスライディングによりボールを奪ったか否かを判断するゲーム結果の演算処理については、即座に行うことが望ましい。

そこで図８（Ａ）のように、サッカーのグラウンドを表すオブジェクトＯＢ１（マップオブジェクト）に対してＯＢ２がヒットするスライディングのヒットイベント発生の判断処理については、Ｈ／Ｗスレッド処理ＨＳ１が行う。そしてスライディングのヒットイベントが発生した場合には、ヒットイベントの発生をＨ／Ｗスレッド処理ＨＳ２に通知すると共に、スライディングによりボールを奪ったか否かを判断するゲーム結果の演算処理を行う。

そして図８（Ａ）のようなスライディングのヒットイベントの発生が通知されると、Ｈ／Ｗスレッド処理ＨＳ２では、図８（Ｂ）に示すように、グラウンドのオブジェクトＯＢ１（マップオブジェクト）の表面の領域のうち、ＯＢ１に対するキャラクタのオブジェクトＯＢ２のヒットにより画像が変化する領域ＳＦ２を特定する処理を行う。即ち、キャラクタのスライディングによりグラウンドの芝が削られる領域ＳＦ２を特定する。そして、必要であれば、この領域ＳＦ２における芝の画像を、芝が削られた画像に変化させるための処理を行う。なお、この画像変化処理については、ゲームスレッドであるＨ／Ｗスレッド処理ＨＳ１において行うようにしてもよい。このようにすることで、このスライディングの領域ＳＦ２での画像が、芝が削れた画像に変化するようになるため、プレーヤの仮想現実感を向上できる。

この場合、図３から明らかなように、Ｈ／Ｗスレッド処理ＨＳ２において領域特定処理を行うと、実際にヒットイベントが発生してから例えば数フレーム後に、領域特定処理が完了するようになる。しかしながら、このように領域特定処理の完了が遅れても、スライディングによるゲーム結果の演算処理については遅れないため、ゲーム進行には悪影響は及ばさない。そして、領域特定処理の完了が遅れると、スライディング後、ある程度時間が経ってから、芝の画像が削れる画像が生成されるようになるため、画像のリアル度を逆に向上できる。

なお領域特定処理は例えば以下のようにして実現できる。即ちスライディングのヒットイベントが発生すると、Ｈ／Ｗスレッド処理ＨＳ１では、例えばスライディング位置、スライディング方向、スライディング速度（或いはこれらの少なくとも１つ）を求める。そして、求められたスライディング位置、スライディング方向（スライディングの方向ベクトル）、スライディング速度を記憶部に保存する。また必要であれば、キャラクタのオブジェクトＯＢ２のモデル情報（モーションデータ）も保存する。そしてＨ／Ｗスレッド処理ＨＳ２では、この保存されたスライディング位置、スライディング方向、スライディング速度（或いはこれらの少なくとも１つ）に基づいて、スライディングの領域ＳＦ２の特定処理を行う。また必要であれば、キャラクタのオブジェクトＯＢ２のモデル情報を読み出し、このモデル情報（モーションデータ）に基づいて領域ＳＦ２の形状を特定する。こうすれば、スライディング時のキャラクタのオブジェクトＯＢ２の足や体の状態に応じて、スライディングの領域ＳＦ２の形状も変化するようになり、プレーヤの仮想現実感を更に向上できる。

２．５ 回転処理
Ｈ／Ｗスレッド処理ＨＳ２で行われる処理として、オブジェクトＯＢ１に対するオブジェクトＯＢ２のヒット位置を求め、ヒット位置に応じてオブジェクトＯＢ１を回転させる処理を行ってもよい。

例えば図９（Ａ）では、サッカー選手のキャラクタが、ボールを表すオブジェクトＯＢ１をキックしている。この場合に、このキックにより、ボールのオブジェクトＯＢ１が回転して見える画像を生成できれば、プレーヤの仮想現実感を向上できる。

しかしながら、このようなオブジェクトＯＢ１の回転処理をゲームのメインのループであるＨ／Ｗスレッド処理ＨＳ１で行うと、Ｈ／Ｗスレッド処理ＨＳ１の処理負荷が増加してしまう。

一方、このようなキックが行われた場合に、そのキックに応じた方向にボールを飛ばし、パスやシュートが成功したか否かなどを判断するゲーム結果の演算処理については、リアルタイムに行うことが望ましい。

そこで図９（Ａ）のように、ボールのオブジェクトＯＢ１に対してキャラクタの足がヒットするキックのヒットイベント発生の判断処理については、Ｈ／Ｗスレッド処理ＨＳ１が行う。そしてキックのヒットイベントが発生した場合には、ヒットイベントの発生をＨ／Ｗスレッド処理ＨＳ２に通知すると共に、ボールのキックに対応するゲーム結果の演算処理を行う。

そして図９（Ａ）のようなキックのヒットイベントの発生が通知されると、Ｈ／Ｗスレッド処理ＨＳ２では、図９（Ｂ）に示すように、キックのヒット位置ＨＰを求め、ヒット位置ＨＰに応じた回転速度や回転方向で、ボールのオブジェクトＯＢ１を回転させる処理を行う。このようにすることで、キックのヒット位置ＨＰに応じて、ボールのオブジェクトＯＢ１の回転速度や回転方向が変化するようになるため、プレーヤの仮想現実感を向上できる。

なお回転処理は例えば以下のようにして実現できる。即ちキックのヒットイベントが発生すると、Ｈ／Ｗスレッド処理ＨＳ１では、例えばキック方向、キック速度（或いはこれらの少なくとも１つ）を求める。そして、キック方向（広義にはヒット方向）、キック速度（広義にはヒット速度）を記憶部に保存する。そしてＨ／Ｗスレッド処理ＨＳ２では、保存されたキック方向、キック速度と、ヒット位置（或いはこれらの少なくとも１つ）に基づいて、オブジェクトＯＢ１の回転速度や回転方向を求める。こうすれば、ボールのキック時のキック方向やキック速度に応じて、ボールの回転速度や回転方向が変化するようになり、プレーヤの仮想現実感を更に向上できる。

２．６ ソフトウェアのマルチスレッド処理
本実施形態では、Ｈ／Ｗスレッド処理ＨＳ２において、ソフトウェアのマルチスレッド処理を行うようにしてもよい。

例えば図１０（Ａ）では、第Ｋのフレームにおいて、戦闘機のオブジェクトＯＢ１に対して弾のオブジェクトＯＢ２がヒットする第１のヒットイベントが発生している。また図１０（Ｂ）では、第Ｋのフレームの後の第Ｌ（Ｌ＞Ｋ。Ｋ、Ｌは自然数）のフレームにおいて、オブジェクトＯＢ１に対して弾のオブジェクトＯＢ３がヒットする第２のヒットイベントが発生している。即ち連射された機関銃の弾が戦闘機に次々に当たっている。

この場合に図３（Ｃ）に示すように、第Ｋのフレーム（第１のフレーム）において、Ｈ／Ｗスレッド処理ＨＳ１では、オブジェクトＯＢ１に対してＯＢ２がヒットする第１のヒットイベントの発生を、Ｈ／Ｗスレッド処理ＨＳ２に通知する。また第Ｌのフレーム（第３のフレーム）において、Ｈ／Ｗスレッド処理ＨＳ１では、オブジェクトＯＢ１に対してＯＢ３がヒットする第２のヒットイベントの発生を、Ｈ／Ｗスレッド処理ＨＳ２に通知する。

すると、Ｈ／Ｗスレッド処理ＨＳ２では、第１のヒットイベント（ＯＢ１、ＯＢ２）に対応する第２のヒットチェック処理ＣＨ２Ａと、第２のヒットイベント（ＯＢ１、ＯＢ３）に対応する第２のヒットチェック処理ＣＨ２Ｂとを、所与の処理単位で交互に行うようにする。即ちこの場合にはソフトウェアのマルチスレッド処理を行う。

例えば図１０（Ｃ）のＡ１では、ＯＢ１にＯＢ２がヒットする第１のヒットイベントしか発生していない。従って、オブジェクトＯＢ１を構成するポリゴンの中から、オブジェクトＯＢ２がヒットしたポリゴンを検索し、そのヒット位置を求める処理が順次行われる。具体的には図１０（Ｃ）のＡ１では、オブジェクトＯＢ１を構成するポリゴンＰＬ１〜ＰＬ２０に対してオブジェクトＯＢ２がヒットしたか否かをチェックするヒットチェック処理ＣＨ２Ａが行われる。

次に、ＯＢ１にＯＢ３がヒットする第２のヒットイベントが発生すると、ソフトウェアのマルチスレッド処理に切り替わる。例えば図１０（Ｃ）のＡ２では、オブジェクトＯＢ１を構成するポリゴンＰＬ１〜ＰＬ２０に続いて、ポリゴンＰＬ２１〜ＰＬ３０に対してオブジェクトＯＢ２がヒットしたか否かをチェックするヒットチェック処理ＣＨ２Ａが行われる。そして所与の処理単位である例えば１０枚分のポリゴンの処理が終了すると、今度は、Ａ３に示すように、例えばポリゴンＰＬ１〜ＰＬ１０に対してオブジェクトＯＢ３がヒットしたか否かをチェックするヒットチェック処理ＣＨ２Ｂが行われる。そして所与の処理単位である１０枚分のポリゴンの処理が終了すると、次は、例えばポリゴンＰＬ３１〜ＰＬ４０に対するヒットチェック処理ＣＨ２Ａが行われる。そしてその次は、ポリゴンＰＬ１１〜ＰＬ２０に対するヒットチェック処理ＣＨ２Ｂが行われる。このように所与の処理単位で交互にヒットチェック処理ＣＨ２Ａ、ＣＨ２Ｂが行われる。

このように、Ｈ／Ｗスレッド処理ＨＳ２においてソフトウェアのマルチスレッド処理を行うようにすれば、更に処理を効率化できる。

即ちソフトウェアのマルチスレッド処理を行わないと、第１のヒットイベントに対応するヒットチェック処理ＣＨ２Ａが、オブジェクトＯＢ１の全てのポリゴンについて終了するまで、第２のヒットイベントに対応するヒットチェック処理ＣＨ２Ｂはスタートできない。そして、オブジェクトＯＢ１のポリゴン数が多い場合には、全てのポリゴンについてのヒットチェック処理ＣＨ２Ａが終了するまでに時間がかかってしまい、ヒットチェック処理ＣＨ２Ｂが、長い期間、待たされてしまう可能性がある。

この点、図１０（Ｃ）に示すようなソフトウェアのマルチスレッド処理を行えば、ヒットチェック処理ＣＨ２Ｂが、長い期間、待たされてしまう事態を防止できる。そしてオブジェクトＯＢ２がヒットしたポリゴンが例えばポリゴンＰＬ５などの前半の順番のポリゴンであれば、ヒットチェック処理ＣＨ２Ｂは直ぐに終了し、弾痕表示へと移行できるため、処理を効率化できる。

なお、図１０（Ｃ）では、ソフトウェアスレッド処理を切り替える処理単位が１０枚のポリゴンである場合を例示したが、処理単位はこれに限定されず、任意の枚数のポリゴンとすることができる。また処理単位を可変に制御してもよい。

２．７ リプレイデータ
図３では、ヒットチェック処理ＣＨ２で取得されたヒットチェック結果情報をＨ／Ｗスレッド処理ＨＳ１に通知し、Ｈ／Ｗスレッド処理ＨＳ１がヒットチェック結果情報に基づくゲーム処理（例えば弾痕表示処理）を行っているが、本実施形態はこれに限定されない。例えば図１１に示すように、ヒットチェック処理ＣＨ２で取得されたヒット位置などのヒットチェック結果情報を、リプレイデータとして記憶部に保存するようにしてもよい。そして、リプレイデータに基づくリプレイ処理においては、保存されたヒットチェック結果情報に基づいてリプレイ画像の生成を行う。なお、この場合に、ヒットチェック結果情報を、ゲームスレッドであるＨ／Ｗスレッド処理ＨＳ１において利用してもよいし、利用しなくてもよい。

即ちリプレイ時には、リアルタイムに画像を生成する必要はなく、リプレイデータに基づく再生処理を行ってリプレイ画像を生成するだけで済むため、通常のゲームプレイ時に比べて、精細で高品質な画像を生成する場合がある。またリプレイ時には、通常のゲームプレイ時とは異なる仮想カメラの視点でリプレイ画像が生成される場合がある。例えば通常のゲームプレイ時に比べて、オブジェクトと仮想カメラの距離を近づけて、リプレイ画像を生成する場合がある。

この点、図１１のように、ヒットチェック処理ＣＨ２で取得された詳細なヒットチェック結果情報をリプレイデータとして保存し、この詳細なヒットチェック結果情報に基づいてリプレイ画像を生成すれば、リプレイモードに最適な精細で高品質な画像の生成が可能になる。例えばプレーヤの戦闘機からの弾が敵戦闘機に当たった場面のリプレイ画像を生成する場合に、仮想カメラの視点を、ゲームプレイ時よりも敵戦闘機に近づけてリプレイ画像を生成する。そして、この時に、ヒットチェック結果情報である弾のヒット位置に基づいて、弾痕が表示されたリプレイ画像を生成する。このようにすれば、敵戦闘機に弾が当たっている様子を弾痕表示によりリアルに表現できるようになるため、プレーヤの仮想現実感や満足度を向上できる。

なおリプレイデータとして保存するヒットチェック結果情報はヒット位置の情報に限定されない。例えば図７（Ａ）、図７（Ｂ）で説明した形状変形の情報や、図８（Ａ）、図８（Ｂ）で説明した領域の特定情報や、図９（Ａ）、図９（Ｂ）で説明したオブジェクトの回転に関する情報を、リプレイデータとして保存するようにしてもよい。このようにすれば、リプレイ時に、パンチのヒット位置が腫れて膨らんで見えるリプレイ画像や、スライディングで芝が削れて見えるリプレイ画像や、ボールが回転して見えるリプレイ画像を生成できるようになり、リプレイ画像の品質を向上できる。またリプレイ時に、ゲームプレイ時には見ることができなかった画像を生成してプレーヤに見せることが可能になり、リプレイモードの付加価値を高めることができる。

なお図１１ではＨ／Ｗスレッド処理ＨＳ２（第２のハードウェアスレッド処理部）が、リプレイデータの保存を行っているが、Ｈ／Ｗスレッド処理ＨＳ１（第１のハードウェアスレッド処理部）がリプレイデータの保存を行うようにしてもよい。即ちＨ／Ｗスレッド処理ＨＳ２がヒットチェック結果情報を通知すると、Ｈ／Ｗスレッド処理ＨＳ１がこのヒットチェック結果情報を受けてゲーム処理を行う。それと同時にＨ／Ｗスレッド処理ＨＳ１は、このヒットチェック結果情報をリプレイデータとしてリプレイデータ記憶部に保存する。この場合、戦闘機とミサイルや弾とが実際にヒットしたことを表すヒットイベントフラグＦ２を、リプレイデータに関連づけて保存する。こうすることで、リプレイモード時に、これらのリプレイデータとヒットイベントフラグＦ２を用いることで、弾痕表示等が表現された精細な画像を生成できるようになる。

２．８ 詳細な処理例
次に本実施形態の詳細な処理例を図１２、図１３のフローチャートを用いて説明する。図１２は、ゲームスレッドであるＨ／Ｗスレッド処理ＨＳ１のフローチャートである。

まずフレーム（１／６０秒）の更新タイミングか否かを判断する（ステップＳ２１）。そしてフレームの更新タイミングである場合には、図５（Ｂ）で説明したヒットイベントフラグＦ２がオンか否かを判断する（ステップＳ２２）。即ちステップＳ２２では、少なくともステップＳ３２の画像描画指示の前に、Ｈ／Ｗスレッド処理ＨＳ２からのヒットチェック結果情報であるヒットイベントフラグＦ２の監視処理を行っている。

そしてヒットイベントフラグＦ２がオンである場合には、ヒット位置ＨＰに対して弾痕を描画するための処理を行う（ステップＳ２３）。例えば弾痕表示用のポリゴンデータを用意したり、弾痕表示用のテクスチャを用意する処理を行う。そしてヒットイベントフラグＦ２をオフにする（ステップＳ２４）。なお、ステップＳ２２でヒットイベントフラグＦ２がオフである判断された場合には、ステップＳ２３、Ｓ２４の処理は行われない。

次に、操作部により入力された操作データ（入力データ）を取得する（ステップＳ２５）。そして移動体演算等のゲーム処理を行う（ステップＳ２６）。例えば戦闘機、ミサイル、弾等の移動体（モデルオブジェクト）の移動処理を行う。即ち移動体の速度、加速度等に基づいて移動体の位置、方向（姿勢）を更新する。

次に、オブジェクトＯＢ１、ＯＢ２（ＳＰ１、ＳＰ２）のヒット半径をＲ１、Ｒ２とし、ＯＢ１、ＯＢ２間の距離をＲとした場合に、Ｒ≦Ｒ１＋Ｒ２か否かを判断する（ステップＳ２７）。即ち図４（Ａ）の簡易なヒットチェック処理ＣＨ１を行う。そしてＲ≦Ｒ１＋Ｒ２である場合には、オブジェクトＯＢ１にＯＢ２がヒットしたと判断して、図５（Ａ）で説明したようにオブジェクトＯＢ１（戦闘機）のモデル情報を保存する（ステップＳ２８）。またオブジェクトＯＢ２（ミサイル、弾）の位置Ｐ２とベクトルＶ２を保存する（ステップＳ２９）。そしてヒットイベントが発生したことをＨ／Ｗスレッド処理ＨＳ１に通知するために、ヒットイベントフラグＦ１をオンにする（ステップＳ３０）。なお、ステップＳ２７でＲ＞Ｒ１＋Ｒ２であると判断され、オブジェクトＯＢ１に対してＯＢ２がヒットしていないと判断された場合には、ステップＳ２８、Ｓ２９、Ｓ３０の処理は行われない。

次に、ヒットチェックの結果等に応じてゲーム結果の演算処理を行う（ステップＳ３１）。即ち戦闘機にミサイルや弾がヒットした判断された場合には、戦闘機の耐久力を低下させたり、戦闘機を墜落させるなどのゲーム結果の演算処理を行う。そして、描画データを送信すると共に描画コマンドを発行して、当該フレームの画像の描画開始を描画部に指示する（ステップＳ３２）。

図１３は、コリジョンスレッドであるＨ／Ｗスレッド処理ＨＳ２のフローチャートである。まずヒットイベントフラグＦ１がオンか否かを判断する（ステップＳ４１）。即ちＨ／Ｗスレッド処理ＨＳ１からヒットイベントの発生が通知されたか否かを監視する。そして、ポリゴンの番号を表す変数であるｎを１に設定する（ステップＳ４２）。

次に、オブジェクトＯＢ１（戦闘機）のモデル情報と、ＯＢ２（ミサイル、弾）の位置Ｐ２とベクトルＶ２を読み出す（ステップＳ４３）。これらのモデル情報、位置Ｐ２、ベクトルＶ２は、図１２のステップＳ２８、Ｓ２９で保存されたものである。

次に、図４（Ｂ）で説明した詳細なヒットチェック処理ＣＨ２を行う。即ち、ｎ番のポリゴンの法線をＮ、そのポリゴンの頂点の１つをＰＶとした場合に、ｔ＝（ＰＶ−Ｐ２）・Ｎ／（Ｖ２・Ｎ）を求める（ステップＳ４４）。そして、Ｖ２・Ｎが０ではなく、かつ、ｔ≧０か否かを判断する（ステップＳ４５）。

例えば図１４（Ａ）において、直線ＬＮの開始点をＰ２とし、直線ＬＮの傾きのベクトルをＶ２とすると、直線ＬＮの方程式は、
Ｐ＝Ｐ２＋ｔＶ２ （１）
と表せる。

またポリゴンＰＬの頂点の１つをＰＶとし、ポリゴンＰＬの法線をＮとした場合に、ポリゴンＰＬを含む平面の方程式は、
（Ｐ−ＰＶ）・Ｎ＝０ （２）
と表される。

従って上式（１）、（２）の連立方程式を解いてＰを消去することで、開始点Ｐ２からポリゴンＰＬへの距離に相当するｔは、下式のように求められる。

ｔ＝（ＰＶ−Ｐ２）・Ｎ／（Ｖ２・Ｎ） （３）
そしてＶ２・Ｎ＝０である場合には、ポリゴンＰＬの法線Ｎと直線ＬＮとが垂直であり、直線ＬＮの方向がポリゴンＰＬの平面に平行になるため、直線ＬＮとポリゴンＰＬの平面は交わらない。またｔ＜０の場合には、直線ＬＮの開始点Ｖ２の後ろ側に交点が存在するため、この場合にも直線ＬＮとポリゴンＰＬの平面は交わらない。従って、ステップＳ４５により、直線ＬＮとポリゴンＰＬの平面が交わるか否かを判断できる。

次にステップＳ４５で、「Ｙｅｓ」と判断された場合には、図１４（Ｂ）に示すように、交点Ｐとポリゴンの頂点ＰＶとを結ぶベクトルをｄ０とし、ポリゴンの３辺のベクトルをｄ１、ｄ２、ｄ３とした場合に、外積であるＯＰ１＝ｄ０×ｄ１、ＯＰ２＝ｄ０×ｄ２、ＯＰ３＝ｄ０×ｄ３を求める（ステップＳ４６）。そして、ＯＰ１＞０かつＯＰ２＞０かつＯＰ３＞０、または、ＯＰ１＜０かつＯＰ２＜０かつＯＰ３＜０か否かを判断する（ステップＳ４７）。そしてステップＳ４７で「Ｙｅｓ」と判断された場合には、交点Ｐの座標をヒット位置ＨＰとして保存する（ステップＳ４８）。そしてヒットイベントフラグＦ２をオンにして（ステップＳ４９）、ヒットイベントフラグＦ１をオフに戻す（ステップＳ５０）。

即ち外積ＯＰ１、ＯＰ２、ＯＰ３のベクトルは、ポリゴンＰＬの法線Ｎと同じ方向を向くか、或いは反対の方向を向く。そして、この向きは、交点Ｐが三角形のポリゴンＰＬの内部にあるか外部にあるかで、その符号が変わる。従って、ポリゴンＰＬの全ての辺について符号が同じである場合には、交点ＰはポリゴンＰＬの内部に存在すると判断できる。

ステップＳ４又はステップＳ４７で「Ｎｏ」と判断された場合には、ｎを１だけインクリメントする（ステップＳ５１）。そしてｎがオブジェクトＯＢ１の総ポリゴン数よりも小さいか否かを判断し（ステップＳ５２）、小さい場合にはステップＳ５０に移行し、小さくないならばステップＳ４３に移行する。

３．ハードウェア構成
図１５（Ａ）に本実施形態を実現できるハードウェアの構成例を示す。

ＣＰＵ９００（メインプロセッサ）は、複数のＣＰＵコア１、ＣＰＵコア２、ＣＰＵコア３を含むマルチコアプロセッサである。またＣＰＵ９００は図示しないキャッシュメモリを含む。ＣＰＵコア１、２、３の各々にはベクタ演算器等が設けられている。そしてＣＰＵコア１、２、３の各々は、例えば２つのＨ／Ｗスレッド処理をコンテクストスイッチをすることなしに並列実行でき、マルチスレッド機能がハードウェアでサポートされている。そして３つのＣＰＵコア１、２、３の合計で、６つのＨ／Ｗスレッド処理を並列実行できる。

ＧＰＵ９１０（描画プロセッサ）は、頂点処理やピクセル処理を行って、描画（レンダリング）処理を実現する。具体的には、シェーダプログラムに従って、頂点データの作成・変更やピクセル（フラグメント）の描画色の決定を行う。１フレーム分の画像がＶＲＡＭ９２０（フレームバッファ）に書き込まれると、その画像はビデオ出力を介してＴＶなどのディスプレイに表示される。なおメインメモリ９３０はＣＰＵ９００やＧＰＵ９１０のワークメモリとして機能する。またＧＰＵ９１０では、複数の頂点スレッド、複数のピクセルスレッドが並列実行され、描画処理のマルチスレッド機能がハードウェアでサポートされている。またＧＰＵ９１０にはハードウェアのテッセレータも備えられている。またＧＰＵ９１０は、頂点シェーダとピクセルシェーダとがハードウェア的に区別されていないユニファイド・シェーダ・タイプとなっている。

ブリッジ回路９４０（サウスブリッジ）は、システム内部の情報流通を制御する回路であり、ＵＳＢコントローラ（シリアルインターフェース）、ネットワーク（イーサネット（登録商標））の通信コントローラ、ＩＤＥコントローラ、或いはＤＭＡコントローラなどのコントローラを内蔵する。そしてこのブリッジ回路９４０により、ゲームコントローラ９４２、メモリーカード９４４、ＨＤＤ９４６、ＤＶＤドライブ９４８との間のインターフェース機能が実現される。

なお本実施形態を実現できるハードウェア構成は図１５（Ａ）に限定されず、例えば図１５（Ｂ）のような構成であってもよい。

図１５（Ｂ）ではＣＰＵ９０２が、プロセッサエレメントＰＰと８つのプロセッサエレメントＰＥ１〜ＰＥ８を含む。プロセッサエレメントＰＰは汎用的なプロセッサコアであり、プロセッサエレメントＰＥ１〜ＰＥ８は比較的シンプルな構成のプロセッサコアである。そしてプロセッサエレメントＰＰとプロセッサエレメントＰＥ１〜ＰＥ８のアーキテクチャは異なっており、プロセッサエレメントＰＥ１〜ＰＥ８は、複数のデータに対して１命令で同じ処理を同時にできるＳＩＭＤ型のプロセッサコアとなっている。これによりストリーミング処理などのマルチメディア処理を効率的に実行できる。プロセッサエレメントＰＰは、２つのＨ／Ｗスレッド処理を並列実行でき、プロセッサエレメントＰＥ１〜ＰＥ８の各々は、１つのＨ／Ｗスレッド処理を実行できる。従って、ＣＰＵ９０２では、合計で１０個のＨ／Ｗスレッド処理の並列実行が可能になる。

図１５（Ｂ）では、ＧＰＵ９１２とＣＰＵ９０２の連携が密になっており、ＧＰＵ９１２は、ＣＰＵ９０２側のメインメモリ９３０に直接にレンダリング処理を行うことができる。また例えばＣＰＵ９０２がジオメトリ処理を行って、頂点データを転送したり、ＧＰＵ９１２からＣＰＵ９０２にデータを戻すことも容易にできる。またＣＰＵ９０２が、レンダリングのプリプロセッシング処理やポストプロセッシング処理を行うことも容易であり、テッセレーション（平面分割）やドットフィルをＣＰＵ９０２が実行できる。例えば抽象度の高い処理はＣＰＵ９０２が行い、抽象度が低い細かな処理はＧＰＵ９１２が行うというような役割分担が可能である。

なお本実施形態の各部の処理をハードウェアとプログラムにより実現する場合には、情報記憶媒体には、ハードウェア（コンピュータ）を本実施形態の各部として機能させるためのプログラムが格納される。より具体的には、上記プログラムが、ハードウェアであるプロセッサ（ＣＰＵ、ＧＰＵ）に処理を指示すると共に、必要であればデータを渡す。そして、プロセッサは、その指示と渡されたデータとに基づいて本発明の各部の処理を実現する。

なお、上記のように本実施形態について詳細に説明したが、本発明の新規事項および効果から実体的に逸脱しない多くの変形が可能であることは当業者には容易に理解できるであろう。従って、このような変形例はすべて本発明の範囲に含まれるものとする。例えば、明細書又は図面において、少なくとも一度、より広義または同義な異なる用語（装飾画像、ヒット方向、ヒット速度等）と共に記載された用語（弾痕画像、キック方向、キック速度等）は、明細書又は図面のいかなる箇所においても、その異なる用語に置き換えることができる。

また、ヒットチェック処理手法、情報の保存手法、画像の生成手法も本実施形態で説明したものに限定されず、これらと均等な手法も本発明の範囲に含まれる。

また本発明は種々のゲームに適用できる。また本発明は、業務用ゲームシステム、家庭用ゲームシステム、多数のプレイヤが参加する大型アトラクションシステム、シミュレータ、マルチメディア端末、ゲーム画像を生成するシステムボード、携帯電話等の種々の画像生成システムに適用できる。

本実施形態の画像生成システムのブロック図の例。 本実施形態のＨ／Ｗスレッド処理手法の説明図。 本実施形態のＨ／Ｗスレッド処理手法の説明図。 図４（Ａ）〜図４（Ｃ）はヒットチェック処理手法の説明図。 図５（Ａ）、図５（Ｂ）はヒットチェック処理での情報の保存手法の説明図。 図６（Ａ）〜図６（Ｃ）は弾痕画像の表示処理の説明図。 図７（Ａ）〜図７（Ｃ）はヒット位置の領域での形状変形手法の説明図。 図８（Ａ）、図８（Ｂ）は画像変化領域を特定する手法の説明図。 図９（Ａ）、図９（Ｂ）はオブジェクトを回転させる手法の説明図。 図１０（Ａ）〜図１０（Ｃ）はＨ／Ｗスレッド処理におけるソフトウェアのマルチスレッド手法の説明図。 ヒットチェック結果情報をリプレイデータとして保存する手法の説明図。 本実施形態の詳細な処理を説明するフローチャート。 本実施形態の詳細な処理を説明するフローチャート。 図１４（Ａ）、図１４（Ｂ）は本実施形態の詳細な処理の説明図。 図１５（Ａ）、図１５（Ｂ）はハードウェア構成例。

符号の説明

１００ 処理部、１０１ Ｈ／Ｗスレッド処理部、１０２ Ｈ／Ｗスレッド処理部、
１１０ オブジェクト空間設定部、１１２ 移動体演算部、１１４ 仮想カメラ制御部、
１１６ 第１のヒットチェック処理部、１１７ ゲーム結果演算部、
１１８ 第２のヒットチェック処理部、１１９ 画像変化処理部、
１２０ 描画部、１３０ 音生成部、１６０ 操作部、１７０ 記憶部、
１７２ 主記憶部、１７４ 描画バッファ、１７６ モデルデータ記憶部、
１７８ テクスチャ記憶部、１７９ リプレイデータ記憶部、
１８０ 情報記憶媒体、１９０ 表示部、１９２ 音出力部、１９４ 補助記憶装置、
１９６ 通信部

Claims (21)

1. ゲームを進行させるゲーム処理を、第１のハードウェアスレッド処理として行う第１のハードウェアスレッド処理部と、
   前記第１のハードウェアスレッド処理と並列に第２のハードウェアスレッド処理を行う第２のハードウェアスレッド処理部と、
   画像を描画する描画部として、
   コンピュータを機能させるプログラムであって、
   前記第１のハードウェアスレッド処理部は、
   第１、第２のオブジェクトについての第１のヒットチェック処理を行い、前記第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知すると共に、前記第２のハードウェアスレッド処理部において行われる第２のヒットチェック処理のヒットチェック結果情報が前記第２のハードウェアスレッド処理部から通知される前に、前記第１のヒットチェック処理の結果に基づいてゲーム結果を演算するゲーム処理を行い、
   前記第２のハードウェアスレッド処理部は、
   前記第１のハードウェアスレッド処理部からヒットイベントの発生が通知された場合に、第１、第２のオブジェクトのヒットチェック処理として、前記第１のヒットチェック処理と異なる前記第２のヒットチェック処理を行い、前記第２のヒットチェック処理の前記ヒットチェック結果情報を、前記第１のハードウェアスレッド処理部に通知し、
   前記第１のハードウェアスレッド処理部は、
   前記第２のハードウェアスレッド処理部から前記第２のヒットチェック処理の前記ヒットチェック結果情報が通知された場合に、前記ヒットチェック結果情報に応じた画像の描画を、前記描画部に対して指示するゲーム処理を行うことを特徴とするプログラム。
2. ゲームを進行させるゲーム処理を、第１のハードウェアスレッド処理として行う第１のハードウェアスレッド処理部と、
   前記第１のハードウェアスレッド処理と並列に第２のハードウェアスレッド処理を行う第２のハードウェアスレッド処理部として、
   コンピュータを機能させるプログラムであって、
   前記第１のハードウェアスレッド処理部は、
   第１、第２のオブジェクトについての第１のヒットチェック処理を行い、前記第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、
   前記第２のハードウェアスレッド処理部は、
   前記第１のハードウェアスレッド処理部からヒットイベントの発生が通知された場合に、第１、第２のオブジェクトのヒットチェック処理として、前記第１のヒットチェック処理と異なる第２のヒットチェック処理を行うと共に、
   前記第１のハードウェアスレッド処理部は、
   第Ｋのフレームにおいて、第１のオブジェクトに対して第２のオブジェクトがヒットする第１のヒットイベントが発生した場合に、前記第１のヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、第Ｋのフレームの後の第Ｌ（Ｌ＞Ｋ）のフレームにおいて、第１のオブジェクトに対して第３のオブジェクトがヒットする第２のヒットイベントが発生した場合に、前記第２のヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、
   前記第２のハードウェアスレッド処理部は、
   前記第１のヒットイベントに対応する第２のヒットチェック処理と前記第２のヒットイベントに対応する第２のヒットチェック処理とを、所与の処理単位で交互に行い、
   前記第１のヒットイベントに対応する前記第２のヒットチェック処理は、第１のオブジェクトを構成する前記所与の処理単位分の複数のポリゴンと、第２のオブジェクトとのヒットチェック処理であり、
   前記第２のヒットイベントに対応する前記第２のヒットチェック処理は、第１のオブジェクトを構成する前記所与の処理単位分の複数のポリゴンと、第３のオブジェクトとのヒットチェック処理であることを特徴とするプログラム。
3. 請求項１又は２において、
   前記第２のハードウェアスレッド処理部は、
   前記第１のハードウェアスレッド処理部からヒットイベントの発生が通知された場合に、第１、第２のオブジェクトのヒットチェック処理として、前記第１のヒットチェック処理よりも処理負荷が重い第２のヒットチェック処理を行うことを特徴とするプログラム。
4. 請求項１乃至３のいずれかにおいて、
   前記第１のハードウェアスレッド処理部は、
   第Ｋのフレームにおいて、第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、
   前記第２のハードウェアスレッド処理部は、
   第Ｋのフレームでのヒットイベントの発生が通知された場合に、第Ｋのフレームの後の第Ｍ（Ｍ＞Ｋ）のフレームにおいて、前記第２のヒットチェック処理のヒットチェック結果情報を前記第１のハードウェアスレッド処理部に通知することを特徴とするプログラム。
5. 請求項４において、
   前記第１のハードウェアスレッド処理部は、
   第Ｍのフレームにおいて前記第２のハードウェアスレッド処理部から前記ヒットチェック結果情報が通知された場合に、第Ｍのフレームの後の第Ｎのフレーム（Ｎ＞Ｍ）において、前記ヒットチェック結果情報に応じたゲーム処理を行うことを特徴とするプログラム。
6. 請求項４又は５において、
   前記第１のハードウェアスレッド処理部は、
   画像の描画指示の前に、前記第２のハードウェアスレッド処理部からの前記ヒットチェック結果情報の監視処理を行うことを特徴とするプログラム。
7. 請求項１乃至６のいずれかにおいて、
   前記第１のハードウェアスレッド処理部は、
   前記第１のヒットチェック処理として、第１のオブジェクトの形状を簡素化した第１の簡易オブジェクトに対して、第２のオブジェクト又は第２のオブジェクトの形状を簡素化した第２の簡易オブジェクトがヒットしたか否かを判断する処理を行い、
   前記第２のハードウェアスレッド処理部は、
   前記第２のヒットチェック処理として、第１のオブジェクト自体に対して第２のオブジェクトがヒットしたか否かを判断する処理を行うことを特徴とするプログラム。
8. 請求項７において、
   前記第１のハードウェアスレッド処理部は、
   第１の簡易オブジェクトに対して第２のオブジェクト又は第２の簡易オブジェクトがヒットしたと判断した場合に、第１のヒットイベントフラグをオンにすることで、前記第１のヒットチェック処理でのヒットイベントの発生を前記第２のハードウェアスレッド処理部に対して通知し、
   前記第２のハードウェアスレッド処理部は、
   第１のオブジェクト自体に対して第２のオブジェクトがヒットしたと判断した場合に、第２のヒットイベントフラグをオンにすることで、前記第２のヒットチェック処理でのヒットイベントの発生を前記第１のハードウェアスレッド処理部に対して通知することを特徴とするプログラム。
9. 請求項１乃至８のいずれかにおいて、
   前記第１のハードウェアスレッド処理部は、
   前記第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、前記第２のヒットチェック処理に必要な第１、第２のオブジェクトの情報を記憶部に保存し、
   前記第２のハードウェアスレッド処理部は、
   保存された第１、第２のオブジェクトの情報に基づいて、前記第２のヒットチェック処理を行うことを特徴とするプログラム。
10. 請求項１乃至９のいずれかにおいて、
    前記第２のハードウェアスレッド処理部は、
    前記第２のヒットチェック処理として、第１のオブジェクトに対する第２のオブジェクトのヒット位置を求める処理を行うことを特徴とするプログラム。
11. 請求項１０において、
    前記第２のハードウェアスレッド処理部は、
    前記第２のヒットチェック処理により求められたヒット位置の情報を記憶部に保存し、
    前記第１のハードウェアスレッド処理部は、
    保存された前記ヒット位置の情報に基づいて、ゲーム処理を行うことを特徴とするプログラム。
12. 請求項１０又は１１において、
    前記第１のハードウェアスレッド処理部は、
    前記第２のハードウェアスレッド処理部により求められた前記ヒット位置の情報に基づいて、前記ヒット位置の画像を変化させる処理を行うことを特徴とするプログラム。
13. 請求項１０乃至１２のいずれかにおいて、
    前記第１のハードウェアスレッド処理部は、
    第１のオブジェクトに対して第２のオブジェクトがヒットした事を表す装飾画像を、前記ヒット位置に表示する処理を行うことを特徴とするプログラム。
14. 請求項１乃至１３のいずれかにおいて、
    前記第２のハードウェアスレッド処理部は、
    第１のオブジェクトに対する第２のオブジェクトのヒット位置を含む領域での第１のオブジェクトの形状を変形する処理を行うことを特徴とするプログラム。
15. 請求項１４において、
    前記第２のハードウェアスレッド処理部は、
    形状変形処理のために予め細分化された第１のオブジェクトの表面の頂点の位置を変化させることで、前記ヒット位置を含む領域での第１のオブジェクトの形状を変形する処理を行うことを特徴とするプログラム。
16. 請求項１乃至１５のいずれかにおいて、
    前記第２のハードウェアスレッド処理部は、
    前記第２のヒットチェック処理として、第１のオブジェクトの表面の領域のうち、第１のオブジェクトに対する第２のオブジェクトのヒットにより画像が変化する領域を特定する処理を行うことを特徴とするプログラム。
17. 請求項１乃至１６のいずれかにおいて、
    前記第２のハードウェアスレッド処理部は、
    第１のオブジェクトに対する第２のオブジェクトのヒット位置に応じて、第１のオブジェクトを回転させる処理を行うことを特徴とするプログラム。
18. 請求項１乃至１７のいずれかにおいて、
    前記第２のハードウェアスレッド処理部又は前記第１のハードウェアスレッド処理部は、
    前記第２のヒットチェック処理のヒットチェック結果情報を、リプレイデータとして保存することを特徴とするプログラム。
19. コンピュータ読み取り可能な情報記憶媒体であって、請求項１乃至１８のいずれかに記載のプログラムを記憶したことを特徴とする情報記憶媒体。
20. 画像を生成する画像生成システムであって、
    ゲームを進行させるゲーム処理を、第１のハードウェアスレッド処理として行う第１のハードウェアスレッド処理部と、
    前記第１のハードウェアスレッド処理と並列に第２のハードウェアスレッド処理を行う第２のハードウェアスレッド処理部と、
    画像を描画する描画部とを含み、
    前記第１のハードウェアスレッド処理部は、
    第１、第２のオブジェクトについての第１のヒットチェック処理を行い、前記第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知すると共に、前記第２のハードウェアスレッド処理部において行われる第２のヒットチェック処理のヒットチェック結果情報が前記第２のハードウェアスレッド処理部から通知される前に、前記第１のヒットチェック処理の結果に基づいてゲーム結果を演算するゲーム処理を行い、
    前記第２のハードウェアスレッド処理部は、
    前記第１のハードウェアスレッド処理部からヒットイベントの発生が通知された場合に、第１、第２のオブジェクトのヒットチェック処理として、前記第１のヒットチェック処理と異なる前記第２のヒットチェック処理を行い、前記第２のヒットチェック処理の前記ヒットチェック結果情報を、前記第１のハードウェアスレッド処理部に通知し、
    前記第１のハードウェアスレッド処理部は、
    前記第２のハードウェアスレッド処理部から前記第２のヒットチェック処理の前記ヒットチェック結果情報が通知された場合に、前記ヒットチェック結果情報に応じた画像の描画を、前記描画部に対して指示するゲーム処理を行うことを特徴とする画像生成システム。
21. 画像を生成する画像生成システムであって、
    ゲームを進行させるゲーム処理を、第１のハードウェアスレッド処理として行う第１のハードウェアスレッド処理部と、
    前記第１のハードウェアスレッド処理と並列に第２のハードウェアスレッド処理を行う第２のハードウェアスレッド処理部とを含み、
    前記第１のハードウェアスレッド処理部は、
    第１、第２のオブジェクトについての第１のヒットチェック処理を行い、前記第１のヒットチェック処理において第１のオブジェクトに対して第２のオブジェクトがヒットしたと判断した場合に、ヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、
    前記第２のハードウェアスレッド処理部は、
    前記第１のハードウェアスレッド処理部からヒットイベントの発生が通知された場合に、第１、第２のオブジェクトのヒットチェック処理として、前記第１のヒットチェック処理と異なる第２のヒットチェック処理を行うと共に、
    前記第１のハードウェアスレッド処理部は、
    第Ｋのフレームにおいて、第１のオブジェクトに対して第２のオブジェクトがヒットする第１のヒットイベントが発生した場合に、前記第１のヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、第Ｋのフレームの後の第Ｌ（Ｌ＞Ｋ）のフレームにおいて、第１のオブジェクトに対して第３のオブジェクトがヒットする第２のヒットイベントが発生した場合に、前記第２のヒットイベントの発生を前記第２のハードウェアスレッド処理部に通知し、
    前記第２のハードウェアスレッド処理部は、
    前記第１のヒットイベントに対応する第２のヒットチェック処理と前記第２のヒットイベントに対応する第２のヒットチェック処理とを、所与の処理単位で交互に行い、
    前記第１のヒットイベントに対応する前記第２のヒットチェック処理は、第１のオブジェクトを構成する前記所与の処理単位分の複数のポリゴンと、第２のオブジェクトとのヒットチェック処理であり、
    前記第２のヒットイベントに対応する前記第２のヒットチェック処理は、第１のオブジェクトを構成する前記所与の処理単位分の複数のポリゴンと、第３のオブジェクトとのヒットチェック処理であることを特徴とする画像生成システム。

Images