JP4817792B2

JP4817792B2 - テクスチャベースのピクセルパッキング

Info

Publication number: JP4817792B2
Application number: JP2005299093A
Authority: JP
Inventors: スコットウェッツェルマイケル; オースティンマイケル
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2004-11-02
Filing date: 2005-10-13
Publication date: 2011-11-16
Anticipated expiration: 2025-10-13
Also published as: JP2006134309A

Description

３次元グラフィックスをレンダリングするための方法に関する。

コンピュータグラフィックスの進歩により、２次元空間（例えばコンピュータ画面またはモニタ）での３次元グラフィカルオブジェクト（例えばビデオゲームにおけるキャラクタ）の表示が可能となった。ビデオゲームおよび３次元グラフィックスを使用するその他のアプリケーションは、ユーザにとってかなり真に迫って見える、ユーザの体験をおもしろくする物である。３次元グラフィックスを生成するための技法の１つにテクスチャの使用が含まれる。テクスチャとは、通常は、シーンの３次元レンダリングにおいて普通であれば平坦なジオメトリで描画する際に、実世界のテクスチャ細部（例えば木、穀類、カーペット、など）をシミュレートするために使用される２次元のビットマップである。いくつかのケースでは、テクスチャは複数の２次元ピクセルで構成される。各ピクセルは位置、カラー、輝度、および深さのプロパティを有する。テクスチャはいったん作成されると、テキストまたは記号を提示するイメージを含む多くのタイプのイメージをレンダリングするために使用することができる。テクスチャはテキストを必要に応じて容易に投影、拡大縮小、および回転することができるため、２次元テキストをレンダリングするためにテクスチャを使用することは、一般に、他のテキストレンダリング技法全体にわたって望ましい。

ビデオゲームは視覚的に目立つものでなければ売れないため、１つのシーンで複数の魅力的なフォントが使用されることが望ましい。したがって、アプリケーション（例えば３次元ビデオゲーム）でのテキストレンダリングで使用するための単一のテクスチャは、大規模セットのグリフ（例えばある種のフォントまたはテキストのスタイルに付随するテキスト文字、記号、および／またはイメージ）を含むことができる。いくつかのケースでは、グリフは個別に色付けするか、あるいはアウトラインが黒の白文字、黒のドロップシャドウ、および／またはアンチエイリアシング効果とすることができる。アウトラインおよびドロップシャドウ機能は、典型的には、特に背景カラーによってそれほどコントラストが得られない場合に低解像度ディスプレイ（例えばテレビジョン）上での読みやすさを改善する。アンチエイリアシングは、ピクセルが生成したラインの階段状のギザギザ効果を削減し、グリフのアウトライン近くにグレーまたは淡い色のピクセルを使用することを含む。図１は、アンチエイリアシング、アウトライニング、およびドロップシャドウ機能を使用したグリフ１０２の一例を示す図である。こうした機能を組み合わせるために、テクスチャビットマップ内の各ピクセルは、各カラーチャネル（例えば赤、緑、青）につき８ビット、透明因子として使用されるアルファチャネルに８ビットの、通常３２ビットである。ほとんどのケースでは、中規模サイズセットのグリフは２５６×２５６テクスチャビットマップに収まる。図１は、５１２×２５６テクスチャビットマップ１０４の一例も示す。

テクスチャからのテキストレンダリングは、通常、所望のグリフがテクスチャ内に常駐する場合に適合するテクスチャ座標のセットを選択することを含む（例えば文字「Ｇ」を構成する座標）。より複雑なシステムでは、フォント用の組込みサポートおよび同様のテキストレンダリングソリューションが、アプリケーションエンドでのテキストレンダリングを簡略化する。しかしながら、こうした組込みソリューションが必ずしもビデオゲームのコンテキストで使用できるとは限らない。例えば、現世代のビデオゲームコンソースにはフォント用の組込みサポートがない。同様に、パーソナルコンピュータ用に開発されたゲームは、典型的な場合では、通常はパーソナルコンピュータのオペレーティングシステムによって提供されるテキストレンダリングソリューションよりも高性能のテキストレンダリングソリューションを必要とする。

これらの理由により、現在のビデオゲームはしばしばそれら自体のテキストレンダリングサポートを提供している。ビデオゲームでのテキストレンダリングには主に２つの方法がある。第１の方法では、コンピュータまたはコンソールのＣＰＵがレンダリングターゲットに直接ビットを書き込む。この技法はテキストを業界標準のトゥルータイプフォントファイルでレンダリングできるようにするものであるが、高いメモリの使用率および性能に関する多数の致命的な欠点がある。例えば、すべてのビデオゲームコンソールがこうした潜在的に大規模なフォントファイルに充てるだけの十分なメモリを持っているわけではないため、ＣＰＵはしばしばファイルのキャッシュという手段に頼り、これがさらにランタイム性能を損なうことになる。さらに、ほとんどのＣＰＵはビットマップのレンダリングにはあまり適していない。例えば典型的なＣＰＵのフォントのレンダリングは、グラフィックス処理ユニット（ＧＰＵ）よりも１００から１０００倍遅い。

第２の方法は、フォントをビットマップ化されたテクスチャとして格納し、個々のグリフをスクリーン空間整合クワッド（ｓｃｒｅｅｎ−ｓｐａｃｅａｌｉｇｎｅｄｑｕａｄｓ）として（例えば、ＧＰＵのテクスチャラスタライザを使用して）レンダリングする。この技法は、ＧＰＵの本来の機能を使用して、ＧＰＵに関連付けられたハードウェアの最高フィルレート（ｆｕｌｌｆｉｌｌｒａｔｅ）（１秒当たりのピクセル数で測定）でビットマップベースのフォントをレンダリングする。この技法の制限の１つは、大規模文字セット（例えばユニコード文字セット）で使用される場合、現在のハードウェア機能を超え大量のメモリを使用するテクスチャサイズを必要とする可能性があることである。

現在のテキストレンダリング技法に伴う問題は、国際市場向けのビデオゲームを作成する場合に悪化する。例えば、中国語テキストを含むゲームは約５０００〜８０００のグリフを必要とする場合がある。各グリフが事前にテクスチャビットマップの２０×２０ピクセルセクションにレンダリングされた場合、全体のテクスチャビットマップは１８００×１８００ピクセル、すなわち３．２４Ｍピクセルとなる。ほとんどのゲームコンソールは限られた量のテクスチャフォーマットしかサポートしていないため、１ピクセル当たり８ビットのテクスチャを使用している場合、最低スペース要件は３．２４ＭＢである。１ピクセル当たり１６ビットのテクスチャ（赤、緑、青、およびアルファチャネルのそれぞれにつき４ビット）では、最低スペース要件は６．４８ＭＢである。典型的なビデオゲームコンソールには約３２〜６４ＭＢの物理メモリおよび約２６〜５８ＭＢの使用可能メモリしかないため、このように多くのメモリをテキストおよびフォントに充てるのは不合理である。

本発明の目的は、テキストを含む３次元グラフィックスをレンダリングするための方法およびシステムを提供することにある。

テキストを含む３次元グラフィックスをレンダリングするための方法およびシステムは、未圧縮のテクスチャビットマップを圧縮することができる。圧縮されたテクスチャビットマップは、テキスト記号および他のグリフをレンダリングする際に使用可能な出力ピクセルにアンパック可能な値を含む。圧縮されたテクスチャビットマップの各ピクセルは、複数の別個の記号に対応する圧縮されたピクセルに関する値を含む複数の値に関する情報を格納する。例えば、圧縮されたテクスチャビットマップは、それぞれがｍ個までの値（例えば４つの値）を格納するｎビットサイズのピクセル（例えば１６ビットピクセル）を有することができる。ｍ個の値はそれぞれｎ／ｍビット（例えば４ビット）までのサイズの圧縮された値を有することができる。例えばピクセルに関連付けられた別個の赤、緑、青、およびアルファ（ＲＧＢＡ）チャネルを使用して、複数の値を単一のピクセルに格納する。

圧縮されたテクスチャビットマップは、典型的にはビット単位演算を実行しないピクセルシェーダ（ｓｈａｄｅｒ）などの従来のピクセルシェーダによってアンパックするように構成する。アンパッキングには、ピクセルシェーダ内でマスキングオペレーションを使用して所望の値に関連付けられたピクセルを分離することが含まれる場合がある。

本発明の他の実施形態では、圧縮されたテクスチャビットマップは、それぞれがｎ／ｍビット（例えば２ビット値）のサイズを有するｍ個（例えば４個）の圧縮された値を格納するｎビットサイズのピクセル（例えば８ビットピクセル）を有することができる。圧縮されたテクスチャビットマップは、典型的にはビット単位演算を実行しないピクセルシェーダなどの従来のピクセルシェーダによってアンパックするように構成することができる。例えばアンパッキングは、取り出された８ビットピクセルを、２５６カラーパレットからの３２ビット値などのルックアップテーブルのマッピング値とマッチングさせることを含むことができる。ルックアップされたマッピング値は、ピクセルシェーダによる処理を容易にするために別々のサブ値（ｓｕｂ−ｖａｌｕｅ）に分けることができる。例えばルックアップされた値を、従来はカラーピクセルの処理に使用されたＲＧＢＡ値に分割する。

本発明の他の実施形態では、圧縮されたテクスチャビットマップは、それぞれｎ個の１ビット値を格納するｎビットサイズのピクセル（例えば８ビットピクセル）のピクセルを有する。圧縮されたテクスチャビットマップは、典型的にはビット単位演算を実行しないピクセルシェーダなどの従来のピクセルシェーダによってアンパックするように構成する。アンパッキングは、取り出されたピクセルを、２５６カラーパレットからの３２ビット値などのルックアップテーブルのマッピング値とマッチングさせることを含む。ルックアップ値は、ピクセルシェーダによる処理を容易にするために別々のサブ値に分けることができる。例えば、ルックアップされた値を、従来はカラーピクセルの処理に使用されたＲＧＢＡ値に分割する。

図面では、同じ参照番号は同一またはほぼ同様の要素または動作を識別する。任意の特定要素または動作についての説明を容易にするために、参照番号における最上位桁はその要素が最初に紹介された図面番号を示す（例えば要素２０４は図２に関して最初に紹介および説明された）。

本開示の一部には、著作権が主張される資料が含まれる。特許文書または特許開示（図面を含む）が特許商標庁内の特許ファイルまたは記録に掲載されている場合、著作権所有者はいかなる人物によるその複製に対しても異議を唱えることはないが、いかなる他のすべての著作権をも所有する。

次に、本発明について様々な実施形態に関して説明する。以下の説明では、本発明のこれらの実施形態を完全に理解するため、およびこれについての説明を可能にするために、特定の細部を提供する。しかしながら当業者であれば、本発明がこれらの細部なしでも実施可能であることを理解されよう。他の場合では、本発明の諸実施形態の説明を不必要にあいまいにしないために、良く知られた構造および機能については詳細に図示または説明していない。

提示された説明で使用される用語は、たとえ本発明のある特定の実施形態の詳細な説明に関して使用されている場合であっても、その最も広範な妥当な形で解釈されることを意図している。たとえある用語が以下で強調されることがあっても、いずれかの制約された形で解釈されるように意図される用語は、この発明を実施するための最良の形態のセクションで定義されるように明白および明確に定義されることになる。

Ｉ．概要
本明細書で説明される方法およびシステムは、テキスト、記号、および他のグリフをレンダリングする際に使用されるフォントテクスチャを表すために使用されるビットマップをパックおよびアンパックすることができる。アプリケーションはこうした技法を使用して、アプリケーションを実行中のハードウェアによって提供されるメモリリソースに過度の負担をかけることなく、非常に大きなサイズのグリフセットを提供することができる。例えばいくつかの実施形態では、フォントパッキングツールは１ピクセル当たり１６ビットのフォントビットマップを（スクリーンまたは他のディスプレイデバイス上に表示するための１つの出力ピクセルを生成するために使用される情報を含むソースピクセルと共に）１ピクセル当たり４ビットに圧縮する。他の実施形態では、フォントパッキングツールは１ピクセル当たり８ビットのフォントビットマップを１ピクセル当たり２ビットに圧縮する。さらに他の実施形態では、フォントパッキングツールは１ピクセル当たり８ビットのフォントビットマップを１ピクセル当たり１ビットに圧縮する。この方法およびシステムは、従来のピクセルシェーダを含むグラフィックス処理ユニットを介して、圧縮されたフォントビットマップをアンパックすることもできる。

ＩＩ．代表的なシステム
図２および以下の説明では、本発明が実施可能な代表的環境について簡単に概要を述べる。必須ではないが、本発明の諸態様は、汎用コンピュータ（例えばサーバコンピュータ、無線デバイス、またはパーソナル／ラップトップコンピュータ）によって実行されるルーチンなどのコンピュータ実行可能命令との関連において説明される。関連技術業者であれば、本発明が他の通信、データ処理、または、インターネットアプライアンス、ハンドヘルドデバイス（携帯情報端末（ＰＤＡ）を含む）、ウェアラブルコンピュータ、あらゆる種類のセルラー式電話または移動電話、埋込み型コンピュータ（車両に結合された物を含む）、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家庭用電化製品、セットトップボックス、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、およびその他を含む、コンピュータシステム構成で実施可能であることを理解されよう。実際には、「コンピュータ」、「ホスト」、および「ホストコンピュータ」という用語は一般に同義的に使用され、上記のデバイスおよびシステムのうちのいずれか、ならびに任意のデータプロセッサを指すものでる。

本発明の諸態様は、本明細書で詳細に説明する１つまたは複数のコンピュータ実行可能命令を実行するように特別にプログラム、構成、または構築された、特定用途向けコンピュータまたはデータプロセッサで具体化することが可能である。本発明の諸態様は、タスクまたはモジュールが通信ネットワークを介してリンクされたリモート処理デバイスによって実行される、分散コンピューティング環境でも実施可能である。分散コンピューティング環境では、プログラムモジュールをローカルおよびリモートの両方のメモリストレージデバイスに配置することができる。

本発明の諸態様は、磁気または光学式の読み取り可能コンピュータディスクを含むコンピュータ読取り可能媒体上で、半導体メモリ、ナノテクノロジーメモリ、有機または光メモリ、あるいは他のポータブルデータストレージ媒体上のマイクロコードとして、格納または配布することができる。実際には、本発明の諸態様の下でのコンピュータ実施命令、データ構造、スクリーン表示、および他のデータは、インターネットを介すかまたは他のネットワーク（無線ネットワークを含む）を介して、ある期間にわたって伝播媒体（例えば電磁波、音波など）上で伝播される信号で配布可能であるか、あるいは、任意のアナログまたはデジタルネットワーク（パケット交換、回路交換、または他のスキーム）提供可能である。関連技術業者であれば、本発明の一部がサーバコンピュータに常駐する一方で、対応する部分は移動デバイスなどのクライアントコンピュータ上に常駐することを理解されよう。

図２を参照すると、テクスチャのパッキングおよびアンパッキング技法が実施可能な代表的環境に、ゲームコンソール２００が含まれる。ゲームコンソールはＣＰＵ２０２、データストア２０４、メモリ２０６、オーディオ／ビデオポート２０８、イーサネット（登録商標）ポート２１０、電源ポート２１２、および１つまたは複数のコントローラポート２１４を含むことができる。加えてゲームコンソール２００は、ピクセルシェーダ２２０を含むグラフィックス処理ユニット（ＧＰＵ）構成要素２１６を含むことができる。ピクセルシェーダ２２０は従来型設計であってもよい。例えばこれは、ビット単位演算があればいくつかを提供することが可能であり、限定命令セットを使用して制御することができる。

一部の実施形態では、ＧＰＵ構成要素２１６は、ゲームコンソール２００上で実行するゲームアプリケーション２１８によって提供されるパックおよびアンパック済みのテクスチャを処理する。例示された実施形態のゲームアプリケーション２１８は、パック済みフォントテクスチャ２２６を含む。一部の実施形態では、パック済みフォントテクスチャ２２６はゲームアプリケーションの開発時に作成される。ゲームアプリケーションの設計者は、パッキングツール２２４を含む設計システム２２２を使用して、パック済みフォントテクスチャ２２６を生成することができる。図に示されるように、ゲーム設計システム２２２はゲームコンソールの外部にある。

パック済みフォントテクスチャ２２６はビットマップ形式とすることが可能であり、グリフのセット（例えばテキスト文字、記号など）を含むことができる。出力される場合、各グリフは、各ソースピクセルがスクリーンまたは他のディスプレイデバイス上で表示するための１つの出力ピクセルを生成するために使用される情報を含む、複数のピクセルで構成することができる。ビットマップそれ自体は、各ピクセルが複数のチャネルを有する複数のピクセルで構成される。この構成により、ビットマップの各ピクセルが複数の値を保持または表すことができる。例えば本明細書でさらに説明するように、パック済みフォントテクスチャ２２６のいくつかのピクセルは、複数の４ビット値、複数の２ビット値、または複数の１ビット値さえも含むことが可能である。したがって、ディスプレイ画面上でビットマップとして表示された場合、パック済みフォントテクスチャ２２６は複数の重複するグリフを有するように見える場合がある。

出力ピクセルを生成するためのソースピクセルの処理を容易にするために、ＧＰＵ構成要素２１６は、テクスチャのアンパックに使用される値を格納するいくつかのレジスタを含むことができる。例えばＧＰＵ構成要素２１６は、アンパック時にテクスチャからピクセルシェーダ２２０によって取り出されたピクセルを格納するためのｔ０レジスタ２２８を含むことができる。一部の実施形態では、ｔ０レジスタ２２８はピクセルの様々なチャネルに関する情報を分離するためのスペースを含む。同様に、ＧＰＵ構成要素２１６は、ピクセル情報を格納するためのｒ０レジスタ２３０を含むこともできる。ｔ０レジスタ２２８と同様に、ｒ０レジスタ２３０はピクセルに関する別々の値を格納するためのスペースを含むことができる。加えてＧＰＵは、アンパック時に使用される定値（例えばマスク値）を格納するためのｃ０レジスタ２３２およびｃ１レジスタ２３４も含むことができる。ＧＰＵ構成要素２１６は、現在のピクセルに関する補間済み頂点カラー値を格納するｖ０レジスタ２３６も含むことができる。この方法では、ピクセルシェーダ２２０は取り出されて伸張された任意のピクセルにカラー値を割り当てることができる。ＧＰＵ構成要素２１６は他のレジスタ（例えば命令レジスタ）（図示せず）を含むことができる。

本発明を実施するための最良の形態の以下のセクションでは、テクスチャのパッキングおよびアンパッキングの例について説明する。例えば、１６ビットから４ビットへの圧縮、８ビットから２ビットへの圧縮、および８ビットから１ビットへの圧縮に関して説明する。例は、ブロック図、ディスプレイ図、および流れ図の組合せを使用して例示される。これらの図は、可能なデータ構造、構成、フォーマット、およびルーチンをすべて示してはいない代わりに、システム内でのテクスチャのパッキングおよびアンパッキングを理解することができる。関連技術業者であれば、いくつかのデータ構造、構成、フォーマット、およびルーチンが反復、変更、省略、または補足可能であること、および図示されていない他の諸態様が容易に実施可能であることを理解されよう。

ＩＩＩ．テクスチャの圧縮
（１）１ピクセル当たり１６ビットから１ピクセル当たり４ビットへの圧縮
図３〜６は、アンチエイリアシング、ドロップシャドウイング、およびアウトライニングなどの機能を依然として保持しながら、４ビットに圧縮可能なピクセルを有するフォントテクスチャを、パッキングおよびアンパッキングするための技法に対応する。一般に、１ピクセル当たり１６ビットのテクスチャは、カラフルなテキストを有する、および／またはカスタム描画機能をフォント（例えば矢印、グラフィックスなど）に埋め込む、アプリケーションに使用される。こうしたテクスチャは様々なフォーマットを使用して構成することができる。こうしたフォーマットの一例が、ピクセルの各チャネル（例えば赤、緑、青、アルファ）に４ビットが割り当てられた、ＭｉｃｒｏｓｏｆｔのＤｉｒｅｃｔＸ８クラスハードウェアが提供するフォーマットである。このフォーマットは赤に独立した１６の値、緑に１６、というようにすることが可能であり、アーティストの色付けイメージを含むほとんどのカラーイメージに十分である。

図３は、１ピクセル当たり１６ビットのテクスチャを１ピクセル当たり４ビットにパッキングするためのルーチン３００の一例を示す図である。図６のアンパッキングルーチン６００などの補助的なアンパッキングルーチンと共に使用した場合、パッキングルーチン３００はオリジナルテクスチャの望ましい機能（例えばアンチエイリアシング、アウトライニング、およびドロップシャドウイング）を保持しながら、カラーフォントを使用することができる。加えてパッキングルーチン３００は、同じテクスチャビットマップ内で事前色付け済み／カスタムのグリフを可能にすることができる（しかしながら、一部の実施形態では、こうした事前色付け済み／カスタムのグリフは１ピクセル当たり１６ビットのフォーマットのままである）。一部の実施形態では、パッキングルーチン３００の一部はビット単位演算を実行するパッキングツールによって実行される。

パッキングルーチン３００は、黒または透明は黒に、白は白に、カラーはグレーの陰影として表わすグレースケールを使用して、テクスチャビットマップをパックする。一般にパッキングルーチン３００は、白のピクセルが白からグレー、そして黒へと（対応する輝度値に基づいて）フェードし、黒のピクセルは黒から半不透明（ｓｅｍｉ−ｏｐａｑｕｅ）、そして透明へとフェードすると想定する。１６ビットの黒、白、およびグレーのピクセルの場合、ピクセルの赤、緑、青（ＲＧＢ）のチャネルは同一の値（例えば白の場合（１５，１５，１５））を含み、これは、任意の１つのグレーピクセルのグレースケール値（輝度）を表すために単一の４ビットＲＧＢ値（１０進数０〜１５の範囲）のみが必要であることを意味する。一部の実施形態では、基礎となる頂点に格納されたカラー情報がリアルタイムレンダリングシステムで使用される変調技法を使用して、アンパッキング時に適切なカラー情報をグレーピクセルに加えることができる。

このスキームに従って、パッキングルーチン３００は、以下のようにグリフ内の１６ビットピクセルそれぞれに４つのビットを割り振ることができる。ルーチン３００は、白／グレーピクセルまたは黒／透明ピクセルのいずれかを表すために第１のビットを割り振る。ルーチン３００は、グレースケールの輝度に関する情報（白／グレーピクセルの場合）またはアルファ透明度に関する情報（黒／透明ピクセルの場合）のいずれかを表すために、第２、第３、および第４のビットを割り振る。このフォーマットの一例が図４に関して示されている。

図３に戻って参照すると、一部の実施形態ではパッキングルーチン３００がブロック３０１で開始され、オリジナルテクスチャから第１のグリフを取り出す。意思決定ブロック３０２で、パッキングルーチン３００は取り出したグリフをチェックして、事前色付け済み／カスタムのグリフであるかどうかを判定する。意思決定ブロック３０２で、取り出したグリフが事前色付け済み／カスタムのグリフである場合、ルーチン３００はブロック３０３へ進み、パッキングルーチン３００は圧縮されていないグリフをその１６ビット形式（パッキングなし）で出力テクスチャに埋め込み、グリフがパックされていないことを示すフラグを設定する。パッキングルーチン３００はブロック３０３からブロック３１１へと進み、オリジナルテクスチャが取り出すための残りのグリフを含むかどうかを判定する。

しかしながら、意思決定ブロック３０２で取り出したグリフが事前色付け済み／カスタムのグリフに関連付けられていない場合、パッキングルーチン３００はブロック３０４へ進み、取り出したグリフの次のピクセルを取り出す。次のピクセルを取り出した後、ルーチン３００は意思決定ブロック３０５へ進み、取り出したピクセルのＲＧＢ値がすべてゼロに等しい（取り出したピクセルが黒または透明であることを意味する）かどうかをチェックした後、パッキングルーチン３００はブロック３０６へ進み、４つの使用可能ピクセルビットのうちの最初のビットをゼロに設定する。次にブロック３０７でパッキングルーチン３００は、取り出したピクセルのアルファ値に従って次の３つのピクセルビットを設定する。例えば、取り出したピクセルのアルファ値がゼロの場合（例えば完全に半透明なピクセルの場合）、パッキングルーチン３００は次の３つのピクセルビットを（０，０，０）に設定する。しかしながら、取り出した値のアルファ値がゼロよりも大きい場合、ルーチンは取り出したピクセルの４ビットアルファ値の３つの最上位ビットに従って、次の３つのピクセルビットを００１〜１１１の範囲内の２進アルファ値を使用して設定する。（後に、アンパッキングルーチンがこれら３つのビットを１スペース左へシフトし、２進の１１１１または１０進の１５（すなわち非半透明の黒のピクセル）のうちの最大アルファ値を可能にする。）その後、パッキングルーチン３００は意思決定ブロック３１０へ進み、オリジナルテクスチャがフェッチするビットをさらに有するかどうかをチェックする。

しかしながら、意思決定ブロック３０５で取り出したピクセルのＲＧＢ値がゼロより大きい場合（取り出したピクセルが白またはカラーであることを意味する）、パッキングルーチン３００はブロック３０８へと進み、４つの使用可能ピクセルビットのうちの最初のビットを１に等しく設定する。次にブロック３０９でパッキングルーチン３００は、残りの３つのピクセルビットを２進の０００〜１１１の範囲内の輝度値を表すように設定する。パッキングルーチン３００は、オリジナルの１６ビットピクセルそれぞれを白、グレー、またはブロックのいずれかであるように扱うため、各ピクセルについてＲＧＢ値は同一である（例えば、赤＝１１１０、緑＝１１１０、青＝１１１０）。したがって、割り当てられた３ビットの輝度値が、任意の所与のピクセルに関する３つの４ビットＲＧＢ値のうちのいずれかの３つの最上位ビットにほぼ対応することができる。フォントテクスチャのアンパック時に、これらのビットを１スペース左へシフトし、オリジナルの１６ビットピクセルの４ビットＲＧＢ値をマッチングさせることができる。

上記ステップの結果として、オリジナルテクスチャからの１６ビットピクセルを新しいテクスチャの４つのビットに格納することができる。例えば、パッキングルーチン３００は、新しい１６ビットテクスチャの１つのピクセルに対応する単一のチャネル（例えば赤、緑、青、またはアルファ）に割り当てることによって、４ビットピクセルを新しい１ピクセル当たり１６ビットのテクスチャビットマップに埋め込むことができる。

その後ルーチン３００は意思決定ブロック３１０へ進み、グリフに関して取り出す追加のピクセルがあるかどうかをチェックする。意思決定ブロック３１０で取り出す追加のピクセルがある場合、ルーチン３００は次のピクセルを取り出すために折り返してブロック３０４へ戻る。そうでない場合、ルーチンは意思決定ブロック３１１へ進み、取り出す追加のグリフがテクスチャ内にあるかどうかを判定する。この決定に基づいて、ルーチン３００は終了する（取り出す追加のグリフがない場合）か、または次のグリフを取り出すために折り返してブロック３０１に戻る。

図５に示されるように、１ピクセル当たり１６ビット５０２でパッキングルーチン３００を実行すると、各グリフが使用可能な各ピクセルの固有の４ビットチャネルを占有する、一連の重複したグリフとして表される新しいテクスチャビットマップ５０４を生じる結果となる。しかしながら図に示されるように、カスタムまたは事前色付け済みのグリフに対応する任意のピクセルは、４つのチャネルすべてを使用する１６ビットフォーマットのままである可能性がある。

図５のテクスチャビットマップ５０４などの圧縮済みテクスチャビットマップをアンパックするためのルーチンの一例が、図６に示される。アンパッキングルーチン６００は、圧縮済みテクスチャを含むアプリケーション（例えばビデオゲームアプリケーション）から命令を受け取るピクセルシェーダで、少なくとも一部分を実行することが可能である。ピクセルシェーダは、ゲームコンソールのＧＰＵなどのＧＰＵ構成要素に関連付けられたハードウェア内に実装することができる。したがって、アンパッキングルーチン６００に関して説明される特定のピクセルシェーダ命令は、例示された実施形態の特定のピクセルシェーダハードウェアが理解するプロトコルに準拠する。しかしながら当業者であれば、同様または修正されたルーチンが、本発明の範囲を逸脱することなく多くの異なるタイプのピクセルシェーダ（または他のハードウェア／ソフトウェア）で実行可能であることを理解されよう。

ブロック６０１で、アンパッキングルーチン６００は圧縮済みのフォントテクスチャから１６ビットピクセルを取り出す。例えば、以下のようなピクセルシェーダ命令を使用して１６ビットピクセルを取り出し、ＧＰＵのレジスタｔ０にロードすることができる。

１６ビットピクセルを取り出してこれをレジスタｔ０にロードすることの一部として、アンパッキングルーチン６００は、取り出したピクセルに関連付けられた各チャネル（例えば赤、緑、青、およびアルファ）を分離するオペレーションを実行するようにピクセルシェーダに命令することもできる。この方法でアンパッキングルーチン６００は、例えば以下のように、取り出したピクセルの各チャネルを識別することが可能であり、

上式でｔ０．ａはｔ０レジスタのアルファチャネル構成要素を表し、ｔ０．ｒはｔ０レジスタの赤チャネル構成要素を表し、ｔ０．ｇはｔ０レジスタの緑チャネル構成要素を表し、ｔ０．ｂはｔ０レジスタの青チャネル構成要素を表す。ピクセルシェーダのレジスタサイズがピクセルサイズとマッチしないいくつかの実施形態では、取り出されたピクセルに関連付けられた値を必要に応じて拡張することができる。例えば、各チャネルに８ビットの３２ビットレジスタを有するピクセルシェーダでは、ピクセルシェーダ内で１６ビットピクセルを３２ビットに拡張することが可能であり、その結果、１６ビットピクセルのうちの各４ビット値が８ビットとして内部的に格納される。

１６ビットピクセルを取り出し、その値をｔ０レジスタの適切な構成要素に格納した後、アンパッキングルーチン６００は、取り出した１６ビットピクセルが４つの「重複する」グリフに関する情報を含む（例えば１６ビットピクセルの各チャネルが４ビット値を含む）と想定する。したがって、アンパッキングルーチン６００はブロック６０２へ進み、所望のグリフに関する値を含むチャネルを分離するための追加の処理を実行する。例えば、アンパッキングルーチン６００は内積（ｄｐ）命令を使用して、各１６ビットピクセルと、他の３つのチャネルに関連付けられた所望の４ビット値を保持するために特別に作られたマスク値とを組み合わせることができる。一実施形態では、マスキングオペレーションを実行するために使用されるピクセルシェーダ命令は、以下のように表すことが可能であり、

上式で、ｒ０．ａはオペレーションが完了すると所望の４ビット値が格納されることになる出力レジスタのチャネルであり、ｔ０は取り出された１６ビットピクセルを含むレジスタであり、ｃ０は（通常は圧縮済みテクスチャを含むアプリケーションによって供給される）マスク値を保持するピクセルシェーダ定数である。例えばピクセルシェーダが４チャネル内積命令（ｄｐ４）をサポートしていない代替実施形態では、ｄｐ４命令を３チャネル内積命令（ｄｐ３）に置き換えることが可能であり、その後に内積演算を第４のチャネルまで拡張するための乗算および加算（ｍａｄ）命令が続く。

上記の命令に関して、所望のグリフに対応する４ビット値はｒ０レジスタのアルファ構成要素（ｒ０．ａ）に格納される。

アンパッキングルーチン６００は意思決定ブロック６０３へ進み、この時点でｒ０．ａに格納されている所望の４ビット値のテストを実施して、白／グレーピクセルまたは黒／透明ピクセルを表すかどうかを判定する。意思決定ブロック６０３で４ビット値が白／グレーピクセル（例えば１ＸＸＸ）である場合、アンパッキングルーチン６００はブロック６０４へ進み、最上位ビットを除去し、残りの３ビットを１ビット左へシフトした後、結果として生じる４ビット値をそれぞれのＲＧＢチャネル（例えばｒ０．ｒ、ｒ０．ｇ、ｒ０．ｂ）に格納することによって、対応するＲＧＢ値を設定する。

しかしながら、意思決定ブロック６０３で４ビット値が黒／透明ピクセル（例えば０ＸＸＸ）である場合、アンパッキングルーチン６００はブロック６０５へ進み、（それぞれｒ０．ｒ、ｒ０．ｇ、およびｒ０．ｂに格納された）４ビット値のそれぞれのＲＧＢ値をゼロに設定する。その後アンパッキングルーチン６００は、最上位ビットを除去し、残りの下位ビットを１ビット左へシフトした後、結果として生じる４ビット値をアルファチャネル（ｒ０．ａ）に格納することによって、（ｒ０．ａに格納された）４ビット値のアルファ値を設定する。

一部の実施形態では、アンパッキングルーチン６００を実施する際に使用されるピクセルシェーダが、典型的にはビット単位演算を実行しない場合がある。ＤｉｒｅｃｔＸ８ピクセルシェーダはこうしたピクセルシェーダの一例である。こうしたケースでは、他のタイプの演算およびレジスタ変更子（ｍｏｄｉｆｉｅｒ）を使用してビットを分離およびテストし、ビットを左／右へシフトさせることができる。例えば一連の条件（ｃｎｄ）命令およびレジスタシフト変更子を使用して、ブロック６０３〜６０５に関して上述した前述のオペレーション（例えば４ビット値の最上位ビットのテスト、必要に応じたビットのシフト、および適切なＲＧＢＡチャネルへの出力値の格納）をピクセルシェーダに実行させることができる。したがって一部の実施形態では、対応するピクセルシェーダ命令は以下のように表すことができる。

第２の命令の前の「＋」記号は、ピクセルシェーダが２つの命令を同時に実行できるように、この命令を前の命令とペアにできることをピクセルシェーダに指示する。これは、ハードウェアがＲＧＢ専用命令とアルファ専用命令とを同時に実行できる場合に可能である。この方法で命令をペアにすることで、性能を上げることができる。

意思決定ブロック６０６で、アンパッキングルーチン６００は、最初に取り出された（依然としてレジスタｔ０に格納されている）ピクセルが（パッキング時にその１ピクセル当たり１６ビットのフルフォーマットを使用してテクスチャに格納された）カスタムグリフのピクセルを表すかどうか、あるいはそれが、（ブロック６０２〜６０５でアンパッキングルーチン６００によって想定されたように）各グリフの４ビット値が１６ビットピクセルのそれぞれのＲＧＢＡチャネルに格納された状態である、４つの「重複する」グリフに関する情報を含むかどうかを判定する。いくつかのピクセルシェーダは、ブロック６０２〜６０５で実行される処理に先行して意思決定ブロック６０６を実行できるようにする命令を提供することができる。例えばこうしたルーチンは、取り出されたピクセルのグリフに対応するフラグがパッキング中に設定されたかどうか（例えば、図３のパッキングルーチン３００のブロック３０３）をテストすることができる。しかしながら、例示された実施形態のピクセルシェーダはこうしたフラグをテストするように構成されていないため、ブロック６０２〜６０５の処理が実行された後に、線形補間オペレーション（ｌｒｐ）を使用してｔ０レジスタ（カスタムグリフの場合に使用される、最初に取り出された１６ビット値を含む）とｒ０レジスタ（ブロック６０２〜６０５に従って処理された値を含む）との間でスケーリングする。一部の実施形態では、線形補間用のピクセルシェーダ命令は以下に類似する場合がある。

この線形補間命令が４つのＲＧＢＡチャネルすべてに適用され、以下のように拡張される。

この線形補間命令の結果、ｃ１．ａの値に応じてアンパッキングルーチン６００は、ｔ０のコンテンツ（上式ではｃ１．ａ＝１）と等価になるようにｒ０レジスタ内のＲＧＢＡ値を更新する（ブロック６０７）か、または出力用にｒ０に格納された処理済みの値を保持する。

アンパッキングルーチン６００はオプションブロック６０８へ進み、他の白またはグレーピクセルに色付けを適用する。例えばアンパッキングルーチン６００は、所望の出力カラーに基づいて出力の変調を実行することができる。例示された実施形態では、これににはｒ０に格納された出力値に（例えばレジスタｖ０に格納された）頂点カラー値、または所望のカラーに関する情報を含むピクセルシェーダ定数（例えばｃ２）を掛けることが含まれる場合がある。ブロック６０９でアンパッキングルーチン６００は、レジスタｒ０に格納された値を出力ピクセルとして出力する。その後アンパッキングルーチン６００は意思決定ブロック６１０へ進み、グリフを完了するために次のピクセルを取り出すべきであるかどうかの判定をチェックする。次のピクセルを取り出すべきである場合、アンパッキングルーチン６００は折り返してブロック６０１へ戻る。そうでない場合、アンパッキングルーチン６００は（出力がレジスタｒ０に格納された状態で）終了する。

一部の実施形態では、前述のアンパッキングルーチン６００はスペーシングおよび位置決めルーチン（図示せず）と協働することができる。スペーシングおよび位置決めルーチンは、アプリケーションで使用される各グリフに関するスペーシングおよび境界（ｂｏｕｎｄｉｎｇ）情報を含む第２のファイルを参照することができる。例えば、文字「Ａ」をレンダリングする場合、ピクセルシェーダはテーブルを参照してフォントテクスチャ内で文字「Ａ」の長方形の境界を見つけることができる。アンパッキングルーチン６００を使用して文字に関するすべてのピクセルを描画した後、その文字のスペーシングに応じて描画位置は前進する。

（２）１ピクセル当たり８ビットから１ピクセル当たり２ビットへの圧縮
図７〜１０は、アンチエイリアシングなどの機能を依然として保持しながら、わずか２ビットに圧縮可能なピクセルを有するフォントをパッキングおよびアンパッキングするための技法に対応する。図７は、こうしたフォントを含むテクスチャビットマップ７００の一例を示す。このフォーマットで構成されたテクスチャの場合、あらゆるピクセルのカラー値を白にすることができる。アンチエイリアシング効果を可能にするために、各グリフの外側に近い白のピクセルに透明値を割り当てることが可能であり、その結果こうしたピクセルがカラーの背景にフェードインして見える。

こうしたビットマップは通常は、８ビットのアルファを有する３２ビットのＴａｒｇａファイル（２５６の固有のアルファ値を可能にする）として保存されるが、一部の実施形態では、固有のアルファ値の数は４（例えば１００％不透明（白）、６６％不透明、３３％不透明、および透明）まで減らされる。次に、４つの固有のアルファ値を以下のように２ビットに符号化することができる。

１１：ＲＧＢ＝白、アルファ＝１００％不透明（白）
１０：ＲＧＢ＝白、アルファ＝６６％不透明
０１：ＲＧＢ＝白、アルファ＝３３％不透明
００：ＲＧＢ＝白、アルファ＝０％（透明）
（例えばビット単位演算を実行するパッキングツールを使用して）上記のフォーマットにパックされるテクスチャビットマップは、その後アプリケーション（例えばビデオゲームアプリケーション）で使用することができる。図８は、１ピクセル当たり２ビットの圧縮済みテクスチャビットマップ８００の表示例を提供する。

値を１６ビットピクセルのそれぞれのＲＧＢＡチャネルにパックすることによって、１６ビットピクセルを４ビット値にパックするパッキングルーチン３００と同様に、２ビットパッキングルーチンは各ＲＧＢＡチャネルについて２ビットを有する８ビットテクスチャを作成する。これと同時に２ビットパッキングルーチンは、アプリケーションの実行時に従来のＧＰＵピクセルシェーダでのこの値のアンパッキングを容易にするパレット（または他の形のテーブルルックアップ構成要素）を作成する。具体的に言えば２ビットパッキングルーチンは、従来のピクセルシェーダがすでに認識している、３２ビットカラー値のアレイを含む２５６色パレットなどのパレットフォーマットを使用することができる。一部の実施形態では、ルックアップパレットはアルゴリズム的に生成されるため、圧縮済みテクスチャの２ビット値はそれぞれ以下のマッピングに従うことになる。

したがって、例えば使用されているグリフの特定の組合せが値００１０１１１０を有する８ビットピクセルを生成する場合、パッキングルーチンはパッキング時にこの値をカラーパレットからの対応する３２ビットのカラー値（例えば、００００００００１０１０１０１０１１１１１１１１１０１０１０１０）に割り当てる。

図９は、ビット単位演算を使用せずに圧縮済みの１ピクセル当たり２ビットのテクスチャをアンパックすることが可能な（したがって、通常はビット単位演算を実行しない従来のピクセルシェーダ／ＧＰＵによるアンパッキングが可能な）ルーチン９００を示す流れ図である。一部の実施形態では、アンパッキングルーチン９００はルックアップツールに前述のような２５６色パレットを使用する。しかしながら当業者であれば、アンパッキングルーチンが１つのテクスチャから値を取り出し、その値を使用してテクスチャ座標を計算し、次にこの座標を使用して第２のテクスチャから値を取り出すという、従属テクスチャ（ｄｅｐｅｎｄｅｎｔｔｅｘｔｕｒｅ）読み取り実施などの、他の実施も可能であることを理解されよう。

ブロック９０１では、アンパッキングルーチン９００は以下のように、８ビットピクセルが４つの別個の２ビット値を有する状態（例えばパック済みテクスチャのＲＧＢＡチャネルごとに１つ）で圧縮済みテクスチャから８ビットピクセルを取り出す。

ブロック９０２では、アンパッキングルーチン９００は以下のように、３２ビット値が４つの別個の８ビット値を有する状態（例えば各ＲＧＢＡチャネルごとに１つ）で２５６色パレットから対応する３２ビット値を取り出す。

したがって、８ビットピクセルからの２ビットピクセルはそれぞれ便利に変換され、従来のピクセルシェーダが容易に取り扱うことのできる各ＲＧＢＡチャネルごとに１つの４つの８ビット値に分けられる。これらの４つの８ビット値は４つの別々のグリフに属することが可能であるため、ブロック９０３でアンパッキングルーチン９００は所望のグリフに属する８ビット値を分離する。例えばアンパッキングルーチン９００は、図６のｄｐ４マスキングオペレーション６０２と同様のマスキングオペレーションを実行することができる。ブロック９０４でアンパッキングルーチン９００は、分離された８ビット値を、すぐに出力される（ｓｏｏｎ−ｔｏ−ｂｅ−ｏｕｔｐｕｔｔｅｄ）アンパック済みピクセルの８ビットアルファ（透明）値として使用する。ブロック９０５でアンパッキングルーチン９００は、レジスタｖ０に格納された頂点カラーをＲＧＢチャネル用の値として使用する。例えばアンパッキングルーチン９００は、図６の乗算演算６０８と同様の乗算演算を実行することができる。

ブロック９０６で、アンパッキングルーチン９００はアンパック済みのピクセルを出力する。その後アンパッキングルーチン９００は意思決定ブロック９０７に進み、グリフを完了するために次のピクセルを取り出すべきであるかどうかの判定をチェックする。次のピクセルを取り出すべきである場合、アンパッキングルーチン９００は折り返してブロック９０１に戻る。そうでない場合、アンパッキングルーチン９００は終了する。

２ビットのアンパッキングルーチン９００でレンダリングされたテキストには、アウトライニングおよびドロップシャドウイング効果が欠如している場合があるが、テキストを複数回レンダリングすることでこうした効果を組み込むことができる。例えば、ドロップシャドウイングを備えたテキストは最初に２ピクセルのオフセットを伴う黒いテキストとして描画され、次にオリジナル位置に白（またはカラー）として描画される。この技法を使用してレンダリングしたアウトライニングおよびドロップシャドウイングが施されたテキストの一例が、図１０に示されている。

図１０に示された２ビットにパッキングされたビットマップ１０００のフォントはアンチエイリアシングされているため、丸くなった縁部は最小化された「階段状のギザギザ」効果を有する。また図に示されるように、フォントは十分に拡大縮小するため、異なるサイズのフォントを表示するゲームで使用する際に望ましい。フォントが１ピクセル当たりたったの２ビットにパッキングされた場合であっても、パレットルックアップ後にハードウェアのテクスチャフィルタリングが実行されるため（例えばルックアップ後、各値は別々のＲＧＢＡチャネル内にあり、ハードウェアは各チャネルを別々にフィルタリングする）、フォントの拡大縮小は依然として可能である。

一部の実施形態では、限定カラーセット（例えば、２５６色パレットから使用可能なカラー、すなわち赤の４色、緑の４色、青の４色、およびアルファの４値）を使用して描画可能なイメージを使用することによって、埋め込まれた事前色付け（例えばカスタム）イメージを圧縮済みテクスチャビットマップに含めることができる。

（３）１ピクセル当たり８ビットから１ピクセル当たり１ビットへの圧縮
一部のアプリケーションでは、メモリの使用量を減らすために可能なあらゆる手段を講じることが望ましい。こうしたケースでは、（依然として８，０００＋文字フォントをサポートしながら）１ピクセル当たり８ビットのフォントを１ピクセル当たり１ビットにパッキングするための技法は、アンチエイリアシングのサポートが容易でないという欠点があり得るにもかかわらず、かなりの利点を与えることができる。

１ビットの場合、フォントパッキングルーチンはすべてのカラーピクセルを１に、すべての透明ピクセルを０に（またはその逆に）設定することができる。一部の実施形態では、フォントパッキングルーチンが８レイヤ深さで記号をパックするため、テクスチャ内の各８ビットピクセルは８つの別々の記号に属している８つまでの別個の１ビット値によって共有される。この構成は、４つの可能な組合せ（００、０１、１０、または１１）で、各ＲＧＢＡチャネル（それぞれ２ビット割り当てられる）が２つの別々のグリフに関する情報を含むことができることを意味する。同時に１ビットパッキングルーチンは、アプリケーション実行時にＧＰＵピクセルシェーダ内でのこの値のアンパッキングを容易にするマッピングをルックアップテーブル内に作成することができる（例えば２５６色パレット）。例えば一部の実施形態では、２５６色パレットがアルゴリズム的に生成されるため、圧縮済みテクスチャの１ビット値のペアはそれぞれ以下のマッピングに従うことになる。

上記のマッピングスキームに従って、圧縮済みテクスチャビットマップ内の各８ビットピクセルは、異なるグリフのピクセルをそれぞれが表す（例えばＲ₁Ｒ₂Ｇ₁Ｇ₂Ｂ₁Ｂ₂Ａ₁Ａ₂）２つの値をそれぞれが含む、４つの値セット（例えばＲ、Ｇ、Ｂ、およびＡ）を有することができる。図１１は、１ピクセル当たり１ビットの圧縮済みテクスチャビットマップ１１００の表示例を提供する。

図１２は、ビット単位演算を使用せずに圧縮済みの１ピクセル当たり１ビットテクスチャのアンパッキングが可能な（したがって、従来のピクセルシェーダ／ＧＰＵによるアンパッキングが可能な）ルーチン１２００を示す流れ図である。１ビットアンパッキングルーチン１２００は、オリジナルの（圧縮されていない）テクスチャからの８ビット値で索引付けされた２５６色パレットを使用して実施可能な、１ピクセルごとのルックアップテーブルを使用する。しかしながら当業者であれば、ルーチンが１つのテクスチャから値を取り出し、その値を使用してテクスチャ座標を計算した後、その座標を使用して第２のテクスチャから値を取り出す、従属テクスチャ読み取り実施などの他の実施が可能であることを理解されよう。

ブロック１２０１で１ビットアンパッキングルーチン１２００は、８ビット値が８つの別個の１ビット値を有する状態（例えばＲＧＢＡチャネル当たり２つ）の８ビット値を圧縮済みテクスチャから取り出す。例えば各チャネルは、異なるグリフのピクセルをそれぞれが表す（例えばＲ₁Ｒ₂Ｇ₁Ｇ₂Ｂ₁Ｂ₂Ａ₁Ａ₂）２つのビットを有することが可能である。一部の実施形態では、これら８つの１ビット値のうちの１つのみが所望のグリフのピクセルに対応する一方で、アンパッキングルーチン１２００による初期の処理には８ビットすべての処理が含まれる。したがってブロック１２０２でルーチン１２００は、３２ビット値が４つの別個の８ビット値を有する状態（例えばＲＲＲＲＲＲＲＲ、ＧＧＧＧＧＧＧＧ、ＢＢＢＢＢＢＢＢ、ＡＡＡＡＡＡＡＡ）の、対応する３２ビット値をパレットから取り出す。例えば、ビット１００１０１１１を有する取り出された８ビット値にマッピングが適用された場合、結果として生じる３２ビット値は１０１０１０１００１０１０１０１０１０１０１０１１１１１１１１１となり、これは以下の表でＲＧＢＡ内部値ごとに分類されて示される。

ブロック１２０３でアンパッキングルーチン１２００は、所望のグリフのピクセルに対応する８ビット内部値を分離するために３２ビット値から４つのＲＧＢＡチャネルのうちの１つを識別する。例えばアンパッキングルーチン１２００は、図６のｄｐ４マスキングオペレーション６０２と同様のマスキングオペレーションを実行することができる。この点でアンパッキングルーチン１２００には、所望のグリフのピクセルを含む２つのピクセルに関する情報を表す８ビット値が残されている。例えば上の表を参照すると、マスキングオペレーションが青チャネルに関連付けられた内部値を分離した場合、アンパッキングルーチン１２００には内部値０１０１０１０１が残され、これは２つの可能なグリフのうちの第１のグリフに対応する。

ブロック１２０４でアンパッキングルーチン１２００は、分離された内部値が２つの可能なグリフのうちの第１のグリフに関する場合、これを格納およびテストすることができる。例えばアンパッキングルーチン１２００は、８ビット内部値を第１のレジスタチャネル（例えばｒ０．ａ）に格納し、この８ビット内部値の最上位ビットをテストして、グリフの色付けされている部分またはグリフの色付けされていない部分に対応するかどうかをチェックすることができる。同様にブロック１２０５でアンパッキングルーチンは、分離された内部値（または分離された内部値のバイアスバージョン）が２つの可能なグリフのうちの第２のグリフに関する場合、これを格納およびテストすることができる。例えばアンパッキングルーチン１２００は、８ビット内部値（または８ビット内部値のバイアスバージョン）を第２のレジスタチャネル（例えばｒ１．ａ）に格納し、第２位ビットをテストして、グリフの色付けされている部分またはグリフの色付けされていない部分に対応するかどうかをチェックすることができる。ブロック１２０４および１２０５のオペレーションを実行するために使用されるピクセルシェーダ命令は以下のようになる。

これは以下のように擬似コードで書くことができる。

ピクセルシェーダでは、値０．５が２進の８ビット値１０００００００に対応するため、値を０．５だけ減じると、その値から高位ビットが効果的に除去される。したがって上記の擬似コードは以下のように解釈することができる。

ブロック１２０６でアンパッキングルーチン１２００は、第１のグリフに対応する値（例えばｒ０．ａに格納された値）または第２のグリフに対応する値（例えばｒ１．ａに格納された値）のいずれかを選択する。このオペレーションを実行するために使用されるピクセルシェーダ命令は以下のようになる。

ブロック１２０７でアンパッキングルーチン１２００は、上記の処理に基づいて色付けされたピクセル（例えば白）または色付けされていないピクセルのいずれかを出力する。ｒ０．ａの高位ビットは透明を設定するために使用される。このオペレーションを実行するために使用される対応するピクセルシェーダ命令は以下のようになる。

別のブロックとして示されていないが、２ビットアンパッキングルーチン９００と同様に、１ビットアンパッキングルーチン１２００は色付けされたピクセルに特定のカラーを適用することができる（例えば頂点カラー適用技法を使用）。その後アンパッキングルーチン１２００は意思決定ブロック１２０８に進み、グリフを完了するために次のピクセルを取り出すべきであるかどうかの判定をチェックする。次のピクセルを取り出すべきである場合、アンパッキングルーチン１２００は折り返してブロック１２０１に戻る。そうでない場合、アンパッキングルーチン１２００は終了する。

１ビット圧縮を使用するとメモリを大幅に節約することができる。例えば、それぞれが１６×１６ピクセルを占有する８０００文字を備えた中国語フォントをわずか２５６ＫＢに収めることができる。２０×２０ピクセルのより大きな文字も４００ＫＢに収められる。一部の実施形態では、大量テキスト状況（８０００文字すべてを必要とするダイアログなど）に対する１ビットフォント、ならびにより小規模な文字のサブセットに依存する他の用途（メニューおよびユーザインターフェースなど）用に拡大縮小可能な２ビットフォントを維持することが可能である。加えて、２ビットの圧縮済みフォントを使用するのと同様に、テキストを（例えば、最初に２ピクセルのオフセットを伴う黒いテキストとして、次にオリジナル位置に白（またはカラー）として）複数回レンダリングすることにより、１ピクセル当たり１ビットのテクスチャビットマップを使用してアウトライニングおよび／またはドロップシャドウイング効果を達成することができる。

ＩＶ．結論
文脈上明確に必要としない限り、「有する」「有している」などの単語は、説明および特許請求の範囲全体を通じて排他的または網羅的な意味と対立する包含的な意味、すなわち「含むが限定されない」という意味であると解釈される。さらに、「本明細書で」、「上記」、「下記」および同様の趣旨の単語は、本明細書で使用される場合、本明細書のいずれかの特定部分ではなく本明細書全体を指すものとする。特許請求の範囲が２つまたはそれ以上のリストを参照する際に「または」という単語を使用する場合、この単語は、リスト内の項目のいずれか、リスト内の項目のすべて、およびリスト内の項目のいずれかの組合せ、という単語の解釈のすべてをカバーする。

本発明の諸実施形態についての上記の詳細な説明は、本発明が上記で開示された精密な形を網羅すること、または本発明をこれに限定することを意図するものではない。本発明の特定の実施形態および例は例示の目的で上記に説明されており、本発明の範囲内で様々な等価の修正が可能であることを当業者であれば理解されよう。例えば、プロセスまたはブロックは所与の順序で提示されているが、代替の実施形態は異なる順序のステップを有するルーチンを実行するか、異なる順序のブロックを有するシステムを採用することが可能であり、いくつかのプロセスまたはブロックを削除、移動、追加、再分割、組合せ、および／または修正することが可能である。これらのプロセスまたはブロックはそれぞれ、様々な異なる方法で実施することができる。さらに、プロセスまたはブロックは時には順次実行されたように示されているが、これらのプロセスまたはブロックは並行して実行するか、あるいは別の時間に実行することも可能である。状況が許せば、上記の発明を実施するための最良の形態において単数または複数を使用している単語は、それぞれ複数または単数も含むことが可能である。

本明細書で説明される本発明の教示は、必ずしも本明細書で説明されていない他のシステムにも適用可能である。上記の様々な実施形態の要素および動作を組み合わせて、他の実施形態を提供することが可能である。

添付の出願書類に列挙されている可能性のあるいずれをも含む上記の特許および明細書および他の参照のすべては、参照により本明細書に組み込まれている。本発明の諸態様は、必要であれば、本発明の他の諸実施形態を提供するために上記の様々な参照のシステム、機能、および概念を使用するように修正が可能である。

上記の発明を実施するための最良の形態に鑑みて、本発明に対するこれらおよび他の変更が可能である。上記では本発明のある諸実施形態を詳細に説明しており、企図される最良のモードについて説明しているが、上記でどのように詳細に説明されていても、本発明は多くの方法で実施することができる。コンテンツ共有システムならびにスパム制御およびプライバシー管理技法の詳細は、それらの実施の詳細においてかなり変更される場合があるが、依然として本明細書に開示された本発明によって包含されている。前述のように、本発明のある特徴または態様を説明する際に使用された特定の用語は、その用語が関連付けられている本発明のいずれの特定の特徴、機能、または態様にも制約されるように、その用語が本明細書で再定義されていることを暗示するものとみなすべきではない。一般に、添付の特許請求の範囲で使用される単語は、上記の発明を実施するための最良の形態のセクションでこうした単語を明示的に定義していない限り、本明細書で開示された特定の実施形態に本発明を限定するものと解釈されるべきではない。したがって本発明の実際の範囲は、開示された諸実施形態だけでなく、特許請求の範囲の下で本発明を実行または実施するすべての等価の方法も包含する。

本発明のある態様はある特許請求の範囲の形で提示されているが、発明者は、任意数の特許請求の範囲の形で本発明の様々な態様を企図している。例えば、コンピュータ読取り可能媒体で本発明の一態様のみが具体化されるように説明されているが、コンピュータ読取り可能媒体では他の態様も同様に具体化することができる。したがって発明者は、本明細書提出後に、本発明の他の態様に対して追加の特許請求の範囲の形を遂行するために、こうした追加の特許請求の範囲を加える権利を保持する。

従来のテクスチャビットマップの一例を示すブロック図である。本発明が一実施形態で実施可能な環境の一例を示すブロック図である。一実施形態において、１６ビットから４ビットへのテクスチャパッキングルーチンを示す流れ図である。一実施形態において、４ビット値を圧縮されたテクスチャビットマップに格納するために使用されるデータ構造の一例を示すブロック図である。一実施形態において、１ピクセル当たり１６ビットのテクスチャビットマップを１ピクセル当たり４ビットに圧縮する一例を示す表示および流れ図である。一実施形態において、１ピクセル当たり４ビットのフォーマットに圧縮されたテクスチャビットマップをアンパックするためのルーチンを示す流れ図である。一実施形態において、１ピクセル当たり２ビットのフォーマットに圧縮可能なフォント文字の一例を示すディスプレイ図である。一実施形態において、１ピクセル当たり８ビットから１ピクセル当たり２ビットに圧縮されたテクスチャビットマップの一例を示すディスプレイ図である。１ピクセル当たり２ビットに圧縮されたテクスチャをアンパックするためのルーチンの一例を示す流れ図である。一実施形態において、１ピクセル当たり２ビットに圧縮されたフォントの拡大縮小の一例を示すディスプレイ図である。一実施形態において、１ピクセル当たり１ビットにパックされたテクスチャビットマップの一例を示すディスプレイ図である。一実施形態において、１ピクセル当たり１ビットにパックされたテクスチャビットマップをアンパックするためのルーチンの一例を示す流れ図である。

符号の説明

２００ゲームコンソール
２０４データストア
２０６メモリ
２０８オーディオ／ビデオポート
２１０イーサネット（登録商標）ポート
２１２電源ポート
２１４コントローラポート
２１８ゲームアプリケーション
２２０ピクセルシェーダ
２２２ゲーム設計システム
２２４パッキングツール
２２６パック済みテクスチャ

Claims

２次元空間での表示用の３次元グラフィックスをレンダリングするために使用されるテクスチャに、テキスト記号を格納するために使用されるビット数を減らすための、コンピュータにより実行される方法であって、
前記コンピュータが、テキスト記号を含む未圧縮のテクスチャビットマップを受け取るステップであって、前記未圧縮のテクスチャビットマップは１ピクセル当たり１６ビットのフォーマットを有するピクセルを使用する、受け取るステップと、
前記コンピュータが、前記未圧縮のテクスチャビットマップを圧縮されたテクスチャビットマップにパックするステップであって、該パックするステップは、
前記コンピュータが、前記未圧縮のテクスチャビットマップに含まれた各テキスト記号が、事前に色付けされたあるいはカスタムのテキスト記号であるか否か判定するステップと、
前記コンピュータが、前記各テキスト記号が事前に色付けされたあるいはカスタムのテキスト記号である場合、前記各テキスト記号を、圧縮されたテクスチャビットマップに埋め込み、かつ、該各テキスト記号がパックされていないことを示すフラグをセットするステップと、
前記コンピュータが、前記各テキスト記号が事前に色付けされたあるいはカスタムのピクセルでない場合、前記各テキスト記号に含まれる各ピクセルのＲＧＢ値のすべてが黒または透明を表すゼロに等しいか否か判定するステップと、
前記コンピュータが、前記各ピクセルのＲＧＢ値のすべてがゼロに等しい場合、第１の４ビットを発生し、該第１の４ビットが、０に設定された第１のビットと、アルファ値に設定された第２ないし第４のビットとを含む、ステップと、
前記コンピュータが、前記各ピクセルのＲＧＢ値のすべてがゼロに等しくない場合、第２の４ビットを発生し、該第２の４ビットが、１に設定された第１のビットと、前記ＲＧＢ値にしたがって設定された第２ないし第４のビットとを含む、ステップと、
を含む、パックするステップと、
を含み、これにより、前記各テキスト記号の前記圧縮されたテクスチャビットマップは、前記各テキスト記号が事前に色付けされたあるいはカスタムのテキスト記号である場合には該各テキスト記号を表す未圧縮のテクスチャビットマップと前記フラグを含み、事前に色付けされたあるいはカスタムのテキスト記号でない場合には該各テキスト記号に含まれる各ピクセルについて前記第１または第２の４ビットを含む、
方法。
請求項１記載の方法をコンピュータに実行させるコンピュータ実行可能命令を格納したコンピュータ読み取り可能記憶媒体。
テキスト記号の圧縮されたテクスチャビットマップをアンパッキングするための、コンピュータにより実行される方法であって、前記圧縮されたテクスチャビットマップは、各テキスト記号が事前に色付けされたあるいはカスタムのテキスト記号である場合には該各テキスト記号を表す未圧縮のテクスチャビットマップと、該各テキスト記号がパックされていないことを示すようにセットされたフラグを含み、事前に色付けされたあるいはカスタムのテキスト記号でない場合には該各テキスト記号に含まれる各ピクセルについて４ビット・データを含み、前記未圧縮のテクスチャビットマップは、ピクセル当たり１６ビットのフォーマットを有するピクセルを使用し、前記方法が、
前記コンピュータが、前記圧縮されたテクスチャビットマップからの各１６ビット・データを取り出すステップと、
前記コンピュータが、前記各１６ビット・データからアンパッキングしたテクスチャビットマップを発生するステップであって、該ステップが、
前記コンピュータが、前記各１６ビット・データに対応するフラグをテストして、前記各１６ビット・データが、事前に色付けされたあるいはカスタムのテキスト記号でないかどうか判定するステップと、
前記コンピュータが、前記前記各１６ビット・データが、事前に色付けされたあるいはカスタムのテキスト記号でないと判定した場合、
前記コンピュータが、前記各１６ビット・データを４つのチャネルに分離するステップであって、各前記チャネルが４ビットを含む、ステップと、
前記コンピュータが、各前記チャネルの第１のビットが、黒または透明を示す値に設定されているか否か判定するステップと、
前記コンピュータが、前記第１のビットが黒または透明を示す値に設定されている場合、該各チャネルのＲＧＢ値をゼロに設定し、かつ該各チャネルの４ビットのうちの第２〜第４ビットにしたがってアルファ値を設定するステップと、
前記コンピュータが、前記第１のビットが黒または透明を示す値に設定されていない場合、該各チャネルの４ビットのうちの第２〜第４ビットにしたがってＲＧＢ値を設定するステップと、
を実行するステップと、
を含む、アンパッキングしたテクスチャビットマップを発生するステップと、
を含む、方法。
請求項３記載の方法であって、前記コンピュータが、前記各１６ビット・データが、事前に色付けされたあるいはカスタムのテキスト記号である場合には、該各１６ビット・データをアンパッキングしたテクスチャビットマップに出力する、方法。
請求項３または４のいずれかに記載の方法をコンピュータに実行させるコンピュータ実行可能命令を格納したコンピュータ読み取り可能記憶媒体。