フォントキャッシュとメタフォント
【課題】一つまたは複数のフォントのキャラクタへのアクセスと表示を管理するための方法およびシステムを提供する。
【解決手段】該方法およびシステムは、コンピュータメモリ内の記憶スペースの初期化を含む。記憶スペースは、一つまたは複数のフォントからキャラクタを選択するための情報を記憶し、フォント管理ルーチンによるアクセスを容易にすることができる。一方、第二の記憶スペースは、一つまたは複数のファイルに含まれ得る一つまたは複数のフォントからのすべてのキャラクタに関する情報を記憶する。フォント管理ルーチンは、レンダリングされるべき所望のキャラクタの指示情報を受け取り、その所望のキャラクタが現在第一の記憶スペースに記憶されているか否かを判断し、フォント管理ルーチン（または関連ルーチン）は、第二の記憶スペースから所望のキャラクタを第一の記憶スペースにロードすることができる。
【解決手段】該方法およびシステムは、コンピュータメモリ内の記憶スペースの初期化を含む。記憶スペースは、一つまたは複数のフォントからキャラクタを選択するための情報を記憶し、フォント管理ルーチンによるアクセスを容易にすることができる。一方、第二の記憶スペースは、一つまたは複数のファイルに含まれ得る一つまたは複数のフォントからのすべてのキャラクタに関する情報を記憶する。フォント管理ルーチンは、レンダリングされるべき所望のキャラクタの指示情報を受け取り、その所望のキャラクタが現在第一の記憶スペースに記憶されているか否かを判断し、フォント管理ルーチン（または関連ルーチン）は、第二の記憶スペースから所望のキャラクタを第一の記憶スペースにロードすることができる。
【発明の詳細な説明】
【背景技術】
【０００１】
コンピュータグラフィクスの進化により、二次元空間（たとえば、コンピュータのスクリーンまたはモニタ）に三次元のグラフィックオブジェクト（たとえば、ビデオゲームのキャラクタ）を表示することが可能となった。三次元グラフィクスを使用するビデオゲームやその他のアプリケーションはユーザにとって非常にリアルに見え、ユーザがこれを体験する中での楽しさが増す。三次元グラフィクスを生成するための一つの技術に、テクスチャの使用がある。テクスチャは二次元のビットマップであり、シーンを三次元レンダリングする場合に、これを使わなければフラットとなるような表面形状を描く際、実世界のテクスチャの詳細（たとえば、木、布目、カーペット等）を擬態するために一般的に使用される。一部の例では、テクスチャは複数の二次元ピクセルで構成される。各ピクセルは位置、色、明るさ、色の濃さ（depth）という特性（property）を有する。いったん作成されると、テクスチャは、テキストや記号を表す画像を含む多くの種類の画像をレンダリングするのに使用することができる。一般に、二次元テキストをレンダリングするためにテクスチャを使用することは、他のテキストレンダリング技術より好ましい。なぜなら、テクスチャにより、テキストを必要に応じて投射、スケーリング、回転することが容易になるからである。
【０００２】
フォントのレンダリングに使用されるテクスチャは、非常に大きいことが多い。たとえば、ビデオゲームは、視覚的に印象深くなければあまり売れないため、しばしば、一つのシーンに複数の魅力的なフォントが使用されていることが望まれる。したがって、三次元ビデオゲームのためのテキストのレンダリングに使用される一つのテクスチャは情報量の大きなキャラクタセット（たとえば、テキストキャラクタ、記号および／または特定のフォントもしくはテキストスタイルに伴う画像）を含むかもしれない。国際市場向けのビデオゲームにおけるフォントのレンダリングに使用されるテクスチャもまた、非常に多くのキャラクタセットを含むかもしれない。たとえば、中国語のテキストを含むゲームには、約５，０００から８，０００文字が必要となりうる。各文字がテクスチャビットマップの２０×２０のピクセル区分にプレレンダリングされたとすれば、テクスチャビットマップ全体は１，８００×１，８００ピクセル、つまり３．２５ＭＰｉｘｅｌとなる。
【０００３】
テクスチャからテキストをレンダリングする場合、一般に、所望のグリフ（flyph）がテクスチャ内にあるところとなる、一致するテクスチャ座標のセット（たとえば、「Ｇ」の文字を構成する座標）の選択が行われる。たとえば、テクスチャからのテキストのレンダリング方法の一つにおいては、フォントをビットマップ化されたテクスチャ（たとえば、フォントビットマップ）として記憶し、個々の文字を画面空間で整列されたクワタ（quad）としてレンダリングする。この技術は、グラフィクスプロセシングユニット（ＧＰＵ）またはこれに類するハードウェアの本来的機能を用い、ビットマップに基づくフォントを、ＧＰＵに関連するハードウェアの最大のフィルレート（１秒あたりのピクセル数）でレンダリングする。この技術の一つの限界は、情報量の大きなキャラクタセット（たとえば、ユニコードのキャラクタセット）について使用された場合、現在のハードウェア容量を超えるテクスチャのサイズが必要となり、大量のメモリを使用するかもしれない。さらに、ゲームがフォントビットのためにとっておくべきメモリ量を、テキストの翻訳を行う前に予測することは非常に難しい。その上、フォントビットマップは、新しいフォントがダウンロード用コンテンツとして取得可能になるとアップデートされる可能性があり、将来のメモリ割り当て上の問題やその他の問題の原因となりうる。
【発明の開示】
【課題を解決するための手段】
【０００４】
テキストキャラクタ、記号およびその他のキャラクタを含むテキストをレンダリングするための方法とシステムについて、ここで説明する。一部の実施形態において、これらの方法とシステムは、少なくとも部分的に、ソフトウェアアプリケーション（たとえば、ビデオゲーム）のフォント管理ルーチンを通じて実施されるかもしれない。フォント管理ルーチンは、少なくとも一時的にハードディスク、ＤＶＤ、あるいはフォント管理ルーチンが必要に応じてアクセスできるその他の媒体に記憶される一つまたは複数のフォントファイルから個々のキャラクタを読み取ることができる。
【０００５】
一部の実施形態において、フォント管理ルーチンは、読み取ったキャラクタをフォントキャッシュシステム（たとえば、アプリケーションの初期化時にインスタンスとして作られる）にコピーまたはロードすることができる。また、フォント管理ルーチンは、読み取られたキャラクタに関係するメタデータおよび／またはその他の情報（たとえば、キャラクタの幅、オフセット、配置情報等）もフォントキャッシュシステムにロードすることができる。したがって、フォントキャッシュシステムは、キャッシュ（たとえば、キャラクタそのものを記憶するためのもの）と、キャラクタに関係するメタデータおよび／またはその他の情報を記憶するテーブルもしくはその他のデータストラクチャを含むことができる。
【０００６】
場合によっては、フォントキャッシュシステムのキャッシュは所定のサイズで、フォントファイルの中の利用可能なキャラクタの総数より小さい。したがって、テーブルは、ステータスに関する情報（たとえば、そのキャラクタが現在キャッシュ内にあるか否かに関する情報等）を記憶することができる。テーブル（または場合に応じて、別の優先待ち行列）は、キャッシュに記憶されたキャラクタがどれほど最近使用されたかに関する情報を記憶することができる。このように、キャッシュがいっぱいになると、フォントキャッシュシステムは、テーブルおよび／または優先待ち行列の中のステータス情報に依存して、フォントキャッシュから最近最も使用されないキャラクタを消去する。
【０００７】
一部の実施形態において、テキストを含む三次元グラフィクスをレンダリングするための方法とシステムはまた、複数のフォントタイプを一つのレンダリングスキームにまとめるメタフォントの使用を含んでいてもよい。たとえば、どのメタフォントも、一つの配列による２つ以上のフォントグループ（たとえば、西ヨーロッパのキャラクタと東アジアのキャラクタの両方を含む一つのフォントファイル）を含むことができる。上記のフォントファイルと同様に、メタフォントはハードドライブ、ＤＶＤ、またはその他の永続的記憶媒体に記憶され、その後フォント管理ルーチンによってアクセスされる。
【０００８】
一部の実施形態において、フォント管理ルーチン（またはその他のルーチン）は、レンダリングされるべき入力ストリング内の各キャラクタをチェックし、メタフォントのどのキャラクタ（たとえば、東アジアのフォントかヨーロッパのフォントか）を使用すべきかを判断する。フォントキャッシュシステムを使ってメタフォントが実装されている場合、メタフォントの適当な文字が現在キャッシュ内に記憶されていなければ、フォント管理ルーチンはこれを必要に応じて永続的記憶装置からフェッチし、そのストリングを表示できるようにする。
【０００９】
本明細書の一部には、著作権主張の対象物が含まれる。著作権所有者は、特許商標庁の特許ファイルもしくは記録に表示されているように、何人による特許文書もしくは特許説明書（図面を含む）の複写に対しても異議を申し立てないが、その他すべてのあらゆる著作権を留保する。
【発明を実施するための最良の形態】
【００１０】
次に、本発明をさまざまな実施形態に関して説明する。以下の説明では、本発明のこのような実施形態が十分に理解され、その説明を可能にするための具体的な詳細事項を紹介している。しかしながら、当業者であれば、本発明をこれらの詳細事項がなくても実現することが可能であると理解するであろう。また、周知の構造や機能については、本発明の実施形態の説明が不必要に不明瞭となることを避けるために、示されていない、あるいは詳しく説明されていない。
【００１１】
説明において使用されている用語は、本発明の特定の具体的な実施形態の詳細な説明に関連して使用されていたとしても、合理的にもっとも広く解釈されるものとする。特定の用語は、以下の説明の中で強調されてさえいるが、限定的に解釈されるべき用語であれば、この詳細な説明の中で明確かつ具体的に定義される。
【００１２】
図面において、同一もしくは実質的に同様の要素または動作を特定するために、同じ参照符号が付与されている。特定の要素または動作について論じやすくするために、参照符号の中のもっとも重要な桁は、その要素が初めて紹介された図面の番号を示している（たとえば、要素２０４は図２において最初に紹介され、論じられている）。
【００１３】
Ｉ．代表的なシステム
図１と以下の説明は、本発明を実現できる代表的な環境を簡単に、概説している。必要条件ではないものの、本発明の態様は、汎用コンピュータ（たとえば、サーバコンピュータ、無線デバイスまたはパーソナル／ラップトップコンピュータ）によって実行されるルーチン等のコンピュータ実行可能な命令という一般的な文脈において説明される。当業者は、本発明が他の通信、データ処理またはコンピュータシステムコンフィギュレーション、たとえば、ゲームコンソール、インターネット機器、携帯デバイス（携帯情報端末（ＰＣＡ）を含む）、ウェアラブルコンピュータ、あらゆる形態のセル式その他の携帯電話、埋込式コンピュータ（自動車に搭載されたものを含む）、マルチプロセッサシステム、マイクロプロセッサベースもしくはプログラム可能な民生用電子機器、セットトップボックス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータその他でも実施できることを理解できるであろう。実際、「コンピュータ」という用語は一般に、上記のあらゆるデバイスやシステムのほか、あらゆるデータプロセッサを指す。
【００１４】
本発明の態様は、ここで詳細に説明する一つまたは複数のコンピュータ実行可能命令を実行するよう特にプログラム、構成または構築された特定用途コンピュータもしくはデータプロセッサにおいて実施され得る。本発明の態様はまた、タスクやモジュールが、通信ネットワークを通じて連結されているリモート処理デバイスによって実行される分散型コンピューティング環境でも実施できる。分散型コンピューティング環境において、プログラムモジュールは、ローカルおよびリモートメモリ記憶デバイスの両方に配置できる。
【００１５】
本発明の態様は、半導体メモリ、ナノテクノロジーメモリ、有機もしくは光学式メモリまたはその他の携帯型データ記憶媒体上のマイクロコードとして、磁気的もしくは光学的読取可能コンピュータディスクを含む、コンピュータ読取可能媒体上に記憶し、または配信することができる。実際に、コンピュータに実装される命令、データストラクチャ、スクリーンディスプレイおよび本発明の態様によるその他のデータは、インターネットまたはその他のネットワーク（無線ネットワークを含む）を通じて、ある時間をかけて伝送媒体（たとえば、電磁波、音波等）上の搬送信号で配信され、あるいはどのようなアナログもしくはデジタルネットワーク（パケット交換型、回路交換型またはその他の方式）でも配信され得る。当業者は、本発明が部分的にサーバコンピュータ上にある場合もあれば、同じ部分が携帯デバイス等のクライアントコンピュータ上にある場合もあると認識するであろう。
【００１６】
図１において、テキストを含む三次元グラフィクスをレンダリングするための方法とシステムを実現できる代表的な環境は、ゲームコンソール１００を含む。ゲームコンソール１００は、ＣＰＵ１０２、データストア１０４（たとえば、ハードディスクまたはＤＶＤ）、メモリ１０６、オーディオ／ビデオポート１０８、イーサネット（登録商標）ポート１１０、パワーポート１１２、一つまたは複数のコントローラポート１１４を備えていてもよい。さらに、ゲームコンソール１００は、ピクセルシェーダ１２０を含むことができるグラフィクスプロセシングユニット（ＧＰＵ）コンポーネント１１６を備えていてもよい。
【００１７】
一部の実施形態において、ＧＰＵコンポーネント１１６は、ゲームコンソール１００上で動作するゲームアプリケーション１１８によって提供されるグラフィクスを処理する。ゲームコンソール１００上で動作する間、ゲームアプリケーションの一部（たとえば、フォントキャッシングシステム１２４）はメモリ１０６に記憶され、ゲームアプリケーションの別の部分（たとえば、フォントテクスチャ１２２またはフォントファイル）は（少なくとも一時的に）データストア１０４に記憶され得る。
【００１８】
ＩＩ．システムフロー
図２は、図１の代表的環境のコンポーネントの中のデータの流れを示すブロック図である。一部の実施形態において、データの流れはフォント管理ルーチン２０２によって管理され得る。ここでは、明確さを期すために一つのルーチンとして説明されているが、フォント管理ルーチン２０２は、実際には、コンピュータシステム内のハードウェアおよびソフトウェアとさまざまなに相互作用する一つまたは複数の機能、ルーチンまたはサブルーチンで構成されていてもよい。このようなサブルーチンの一例は、フォント管理ルーチンによって発行されるローディングリクエストを処理するリソースローダルーチン２０４である。たとえば、リソースローダルーチン２０４は、データストア１０４からの情報をフォントキャッシュシステム１２４（どちらも、すでに図１に示されている）にロードすることができる。フォントキャッシュシステム１２４はより詳細に示されており、キャラクタビットマップ情報を保持する（たとえば、ユニフォームグリッドの方式による）キャッシュコンポーネント２０６を含むかもしれない。グリッドスタイルのキャッシュを使用する一部の実施形態において、キャッシュのサイズは次のように決定される。キャッシュのサイズ＝（キャッシュの幅／セルのサイズ）*（キャッシュの高さ／セルのサイズ）。フォントキャッシュシステムはまた、キャラクタに関するメタデータ（たとえば、テクスチャ座標、ビットマップ内の文字のＡＢＣの幅等）を保持するフォント情報コンポーネント２０８と、キャッシュがオーバーフローした場合にキャッシュから消去するキャラクタの順番を管理する優先待ち行列コンポーネントも含んでいてもよい。
【００１９】
図の例において、フォント管理ルーチン２０２は、“ＧＡＭＥ ＯＶＥＲ”というストリング２００からなる入力パラメータを受け取る。ブロック１において、フォント管理ルーチン２０２は、“ＧＡＭＥ ＯＶＥＲ”というストリング２００の中の各キャラクタをチェックし、それが現在、キャッシュ２０６の中に記憶されているか否かを判断する。“ＧＡＭＥ ＯＶＥＲ”というストリングの中のあるキャラクタが現在、キャッシュ２０６内に記憶されていれば、ブロック２において、フォント管理ルーチン２０２は優先待ち行列２１０のアップデートを促進し、そのキャラクタに最も最近使用されたものとしてマークが付けられるようにする。“ＧＡＭＥ ＯＶＥＲ”ストリングの中のあるキャラクタが現在、キャッシュ２０６に記憶されていない場合、ブロック３において、フォント管理ルーチン２０２はリソースローダルーチン２０４にローディングリクエストを発行する。ブロック４において、リソースローダルーチン２０４はそのローディングリクエストを処理し、この処理の実行を助ける一つまたは複数の関連する機能を呼び出すかもしれない。たとえば、ゲームアプリケーションの場合、実際のローディングは、ゲームアプリケーションそのものによって非同期的に実現される。ブロック５において、リソースローダルーチン２０４（または関連する機能）は、所望のキャラクタに関するビットマップ情報をキャッシュ２０６の中にロードし、そのキャラクタに関するメタデータをフォント情報テーブル２０８にロードする。ビットマップ情報とメタデータ情報のローディング順序は、実施形態によって異なる（たとえば、メタデータを最初に、またはビットマップ情報を最初に、または同時にローディング、またはランダムにローディングする等）。
【００２０】
図３は、“ＧＡＭＥ”というストリングの中のすべてのキャラクタがキャッシュ内に確実にロードされるようにすることに関連する一連の動作中に、さまざまなポイント（３１０，３１２，３１４，３１６，３１８，３２０）においてキャッシュ（図２のキャッシュ２０６等）に記憶されているキャラクタの例を示す。ポイント３１０では、キャラクタ“Ａ”，“Ｒ”，“Ｃ”，“Ｘ”，“Ｌ”，“＋”が現在、キャッシュにロードされている。これらは、最も最近使用されたものから最も最近ではないが使用されたものへの順序で並べられているが、キャッシュ内のキャラクタの順序は、図２に関連して説明したように、別の優先待ち行列の使用を含めた各種の技術のいずれを使っても管理できる。“ＧＡＭＥ”というストリングの中のキャラクタ“Ｇ”が現在、キャッシュに入っていないと判断されると、ポイント３１２に示されているように、キャラクタ“Ｇ”がキャッシュにロードされ、キャラクタ“＋”が消去される。
【００２１】
ポイント３１４では、キャラクタ“Ｇ”，“Ａ”，“Ｒ”，“Ｃ”，“Ｘ”，“Ｌ”が現在、キャッシュにロードされ、キャラクタ“Ｇ”が最も最近使用されたキャラクタとして示されている。“ＧＡＭＥ”というストリングの中のキャラクタ“Ａ”３０４が現在、キャッシュ内にあると判断されると、ポイント３１６に示されているように、キャッシュは変化しない。
【００２２】
ポイント３１８では、キャラクタ“Ｇ”，“Ａ”，“Ｒ”，“Ｃ”，“Ｘ”，“Ｌ”が現在、キャッシュにロードされており、キャラクタ“Ｇ”が依然として最も最近使用されたキャラクタとして示されている。“ＧＡＭＥ”のストリングの中のキャラクタ“Ｍ”３０６が現在、キャッシュ内にないと判断されると、ポイント３２０に示されているように、キャラクタ“Ｇ”がキャッシュにロードされ、キャラクタ“Ｌ”が消去され、“Ｍ”が最も最近使用されたキャラクタ、“Ｘ”が最も最近ではないが使用されたキャラクタとなる。このプロセスは、すべての適当なキャラクタがキャッシュ内にロードされるまで続く。いくつかの実施形態において、レンダリングルーチンは、キャラクタがキャッシュにロードされるたびにこれをレンダリングする。別の実施形態において、レンダリングルーチンは、ストリングの中のすべてのキャラクタがキャッシュにロードされるまでレンダリングの実行を待機する。一部の実施形態において、キャラクタごとのレンダリングはストリングごとのレンダリングほど高速に行えないかもしれないが、キャラクタごとのレンダリングにより、キャラクタを、ｘ，ｙ，ｔ軸を中心として回転させること等、キャラクタごとの操作が可能となる。
【００２３】
図４は、ゲームアプリケーションで実行されるフォント管理ルーチン４００の例を示すフロー図である。このルーチン４００を実行する前に、ゲームアプリケーションは、キャッシュとフォント情報テーブルを含むフォントキャッシングシステムのインスタンスを作成する。さらに、フォントキャッシングシステムは、ビデオゲームのディスプレイ内でレンダリングされるべきキャラクタのストリング（たとえば、“Ｓｅｌｅｃｔ Ｐｌａｙｅｒｓ（プレイヤを選択してください）”）の入力を受け取る。ブロック４０１において、ルーチン４００は、そのストリング内の次のキャラクタを特定する。決定ブロック４０２において、ルーチン４００は、特定されたキャラクタに関するエントリーがフォント情報テーブル内にあるか否かを判断する。決定ブロック４０２において、そのキャラクタがフォント情報テーブル内にエントリーを持たないとルーチン４００が判断した場合、そのキャラクタに関するビットマップ情報は現在、キャッシュ内に記憶されていないことが明らかとなる。したがって、ルーチン４００はブロック４０６に進み、ここで、ルーチン４００はキャッシュ内にロードするためにテクスチャからキャラクタをフェッチし、ブロック４０７において、ルーチン４００はフェッチされたキャラクタに関連するメタデータをフォント情報テーブルにロードする。
【００２４】
他方、決定ブロック４０２において、ルーチン４００が、そのキャラクタはすでにフォント情報テーブル内にエントリーを持つと判断すると、ルーチン４００は決定ブロック４０３に進み、ここで、ルーチン４００はフォント情報テーブルに示されている、そのキャラクタのステータスをチェックする。フォント情報テーブルに示されている、そのキャラクタのステータスがＲＥＡＤＹであれば、そのキャラクタは現在キャッシュ内にあり、ルーチン４００はブロック４０４に進み、グリフをレンダリングする。しかし、決定ブロック４０３で、フォント情報テーブルに示されている、そのキャラクタのステータスがＮＯＴ ＲＥＡＤＹであれば、エラーがあり、ルーチン４００は終了する。
【００２５】
決定ブロック４０５において、ルーチン４００は、入力されたストリング内にフェッチおよび／またはレンダリングされるべき別のキャラクタがあるか判断する。もしあれば、ルーチン４００はブロック４０１に戻り、ストリング内の次のキャラクタを特定する。入力ストリング内にフェッチおよび／またはレンダリングされるべき別のキャラクタがなければ、ルーチン４００は終了する。
【００２６】
一部の実施形態において、図４のフォント管理ルーチン４００のようなフォント管理ルーチンは、さまざまな技術を使って、レンダリングを高速化し、および／またはメモリ使用量を削減することができる。たとえば、レンダリングを高速化するために、フォント管理ルーチンは、アプリケーションがランタイム中に作成する新しい頂点バッファ（vertex buffer）の数を減らすという機能を使用するかもしれない。一つの実施例において、フォント管理ルーチンは、アプリケーションからの各ストリングをコピーし、これを一つのクラスで保持し、ゲームがそのクラスを通じてこのストリングのインスタンスを破壊したとき、あるいはストリングがそのクラスを通じてアップデートされたときだけ（、また、スクロールその他の動的作用の結果、レンダリングされたテキストがスクリーン上で移動された場合は常にとは限らず）、頂点バッファが削除され、再び作成されるようにする。これに対し、メモリ使用量の削減においては、各フレームで、新たな頂点バッファにテキストに関する頂点データを直接書き込む技術を採用する。こうすることで、アプリケーションは、フレームごとに、ストリングメモリまたは頂点バッファメモリを常に把握する必要がない。
【００２７】
ＩＩＩ．メタフォント
一部の実施形態において、テキストを含む三次元グラフィクスをレンダリングするための方法とシステムは、複数のフォントタイプをまとめて一つのエンティティ（たとえば、一つの仮想フォントビットマップ）にするメタフォントの使用を含み得る。たとえば、図５に示されているように、いずれのメタフォント（５０２，５０４，５０６，５０８）もが、一つの配列に２つまたはそれ以上のフォントセット（たとえば、西ヨーロッパのキャラクタと東アジアのキャラクタの両方を含む一つのフォントファイル）を含むことができる。
【００２８】
メタフォントは実際には、複数の個別のフォントで構成されることもあるが、一部の実施形態において、図６に示されているように、フォント管理ルーチンにとっては一つのエンティティ６００のように見える。このように、メタフォントは、別のどのフォントのようにも使用できる。たとえば、上記のようなファイル管理ルーチンによってアクセスされるフォントファイルと同様に、メタフォントを定義するファイルは、ハードディスク、ＤＶＤまたはその他の永続的記憶媒体に保存され、その後フォント管理ルーチンによってアクセスされることができる。たとえば、フォント出力をレンダリングするために、フォント管理ルーチン（またはその他のルーチン）が、入力ストリングの各キャラクタをチェックし、メタフォントのどのキャラクタを使用すべきか（たとえば、東アジアのフォントかヨーロッパのフォントか）を判断する。メタフォントの実装にフォントキャッシュシステムが使用されている場合、メタフォントの適当なキャラクタが現在、キャッシュに記憶されていなければ、フォント管理ルーチンはこれを必要に応じてハードディスクまたはその他の永続的記憶装置からフェッチし、そのストリング内のすべてのキャラクタが表示され、レンダリングされるようにすることができる。たとえば、あるフォントがキャッシュ内にあるか否かを判断するために、フォント管理ルーチンは、適当なメタフォントＩＤのほか、キャラクタのユニコードを考慮するかもしれない。
【００２９】
一部の実施形態においては、特定の技術を使い、メタフォントを構成する一つまたは複数のフォントの違いをなくしている。たとえば、ヨーロッパのフォントはしばしば、「内部余白（インタナルリーディング）」を持たせて設計されており、つまり、各キャラクタの上部にスペースがある（このスペースにアクセント記号が表示される）が、アクセント記号を持たない言語のフォントにはこのスペースがない。このような違いが言語ごとに存在し、言語により異なる（たとえば、高さ、幅、キャラクタのスペースの違い）場合がある。別の言語におけるこの種の不一致を埋め合わせるために、メタフォントは、メタフォントの中の各言語のキャラクタについて、異なるサイズとスタイルのスクリプトを使用するかもしれない。たとえば、ヨーロッパと東アジアのキャラクタの両方を含むメタフォントのビットマップは、Ａｒｉａｌ−２４を使って描かれるヨーロッパのキャラクタとＭＳゴシック−２０を使って描かれる東アジアのキャラクタを使用するかもしれない。このような違いを補償するための別の例は、強制的に東アジアのキャラクタをより下側に表示させるためのローカライズ可能なオフセット値を追加する方法である。
【００３０】
一部の実施形態において、メタフォントは、図７に示されているように、メタフォント初期化ファイル７００の中の情報に基づいて動作する初期化ルーチンを使って実現される。たとえば、初期化ファイルは、異なるフォント言語の各々に関するメタデータを含む一つまたは複数のファイルに関するロケーション情報の第一のセット７０４（たとえば、ヨーロッパのフォント情報ファイルのための第一のファイルパスと東アジアフォント情報ファイルのための第二のファイルパス）のほか、メタフォントの名前７０２（またはその他の識別子）を含むことができる。初期化ファイルはまた、異なるフォント言語の各々に関するビットマップデータを含む一つまたは複数のファイルに関するロケーション情報の第二のセット７０６（たとえば、ヨーロッパのフォントビットマップファイルのための第一のファイルパスと東アジアのフォントビットマップファイルのため第二のファイルパス）を含むことができる。初期化ファイルはさらにまた、メタフォントの一つまたは複数のフォントに適用されるオフセット情報７０８（たとえば、東アジアの文字がフォントの最上部から表示されるときのピクセル数）も含むことができる。この構成の効果は、図６に示されるように、ゲームアプリケーションが一つのエンティティとして扱うことのできる仮想フォントビットマップおよびフォント情報ファイルの一種である。
【００３１】
初期化ファイルは異なるフォントを参照するよう変更できるため、アプリケーションデザイナは、所望のフォントに関する新しいフォント情報ファイルとフォントビットマップファイルを特定するように初期化ファイルを変えるだけで、アプリケーションにおいて使用されるフォントをより簡単に変更できる。このように、デザイナは、アプリケーションの中で使用される他のフォントを変えずに、フォントを変更し、あるいは複数の言語からの新しいフォントを追加することができる。
【００３２】
ＩＶ．むすび
文脈上、明確に他の解釈が必要とならないかぎり、説明と特許請求範囲全体を通じて、「でなる」、「からなる」等の言葉は、限定的な意味ではなく、包含的な意味、つまり、「以下を含み、これに限定されない」という意味で解釈される。さらに、「ここで」、「上記の」、「下記の」および同様の言葉は、本願において使用される場合、本願全体を指すものであり、本願の中の特定の部分を指すものではない。特許請求範囲で２つまたはそれ以上の事柄の列記に関して「または」との用語が使用されている場合、列記されたもののいずれか、列記されたもののすべて、および列記されたもののいくつかの組み合わせを意味する。
【００３３】
本発明の実施形態の上記の詳細な説明は、排他的なもの、あるいは本発明を先述の詳細な形態に限定するものではない。本発明の具体的な実施形態および例を、上で説明のために紹介したが、当業者が認識するように、本発明の範囲内で、さまざまな同等の変更を実現できる。たとえば、工程やブロックはある順序によって紹介されているが、別の実施形態では、異なる順序のステップを含むルーチンを実行し、あるいは異なる順序のブロックを有するシステムを使用でき、いずれの工程またはブロックを削除、移動、追加、再分割、統合および／または変更することができる。これらの工程やブロックの各々は、さまざまな方法で実現できる。また、工程やブロックは時々逐次的に実行されるように示されているが、これらの工程やブロックは、並列して実行することも、また、別のタイミングで実行することもできる。文脈上可能であれば、上記の詳細な説明において単数形または複数形で使用される単語は、それぞれ複数形または単数形も含む。
【００３４】
ここで紹介する発明の教示は、必ずしもここで説明されたシステムに限らず、他のシステムにも適用される。上記の各種の実施形態の要素や動作を組み合わせて、さらに別の実施形態とすることができる。たとえば、上記の技術を、本願と同じ所有者による米国特許出願（２００４年１１月２日出願の「１６ビットピクセルの４ビットへのパッキング等のテクスチャベースパッキング」と題する米国特許出願第１０／９７９，９６２号、２００４年１１月２日出願の「８ビットピクセルの２ビットへのパッキング等のテクスチャベースパッキング」と題する米国特許出願第１０／９７９，９６３号、２００４年１１月２日出願の「８ビットピクセルの１ビットへのパッキング等のテクスチャベースパッキング」と題する米国特許出願第１０／９８０，４０４）に記載されているフォントパッキング技術等、メモリ使用量の問題を改善するための他の技術と組み合わせることができる。本発明の態様は、必要であれば、上記の参考文献のシステム、機能、コンセプトを利用するよう変更し、さらに別の実施形態を提供できる。
【００３５】
これらの、およびその他の変更は、上記の詳細な説明に照らして本発明に適用することができる。上記の説明は、本発明の特定の実施形態を詳細に紹介し、予測される最良の形態を述べているが、上記のものが文章においていかに詳細に見えても、本発明はさまざまな方法で実現できる。前述のように、本発明の特定の特徴または態様を説明する際使用された具体的な用語は、その用語が、その用語が関連付けられている本発明の特定の特徴または態様に限定されるものとここで再定義されていると暗示しているとは解釈すべきではない。一般に、特許請求範囲で使われている用語は、上記の詳細な説明がその用語を明確に定義している場合を除き、明細書において開示されている本発明の特定の実施形態に本発明を限定するものと解釈すべきではない。したがって、本発明の実際の範囲は、開示された実施形態だけでなく、特許請求範囲に基づいて本発明が実践、実現されるあらゆる同等の方法も包含する。
【図面の簡単な説明】
【００３６】
【図１】本発明を一実施形態において実現できる環境の一例を示すブロック図である。
【図２】一実施形態における図１の代表的環境のコンポーネントの中のデータの流れを示すブロック図である。
【図３】一実施形態において一連のイベントの過程で記憶されるキャラクタの例を示すデータ図である。
【図４】ゲームアプリケーションで実行されるフォント管理ルーチンの例を示すフロー図である。
【図５】各々２つまたはそれ以上フォントで構成されるメタフォントの例を示すブロック図である。
【図６】一実施形態におけるフォント管理ルーチンから見た一つのエンティティとしてのメタフォントの例を示すデータ図である。
【図７】一実施形態におけるメタフォント初期化ファイルの内容の例を示すデータ図である。
【背景技術】
【０００１】
コンピュータグラフィクスの進化により、二次元空間（たとえば、コンピュータのスクリーンまたはモニタ）に三次元のグラフィックオブジェクト（たとえば、ビデオゲームのキャラクタ）を表示することが可能となった。三次元グラフィクスを使用するビデオゲームやその他のアプリケーションはユーザにとって非常にリアルに見え、ユーザがこれを体験する中での楽しさが増す。三次元グラフィクスを生成するための一つの技術に、テクスチャの使用がある。テクスチャは二次元のビットマップであり、シーンを三次元レンダリングする場合に、これを使わなければフラットとなるような表面形状を描く際、実世界のテクスチャの詳細（たとえば、木、布目、カーペット等）を擬態するために一般的に使用される。一部の例では、テクスチャは複数の二次元ピクセルで構成される。各ピクセルは位置、色、明るさ、色の濃さ（depth）という特性（property）を有する。いったん作成されると、テクスチャは、テキストや記号を表す画像を含む多くの種類の画像をレンダリングするのに使用することができる。一般に、二次元テキストをレンダリングするためにテクスチャを使用することは、他のテキストレンダリング技術より好ましい。なぜなら、テクスチャにより、テキストを必要に応じて投射、スケーリング、回転することが容易になるからである。
【０００２】
フォントのレンダリングに使用されるテクスチャは、非常に大きいことが多い。たとえば、ビデオゲームは、視覚的に印象深くなければあまり売れないため、しばしば、一つのシーンに複数の魅力的なフォントが使用されていることが望まれる。したがって、三次元ビデオゲームのためのテキストのレンダリングに使用される一つのテクスチャは情報量の大きなキャラクタセット（たとえば、テキストキャラクタ、記号および／または特定のフォントもしくはテキストスタイルに伴う画像）を含むかもしれない。国際市場向けのビデオゲームにおけるフォントのレンダリングに使用されるテクスチャもまた、非常に多くのキャラクタセットを含むかもしれない。たとえば、中国語のテキストを含むゲームには、約５，０００から８，０００文字が必要となりうる。各文字がテクスチャビットマップの２０×２０のピクセル区分にプレレンダリングされたとすれば、テクスチャビットマップ全体は１，８００×１，８００ピクセル、つまり３．２５ＭＰｉｘｅｌとなる。
【０００３】
テクスチャからテキストをレンダリングする場合、一般に、所望のグリフ（flyph）がテクスチャ内にあるところとなる、一致するテクスチャ座標のセット（たとえば、「Ｇ」の文字を構成する座標）の選択が行われる。たとえば、テクスチャからのテキストのレンダリング方法の一つにおいては、フォントをビットマップ化されたテクスチャ（たとえば、フォントビットマップ）として記憶し、個々の文字を画面空間で整列されたクワタ（quad）としてレンダリングする。この技術は、グラフィクスプロセシングユニット（ＧＰＵ）またはこれに類するハードウェアの本来的機能を用い、ビットマップに基づくフォントを、ＧＰＵに関連するハードウェアの最大のフィルレート（１秒あたりのピクセル数）でレンダリングする。この技術の一つの限界は、情報量の大きなキャラクタセット（たとえば、ユニコードのキャラクタセット）について使用された場合、現在のハードウェア容量を超えるテクスチャのサイズが必要となり、大量のメモリを使用するかもしれない。さらに、ゲームがフォントビットのためにとっておくべきメモリ量を、テキストの翻訳を行う前に予測することは非常に難しい。その上、フォントビットマップは、新しいフォントがダウンロード用コンテンツとして取得可能になるとアップデートされる可能性があり、将来のメモリ割り当て上の問題やその他の問題の原因となりうる。
【発明の開示】
【課題を解決するための手段】
【０００４】
テキストキャラクタ、記号およびその他のキャラクタを含むテキストをレンダリングするための方法とシステムについて、ここで説明する。一部の実施形態において、これらの方法とシステムは、少なくとも部分的に、ソフトウェアアプリケーション（たとえば、ビデオゲーム）のフォント管理ルーチンを通じて実施されるかもしれない。フォント管理ルーチンは、少なくとも一時的にハードディスク、ＤＶＤ、あるいはフォント管理ルーチンが必要に応じてアクセスできるその他の媒体に記憶される一つまたは複数のフォントファイルから個々のキャラクタを読み取ることができる。
【０００５】
一部の実施形態において、フォント管理ルーチンは、読み取ったキャラクタをフォントキャッシュシステム（たとえば、アプリケーションの初期化時にインスタンスとして作られる）にコピーまたはロードすることができる。また、フォント管理ルーチンは、読み取られたキャラクタに関係するメタデータおよび／またはその他の情報（たとえば、キャラクタの幅、オフセット、配置情報等）もフォントキャッシュシステムにロードすることができる。したがって、フォントキャッシュシステムは、キャッシュ（たとえば、キャラクタそのものを記憶するためのもの）と、キャラクタに関係するメタデータおよび／またはその他の情報を記憶するテーブルもしくはその他のデータストラクチャを含むことができる。
【０００６】
場合によっては、フォントキャッシュシステムのキャッシュは所定のサイズで、フォントファイルの中の利用可能なキャラクタの総数より小さい。したがって、テーブルは、ステータスに関する情報（たとえば、そのキャラクタが現在キャッシュ内にあるか否かに関する情報等）を記憶することができる。テーブル（または場合に応じて、別の優先待ち行列）は、キャッシュに記憶されたキャラクタがどれほど最近使用されたかに関する情報を記憶することができる。このように、キャッシュがいっぱいになると、フォントキャッシュシステムは、テーブルおよび／または優先待ち行列の中のステータス情報に依存して、フォントキャッシュから最近最も使用されないキャラクタを消去する。
【０００７】
一部の実施形態において、テキストを含む三次元グラフィクスをレンダリングするための方法とシステムはまた、複数のフォントタイプを一つのレンダリングスキームにまとめるメタフォントの使用を含んでいてもよい。たとえば、どのメタフォントも、一つの配列による２つ以上のフォントグループ（たとえば、西ヨーロッパのキャラクタと東アジアのキャラクタの両方を含む一つのフォントファイル）を含むことができる。上記のフォントファイルと同様に、メタフォントはハードドライブ、ＤＶＤ、またはその他の永続的記憶媒体に記憶され、その後フォント管理ルーチンによってアクセスされる。
【０００８】
一部の実施形態において、フォント管理ルーチン（またはその他のルーチン）は、レンダリングされるべき入力ストリング内の各キャラクタをチェックし、メタフォントのどのキャラクタ（たとえば、東アジアのフォントかヨーロッパのフォントか）を使用すべきかを判断する。フォントキャッシュシステムを使ってメタフォントが実装されている場合、メタフォントの適当な文字が現在キャッシュ内に記憶されていなければ、フォント管理ルーチンはこれを必要に応じて永続的記憶装置からフェッチし、そのストリングを表示できるようにする。
【０００９】
本明細書の一部には、著作権主張の対象物が含まれる。著作権所有者は、特許商標庁の特許ファイルもしくは記録に表示されているように、何人による特許文書もしくは特許説明書（図面を含む）の複写に対しても異議を申し立てないが、その他すべてのあらゆる著作権を留保する。
【発明を実施するための最良の形態】
【００１０】
次に、本発明をさまざまな実施形態に関して説明する。以下の説明では、本発明のこのような実施形態が十分に理解され、その説明を可能にするための具体的な詳細事項を紹介している。しかしながら、当業者であれば、本発明をこれらの詳細事項がなくても実現することが可能であると理解するであろう。また、周知の構造や機能については、本発明の実施形態の説明が不必要に不明瞭となることを避けるために、示されていない、あるいは詳しく説明されていない。
【００１１】
説明において使用されている用語は、本発明の特定の具体的な実施形態の詳細な説明に関連して使用されていたとしても、合理的にもっとも広く解釈されるものとする。特定の用語は、以下の説明の中で強調されてさえいるが、限定的に解釈されるべき用語であれば、この詳細な説明の中で明確かつ具体的に定義される。
【００１２】
図面において、同一もしくは実質的に同様の要素または動作を特定するために、同じ参照符号が付与されている。特定の要素または動作について論じやすくするために、参照符号の中のもっとも重要な桁は、その要素が初めて紹介された図面の番号を示している（たとえば、要素２０４は図２において最初に紹介され、論じられている）。
【００１３】
Ｉ．代表的なシステム
図１と以下の説明は、本発明を実現できる代表的な環境を簡単に、概説している。必要条件ではないものの、本発明の態様は、汎用コンピュータ（たとえば、サーバコンピュータ、無線デバイスまたはパーソナル／ラップトップコンピュータ）によって実行されるルーチン等のコンピュータ実行可能な命令という一般的な文脈において説明される。当業者は、本発明が他の通信、データ処理またはコンピュータシステムコンフィギュレーション、たとえば、ゲームコンソール、インターネット機器、携帯デバイス（携帯情報端末（ＰＣＡ）を含む）、ウェアラブルコンピュータ、あらゆる形態のセル式その他の携帯電話、埋込式コンピュータ（自動車に搭載されたものを含む）、マルチプロセッサシステム、マイクロプロセッサベースもしくはプログラム可能な民生用電子機器、セットトップボックス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータその他でも実施できることを理解できるであろう。実際、「コンピュータ」という用語は一般に、上記のあらゆるデバイスやシステムのほか、あらゆるデータプロセッサを指す。
【００１４】
本発明の態様は、ここで詳細に説明する一つまたは複数のコンピュータ実行可能命令を実行するよう特にプログラム、構成または構築された特定用途コンピュータもしくはデータプロセッサにおいて実施され得る。本発明の態様はまた、タスクやモジュールが、通信ネットワークを通じて連結されているリモート処理デバイスによって実行される分散型コンピューティング環境でも実施できる。分散型コンピューティング環境において、プログラムモジュールは、ローカルおよびリモートメモリ記憶デバイスの両方に配置できる。
【００１５】
本発明の態様は、半導体メモリ、ナノテクノロジーメモリ、有機もしくは光学式メモリまたはその他の携帯型データ記憶媒体上のマイクロコードとして、磁気的もしくは光学的読取可能コンピュータディスクを含む、コンピュータ読取可能媒体上に記憶し、または配信することができる。実際に、コンピュータに実装される命令、データストラクチャ、スクリーンディスプレイおよび本発明の態様によるその他のデータは、インターネットまたはその他のネットワーク（無線ネットワークを含む）を通じて、ある時間をかけて伝送媒体（たとえば、電磁波、音波等）上の搬送信号で配信され、あるいはどのようなアナログもしくはデジタルネットワーク（パケット交換型、回路交換型またはその他の方式）でも配信され得る。当業者は、本発明が部分的にサーバコンピュータ上にある場合もあれば、同じ部分が携帯デバイス等のクライアントコンピュータ上にある場合もあると認識するであろう。
【００１６】
図１において、テキストを含む三次元グラフィクスをレンダリングするための方法とシステムを実現できる代表的な環境は、ゲームコンソール１００を含む。ゲームコンソール１００は、ＣＰＵ１０２、データストア１０４（たとえば、ハードディスクまたはＤＶＤ）、メモリ１０６、オーディオ／ビデオポート１０８、イーサネット（登録商標）ポート１１０、パワーポート１１２、一つまたは複数のコントローラポート１１４を備えていてもよい。さらに、ゲームコンソール１００は、ピクセルシェーダ１２０を含むことができるグラフィクスプロセシングユニット（ＧＰＵ）コンポーネント１１６を備えていてもよい。
【００１７】
一部の実施形態において、ＧＰＵコンポーネント１１６は、ゲームコンソール１００上で動作するゲームアプリケーション１１８によって提供されるグラフィクスを処理する。ゲームコンソール１００上で動作する間、ゲームアプリケーションの一部（たとえば、フォントキャッシングシステム１２４）はメモリ１０６に記憶され、ゲームアプリケーションの別の部分（たとえば、フォントテクスチャ１２２またはフォントファイル）は（少なくとも一時的に）データストア１０４に記憶され得る。
【００１８】
ＩＩ．システムフロー
図２は、図１の代表的環境のコンポーネントの中のデータの流れを示すブロック図である。一部の実施形態において、データの流れはフォント管理ルーチン２０２によって管理され得る。ここでは、明確さを期すために一つのルーチンとして説明されているが、フォント管理ルーチン２０２は、実際には、コンピュータシステム内のハードウェアおよびソフトウェアとさまざまなに相互作用する一つまたは複数の機能、ルーチンまたはサブルーチンで構成されていてもよい。このようなサブルーチンの一例は、フォント管理ルーチンによって発行されるローディングリクエストを処理するリソースローダルーチン２０４である。たとえば、リソースローダルーチン２０４は、データストア１０４からの情報をフォントキャッシュシステム１２４（どちらも、すでに図１に示されている）にロードすることができる。フォントキャッシュシステム１２４はより詳細に示されており、キャラクタビットマップ情報を保持する（たとえば、ユニフォームグリッドの方式による）キャッシュコンポーネント２０６を含むかもしれない。グリッドスタイルのキャッシュを使用する一部の実施形態において、キャッシュのサイズは次のように決定される。キャッシュのサイズ＝（キャッシュの幅／セルのサイズ）*（キャッシュの高さ／セルのサイズ）。フォントキャッシュシステムはまた、キャラクタに関するメタデータ（たとえば、テクスチャ座標、ビットマップ内の文字のＡＢＣの幅等）を保持するフォント情報コンポーネント２０８と、キャッシュがオーバーフローした場合にキャッシュから消去するキャラクタの順番を管理する優先待ち行列コンポーネントも含んでいてもよい。
【００１９】
図の例において、フォント管理ルーチン２０２は、“ＧＡＭＥ ＯＶＥＲ”というストリング２００からなる入力パラメータを受け取る。ブロック１において、フォント管理ルーチン２０２は、“ＧＡＭＥ ＯＶＥＲ”というストリング２００の中の各キャラクタをチェックし、それが現在、キャッシュ２０６の中に記憶されているか否かを判断する。“ＧＡＭＥ ＯＶＥＲ”というストリングの中のあるキャラクタが現在、キャッシュ２０６内に記憶されていれば、ブロック２において、フォント管理ルーチン２０２は優先待ち行列２１０のアップデートを促進し、そのキャラクタに最も最近使用されたものとしてマークが付けられるようにする。“ＧＡＭＥ ＯＶＥＲ”ストリングの中のあるキャラクタが現在、キャッシュ２０６に記憶されていない場合、ブロック３において、フォント管理ルーチン２０２はリソースローダルーチン２０４にローディングリクエストを発行する。ブロック４において、リソースローダルーチン２０４はそのローディングリクエストを処理し、この処理の実行を助ける一つまたは複数の関連する機能を呼び出すかもしれない。たとえば、ゲームアプリケーションの場合、実際のローディングは、ゲームアプリケーションそのものによって非同期的に実現される。ブロック５において、リソースローダルーチン２０４（または関連する機能）は、所望のキャラクタに関するビットマップ情報をキャッシュ２０６の中にロードし、そのキャラクタに関するメタデータをフォント情報テーブル２０８にロードする。ビットマップ情報とメタデータ情報のローディング順序は、実施形態によって異なる（たとえば、メタデータを最初に、またはビットマップ情報を最初に、または同時にローディング、またはランダムにローディングする等）。
【００２０】
図３は、“ＧＡＭＥ”というストリングの中のすべてのキャラクタがキャッシュ内に確実にロードされるようにすることに関連する一連の動作中に、さまざまなポイント（３１０，３１２，３１４，３１６，３１８，３２０）においてキャッシュ（図２のキャッシュ２０６等）に記憶されているキャラクタの例を示す。ポイント３１０では、キャラクタ“Ａ”，“Ｒ”，“Ｃ”，“Ｘ”，“Ｌ”，“＋”が現在、キャッシュにロードされている。これらは、最も最近使用されたものから最も最近ではないが使用されたものへの順序で並べられているが、キャッシュ内のキャラクタの順序は、図２に関連して説明したように、別の優先待ち行列の使用を含めた各種の技術のいずれを使っても管理できる。“ＧＡＭＥ”というストリングの中のキャラクタ“Ｇ”が現在、キャッシュに入っていないと判断されると、ポイント３１２に示されているように、キャラクタ“Ｇ”がキャッシュにロードされ、キャラクタ“＋”が消去される。
【００２１】
ポイント３１４では、キャラクタ“Ｇ”，“Ａ”，“Ｒ”，“Ｃ”，“Ｘ”，“Ｌ”が現在、キャッシュにロードされ、キャラクタ“Ｇ”が最も最近使用されたキャラクタとして示されている。“ＧＡＭＥ”というストリングの中のキャラクタ“Ａ”３０４が現在、キャッシュ内にあると判断されると、ポイント３１６に示されているように、キャッシュは変化しない。
【００２２】
ポイント３１８では、キャラクタ“Ｇ”，“Ａ”，“Ｒ”，“Ｃ”，“Ｘ”，“Ｌ”が現在、キャッシュにロードされており、キャラクタ“Ｇ”が依然として最も最近使用されたキャラクタとして示されている。“ＧＡＭＥ”のストリングの中のキャラクタ“Ｍ”３０６が現在、キャッシュ内にないと判断されると、ポイント３２０に示されているように、キャラクタ“Ｇ”がキャッシュにロードされ、キャラクタ“Ｌ”が消去され、“Ｍ”が最も最近使用されたキャラクタ、“Ｘ”が最も最近ではないが使用されたキャラクタとなる。このプロセスは、すべての適当なキャラクタがキャッシュ内にロードされるまで続く。いくつかの実施形態において、レンダリングルーチンは、キャラクタがキャッシュにロードされるたびにこれをレンダリングする。別の実施形態において、レンダリングルーチンは、ストリングの中のすべてのキャラクタがキャッシュにロードされるまでレンダリングの実行を待機する。一部の実施形態において、キャラクタごとのレンダリングはストリングごとのレンダリングほど高速に行えないかもしれないが、キャラクタごとのレンダリングにより、キャラクタを、ｘ，ｙ，ｔ軸を中心として回転させること等、キャラクタごとの操作が可能となる。
【００２３】
図４は、ゲームアプリケーションで実行されるフォント管理ルーチン４００の例を示すフロー図である。このルーチン４００を実行する前に、ゲームアプリケーションは、キャッシュとフォント情報テーブルを含むフォントキャッシングシステムのインスタンスを作成する。さらに、フォントキャッシングシステムは、ビデオゲームのディスプレイ内でレンダリングされるべきキャラクタのストリング（たとえば、“Ｓｅｌｅｃｔ Ｐｌａｙｅｒｓ（プレイヤを選択してください）”）の入力を受け取る。ブロック４０１において、ルーチン４００は、そのストリング内の次のキャラクタを特定する。決定ブロック４０２において、ルーチン４００は、特定されたキャラクタに関するエントリーがフォント情報テーブル内にあるか否かを判断する。決定ブロック４０２において、そのキャラクタがフォント情報テーブル内にエントリーを持たないとルーチン４００が判断した場合、そのキャラクタに関するビットマップ情報は現在、キャッシュ内に記憶されていないことが明らかとなる。したがって、ルーチン４００はブロック４０６に進み、ここで、ルーチン４００はキャッシュ内にロードするためにテクスチャからキャラクタをフェッチし、ブロック４０７において、ルーチン４００はフェッチされたキャラクタに関連するメタデータをフォント情報テーブルにロードする。
【００２４】
他方、決定ブロック４０２において、ルーチン４００が、そのキャラクタはすでにフォント情報テーブル内にエントリーを持つと判断すると、ルーチン４００は決定ブロック４０３に進み、ここで、ルーチン４００はフォント情報テーブルに示されている、そのキャラクタのステータスをチェックする。フォント情報テーブルに示されている、そのキャラクタのステータスがＲＥＡＤＹであれば、そのキャラクタは現在キャッシュ内にあり、ルーチン４００はブロック４０４に進み、グリフをレンダリングする。しかし、決定ブロック４０３で、フォント情報テーブルに示されている、そのキャラクタのステータスがＮＯＴ ＲＥＡＤＹであれば、エラーがあり、ルーチン４００は終了する。
【００２５】
決定ブロック４０５において、ルーチン４００は、入力されたストリング内にフェッチおよび／またはレンダリングされるべき別のキャラクタがあるか判断する。もしあれば、ルーチン４００はブロック４０１に戻り、ストリング内の次のキャラクタを特定する。入力ストリング内にフェッチおよび／またはレンダリングされるべき別のキャラクタがなければ、ルーチン４００は終了する。
【００２６】
一部の実施形態において、図４のフォント管理ルーチン４００のようなフォント管理ルーチンは、さまざまな技術を使って、レンダリングを高速化し、および／またはメモリ使用量を削減することができる。たとえば、レンダリングを高速化するために、フォント管理ルーチンは、アプリケーションがランタイム中に作成する新しい頂点バッファ（vertex buffer）の数を減らすという機能を使用するかもしれない。一つの実施例において、フォント管理ルーチンは、アプリケーションからの各ストリングをコピーし、これを一つのクラスで保持し、ゲームがそのクラスを通じてこのストリングのインスタンスを破壊したとき、あるいはストリングがそのクラスを通じてアップデートされたときだけ（、また、スクロールその他の動的作用の結果、レンダリングされたテキストがスクリーン上で移動された場合は常にとは限らず）、頂点バッファが削除され、再び作成されるようにする。これに対し、メモリ使用量の削減においては、各フレームで、新たな頂点バッファにテキストに関する頂点データを直接書き込む技術を採用する。こうすることで、アプリケーションは、フレームごとに、ストリングメモリまたは頂点バッファメモリを常に把握する必要がない。
【００２７】
ＩＩＩ．メタフォント
一部の実施形態において、テキストを含む三次元グラフィクスをレンダリングするための方法とシステムは、複数のフォントタイプをまとめて一つのエンティティ（たとえば、一つの仮想フォントビットマップ）にするメタフォントの使用を含み得る。たとえば、図５に示されているように、いずれのメタフォント（５０２，５０４，５０６，５０８）もが、一つの配列に２つまたはそれ以上のフォントセット（たとえば、西ヨーロッパのキャラクタと東アジアのキャラクタの両方を含む一つのフォントファイル）を含むことができる。
【００２８】
メタフォントは実際には、複数の個別のフォントで構成されることもあるが、一部の実施形態において、図６に示されているように、フォント管理ルーチンにとっては一つのエンティティ６００のように見える。このように、メタフォントは、別のどのフォントのようにも使用できる。たとえば、上記のようなファイル管理ルーチンによってアクセスされるフォントファイルと同様に、メタフォントを定義するファイルは、ハードディスク、ＤＶＤまたはその他の永続的記憶媒体に保存され、その後フォント管理ルーチンによってアクセスされることができる。たとえば、フォント出力をレンダリングするために、フォント管理ルーチン（またはその他のルーチン）が、入力ストリングの各キャラクタをチェックし、メタフォントのどのキャラクタを使用すべきか（たとえば、東アジアのフォントかヨーロッパのフォントか）を判断する。メタフォントの実装にフォントキャッシュシステムが使用されている場合、メタフォントの適当なキャラクタが現在、キャッシュに記憶されていなければ、フォント管理ルーチンはこれを必要に応じてハードディスクまたはその他の永続的記憶装置からフェッチし、そのストリング内のすべてのキャラクタが表示され、レンダリングされるようにすることができる。たとえば、あるフォントがキャッシュ内にあるか否かを判断するために、フォント管理ルーチンは、適当なメタフォントＩＤのほか、キャラクタのユニコードを考慮するかもしれない。
【００２９】
一部の実施形態においては、特定の技術を使い、メタフォントを構成する一つまたは複数のフォントの違いをなくしている。たとえば、ヨーロッパのフォントはしばしば、「内部余白（インタナルリーディング）」を持たせて設計されており、つまり、各キャラクタの上部にスペースがある（このスペースにアクセント記号が表示される）が、アクセント記号を持たない言語のフォントにはこのスペースがない。このような違いが言語ごとに存在し、言語により異なる（たとえば、高さ、幅、キャラクタのスペースの違い）場合がある。別の言語におけるこの種の不一致を埋め合わせるために、メタフォントは、メタフォントの中の各言語のキャラクタについて、異なるサイズとスタイルのスクリプトを使用するかもしれない。たとえば、ヨーロッパと東アジアのキャラクタの両方を含むメタフォントのビットマップは、Ａｒｉａｌ−２４を使って描かれるヨーロッパのキャラクタとＭＳゴシック−２０を使って描かれる東アジアのキャラクタを使用するかもしれない。このような違いを補償するための別の例は、強制的に東アジアのキャラクタをより下側に表示させるためのローカライズ可能なオフセット値を追加する方法である。
【００３０】
一部の実施形態において、メタフォントは、図７に示されているように、メタフォント初期化ファイル７００の中の情報に基づいて動作する初期化ルーチンを使って実現される。たとえば、初期化ファイルは、異なるフォント言語の各々に関するメタデータを含む一つまたは複数のファイルに関するロケーション情報の第一のセット７０４（たとえば、ヨーロッパのフォント情報ファイルのための第一のファイルパスと東アジアフォント情報ファイルのための第二のファイルパス）のほか、メタフォントの名前７０２（またはその他の識別子）を含むことができる。初期化ファイルはまた、異なるフォント言語の各々に関するビットマップデータを含む一つまたは複数のファイルに関するロケーション情報の第二のセット７０６（たとえば、ヨーロッパのフォントビットマップファイルのための第一のファイルパスと東アジアのフォントビットマップファイルのため第二のファイルパス）を含むことができる。初期化ファイルはさらにまた、メタフォントの一つまたは複数のフォントに適用されるオフセット情報７０８（たとえば、東アジアの文字がフォントの最上部から表示されるときのピクセル数）も含むことができる。この構成の効果は、図６に示されるように、ゲームアプリケーションが一つのエンティティとして扱うことのできる仮想フォントビットマップおよびフォント情報ファイルの一種である。
【００３１】
初期化ファイルは異なるフォントを参照するよう変更できるため、アプリケーションデザイナは、所望のフォントに関する新しいフォント情報ファイルとフォントビットマップファイルを特定するように初期化ファイルを変えるだけで、アプリケーションにおいて使用されるフォントをより簡単に変更できる。このように、デザイナは、アプリケーションの中で使用される他のフォントを変えずに、フォントを変更し、あるいは複数の言語からの新しいフォントを追加することができる。
【００３２】
ＩＶ．むすび
文脈上、明確に他の解釈が必要とならないかぎり、説明と特許請求範囲全体を通じて、「でなる」、「からなる」等の言葉は、限定的な意味ではなく、包含的な意味、つまり、「以下を含み、これに限定されない」という意味で解釈される。さらに、「ここで」、「上記の」、「下記の」および同様の言葉は、本願において使用される場合、本願全体を指すものであり、本願の中の特定の部分を指すものではない。特許請求範囲で２つまたはそれ以上の事柄の列記に関して「または」との用語が使用されている場合、列記されたもののいずれか、列記されたもののすべて、および列記されたもののいくつかの組み合わせを意味する。
【００３３】
本発明の実施形態の上記の詳細な説明は、排他的なもの、あるいは本発明を先述の詳細な形態に限定するものではない。本発明の具体的な実施形態および例を、上で説明のために紹介したが、当業者が認識するように、本発明の範囲内で、さまざまな同等の変更を実現できる。たとえば、工程やブロックはある順序によって紹介されているが、別の実施形態では、異なる順序のステップを含むルーチンを実行し、あるいは異なる順序のブロックを有するシステムを使用でき、いずれの工程またはブロックを削除、移動、追加、再分割、統合および／または変更することができる。これらの工程やブロックの各々は、さまざまな方法で実現できる。また、工程やブロックは時々逐次的に実行されるように示されているが、これらの工程やブロックは、並列して実行することも、また、別のタイミングで実行することもできる。文脈上可能であれば、上記の詳細な説明において単数形または複数形で使用される単語は、それぞれ複数形または単数形も含む。
【００３４】
ここで紹介する発明の教示は、必ずしもここで説明されたシステムに限らず、他のシステムにも適用される。上記の各種の実施形態の要素や動作を組み合わせて、さらに別の実施形態とすることができる。たとえば、上記の技術を、本願と同じ所有者による米国特許出願（２００４年１１月２日出願の「１６ビットピクセルの４ビットへのパッキング等のテクスチャベースパッキング」と題する米国特許出願第１０／９７９，９６２号、２００４年１１月２日出願の「８ビットピクセルの２ビットへのパッキング等のテクスチャベースパッキング」と題する米国特許出願第１０／９７９，９６３号、２００４年１１月２日出願の「８ビットピクセルの１ビットへのパッキング等のテクスチャベースパッキング」と題する米国特許出願第１０／９８０，４０４）に記載されているフォントパッキング技術等、メモリ使用量の問題を改善するための他の技術と組み合わせることができる。本発明の態様は、必要であれば、上記の参考文献のシステム、機能、コンセプトを利用するよう変更し、さらに別の実施形態を提供できる。
【００３５】
これらの、およびその他の変更は、上記の詳細な説明に照らして本発明に適用することができる。上記の説明は、本発明の特定の実施形態を詳細に紹介し、予測される最良の形態を述べているが、上記のものが文章においていかに詳細に見えても、本発明はさまざまな方法で実現できる。前述のように、本発明の特定の特徴または態様を説明する際使用された具体的な用語は、その用語が、その用語が関連付けられている本発明の特定の特徴または態様に限定されるものとここで再定義されていると暗示しているとは解釈すべきではない。一般に、特許請求範囲で使われている用語は、上記の詳細な説明がその用語を明確に定義している場合を除き、明細書において開示されている本発明の特定の実施形態に本発明を限定するものと解釈すべきではない。したがって、本発明の実際の範囲は、開示された実施形態だけでなく、特許請求範囲に基づいて本発明が実践、実現されるあらゆる同等の方法も包含する。
【図面の簡単な説明】
【００３６】
【図１】本発明を一実施形態において実現できる環境の一例を示すブロック図である。
【図２】一実施形態における図１の代表的環境のコンポーネントの中のデータの流れを示すブロック図である。
【図３】一実施形態において一連のイベントの過程で記憶されるキャラクタの例を示すデータ図である。
【図４】ゲームアプリケーションで実行されるフォント管理ルーチンの例を示すフロー図である。
【図５】各々２つまたはそれ以上フォントで構成されるメタフォントの例を示すブロック図である。
【図６】一実施形態におけるフォント管理ルーチンから見た一つのエンティティとしてのメタフォントの例を示すデータ図である。
【図７】一実施形態におけるメタフォント初期化ファイルの内容の例を示すデータ図である。
【特許請求の範囲】
【請求項１】
コンピュータ内で、キャラクタを表示させるアプリケーションに関連した、少なくとも一つのフォントグループに配列されたキャラクタへのアクセスと表示を管理する方法において、
前記コンピュータ内のメモリにおける第一の記憶スペースを初期化するステップであって、前記第一の記憶スペースは、前記少なくとも一つのフォントグループに含まれる所定の数のキャラクタに関する情報のための記憶を含むステップと、
前記少なくとも一つのフォントグループに関連する情報を前記コンピュータに関連する第二の記憶スペースに記憶するステップであって、前記第二の記憶スペースは、前記コンピュータの前記メモリとは区別され、前記第二の記憶スペースは、前記少なくとも一つのフォントグループに含まれるすべてのキャラクタに関する情報を記憶するステップと、
前記少なくとも一つのフォントグループから、レンダリングされるべきキャラクタの指示情報を受け取るステップと、
前記レンダリングされるべきキャラクタが現在、前記第一の記憶スペース内に記憶されているか否かを判断するステップと、
前記レンダリングされるべきキャラクタが現在前記第一のスペース内に記憶されていなければ、前記レンダリングされるべきキャラクタを前記第一の記憶スペースにロードするステップと、
を含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、
前記アプリケーションはゲームアプリケーションであり、
前記レンダリングされるべきキャラクタは、前記アプリケーションによって二次元空間内に三次元文字として表示され、
前記少なくとも一つのフォントグループに関連する情報は、前記第二の記憶スペース内に記憶された状態で、少なくとも一つのフォントビットマップファイルと、前記少なくとも一つのフォントグループの前記キャラクタに関するメタデータを記憶する少なくとも一つのフォント情報ファイルを含み、
前記第一の記憶スペースは、フォントキャッシュとフォント情報テーブルを含み、
前記フォントキャッシュは、少なくとも一つのキャラクタに関するビットマップ情報を記憶し、前記少なくとも一つのキャラクタに関する前記ビットマップ情報は、前記少なくとも一つのフォントビットマップファイルから取得され、
前記フォント情報テーブルは、前記少なくとも一つの文字に関するメタデータを記憶し、
前記少なくとも一つのキャラクタに関する前記メタデータは、前記少なくとも一つのフォント情報ファイルから取得され、
前記少なくとも一つのキャラクタに関する前記ビットマップ情報と前記メタデータは、前記第一のメモリに記憶された状態で、前記少なくとも一つのキャラクタをレンダリングする際に使用される
ことを特徴とする方法。
【請求項３】
請求項１に記載の方法において、
前記少なくとも一つのフォントグループに関連する情報は、前記第二の記憶スペースに記憶された状態で、
第一のフォントに関する第一のフォントビットマップファイルと、
第二のフォントに関する第二のフォントビットマップファイルと、
前記第一のフォントに関する第一のフォント情報ファイルと、
前記第二のフォントに関する第二のフォント情報ファイルと
を含み、
前記第一の記憶スペースは、フォントキャッシュとフォント情報テーブルを含み、
前記フォントキャッシュは、少なくとも一つのキャラクタに関するビットマップ情報を記憶し、
前記フォント情報テーブルは、前記少なくとも一つのキャラクタに関するメタデータを記憶する
ことを特徴とする方法。
【請求項４】
請求項１に記載の方法において、
前記少なくとも一つのフォントグループは、前記アプリケーションにより、前記第一の記憶スペースから一つのフォントエンティティとしてアクセスされる２つまたはそれ以上のフォントでなるメタフォントを含むことを特徴とする方法。
【請求項５】
請求項１に記載の方法において、
前記第一の記憶スペースは、フォントキャッシュとフォント情報テーブルを含み、前記フォントキャッシュは前記少なくとも一つのフォントグループの前記キャラクタの一部に関するビットマップ情報を記憶し、前記フォント情報テーブルは、前記少なくとも一つのフォントグループの前記キャラクタの一部に関するメタデータを記憶し、前記レンダリングされるべきキャラクタが現在、前記第一の記憶スペースに記憶されているか否かを判断するステップは、
前記レンダリングされるべきキャラクタが現在、前記フォント情報テーブル内に対応するエントリーを持っているか否かを判断するステップと、
前記レンダへリングされるべきキャラクタが現在、前記フォント情報テーブル内に対応するエントリーを持っていれば、前記対応するエントリーのステータスを判断するステップと、
を含むことを特徴とする方法。
【請求項６】
請求項１に記載の方法において、
第一の記憶スペースは、フォントキャッシュとフォント情報テーブルを含み、前記フォントキャッシュは前記少なくとも一つのフォントグループの前記キャラクタの一部に関するビットマップ情報を記憶し、前記フォント情報テーブルは、前記少なくとも一つのフォントグループの前記キャラクタの一部に関するメタデータを記憶し、前記レンダリングされるべきキャラクタが現在、前記第一の記憶スペースに記憶されているか否かを判断するステップは、
前記キャラクタに関連するビットマップ情報を前記フォントキャッシュの中にロードするステップと、
前記キャラクタに関連するメタデータを前記フォント情報テーブル内にロードするステップと、
を含むことを特徴とする方法。
【請求項７】
請求項１に記載の方法において、
前記少なくとも一つのキャラクタをロードする前に、前記第一の記憶スペースから過去にレンダリングされたキャラクタに関する情報を削除し、所定の数のキャラクタを超えないようにするステップをさらに含むことを特徴とする方法。
【請求項８】
請求項１に記載の方法において、
前記フォントに含まれるすべてのキャラクタに関する前記情報は、前記第二の記憶スペースに記憶された状態で、少なくとも一つのフォントビットマップファイルと、前記少なくとも一つのフォントグループ内の前記キャラクタに関するメタデータを記憶する少なくとも一つのフォント情報ファイルを含み、
前記第一の記憶スペースは、フォントキャッシュ、フォント情報テーブルおよび優先待ち行列を含む
ことを特徴とする方法。
【請求項９】
請求項１に記載の方法において、
前記少なくとも一つのフォントグループは、前記アプリケーションによって前記第一の記憶スペースから一つのフォントエンティティとしてアクセスされる２つまたはそれ以上のフォントでなるメタフォントを含み、前記２つまたはそれ以上のフォントのうちの第一のフォントはレンダリング中にオフセットされるキャラクタを含み、前記２つまたはそれ以上のフォントのうちの第二のフォントのキャラクタと外観上の一致性が保たれることを特徴とする方法。
【請求項１０】
テキストを表すのに使用されるキャラクタ情報へのアプリケーションによるアクセスを管理するためのシステムにおいて、前記キャラクタ情報は、一つまたは複数のフォントに編成されたキャラクタを定義し、該システムは、
少なくとも間接的に前記アプリケーションによってアクセスされる記憶媒体であって、一つまたは複数のフォントのすべてのキャラクタに関する情報を記憶する記憶媒体と、
前記一つまたは複数のフォントの所定の数のキャラクタに関する情報を記憶するためのフォントキャッシュシステムであって、前記アプリケーションが、前記記憶媒体からの情報にアクセスする場合より迅速に前記フォントキャッシュシステムからの情報にアクセスできるようにするよう構成されたフォントキャッシュシステムと、
前記フォントキャッシュシステムの内容を管理するよう構成されたフォント管理コンポーネントであって、レンダリングされるべきキャラクタに関するキャラクタ情報が現在、前記フォントキャッシュシステム内に記憶されていないときに、前記記憶媒体からの前記キャラクタ情報を前記フォントキャッシュシステムにロードするフォント管理コンポーネントと、
を備えることを特徴とするシステム。
【請求項１１】
請求項１０に記載のシステムにおいて、
前記記憶媒体は、前記アプリケーションが実行されるコンピュータに関連するハードディスク上のスペースを含むことを特徴とするシステム。
【請求項１２】
請求項１０に記載のシステムにおいて、
前記記憶媒体は、前記アプリケーションが実行されるコンピュータに関連する取り外し可能ディスク上のスペースを含むことを特徴とするシステム。
【請求項１３】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、前記アプリケーションが初期化されたときにインスタンスとして作成されることを特徴とするシステム。
【請求項１４】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、前記一つまたは複数のフォントからの所定の数のキャラクタに関するビットマップ情報を記憶するキャッシュを含むことを特徴とするシステム。
【請求項１５】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、前記一つまたは複数のフォントの中の選択されたキャラクタに関するメタデータを記憶するフォント情報エンティティを含むことを特徴とするシステム。
【請求項１６】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、前記一つまたは複数のフォントの中の選択されたキャラクタに関するオフセットデータを記憶するフォント情報エンティティを含むことを特徴とするシステム。
【請求項１７】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、
前記一つまたは複数のフォントの中の選択されたキャラクタに関するビットマップデータを記憶するよう構成されたキャッシュと、
前記一つまたは複数のフォントの中の選択されたキャラクタに関するオフセットデータを記憶するフォント情報エンティティと、
キャラクタ情報が前記フォントキャッシュシステムに追加され、また前記フォントキャッシュシステムから消去される順序を管理するための優先待ち行列と、
を含むことを特徴とするシステム。
【請求項１８】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、選択された文字が前記フォントキャッシュからアクセス可能か否かに関するステータス情報を記憶するフォント情報エンティティを含むことを特徴とするシステム。
【請求項１９】
コンピュータのメモリ内のキャッシュエンティティを初期化するステップであって、前記キャッシュエンティティは、一つまたは複数のフォントに含まれる所定の数のキャラクタに関する情報を記憶するステップと、
前記一つまたは複数のフォントに関連する情報を、前記コンピュータに関連する記憶スペースに記憶するステップであって、前記記憶スペースは前記コンピュータの前記メモリとは別であり、前記記憶スペースは、前記一つまたは複数のフォントに含まれるすべてのキャラクタに関する情報を記憶するステップと、
前記一つまたは複数のフォントから、レンダリングされるべきキャラクタの指示情報を受け取るステップと、
前記レンダリングされるべきキャラクタが現在、前記キャッシュエンティティ内に記憶されているか否かを判断するステップと、
前記レンダリングされるべきキャラクタが現在、前記キャッシュエンティティ内に記憶されていなければ、前記レンダリングされるべきキャラクタを前記キャッシュエンティティにロードするステップと、
を含む方法をコンピュータが実行するための命令を含むコンピュータ読取可能媒体。
【請求項２０】
前記コンピュータ読取可能媒体は、二次元空間において表示可能な三次元グラフィクスを含むゲームアプリケーションの一部であること特徴とする請求項１９に記載のコンピュータ読取可能媒体。
【請求項１】
コンピュータ内で、キャラクタを表示させるアプリケーションに関連した、少なくとも一つのフォントグループに配列されたキャラクタへのアクセスと表示を管理する方法において、
前記コンピュータ内のメモリにおける第一の記憶スペースを初期化するステップであって、前記第一の記憶スペースは、前記少なくとも一つのフォントグループに含まれる所定の数のキャラクタに関する情報のための記憶を含むステップと、
前記少なくとも一つのフォントグループに関連する情報を前記コンピュータに関連する第二の記憶スペースに記憶するステップであって、前記第二の記憶スペースは、前記コンピュータの前記メモリとは区別され、前記第二の記憶スペースは、前記少なくとも一つのフォントグループに含まれるすべてのキャラクタに関する情報を記憶するステップと、
前記少なくとも一つのフォントグループから、レンダリングされるべきキャラクタの指示情報を受け取るステップと、
前記レンダリングされるべきキャラクタが現在、前記第一の記憶スペース内に記憶されているか否かを判断するステップと、
前記レンダリングされるべきキャラクタが現在前記第一のスペース内に記憶されていなければ、前記レンダリングされるべきキャラクタを前記第一の記憶スペースにロードするステップと、
を含むことを特徴とする方法。
【請求項２】
請求項１に記載の方法において、
前記アプリケーションはゲームアプリケーションであり、
前記レンダリングされるべきキャラクタは、前記アプリケーションによって二次元空間内に三次元文字として表示され、
前記少なくとも一つのフォントグループに関連する情報は、前記第二の記憶スペース内に記憶された状態で、少なくとも一つのフォントビットマップファイルと、前記少なくとも一つのフォントグループの前記キャラクタに関するメタデータを記憶する少なくとも一つのフォント情報ファイルを含み、
前記第一の記憶スペースは、フォントキャッシュとフォント情報テーブルを含み、
前記フォントキャッシュは、少なくとも一つのキャラクタに関するビットマップ情報を記憶し、前記少なくとも一つのキャラクタに関する前記ビットマップ情報は、前記少なくとも一つのフォントビットマップファイルから取得され、
前記フォント情報テーブルは、前記少なくとも一つの文字に関するメタデータを記憶し、
前記少なくとも一つのキャラクタに関する前記メタデータは、前記少なくとも一つのフォント情報ファイルから取得され、
前記少なくとも一つのキャラクタに関する前記ビットマップ情報と前記メタデータは、前記第一のメモリに記憶された状態で、前記少なくとも一つのキャラクタをレンダリングする際に使用される
ことを特徴とする方法。
【請求項３】
請求項１に記載の方法において、
前記少なくとも一つのフォントグループに関連する情報は、前記第二の記憶スペースに記憶された状態で、
第一のフォントに関する第一のフォントビットマップファイルと、
第二のフォントに関する第二のフォントビットマップファイルと、
前記第一のフォントに関する第一のフォント情報ファイルと、
前記第二のフォントに関する第二のフォント情報ファイルと
を含み、
前記第一の記憶スペースは、フォントキャッシュとフォント情報テーブルを含み、
前記フォントキャッシュは、少なくとも一つのキャラクタに関するビットマップ情報を記憶し、
前記フォント情報テーブルは、前記少なくとも一つのキャラクタに関するメタデータを記憶する
ことを特徴とする方法。
【請求項４】
請求項１に記載の方法において、
前記少なくとも一つのフォントグループは、前記アプリケーションにより、前記第一の記憶スペースから一つのフォントエンティティとしてアクセスされる２つまたはそれ以上のフォントでなるメタフォントを含むことを特徴とする方法。
【請求項５】
請求項１に記載の方法において、
前記第一の記憶スペースは、フォントキャッシュとフォント情報テーブルを含み、前記フォントキャッシュは前記少なくとも一つのフォントグループの前記キャラクタの一部に関するビットマップ情報を記憶し、前記フォント情報テーブルは、前記少なくとも一つのフォントグループの前記キャラクタの一部に関するメタデータを記憶し、前記レンダリングされるべきキャラクタが現在、前記第一の記憶スペースに記憶されているか否かを判断するステップは、
前記レンダリングされるべきキャラクタが現在、前記フォント情報テーブル内に対応するエントリーを持っているか否かを判断するステップと、
前記レンダへリングされるべきキャラクタが現在、前記フォント情報テーブル内に対応するエントリーを持っていれば、前記対応するエントリーのステータスを判断するステップと、
を含むことを特徴とする方法。
【請求項６】
請求項１に記載の方法において、
第一の記憶スペースは、フォントキャッシュとフォント情報テーブルを含み、前記フォントキャッシュは前記少なくとも一つのフォントグループの前記キャラクタの一部に関するビットマップ情報を記憶し、前記フォント情報テーブルは、前記少なくとも一つのフォントグループの前記キャラクタの一部に関するメタデータを記憶し、前記レンダリングされるべきキャラクタが現在、前記第一の記憶スペースに記憶されているか否かを判断するステップは、
前記キャラクタに関連するビットマップ情報を前記フォントキャッシュの中にロードするステップと、
前記キャラクタに関連するメタデータを前記フォント情報テーブル内にロードするステップと、
を含むことを特徴とする方法。
【請求項７】
請求項１に記載の方法において、
前記少なくとも一つのキャラクタをロードする前に、前記第一の記憶スペースから過去にレンダリングされたキャラクタに関する情報を削除し、所定の数のキャラクタを超えないようにするステップをさらに含むことを特徴とする方法。
【請求項８】
請求項１に記載の方法において、
前記フォントに含まれるすべてのキャラクタに関する前記情報は、前記第二の記憶スペースに記憶された状態で、少なくとも一つのフォントビットマップファイルと、前記少なくとも一つのフォントグループ内の前記キャラクタに関するメタデータを記憶する少なくとも一つのフォント情報ファイルを含み、
前記第一の記憶スペースは、フォントキャッシュ、フォント情報テーブルおよび優先待ち行列を含む
ことを特徴とする方法。
【請求項９】
請求項１に記載の方法において、
前記少なくとも一つのフォントグループは、前記アプリケーションによって前記第一の記憶スペースから一つのフォントエンティティとしてアクセスされる２つまたはそれ以上のフォントでなるメタフォントを含み、前記２つまたはそれ以上のフォントのうちの第一のフォントはレンダリング中にオフセットされるキャラクタを含み、前記２つまたはそれ以上のフォントのうちの第二のフォントのキャラクタと外観上の一致性が保たれることを特徴とする方法。
【請求項１０】
テキストを表すのに使用されるキャラクタ情報へのアプリケーションによるアクセスを管理するためのシステムにおいて、前記キャラクタ情報は、一つまたは複数のフォントに編成されたキャラクタを定義し、該システムは、
少なくとも間接的に前記アプリケーションによってアクセスされる記憶媒体であって、一つまたは複数のフォントのすべてのキャラクタに関する情報を記憶する記憶媒体と、
前記一つまたは複数のフォントの所定の数のキャラクタに関する情報を記憶するためのフォントキャッシュシステムであって、前記アプリケーションが、前記記憶媒体からの情報にアクセスする場合より迅速に前記フォントキャッシュシステムからの情報にアクセスできるようにするよう構成されたフォントキャッシュシステムと、
前記フォントキャッシュシステムの内容を管理するよう構成されたフォント管理コンポーネントであって、レンダリングされるべきキャラクタに関するキャラクタ情報が現在、前記フォントキャッシュシステム内に記憶されていないときに、前記記憶媒体からの前記キャラクタ情報を前記フォントキャッシュシステムにロードするフォント管理コンポーネントと、
を備えることを特徴とするシステム。
【請求項１１】
請求項１０に記載のシステムにおいて、
前記記憶媒体は、前記アプリケーションが実行されるコンピュータに関連するハードディスク上のスペースを含むことを特徴とするシステム。
【請求項１２】
請求項１０に記載のシステムにおいて、
前記記憶媒体は、前記アプリケーションが実行されるコンピュータに関連する取り外し可能ディスク上のスペースを含むことを特徴とするシステム。
【請求項１３】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、前記アプリケーションが初期化されたときにインスタンスとして作成されることを特徴とするシステム。
【請求項１４】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、前記一つまたは複数のフォントからの所定の数のキャラクタに関するビットマップ情報を記憶するキャッシュを含むことを特徴とするシステム。
【請求項１５】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、前記一つまたは複数のフォントの中の選択されたキャラクタに関するメタデータを記憶するフォント情報エンティティを含むことを特徴とするシステム。
【請求項１６】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、前記一つまたは複数のフォントの中の選択されたキャラクタに関するオフセットデータを記憶するフォント情報エンティティを含むことを特徴とするシステム。
【請求項１７】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、
前記一つまたは複数のフォントの中の選択されたキャラクタに関するビットマップデータを記憶するよう構成されたキャッシュと、
前記一つまたは複数のフォントの中の選択されたキャラクタに関するオフセットデータを記憶するフォント情報エンティティと、
キャラクタ情報が前記フォントキャッシュシステムに追加され、また前記フォントキャッシュシステムから消去される順序を管理するための優先待ち行列と、
を含むことを特徴とするシステム。
【請求項１８】
請求項１０に記載のシステムにおいて、
前記フォントキャッシュシステムは、選択された文字が前記フォントキャッシュからアクセス可能か否かに関するステータス情報を記憶するフォント情報エンティティを含むことを特徴とするシステム。
【請求項１９】
コンピュータのメモリ内のキャッシュエンティティを初期化するステップであって、前記キャッシュエンティティは、一つまたは複数のフォントに含まれる所定の数のキャラクタに関する情報を記憶するステップと、
前記一つまたは複数のフォントに関連する情報を、前記コンピュータに関連する記憶スペースに記憶するステップであって、前記記憶スペースは前記コンピュータの前記メモリとは別であり、前記記憶スペースは、前記一つまたは複数のフォントに含まれるすべてのキャラクタに関する情報を記憶するステップと、
前記一つまたは複数のフォントから、レンダリングされるべきキャラクタの指示情報を受け取るステップと、
前記レンダリングされるべきキャラクタが現在、前記キャッシュエンティティ内に記憶されているか否かを判断するステップと、
前記レンダリングされるべきキャラクタが現在、前記キャッシュエンティティ内に記憶されていなければ、前記レンダリングされるべきキャラクタを前記キャッシュエンティティにロードするステップと、
を含む方法をコンピュータが実行するための命令を含むコンピュータ読取可能媒体。
【請求項２０】
前記コンピュータ読取可能媒体は、二次元空間において表示可能な三次元グラフィクスを含むゲームアプリケーションの一部であること特徴とする請求項１９に記載のコンピュータ読取可能媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【公開番号】特開２００６−２０９１０８（Ｐ２００６−２０９１０８Ａ）
【公開日】平成１８年８月１０日（２００６．８．１０）
【国際特許分類】
【出願番号】特願２００６−３９５５（Ｐ２００６−３９５５）
【出願日】平成１８年１月１１日（２００６．１．１１）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
【公開日】平成１８年８月１０日（２００６．８．１０）
【国際特許分類】
【出願日】平成１８年１月１１日（２００６．１．１１）
【出願人】（５０００４６４３８）マイクロソフト コーポレーション (3,165)
【Ｆターム（参考）】
[ Back to top ]