アルゴリズムの勉強をかねて作ってみた「塗りつぶされた円を描く」関数。(私がアルゴリズムを考えたわけではありませんが…) こういうのをどんどん取り込んで、お絵描きツールの動きをもっと改善していきたいなぁ。

ものぐさなので普通に円を描いて塗りつぶしそうです たぶん余ってるページに描いてGCOPYかな？ 連続して描くことを考えるとGSAVEでいったん変数に入れてから、GLOADもありかも ただ、下の絵の色を考慮して半透明っぽく塗りつぶすなら… そのときは1ドットずつぽちぽちと描画していくしかないのかなぁ

そうなんですよ。 この関数は単純な塗り潰しですが、半透明で描くには1ピクセルずつ色を計算していくしかないので、今すごく時間がかかってるんです。(コンマ何秒の世界ですが…) なので、少しでも速いアルゴリズムにしたいんですよね。 この関数に使ったアルゴリズムはかなり速いと思います。 正直私の苦手分野なので頭痛いところです…

こういうのはどうだろ？ 　とりあえず○描いて塗りつぶしてGSAVE 　GSAVEした配列の色を直接編集、GLOADで描画 　これならGPSETでぽちぽちやるよりは早い…ような気がする 課題 　GSAVEしたときどういう形式で持ってるのかわからない 　なんとなく縦横と色情報いっぱいのような気がするけど

GSAVEした配列上で合成計算するというのも確かに手ですね。まとめて物理色に変換してくれるし。 ページ全体をGSAVEしたときに必要な配列のサイズは262144、すなわち512x512なことから、配列の中身は単にベタな色情報が入ってるだけな気もします。 （試しに1ピクセルだけ確認したら、論理色モードでGSAVEした配列[0]の中身は、GSPOITした結果と同じでした） GLOAD命令で縦横省略した時の動きが説明不足でさっぱりわからんのが謎ですが…

結論から言うと残念な自己レスですが、GSAVEした配列上で計算しても速度向上はごくごくわずかでした。 画像は512x512のページ全体の輝度を上げ下げするサブルーチンを上記に対応させたものですが、旧ルーチンで2.8秒かかるのが2.7秒になったかな…という程度ですね。 ボトルネックになっているのは描画よりも計算そのものみたいです。 逆に言うとGPSETはかなり高速だということですかね。