Jw_cad作者さんのサイトの掲示板で以下の発言がありました
え？
・・・
今更そんな話・・・？
・・・
ラバーバンド、ズーム枠色、クロスラインカーソルの色は、背景色が白色以外の場合は、反転色になる、っていうのが、古からのお約束じゃないですか〜
なんで反転色（XOR色）になるのか、って？
そんなの
線を作図するときに、XOR モードで作図するからに決まっている。
なんで XORモードで作図するのかというと
２度描きすれば、元に戻るからに決まっている。
AND演算は
Ａ値 Ｂ値 結果値
０ ０ ０
０ １ ０
１ ０ ０
１ １ １
という風に、Ａ値Ｂ値がどちらも１の時にだけ、１になる。
OR演算は
Ａ値 Ｂ値 結果値
０ ０ ０
０ １ １
１ ０ １
１ １ １
という風に、Ａ値Ｂ値どちらか１の時に、１になる。
XOR演算は
Ａ値 Ｂ値 結果値
０ ０ ０
０ １ １
１ ０ １
１ １ ０
という風に、Ａ値Ｂ値の片方が１の時にだけ、１になる。
これはビット演算だから例えば
１０１１１０１０１０１１１０１０１０１１０１０１０１０
１１１１１１１１１１１１１１１１１１１１１１１１１１１
−−−−−−−−−−−−−−−−−−−−−−−−−−−
０１０００１０１０１０００１０１０１００１０１０１０１
となるけど再度 同じように XOR演算すると
０１０００１０１０１０００１０１０１００１０１０１０１
１１１１１１１１１１１１１１１１１１１１１１１１１１１
−−−−−−−−−−−−−−−−−−−−−−−−−−−
１０１１１０１０１０１１１０１０１０１１０１０１０１０
となって元の値に戻る。
画面に表示されてる絵：１０１１１０１０１０１１１０１０
仮表示色・ズーム枠色：１１１１１１１１１１１１１１１１
ＸＯＲ演算−−−−−−−−−−−−−−−−−−−−−−
画面に表示される絵 ：０１０００１０１０１０００１０１
↑ これが「整合性が取れてないじゃん」
＝指定色と実際に表示される絵が違う〜
って所。
で、再度 線の書き直しをすると
画面に表示される絵 ：０１０００１０１０１０００１０１
仮表示色・ズーム枠色：１１１１１１１１１１１１１１１１
ＸＯＲ演算−−−−−−−−−−−−−−−−−−−−−−
画面に表示される絵 ：１０１１１０１０１０１１１０１０
これは
ラバーバンドやズーム枠の線をXOR作図する前の状態と同じだよね。
画面に線を描いた後にその線を消すと＝背景色で同じ線を描くと、元の画面はその線を消した跡が残ってしまうよね。そうすると、画面を一旦全部消して、画面の描き直しをしないと綺麗に戻らない。画面に描いた線などが多ければ多いほど時間も掛かる。画面を一旦全部消すから画面もチラチラしてしまう（これは裏画面を使う事で低減できるけど）。そんなの、ラバーバンド等を描き直し＝マウスを１ドットずつ移動するたびに、やってられると思う？ 無理に決まっているｗ
まぁ、昔から、シューティングゲーム等で 貧弱なハードで高速描画させるため・ちらつき防止などのために XOR もよく使われるけど、色が変わるのがやはり我慢出来ないという事で、作図前の画面をバックアップし キャラのマスク画像で抜いて キャラ絵を合成して 画面表示 次の移動時にはバックアップした画像を描いて 描き直す、みたいな事をしてたけれども、操作が多くなる以上、遅くなるし、バックアップするメモリも必要になってくる。だから、スプライト機能みたいなのも出来た。
ラバーバンドやズーム枠色でも同様に、バックアップをして、描いて、バックアップした画像を戻す、って事も出来るだろうけど、こういう絵は画面一杯になる事もあるから、画面一杯になった場合の画像のバックアップのメモリも地味に増大していくし、処理も面倒だし、時間も掛かってしまう。
スプライト機能と同じように、別オブジェクトにしてしまう、という事も出来るだろう。つまり、図面を表示する画面の上に、Shapeオブジェクト等を配置しておいて、それをラバーバンドやズーム枠に利用する、という手法だ。使ってない場合は非表示にしておけば干渉はしない。でもまぁ、Jw_cad を見た感じでは、そういう手法は使っていないのだろう。
時代とともにハードウェアの高速性が求められていくと当然、画像に対するANDとかORとかXORのような操作＝ラスターオペレーションの処理速度もアップされていく。画面スクロールに使われるブロック転送についても同じ。もともと、Windows3.1 の頃も、画面描画が遅くて Windows対応のリアルタイムなゲーム（シューティングゲーム等）は実現は無理〜とか言われてたけれども、それに対応すべく開発され始めたのが「WinG」であり、それの拡張版である「GameSDK」から、VGAの機能をもっと直に利用しようぜ、という DirectDraw＝DirectX へと続いていく。CADやCG等のアプリでも当然、画面描画をする以上 WindowsGDI、GDI＋、DirectX（Direct3D）、Direct2D、OpenGL、のいずれかを使うだろう。新しいVGAカードが出て、新しい描画手法が実装されそれに対応するAPIも出てくるかもしれない。ゲームの話？そんなの関係ねぇ〜！とか思う人も居るだろうが、実際問題、ゲームのほうがハード問題・OS問題と切実に向き合ってきたからこそのDirectX発展だったといえる、かもしれない。3DのOpenGL絡みは元々のシリコングラフィックス＝ワークステーションからおりてきたもんで経路が違うから元々話はゲームはあんまり関係無い。
ちなみに、NEC PC-98のアプリケーション登録をしていると、ソフトハウスには色々と資料が送られてきてたけれども、まぁ、新機種情報とかが多かったんだけれども、その中に、GameSDKについての資料もあったように記憶してる。まぁ、DOSからWinになって、NECも PC-98シリーズ路線を辞めて、そういった情報も出なくなり、Microsoft 情報をどうぞってな風になったけど、最初の Microsoft の WindowsSDKの本の分量はハンパじゃないんだけどｗｗｗ まぁ情報があるだけ良いわな〜とか思ったもんだ。あ、ぜんぜん読んで無かったけどｗ
あ、何の話だっけ？ｗ
背景色が"黒"の場合、
仮表示色設定（RGB値）とラバーバンド色との整合性がとれてないように思いますが---
（例）
仮表示色設定値（0 255 255）⇒ ラバーバンド表示色（255 0 0）
どうでしょう？（jww8.03a)
え？
・・・
今更そんな話・・・？
・・・
ラバーバンド、ズーム枠色、クロスラインカーソルの色は、背景色が白色以外の場合は、反転色になる、っていうのが、古からのお約束じゃないですか〜
なんで反転色（XOR色）になるのか、って？
そんなの
線を作図するときに、XOR モードで作図するからに決まっている。
なんで XORモードで作図するのかというと
２度描きすれば、元に戻るからに決まっている。
AND演算は
Ａ値 Ｂ値 結果値
０ ０ ０
０ １ ０
１ ０ ０
１ １ １
という風に、Ａ値Ｂ値がどちらも１の時にだけ、１になる。
OR演算は
Ａ値 Ｂ値 結果値
０ ０ ０
０ １ １
１ ０ １
１ １ １
という風に、Ａ値Ｂ値どちらか１の時に、１になる。
XOR演算は
Ａ値 Ｂ値 結果値
０ ０ ０
０ １ １
１ ０ １
１ １ ０
という風に、Ａ値Ｂ値の片方が１の時にだけ、１になる。
これはビット演算だから例えば
１０１１１０１０１０１１１０１０１０１１０１０１０１０
１１１１１１１１１１１１１１１１１１１１１１１１１１１
−−−−−−−−−−−−−−−−−−−−−−−−−−−
０１０００１０１０１０００１０１０１００１０１０１０１
となるけど再度 同じように XOR演算すると
０１０００１０１０１０００１０１０１００１０１０１０１
１１１１１１１１１１１１１１１１１１１１１１１１１１１
−−−−−−−−−−−−−−−−−−−−−−−−−−−
１０１１１０１０１０１１１０１０１０１１０１０１０１０
となって元の値に戻る。
画面に表示されてる絵：１０１１１０１０１０１１１０１０
仮表示色・ズーム枠色：１１１１１１１１１１１１１１１１
ＸＯＲ演算−−−−−−−−−−−−−−−−−−−−−−
画面に表示される絵 ：０１０００１０１０１０００１０１
↑ これが「整合性が取れてないじゃん」
＝指定色と実際に表示される絵が違う〜
って所。
で、再度 線の書き直しをすると
画面に表示される絵 ：０１０００１０１０１０００１０１
仮表示色・ズーム枠色：１１１１１１１１１１１１１１１１
ＸＯＲ演算−−−−−−−−−−−−−−−−−−−−−−
画面に表示される絵 ：１０１１１０１０１０１１１０１０
これは
ラバーバンドやズーム枠の線をXOR作図する前の状態と同じだよね。
画面に線を描いた後にその線を消すと＝背景色で同じ線を描くと、元の画面はその線を消した跡が残ってしまうよね。そうすると、画面を一旦全部消して、画面の描き直しをしないと綺麗に戻らない。画面に描いた線などが多ければ多いほど時間も掛かる。画面を一旦全部消すから画面もチラチラしてしまう（これは裏画面を使う事で低減できるけど）。そんなの、ラバーバンド等を描き直し＝マウスを１ドットずつ移動するたびに、やってられると思う？ 無理に決まっているｗ
まぁ、昔から、シューティングゲーム等で 貧弱なハードで高速描画させるため・ちらつき防止などのために XOR もよく使われるけど、色が変わるのがやはり我慢出来ないという事で、作図前の画面をバックアップし キャラのマスク画像で抜いて キャラ絵を合成して 画面表示 次の移動時にはバックアップした画像を描いて 描き直す、みたいな事をしてたけれども、操作が多くなる以上、遅くなるし、バックアップするメモリも必要になってくる。だから、スプライト機能みたいなのも出来た。
ラバーバンドやズーム枠色でも同様に、バックアップをして、描いて、バックアップした画像を戻す、って事も出来るだろうけど、こういう絵は画面一杯になる事もあるから、画面一杯になった場合の画像のバックアップのメモリも地味に増大していくし、処理も面倒だし、時間も掛かってしまう。
スプライト機能と同じように、別オブジェクトにしてしまう、という事も出来るだろう。つまり、図面を表示する画面の上に、Shapeオブジェクト等を配置しておいて、それをラバーバンドやズーム枠に利用する、という手法だ。使ってない場合は非表示にしておけば干渉はしない。でもまぁ、Jw_cad を見た感じでは、そういう手法は使っていないのだろう。
時代とともにハードウェアの高速性が求められていくと当然、画像に対するANDとかORとかXORのような操作＝ラスターオペレーションの処理速度もアップされていく。画面スクロールに使われるブロック転送についても同じ。もともと、Windows3.1 の頃も、画面描画が遅くて Windows対応のリアルタイムなゲーム（シューティングゲーム等）は実現は無理〜とか言われてたけれども、それに対応すべく開発され始めたのが「WinG」であり、それの拡張版である「GameSDK」から、VGAの機能をもっと直に利用しようぜ、という DirectDraw＝DirectX へと続いていく。CADやCG等のアプリでも当然、画面描画をする以上 WindowsGDI、GDI＋、DirectX（Direct3D）、Direct2D、OpenGL、のいずれかを使うだろう。新しいVGAカードが出て、新しい描画手法が実装されそれに対応するAPIも出てくるかもしれない。ゲームの話？そんなの関係ねぇ〜！とか思う人も居るだろうが、実際問題、ゲームのほうがハード問題・OS問題と切実に向き合ってきたからこそのDirectX発展だったといえる、かもしれない。3DのOpenGL絡みは元々のシリコングラフィックス＝ワークステーションからおりてきたもんで経路が違うから元々話はゲームはあんまり関係無い。
ちなみに、NEC PC-98のアプリケーション登録をしていると、ソフトハウスには色々と資料が送られてきてたけれども、まぁ、新機種情報とかが多かったんだけれども、その中に、GameSDKについての資料もあったように記憶してる。まぁ、DOSからWinになって、NECも PC-98シリーズ路線を辞めて、そういった情報も出なくなり、Microsoft 情報をどうぞってな風になったけど、最初の Microsoft の WindowsSDKの本の分量はハンパじゃないんだけどｗｗｗ まぁ情報があるだけ良いわな〜とか思ったもんだ。あ、ぜんぜん読んで無かったけどｗ
あ、何の話だっけ？ｗ
詳細な解説ありがとうございました。
（”アホ”な奴ですが---）
絵画的に、下地が変わるだけと、思ってました。