バグ:カラーセルの描画が1.50と異なる

[ルンバ]

NEXTのバグhttps://bitbucket.org/k4nagatsuki/cwxeditor/issues/399/wsm-next
の検証の最中にわかりましたがPyにもカラーセルの仕様違いがあるようです。
通常の使用上ではほとんど気にならないとは思いますが
以下の画像をご覧いただければ（描画方式が通常以外の）セルを多数重ねると差が出る事がわかります。

加算を多数重ねた時の見え方や0％近辺で多数重なった時の濁った見え方が異なります。

‌

Pyは加算の描画方式は他と異なるようです。また乗算も含め0％近辺での色の濁りが発生します。
これが影響しそうなケースとしては、キーコード「明かり」仕様回数に応じ加算を重ねるとか、不透明度の低い加算セルを大量に重ね、エフェヴを使わずに画面を白くする疑似アニメとかはあるかもです。（かなり稀だと思いますが）

以下は0～1％のグラデを百回重ねた画像比較です

‌

以下は左０％　右１％　でグラデ無しで百回重ねた画像比較です

‌

[ルンバ]

他の件の検証の中でしか気づかなかった事なので対応は不急です。

[ルンバ]

背景画はgroupAskの著作物です

[k4nagatsuki]

ご報告ありがとうございます。

極端に小さな値の時に違いが出るということであれば、計算式の小数点以下の丸め方に違いがあるのかもしれませんね。

余裕ができたら調べてみます。

[k4nagatsuki]

調べてみたところよくわからなくなったのですが、この手のグラフィクス処理において数値の丸めが発生するのはどういうタイミングなのでしょうか？

実はそれが最後に一度だけ行われるもので、その処理がOSのグラフィクスコンテキストの処理の中に隠蔽されているのだとしたら、この手の繊細な部分の仕様合わせはかなり難しくなります。

CW 1.50のカラーセルの描画方式は一般的なやり方と異なっている事が分かっています。これに合わせるため、CWPyとcwxeditorでは処理中のビットマップをRGB形式で取り出して、それに1.50に合わせた方法で整数値で合成するという方式で描画を行っています。このやり方がそもそも間違っていると思うのですが、正しい方式は把握していませんし、SWTやwxでそのためのAPIを見たこともありません。

詳しい方がいらっしゃったらご教示いただけるとありがたいです。

[k4nagatsuki]

CW 1.50-CWNextの違いもそうですが、この合成処理がそもそもOSやライブラリの実装依存で仕様が安定していないという事はないでしょうか？

[ルンバ]

0％付近の問題と別にやはりPyは加算のやり方が違うようです。

↑最初に貼った３０層重ねの画像ではPyの加算は少し水色が濃いですが
さらに重層してゆくとさらに水色が濃く不透明になり次第に後ろのマップオブワースが隠されてしまいます。

加算であれば重層によってより明るくなる概念でしょうから、この挙動には違和感があります。

前述のようにエフェヴなしで爆発や魔法エフェクトで段階的に明るくする疑似アニメをするなら
加算を多重に重ねるという発想は普通に行われえる事と思いますのでこれは目視上は下の1.50に寄せた出力にした方がよいでしょう。
（現在そのようなシナがあるかわかりませんが）

[ルンバ]

Pyで不透明な塗りつぶしになる色は、下の1.50でマップオブワースの黒が透けてる色のように見えますね。

[k4nagatsuki]

pull request #192

とりあえず合成時に整数計算が行われず四捨五入らしき操作が行われていたことはわかったので、そこだけ合わせる事を試みます。

ただ、実際の描画を見ると、グラデーションの切り替え位置や加算合成で微妙に異なった結果が出ます。浮動小数点数のビット数や境界値の扱い方などいろいろ検討してみましたが合いません。グラフィックのことなので最悪ハードウェアまで下りていく必要があるのかもしれませんが(実際には何か見落としがあるか、中間のどこかに答えがあるのだと思います)、本当にそうしようとしたら年単位の時間がかかりますし、そういうモチベーションはありませんし、結果に将来性も移植性もない事が想像できます。また、ごく小さな食い違いであるため、そこまでして合わせても得られるメリットはほとんどありません。

なお、現状CWPyとcwxeditorのあいだでもごく小さな違いが出ますが、これを合わせようとするとCWPy側のパフォーマンスが数十倍悪化する事が分かっています。

すでに時間をかけすぎました。私個人としては、これ以上の対応はちょっとできかねます。

合わせるモチベーションのある方がいらっしゃったら、1.50やNextの正確な合成方式を調べ、何らかの形で結果をpushしていただければと面ます。

[ルンバ]

確認しました。加算を多重した際に不透明になる事もなくなりましたので、シナリオ上で問題化するような差異は無さそうです。対応ありがとうございます。実質解決なのですが、もし将来さらに対応をされる方が居る場合のため、加算の0-255グラデを多重した場合の目視上だけ0％付近がa値が高そうに見える点を付記し課題優先度を下げておきます。

[ルンバ]

背景変更コンテンツを連続させ疑似アニメを行ってエンジンごとに比較（背景切り替え方式アニメーションなし、拡大時滑らかにするOFFで）
をしてみると、合成方式が通常以外だと、4.3と5.0で速度感に体感できるかなりの差がありました。（特に拡大表示時）これはこの課題の処置によって処理が変わったからという事でしょうか？

私の環境でフルスクリーン拡大時での場合は

4.3は合成方式通常の場合も乗算の場合も一見速度に変化がなくいずれも1.50やNEXTよりやや遅め。(アニメとして不自然なまでではないのでこれはこれで問題ない)

5.0は合成方式通常の場合は4.3と同じ？だが、乗算の場合は4.3よりも相当に遅く、1.50やNEXTと比しかなり違和感がある

修正可能ならそれにこしたことはないのですが、これがもし本課題による修正により避けられない事象の場合、合成方式が通常以外の背景変更コンテンツを連続させ疑似アニメを行っている既存シナリオを5.0でプレイした場合に、速度感の違和感が問題になるシナがあるかがわからない所ではあります。

そして、この課題で問題になっていたPyのカラーセルの仕様違いはセルを多数重ねてはじめて判別される症状であり、数十層単位で重ねるというのは疑似アニメ以外では考えにくい使用方法です。ですが速度的に大きく低下するとなると疑似アニメでは合成方式が通常以外のセルは扱いにくい事にはなります。そうなると、加算の描画が修正されたりと画像表示自体は改善されているわけですが、実用上は元の方が良いようには思えます。

[k4nagatsuki]

pull request #211

浮動小数点数の計算が遅いようなので丸め方を変えました。マシになったと思います。

[ルンバ]

4.3と変わらぬ印象になりました。対応ありがとうございます。