提案:WSM専用でNEXTエンジンのカラーセルバグ対策オプションを設ける
まず下の背景変更コンテンツxmlをツリーにペーストしたWSMシナリオで1.50&Pyと、NEXTでの表示の違いをご覧下さい。
画面内、下段と上段のセルの色の差をエンジンごとに比較していただければわかるように
NEXTのカラーセルは合成方式が通常以外だと、不透明度を下げると他エンジンよりもかなり薄くなり
(不透明度255%だと変わらず)特に合成方式が減算の場合は彩度もかなり落ちた表示になります。
写真に不透明度を調整したカラーセルを重ね夜景を表現しているようなシナリオはどこかで見かけた事がありますが、そのような場合は、このバグが大きく影響し、使用エンジンによって同じ1.50形式なのに想定外の描写になります。
しかしこれは単色セルの場合のみ発生するバグで、同色でのグラデーションセルにしてしまえば発生しないようです。(中段)
とはいえ手動で一々同色グラデーションを作成するのも面倒です。不透明度を変更するたびに倍の手間がかかります。
そこでWSMシナリオ向けのオプションとして、単色セルはWSMデータ上は同色グラデーションとして保存され、xエディター上では単色セルとして開かれるようなオプションを提案します。作業中は今までと同じように単色セルとして扱えるが実データとしては同色グラデとして保存されればNEXTエンジンで開いても同じ色表示になります。
このオプションONの状態で完成済みシナリオを開き保存しなおせば単色セルを同色グラデセルに一括変換されるという事にもなれば既存シナのNEXT対応も簡単に解決できます。(結果的にxエディタの使用者も増えるかもしれません)
解決方法は他にもっと良い方式があるかもしれませんが、WSMシナリオはより多くのユーザーに同じようにプレイ可能であるべきなので何らかの方法でこのバグの対応を提案します。
<?xml version="1.0" encoding="UTF-8"?>
<Change type="BgImage" transition="Default" transitionspeed="5" contentId="7212DF96F8-499143585819/10000000-412" lastNextType="None" paneId="720D5FB208-501218647891/10000000">
<BgImages>
<BgImage smoothing="Default" mask="False">
<ImagePath>MapOfWirth.BMP</ImagePath>
<Flag/>
<Location left="0" top="0"/>
<Size width="632" height="420"/>
</BgImage>
<ColorCell>
<BlendMode>Normal</BlendMode>
<Color r="0" g="128" b="255" a="250"/>
<Flag/>
<Location left="158" top="52"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Add</BlendMode>
<Color r="0" g="128" b="255" a="250"/>
<Flag/>
<Location left="267" top="52"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Subtract</BlendMode>
<Color r="0" g="128" b="255" a="250"/>
<Flag/>
<Location left="385" top="52"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Multiply</BlendMode>
<Color r="0" g="128" b="255" a="250"/>
<Flag/>
<Location left="511" top="52"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Normal</BlendMode>
<Color r="0" g="128" b="255" a="150"/>
<Gradient direction="LeftToRight">
<EndColor r="0" g="128" b="255" a="150"/>
</Gradient>
<Flag/>
<Location left="158" top="134"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Add</BlendMode>
<Color r="0" g="128" b="255" a="150"/>
<Gradient direction="TopToBottom">
<EndColor r="0" g="128" b="255" a="150"/>
</Gradient>
<Flag/>
<Location left="267" top="134"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Subtract</BlendMode>
<Color r="0" g="128" b="255" a="150"/>
<Gradient direction="TopToBottom">
<EndColor r="0" g="128" b="255" a="150"/>
</Gradient>
<Flag/>
<Location left="385" top="135"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Multiply</BlendMode>
<Color r="0" g="128" b="255" a="150"/>
<Gradient direction="LeftToRight">
<EndColor r="0" g="128" b="255" a="150"/>
</Gradient>
<Flag/>
<Location left="511" top="134"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Normal</BlendMode>
<Color r="0" g="128" b="255" a="150"/>
<Flag/>
<Location left="158" top="221"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Add</BlendMode>
<Color r="0" g="128" b="255" a="150"/>
<Flag/>
<Location left="267" top="221"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Subtract</BlendMode>
<Color r="0" g="128" b="255" a="150"/>
<Flag/>
<Location left="385" top="221"/>
<Size width="69" height="58"/>
</ColorCell>
<ColorCell>
<BlendMode>Multiply</BlendMode>
<Color r="0" g="128" b="255" a="150"/>
<Flag/>
<Location left="511" top="221"/>
<Size width="69" height="58"/>
</ColorCell>
<TextCell>
<Text>上段255%</Text>
<Font size="25" bold="true" italic="false" underline="false" strike="false">MS ゴシック</Font>
<Vertical>false</Vertical>
<Color r="0" g="0" b="0" a="255"/>
<Bordering type="Outline" width="1">
<Color r="255" g="255" b="255" a="255"/>
</Bordering>
<UpdateType>Fixed</UpdateType>
<Flag/>
<Location left="9" top="55"/>
<Size width="140" height="33"/>
</TextCell>
<TextCell>
<Text>中段150%~\n 150%</Text>
<Font size="25" bold="true" italic="false" underline="false" strike="false">MS ゴシック</Font>
<Vertical>false</Vertical>
<Color r="0" g="0" b="0" a="255"/>
<Bordering type="Outline" width="1">
<Color r="255" g="255" b="255" a="255"/>
</Bordering>
<UpdateType>Fixed</UpdateType>
<Flag/>
<Location left="9" top="140"/>
<Size width="147" height="59"/>
</TextCell>
<TextCell>
<Text>下段150%</Text>
<Font size="25" bold="true" italic="false" underline="false" strike="false">MS ゴシック</Font>
<Vertical>false</Vertical>
<Color r="0" g="0" b="0" a="255"/>
<Bordering type="Outline" width="1">
<Color r="255" g="255" b="255" a="255"/>
</Bordering>
<UpdateType>Fixed</UpdateType>
<Flag/>
<Location left="9" top="235"/>
<Size width="147" height="59"/>
</TextCell>
</BgImages>
</Change>
Comments (16)
-
repo owner -
reporter NEXTのバグへの対応であり不急なので後回しでけっこうです。
ただ、おっしゃるようなNEXTシナからの変換の際に、他に合わせるという機能もそれはそれで有益なのですが、
本課題は、WSMシナリオでどのエンジンでも見た目同じに見える様にする提案ですのでそちらも検討願えたらと思います。とりあえず上のxmlをエンジン上で描画した比較画像をあげます。
各列合成方式は左から 通常 加算 減算 乗算 で
NEXTの下段の見え方は実数とa値が異なる印象で色が薄げで減算の彩度も異なりますが
中段のように同色グラデに変換してしまえば正常に描画されてるっぽく問題なさそうに見えます。また、現在このバグの規則性を見つけようとカラーセルの描画をエンジンごとに比較しておりますが、このNEXTバグ以外にも、
Pyにも他のエンジンと描画処理が異なる点がある様で、その対応によってこちらの課題も影響があるかもしれませんし
そちらはバグとしてこれからCardWirthPy Rebootの方で課題を別に立てます。※https://bitbucket.org/k4nagatsuki/cardwirthpy-reboot/issues/1007/150で実質解決 -
reporter なおNEXTはWirthBuilder上の編集画面でもこのように見えています。
-
reporter 背景画はgroupAskの著作物です
-
reporter 上の背景を255%合成方式通常の灰色にかえてみたらなぜかNEXTは元のマップオブワースが透けますね。
-
repo owner なんだこれ……。計算式が違う程度ならオプションを増やせばいい話なのですが、最後の現象を見ると再現が難しそうな気がしてきました。
-
repo owner -
reporter PyとXEditorセルの描画の問題は修正いただき、またNEXT専→WSN変換での再現は困難そうですので、当初の課題の提案を整理します。
NEXTエンジンで合成方式通常以外でa値が255%以外の単色カラーセルが他エンジンと著しく異なる描画になるバグは、『同色、同a値でのグラデーション』にする事で解決可能です。CWXEditorを用いないシナ作者でも、全エンジンで齟齬の無い描画を想定するならこの方法をとる事になるでしょう。しかし手動での変更はシナリオサイズが長大であるほど労力が必要です。
そこでCWXEditorでは
①WSM保存時『合成方式が通常以外のグラデーション無しのカラーセル』は『同色、同a値でのグラデーション』に変換し保存しする。
②WSMを開く際には『合成方式が通常以外の同色、同a値グラデーションのカラーセル』なら(作業簡易化のため)単色グラデーション無しのセルに変換し開く。
③WSNには無意味な要素なので、WSMをWSNにする際には同色グラデは単色化されるが、WSNをWSMで保存する際には同色グラデ化変換は行われる。
という機能を設けるべきです。これならシナリオ作者としては作業上は今まで同じように行なえます。
シナリオ作者はエンジン専用シナ以外ではどのエンジンでも同様に再現する事を望むので、とても有益な機能です。デメリットをあげるなら実装以前のXEditorや、XEditor以外で開いた時には当然、同色、同a値でのグラデーションで開かれるので、それらと並用するシナ作者にとってはオプション化の方がいいのかもしれません。(特にこのバグを知らないワースビルダー並用者の混乱回避のためには)
また並用の際に、0~244%までと255%で異なる処理になるのも混乱の元かと思いますので、問題が視認されないa値255%でも同色のグラデーションに変換してしまうべきかと思います。(同様な理由で合成方式通常の単色セルも同色グラデ変換してしまうべきかは考えどころですが個人的には不要な気がします)念の為NEXTの合成方式が通常以外の同色グラデセルで、グラデ方向が「左から右へ」と「上から下へ」で描画に違いがないか見た所、目視上は無いようです。
変換の際には当然同色グラデの方向が「左から右へ」と「上から下へ」のどちらかに統一される事になりますが、手動で行う際は「左から右へ」を選択する方が手間が少ないので「左から右へ」に統一の方がいいのかもしれません。(「左から右へ」は三択の中央なので「グラデーションなし」「上から下へ」のどちらへも変更しやすいともいえる?)
これは正直どちらでもいいですが。 -
repo owner このバグが発生するカラーセルを配置した場合、1.50向けに作ったシナリオでは常に問題が発生するので、見えづらいようなサポートを行うと余計に混乱を冗長するように思います。
この問題に触れる可能性のあるシナリオ作者全員に告知しなければなりませんが、それは要するに1.50以降を使うすべてのクラシックシナリオの作者であって、その告知をエディタが担うとなると、クラシックシナリオでのカラーセルの配置の際に警告を発する、という機能を載せる事になります。
つまりこれは誤り検索が担うべき問題ではないでしょうか?
-
reporter WSMだと合成方式が通常以外のグラデーション無しのカラーセルを誤り検索で警告するというような事ですか。たしかにそれは必要な気がします。
ただそれはそれとして、やはりWSMシナで合成方式が通常以外の単色カラーセルを作る際に、一々手動で同色グラデーションを設定する労力の解決方法もあるべきでしょう。たとえば夜景表現で紺色の乗算を重ねる、電撃の表現で黄色を加算する等といった表現に色調整はつきものでしょうが、その都度基本色と終端色を合わせ直す倍の手間が必要なわけです。
他の方法としては、カラーセル作成ウィンドウに
・『終端色を基本色に揃える』ボタンを設けワンクリックでそうなるようにする、とか
・グラデーションのドロップウインドウの「グラデーション無し」の下に「終端色を基本色と揃える」をWSMでのみ設け、基本色を変更すると自動で終端色も連動するようにする。(また、オプションで「カラーセルの終端色を基本色と揃えるをデフォルトにする」を設ける)といった方法もあるかと思います。
ただ、これだと既存のシナリオをバグ対応する際の省力にはなりません。そういった次第で警告と、変換保存のオプションの両方が望ましいと思います。その場合はオプションがONでない場合に「合成方式が通常以外のグラデーション無しのカラーセル」が誤り検索で警告されるという感じでしょうか。(もちろん、もっといい方法があればそれにこした事はないです)
警告のみでバグが周知された場合、手動対応には今までより手間が増えるわけなので、まじめに多エンジン対応を作ろうとする作者の労力だけ増え、そこまでしたくない作者は通常以外の合成方式を忌避するという何か時代を逆行するっぽい事になりそうな気もします。あるいは多エンジン互換をやめる動機に働くとか。
直接は治しようのないNEXTのバグのためxエディタ側の改良に労を求めるのは申し訳ないのですが。 -
repo owner 色を合わせる機能は単純に便利そうなので設けることに異存はありませんが、自動的な変換機能まで必要でしょうか? そういうシナリオがすでに大量に存在するのであれば必要ですが、実際どの程度あるのでしょう?
-
reporter たしかに(私の知る限りでは)大量にあるとは言えないですね。
では変換保存ではなく、警告と、色を合わせる機能という方向でご検討いただければと思います。 -
repo owner -
reporter ご対応有り難うございます。
新設3種ボタンはこのバグ対応以外でも便利で助かります。
以下実際に、誤り検索から複数箇所の修正を行ってみた所の所感です。・警告について
背景変更コンテンツやシーンビューのセルリスト上のカラーセルのアイコンの上にも警告アイコンが表示される方がわかりやすくはなると思います。
誤り検索から辿り着くとしても、グラデーションなしのカラーセルが複数ある場合どれが該当するか開いてみないとわからないからです。・終端色は基本色がコピーされた状態をデフォルトにした方が良い
現在仕様ですと終端色のデフォルトは<EndColor r="0" g="0" b="0" a="255"/>です。
黒のグラデーションは割合用いられやすい方だとは思いますが(このバグ該当以外のケースも含め)普通に最もありそうなのは「終端色と基本色が同じrgbで、a値だけを増減するグラデーション」かと思います。
たとえ黒のグラデーションばかり必要とするユーザーがいても、この仕様変更後も基本色を黒にすれば単にそれがコピーされるので特に不利益は発生しません。(黒以外の色と黒とのグラデーションを多数必要とするユーザーのみが不利益を被る事になりますが、そのような用途は極めて稀でしょう)NEXTのバグ該当に限ったケースとしても、たとえば、徐々に画面を暗く(明るく)してゆく演出をする際、多数の乗算(加算)セルを重ねてゆくという事は演出上普通に行われえる事です(エフェヴだとカードも含め暗くなるので、背景のみ暗くしたい場合は使えません)ので多数の処理を省力可能にすべきでしょう。
ですので、この際、終端色は基本色がコピーされた状態がデフォルトになる方が合理的かと思います。
-
repo owner 終端色はたぶんWirthBuilderに合わせてこういう仕様にしたんだと思うんですが、同色のほうが使いやすそうなのはその通りなので変更します。グラデーション無しの時は終端色のデータが保存されないので、再読込時に同色になるようにしました。
警告の表示方法はこの機会に全体的に見直しました。
-
reporter - changed status to resolved
修正確認しました。NEXTバグ対応以外でもカラーセル操作が非常に効率的に改善されました。ありがとうございます。
- Log in to comment
ありがとうございます。
いまちょっと(というかほとんど)時間が取れないので確認していないのですが、α値が過剰に小さくなるというような症状でしょうか。
法則が分かれば、シナリオの変換時に対応できそうな気がします。