属性の衝突

属性の衝突(カラー クラッシュまたはブリーディングとも呼ばれる) は、一部のカラー 8 ビットホーム コンピュータ(最も有名なのはZX Spectrum ) のグラフィック回路の制限によって発生する表示アーティファクトで、8×8 のピクセル タイルで使用できる色は 2 色のみでした。この影響は、 MSXソフトウェアや一部のCommodore 64タイトルでも顕著でした。この制限が明らかになるのを防ぐ回避策は、それ以来 Spectrum プログラマー文化の要素と見なされてきました。

この問題は、カラー コンピュータやDragonの「セミグラフィック モード」(テキスト モードとグラフィック機能) でも発生しますが、これらのコンピュータも非属性グラフィックを備え、解像度も高くなっています。当時のいくつかのビデオ ゲーム コンソールには、このような制限を引き起こすビデオ モードがありましたが、通常はタイルごとに 2 色以上を使用できました。NES (ファミコン) には、やはり「セミグラフィック」であるモードが 1 つだけあり、16×16「ブロック」(4 つの 8×8 タイルのグループ) ごとに 4 色を使用できましたが、画面ごとに 16 色でした。スーパー NES では、タイルごとに 16 色を使用できましたが、画面ごとに 256 色を使用できました (他の改善点の中でも)。これにより、アーティファクトがはるかに目立ちにくくなりました (デバイスをプログラムする必要があった人を除く)。

ZX Spectrum での属性の衝突は、フレーム バッファのメモリ使用を最小限に抑え、グラフィックスではなくテキスト表示を最適化するように設計された、その独特なディスプレイ メモリ レイアウトが原因でした。メモリを節約するためにカラー パレットを制限するのではなく、Sinclair の設計では、ピクセル ビットマップとカラー情報をメモリの別の領域に格納しました。ビットマップは個々のピクセルの状態 (オンまたはオフ) を指定しますが、カラー情報 (または「属性」) は、8x8 ピクセルの文字セルごとに 1バイトで、テキスト文字マトリックス (24 行 32 列) に対応していました。このバイトは、カラー値を定義するために使用されるBASIC命令にちなんで、 INK (前景色) とPAPER (背景色)と呼ばれる 2 つの 3ビット値をエンコードしました。属性には、他の 2 つのバイナリ値が含まれていました。2つの色の 2 つの明るさレベルのいずれかを示すBRIGHTビットと、設定すると 2 つの色が定期的に入れ替わるFLASHビットです。このスキームでは、2 つの明るさレベルでの赤、緑、青の 8 つの組み合わせ (両方の明るさで同じに表示された黒を除く) の 15 種類の色が提供されました。したがって、各 8x8 ピクセル ブロックには、使用可能な 15 色のうち 2 色のみを含めることができ、その 2 色はパレットの明るい半分または明るくない半分のいずれかから選択する必要があります。8x8 ピクセル領域に 3 色目を追加しようとすると、前の色の 1 つが上書きされます。

ZX Spectrum はビットマップに 6144 バイト (1 バイトは 8 ピクセルを表す) を使用し、カラー属性に 768 バイトを使用しました。これにより、グラフィックス ディスプレイ全体で合計 6912 バイトとなり、Spectrum 時代の「カラー」機能を備えたコンピューターとしては比較的小さい合計です。このグラフィックス アーキテクチャは、Sinclair とAmstradによるSpectrum のその後の再設計、Amstrad の最終モデルである ZX Spectrum +3 まで保持されましたが、後続のモデルには 128  KiBの RAM が搭載され、このようにメモリを節約する必要性が減りました。このアーキテクチャが保持されたのは、下位互換性が失われないようにするためです。

属性は、コモドール 64、MSX、NESなど、さまざまなコンピュータやコンソールで使用されていましたが、属性ブロックのサイズとブロックあたりの色の数はさまざまでした。ただし、ハードウェアスプライトを使用すると、属性の衝突を回避できました。

Thomson MO5およびTO7マイクロコンピュータ、Oric 1、MSX 1 アーキテクチャ、およびTexas Instruments TMS9918 ビデオ ディスプレイ コントローラに基づくその他のシステムでも、非常によく似た制約が見られます。水平方向の 8 ピクセルの各グループでは、16 色の​​うち 2 色しか使用できないため、Spectrum の場合と似ていますが、それほど深刻ではありません。MSX 1 では、Sinclair Spectrum の場合のように、8x8 ピクセル領域全体で使用できる色属性バイトが 1 つだけではなく、8x1 ピクセル グループごとに 1 つの属性バイトがあり、8 つあります。したがって、Spectrum では 8x8 ピクセルの正方形領域に対して 1 つの色ペアに制限されていましたが、MSX 1 では、隣接する 8 つのピクセルの「ライン」に対して 1 つの色ペアに制限されていました。さらに、MSX1 では、属性の衝突の問題に縛られないスプライトを使用できました (ただし、MSX 1 スプライトには、モノクロであるなどの独自の制限がありました)。

実際には、この技術的な利点は、MSX 1 システムでより優れた画像を生成することに役立たないことが多かった。MSX 1 の問題は、Spectrum ゲームを MSX 1 に変換した多くのヨーロッパのソフトウェア会社が、MSX 1 が Spectrum に対して行ったすべての改善を無視したため、結果として得られた MSX 1 バージョンに、元の Spectrum ゲームと同じ量の属性の衝突があったことである ( Jack the Nipper II: In Coconut Capers はこの一例である)。変換を容易にするために、ソフトウェア開発者は、Spectrum の単一の属性バイト値を、MSX 1 の対応する 8 つの属性バイトすべてに単純にコピーした。同じ理由で、ソフトウェア会社は MSX 1 のスプライト機能も無視し、ビデオ表示機能がその他の点では極めて類似していたため (256×192 解像度、16 色)、両方のシステムは同じゲームに対して実質的に同一の表示を生成した。対照的に、日本の MSX 1 ゲーム^{[ which? ]}はMSX 1 のすべての機能を使用していたため、多くの場合、より見栄えの良いゲームになった^[要出典]。

属性の衝突を避けるため、静的グラフィック ディスプレイは慎重に構築する必要がありました。色は 8×8 ピクセル ブロックでしか適用できないため、精細なカラー グラフィックは不可能でした。注意深い設計により印象的な結果を達成でき、色の変化をディスプレイ (通常はテレビ) のリフレッシュ レートに同期させることも可能です。

しかし、アニメーション表示はより困難であり、ビデオゲームをプレイすることを主な目的としたマシンでは明らかな欠点でした。 ディスプレイの動く部分が触れて 8×8 ブロック内の 1 つのピクセルの色が変わるだけでも、ブロック全体の色が変わります。 そのため、細かく動くグラフィックスでは、急速に変化する色の大きな醜い縁取りが周囲に残りました。

初期のソフトウェアでは、この問題は単に無視されていました。その後、標準的な回避策は、画面の端の装飾的な境界線 (スコア表示など) や何らかの楽器など、静的な表示要素に色を使用し、中央の小さなモノクロ領域にすべてのアニメーション グラフィックを配置することでした。これにより、更新する画面領域が少なくなり、ピクセル情報のみが変更され、カラー領域はそのままになったため、グラフィックも高速化しました。

FTL のLight Forceなどの一部の Spectrum ソフトウェアでは、基本的に画面上の要素のデザインと動きの経路の両方を 8×8 色解像度の境界に制限することで、非常に注意深いグラフィック デザインを使用してフルカラーの動くグラフィックを実現しました。そのため、動く要素は比較的大きく、むしろブロック状または四角形になり、動きが制限されていましたが、これは視覚的に明らかではなく、動くフルカラー グラフィックの光景は Spectrum 所有者にとって非常に印象的でした。

主流の開発者は、属性の衝突の問題に対する適切な包括的な修正方法を見つけることができず、代わりに、高速で鮮明なグラフィックスが必要な場合にはモノクロ グラフィックス方式を使用し、状況が許す場合はフルカラー グラフィックスを使用することを好みました。

タイミングに細心の注意を払うことで、ディスプレイが描画されるときに特定の時間に RAM の属性領域を変更することが可能になりました。ディスプレイ ハードウェアにディスプレイの 1 行を描画させ、次の行が描画される前に属性 RAM を変更して、各行ごとに異なる属性の効果を与えることができます。これらの変更はソフトウェアで行う必要があり、プログラムに時間がかかるため、この手法は通常、特殊効果に限定されていました。この手法は、デモシーンでも非常に人気がありました。

1987 年以前のほとんどのゲームでは、属性の衝突は無視されていました。Knight TymeやThree Weeks in Paradiseなどの後発のゲームでは、プレイヤーが 2 つの属性の衝突モードを選択できるようになりました。1 つはメイン キャラクターの属性を無視して、キャラクターを背景に溶け込ませるもので、その逆で、背景画像よりもキャラクターの配色を優先します。

もう 1 つの回避策は、1984 年にKnight Loreの Spectrum バージョンで実行されたように、グラフィックを単純に 2 色 (モノクロとも呼ばれる) でレンダリングすることでした。

多くのゲームでは、フルカラーの背景と「キャラクタースクロール」（環境が一度に 8 ピクセルスクロールされる）が使用されていましたが、『Double Dragon』のように実質的に透明なモノクロのスプライトは、色への依存を避けて目立つように描画されていました。多くのゲームでは、この方法を使用してピクセル単位のスムーズなスクロールが行われていましたが、1 つのキャラクター ブロックの要素が次のブロックに「渡される」際の属性の衝突がはっきりと見えました。

フルカラー グラフィックスの使用例としては、Altered Beastの Spectrum 版が有名ですが、あまり成功していません。このゲームでは、属性の衝突がかなり発生しています。

プログラマーのドン・プリーストリーは、いくつかのゲームで、大きくて漫画のようなスプライトを使用して独特のスタイルを開発した。これらのスプライトは、過度に四角く見えないように、キャラクターブロック全体に広がるように注意深くデザインされている。この手法の欠点は、ゲームプレイをグラフィックに合わせて設計する必要があるため、他のプラットフォームからの移植には適さないことである。この手法を使用したゲームには、Popeye、The Trap Door、Through the Trapdoor、Flunky などがある。同様の手法を使用した他の開発者には、Dark Sceptreのマイク・シングルトンやDan Dare: Pilot of the Future のギャング・オブ・ファイブがいる。

1994 年、プログラマーの Igor Maznitsa は、ZX-Spectrum-128 をベースにしたマルチ CPU コンセプト プラットフォーム「ZX-Poly」を開発しました。このプラットフォームでは、属性の衝突を回避でき、実行可能コードを変更せずに多くの古いゲームをカラー化することもできます。

• 「FAQ: リファレンス」。WorldOfSpectrum.org。
• サーマン、デイビッド。「アーケードの色彩、イラストレーション、属性の衝突 1979 - 89」。Academia.edu。
• スミス、トニー (2012-04-23)。「シンクレア ZX スペクトラム、30 周年おめでとう」。The Register。
• ZX-Poly エミュレータのソースとプラットフォームの説明