仕様相違？：bmp画像が透過しない

[Former user]

いつも大変お世話になっております。

1.28と1.50だと下記のサンプル画像は透過しますが、CardWirthPy_1.0beta1だと透過しない相違がありましたので報告しに上がりました。

元画像は、VIPWirth保管庫のシルエット素材ですが、こちらでは透過しませんでした。「酒の魔術師」（VIPWirthシナリオ）で加工された画像が何故か透過します。

もしかしたら、こちらの環境の所為かもしれませんがご確認頂けたら幸いです。

確認した環境：windows7 64bit

[k4nagatsuki]

素材のライセンスについて記述がなかったのでこちらで確認しました。CWでの使用に限り自由・著作権表記は任意という事なので問題無いようです。できればそうした事柄を書いていただけると問題が減りますので、できるだけお願いします。

さて、この問題ですが、ビット深度1(2色)のイメージが半透明になってしまうというCWに古くからあるバグによる食い違いのようです。この現象はバグながら演出に効果的なので、「巨人を狩る者」などのシナリオで利用されてしまっています。

いつか対応しなきゃならなくなるんだろうなぁ、と思いながらすっかり忘れていましたが、これを機に対応しましょう。

しかしこの画像はどちらもビット深度1のようですが、片方だけ半透明になっていないのはなぜだろう？ そこは対応前に調査する必要があります。

[k4nagatsuki]

実態に合わせてステータスを変更。

[k4nagatsuki]

RGBそれぞれでなんらかの演算が発生しているようです。

カード画像と背景の兼ね合いを以下のようにして結果を見てみました。

• 255, 128 = 128
• 128, 128 = 128
• 192, 128 = 128
• 64, 128 = 0
• 102, 128 = 0
• 254, 128 = 128
• 255, 191 = 191
• 255, 225 = 225
• 128, 225 = 128
• 253, 252 = 252
• 33, 34 = 32

どうも左辺値はどこかで下位ビットが落ちていて、それを右辺値と掛けた結果が出ているような気がするのですが、ちょっと整理がつきません。

[k4nagatsuki]

• 255, 191 = 191
• 254, 191 = 190

この答は以下のように乗算で計算する事ができます。

• 255 * 191 / 255 = 191
• 254 * 191 / 255 = 190.25 ..

しかしこれでは以下のような例は説明できません。

• 64, 128 = 0 (32になるはず)
• 102, 128 = 0 (51になるはず)
• 33, 34 = 32 (4になるはず)

上記の例は全てRで試してみましたが、GとBの値を変更しても結果は変わらないように見えます。

[k4nagatsuki]

• 255, 191 = 191 (乗算=191)
• 254, 191 = 190 (乗算=190.25..)
• 240, 191 = 176 (乗算=179.76..)
• 224, 191 = 160 (乗算=167.78..)
• 200, 191 = 136 (乗算=149.8..)
• 192, 191 = 128※ (乗算=143.8..)
• 191, 191 = 191※ (乗算=143.06..)
• 190, 191 = 190 (乗算=142.31..)
• 184, 191 = 184 (乗算=137.8196..)
• 152, 191 = 152 (乗算=113.85..)
• 136, 191 = 136 (乗算=101.866...)

カードのR値が台紙の値より超過か以下かによってがらりと結果が違いますね(※の部分)。答が見えたような気がしますが慌てずにもう少し考えてみます。

[k4nagatsuki]

• 128, 129 = 128
• 128, 128 = 128
• 127, 128 = 0
• 64, 64 = 64
• 63, 64 = 0

台紙の値が128超過か以下かによっても何か断絶がありそうです。

[k4nagatsuki]

• 128, 128 = 128
• 127, 128 = 0
• 126, 127 = 126
• 64, 64 = 64
• 63, 64 = 0
• 62, 63 = 62
• 32, 32 = 32
• 31, 32 = 0
• 30, 31 = 30
• 16, 16 = 16
• 15, 16 = 0
• 15, 15 = 15
• 14, 15 = 14

どうも台紙の値が2の乗数の値の時にピンポイントでおかしくなっているようです。

[k4nagatsuki]

バグなので当然ではありますが、この直前に書いた挙動はユーザ視点でも理屈に合いませんし、実際に表示が乱れる原因になっています。いっそ単純にRGB値をα値として使ったほうが遥かに綺麗に見えるはずです。

この現象をそのまま再現はせず(どっちにしろ今のところ再現する方法が分かりませんが)、そのように少し変更した形で再現した方がいいかもしれません。このバグの効果を精密に利用する事はおそらく不可能なので、それは許容可能な変更だと思います。

[k4nagatsuki]

再現する際の技術的な難度が異常に高すぎます。パフォーマンスについては諦めていただく必要があるかもしれません。

これだけははっきりさせておきたいのですが、そもそもこんなバグは利用するべきではありません。今からシナリオを作るのであれば、本物の半透明の画像を用意しなければなりません。

それを前提にした上で、努力はします。

[k4nagatsuki]

メッセージ内については、構造上どうやっても対応不能かもしれません。対応するにはメッセージの描画処理を根底から覆す必要がありますし、覆す事にデメリットは多く、他のメリットは一切無い上、将来の拡張性と可読性を損ないます。

私はそこまでしてこのバグに対応したくはありませんし、たぶんやろうと思ってもできません。

[k4nagatsuki]

どうもRGB値のAND演算っぽいですね。理屈は分かりませんが同じ表示になります。

[k4nagatsuki]

対応したので最新のテスト版をお試しください。

たまたまAND演算だと気づいたのでパフォーマンスについては大きな問題は発生しないかと思います。

しかしメッセージについては描画方式が異なる関係上完全な再現は不可能ですし、明白なバグなので今後は使うべきでないという事に変わりはありません。

[k4nagatsuki]

対応は完了していると思うのでクローズします。

また何かあったらよろしくお願いします。