IEのバグ
つい先日、当サイトをネスケに対応させるべく大改造を行なった。
そして、明らかになったこと、それは「IEがダメ」ということである。
これはあくまで「CSS」を基準に考えた場合の話であるが、今までネスケといえば、CSSへの対応が極悪で全く使い物にならなかった。
当サイトも、長い間ネスケでの表示は保証対象外としてきた。
しかし、思い付きでインストールした『ネスケ 6.2』がなかなか良い。
CSSへの対応レベルも高かったため、今回ついにネスケを表示保証に加えた。
その際、明らかになったことは、ネスケのCSSへの対応レベルが、これまで首位だったIEを抜いて逆転したということである。
ネスケのCSSへの対応レベルは極めて高く、CSS2規格にほぼ忠実に準拠している。
ネスケの素晴らしさがわかるにつれ、逆に、挙動にいら立ちを覚えたのがIEである。
規格に準拠しない誤った挙動、独自の仕様。
挙句の果てには、ページ製作過程に泥沼を作るバグ。
このように、IEが規格に従わないために、当サイトの再構築は困難を極めた。
特に問題だったのが「ブロックタグのセンタリング」である。
これをCSSを用いて行なう正しい方法は“margin-left:auto;margin-right:auto;”である。
しかし、IEではこれが通用しないうえに“text-align:center;”でセンタリングされるという、規格上誤った動作をする。
まあ、それでもまだこの程度なら許せる。
本当にひどいのは、divタグに“border-left:XX;”で左側のみにボーダを与えると、それ以下のdivタグの内容が破壊されるというバグである。
言葉で書くと難しいが、実は「本ページ」はそのバグの直撃を受けた。
なんとか対処法を考案して、現在はご覧のとおり問題はないはずだが、それにしても、IEはもっと規格に従うべきではないか?
アルファブレンド その3
MMXコードを書きたいのだが、ここでひとつの問題にぶち当たった。
それは「透明色処理」である。
普通、アルファブレンドは1ドットずつ処理を行なうコードを書くのが一般的である。
しかし、MMXレジスタを使用せずともレジスタ幅は32ビットであるため、16ビット画像なら2ドットずつ処理を行なうことができる。
その反面、透明色処理も2ドット同時に行なわなければならず、コードが複雑になり、しかも、上手く書かないとかえって遅くなってしまう。
私はこの2ドット同時透明色処理を昔懐かしの「AND-OR法」(今名付けた)を用いてクリアした。
「AND-OR法」を用いる際にどうしても必要なのが「マスク」である。
このマスクは透明色のパターンに応じて毎度作る必要がある。
透明色のパターンは2ドット組の場合4通り存在する。
このうち、2ドットとも透明または不透明の場合はマスクなしで処理できるため、実際は2通りでよい。
ただ、あらかじめ作ったマスクをレジスタ(高級言語なら変数)に保存して「AND-OR法」に適用すると極めて遅い。
これを解決するためには、パターン毎に「マスク使用部にマスクの直値(マジックナンバー)を入れたコード」(*)を用意し、パターン別に分岐する必要がある。
このコードなら高速な実行が可能だ。
しかし、単純にコードが2倍になってしまう。
さて、話はMMXに戻って。
MMXレジスタの幅は64ビットであり、16ビット画像なら4ドットずつ処理することができる。
しかし、ここで問題になるのが先にも挙げた「透明色処理」である。
4ドット組の場合、透明色のパターンは16通りである。
このうち、4ドットとも透明または不透明の場合を除いた14通りが、記述しなければならないコードの数である。
まあ、記述すること自体はコピペで作れるものだからたいした問題ではないが、出来上がりは非常に醜いものとなるだろう。
そこで、別の方法を考えているのだが、どうやらこの醜い手段以外はなさそうである。
- マスク使用部に～
-
ある条件で変数maskは0x0000FFFF、または、0xFFFF0000の値を持つとする。
このあとのコードはdata&=maskであるとする。
このコードを「ある条件でdata&=0x0000FFFF、または、data&=0xFFFF0000のコード」に書き換える。
続・アルファブレンド
昨日の続き。
今日は予定通り1日中アセンブラと格闘。
いらぬ知識が雪だるま式に増えていった。
その甲斐あって、コンパイラに勝てるコードを書けるようになった。
これは大きな進歩である。
MMX命令を使用していないにもかかわらず、条件付きで既に従来の3倍以上の処理速度を実現している。
これに加えてさらにMMX命令を用いれば、きっと愉快なことになるだろう・・・
アルファブレンド
私が作ったゲーム開発ライブラリには言わずと知れた問題がある。
それは「アルファブレンドが激重」という問題である。
そりゃそうだ、たいした最適化は行なっていない。
すべて“C”である。
いや、一度、アセンブラでの最適化を試みたのだが、コンパイラの最適化に完敗して以来、この手段は封印している。
それにしても重い。
というわけで、再度アセンブラによる最適化を試みる一大プロジェクトを立ち上げた。
リベンジである。
しかし、以前と同じ手段を使ったのでは、また砂を持ち帰る羽目になる。
そこで、今回はある作戦を打ち立てた。
キーワードは「MMX」である。
MMX命令を使えば倍単位での高速化が見込める。
その反面、恩恵を受けられるCPUは限定されてしまう。
まあ、テストということで、今回はMMX限定で行ないたいと思う。
ところで、問題がいくつかある。
その中でも最も厄介な問題がビデオチップの違いによるビットフォーマットの違いである。
これは16ビット表示を用いる際に発生する問題なのだが、ビデオチップによってRGBのビット数と並びが異なるのである。
並びはともかく、ビット数の違いはプログラムが複雑になる。
せっかくの最適化も無駄にしかねない。
この問題をどう工夫して乗り切るかが勝負の分かれ目といえよう。
EUP 復活
年末にネット散策中、実に面白いものを発見した。
『kbMedia Player』というオーディオ再生ソフトウェアと、EUP形式対応プラグインである。
このうち前者は以前から活用していたのだが、年末に行なったPCメンテナンスのついでにアップデートも行なおうと思いサイトを訪ねた。
その際に後者を発見したのである。
ところで「EUP」と聞いてそれが一体なんなのか即答できる方は実に素晴らしい。
こんなマニアックな形式は知らないのが普通である。
なにかというと FM TOWNS におけるMIDIの標準形式だ。
本来は『EUPHONY』というシーケンサの独自形式なのだが、なぜか、タウンズではMIDIの標準形式としてこれが利用されていた。
それはさておき、この形式は実によくできている。
普通にMIDIを扱うことはもちろん可能であり(残念ながら先述プラグインでは不可)、さらに「内蔵音源」と呼ばれるFM/PCM音源も利用可能なのだ。
まあ、ただそれだけなのならたいしたことはない。
なにが素晴らしいのかというと、実は内蔵音源はソフトウェア的に自作できるのである。
FM音源はアルゴリズムを編集し、PCM音源は音声波形を登録する。
それぞれの情報はファイルの形で出力され、EUP再生時に読み込んで楽器として利用する。
よって、メモリの許す限り(とはいっても64KB)、楽器のクオリティを追求することも、音声を含ませることも可能なのだ。
今でいうところのMOD形式に一番近いのではないか。
MODもマニアックという説は置いといて・・・
もうひとつ素晴らしい点を挙げるなら、昔作った曲を再生できることだろうか。
