いや、0ゼロとOオー間違えても大丈夫にするための仕様って訳じゃないです。たまたま結果そうだっただけ^^; それに変数Oオーすでにちゃんと目的があって他で値代入されて使われてたら、0ゼロと間違ったら大丈夫じゃないだろうし。 ＃冗談のつもりでした。混乱させちゃってたら ＃ごめんね。

0ゼロとOオーを間違えてもいいように、プチコンでは変数を定義しなくても使える仕様になっています:-p

PROJECT"SYS":FILES とかはできるんですよね。まぁPROJECTがDirectモード専用かっていうと微妙なところではありますが^^;

1000回で6msとなると、カラーピッカーのサイズが仮にRGB32階調全色数分あるとすると32×32×32=32768ピクセルだから、え～と、、、とにかく結構な時間短縮になりそうですね^^; ＃こだわりは伝わりました。

お絵描きツールで普通にものを描く機能(って書くとよう分からんな。普通の細いペンの機能ね)なんかは、GPSETじゃなくGLINE使ってるのを良く見かけますね。GLINEとGFILLだとどっちが速いんだろう？

ちょっと前に私も気付きました。BIGでも同様のようです。Directモード専用の命令だからって訳じゃなく、特定の命令は繋げられなくなってるみたいです。他に、何かに続けてRUNもできないようです(教えていただきました)。 例えばFILESをちょっと拡張した短めのプログラム作ってKEY 1に登録して使いたいなぁと思った時に、配列宣言はDuplicateになっちゃうから先頭にCLEAR、とかしたかったんだけどダメなんですよねぇ。 それで何となくなんですけど、CLEARの後を有効にすると、Directモードで色々できるようになっちゃってあぶないこととかあるからできないようになってるのかなぁ、と思ってます(何があぶないかは分かってないけど^^;)。

おぉ～、CLSで上手く動くようになりました(^o^) ＃CLS気付かなかったとは。。。恥ずかしい^^; ただ、まだちょっと謎があるのでもう少し調べようと思ってます。 説明しときますと、画面の幅/高さ種類の配列用意しといて、サイズ大きい方から「PRINTサイズいっぱい」を実行していって、想定していたサイズとCSRX,CSRYが一致していればその画面サイズだろうと判定しています。 で、大きいサイズから「PRINTサイズいっぱい」を順に実行しているので、毎回かならず全画面スクロールして、画面に文字残らないはずなんですよね。 とは言え、デバッグの糸口掴めたような気がします(CLSで動いてるからそれで良いっちゃ良いんですけど、気になるもので^^;)。

ぼかし関数、やっと整いました(^o^) ＃え～、「画像処理」とかけまして ＃「ヤクルト戦のプロ野球解説」と説く ＃そのこころは?^^; 公開キー：N3S8N5HS ファイル：SUFBLR01_S1 ガウシアンぼかしの関数を、FILLタイプとSPOITタイプ、ついでにブロックぼかしのFILLタイプも入れときました。 SPOITタイプは指定座標1ピクセルのぼかした色を取得するだけですが、ぼかしペンに使えるかと思って用意しました。また、3×3と5×5はよく使われるんじゃないかと思い、テーブル固定の高速版を用意しました(SPOITのみです。FILLは固定にしても速度ほとんど変わらなかった)。 バグ、見た感じ大丈夫そうだけど画面端っこ処理はどっか間違ってるかも(座標足し算引き算こんがらがっちゃって^^;)。何か気付いたこととかありましたらご指摘頂けるとありがたいです。とっても。

ようし、現時点で改善ネタはもう尽きたはずだ。ということで、最新版公開。 公開キー：N3S8N5HS ファイル：SUFBLR01_S1 詳しいことは3号のmoh6anさんの研究会その2の方で説明しようと思いますので、興味のある方はそちらをのぞいてみてください。

あっ、上画面/下画面っていうのは例えば上画面を上下2分割した際の、上/下のつもりでした^^; 私も今は見たい部分を見えるところにコピペしたり別スロットにコピペしたりしてます。 私の場合は別のところを見ながら、ってのができれば結構うれしいんですけど、みんなはどうなんだろう? 画面切り替えて見るのも良いんですけど、切り替えた瞬間忘れちゃうこともあって、画面切り替えを何度も繰り返しちゃったり^^;

例えば上画面で変数定義部分見ながら、下画面でコーディング、新しい変数必要になったらカーソル上画面に移動して変数定義追加、とか考えてました。 まぁ、マークとジャンプができれば画面分割できなくても全然平気そうですね(^^ゞ ＃完成楽しみにしてます(^o^)

あれ?まだないものの中にマルチ画面が見当たらないなぁ:-p 画面分割表示できればかなりのアドバンテージかと思いました。2分割でも十分。

適当に全部の配列を実数型にするんじゃなく、必要なのだけ実数型にして、分子分母別々誤差最小作戦やってみたら、あまり暗くならないフィルターができました(^o^)ただちょっと遅い。 右上が従来。右下が誤差最小作戦。 ＃関数完成したと思っても、次々と改善ネタが ＃湧き出てきちゃうなぁ^^;

私のあの暴走はここの投稿者の誰かに向けてということでは全くなくて、日頃度々現れるプチコンの謎仕様に悩まされ溜まったストレスが漏れ出てしまったものでした。反省m__m。 バグ改修や機能改善はもちろん大事だと思うけど、SmileBoomにはもうちょっとドキュメントの充実、仕様開示にも力を入れて欲しいなぁと思う今日この頃。不明なことも試せば大体分かるっちゃ分かるんだけど、その頻度が多すぎていつの間にか試すことだけに終始しちゃうことが度々orz ＃おっと脱線。 ＃そろそろトピ閉めたかったかな。ごめんね。

私はその無段階に選べるような滑らかなカラーピッカーが苦手(というか食わず嫌いで使ったことない)。 だって1ピクセル毎に違う色なんでしょ?狙った色選ぶの大変そう。「うぁ～ズレてたぁ～この色じゃな～い」みたいな。えっ?そんな使い方じゃない?(^^ゞ あと、私の目は生まれつき赤と緑の区別がつきにくいので、結局RGB値で確認したくなるというのは全くの個人的都合。色塗るの苦手^^;

係数の分子と分母分けて誤差少なくしてみようと試したら、ヘンチクリンなフィルターに^^; RGB関係の配列全部実数型にしたらアカンみたいね。そしてやっぱり実数型配列BIG遅いようだし(倍近くの処理時間になっちゃった)。 さぁ、限界と思ってた速度も、実はRINGCOPY使える奴だったことが分かってまた少し速くできました。前に、RINGCOPYはコピー先/コピー元同じだとダメって言ったことあったんだけど、実はコピー先/コピー元同じでも大丈夫みたい。リファレンスやヘルプのマルチチャンネル云々がよく分からなくて誤解してました(今でもあの文章自体の意味は分からんけど)。 RINGCOPYを画像配列に対して有効に使うには2次元で定義した方が良いんだけど、その際、オフセット値に指定できるのは低次元側の要素数(G%[Y,X]ならX)の範囲である必要がありました。 ＃もうこれ以上いじるとこないはずだ。

配列の整数型が実数型より速いと言ったものの、それはBIGでのことだったので、3号(旧3DS)でも確認してみたら、ほとんど変わらないみたい(試したケースではむしろ実数型の方が僅かに速かった)。 ケースにも依るだろうし、一概に速い遅い言うのは難しいかもしれませんね。

確かに暈すと暗くなったように見えますね。論理的には、係数のテーブルの合計が1になっていれば暗くなることはないはずなんだけど、実数から整数への変換の際の丸め誤差で暗くなっちゃうのかな。誤差なるべく出さないためには、例えば係数を分子と分母に分けといて、分子だけ掛けて全部足したあと最後に分母で割るとか。面倒だけど。 あといつものGRP4のみたいに透明部分多いと、混ぜる時にそこケアしとかないと透明の黒と混ざって暗くなっちゃう。 某更新料さん暈しGPAINT作られてましたか。これは楽しみ(^o^)早くパクリたいなぁ(^^ゞ 私が暈しにハマったのがまさにギザギザきっかけ。手動アンチエイリアシングは苦行過ぎ。 画像は左上オリジナル、右上15×15ガウシアン暈し、左下3×3を5回ブロック暈し、右下3×3を5回ガウシアン暈し。白背景で。3x3数回に分けてもそれなりに見える(速度はその方が速い)。

ふとFILES 3列で表示しようと思い、プログラムしてたら画面サイズの判定方法思い付いたのでそれと共に組み上げたのですが、惜しいところでバグって困ってます。 本命は画面サイズ判定なのですが、やってることは画面サイズの種類毎にコンソール幅、高さいっぱいにPRINTした際のシステム変数CSRX,CSRYの値から判定してて、そこは上手くいっているようです。 ただ、コンソール使ってるので判定終わったらコンソール元に戻そうとしたのですが、それが上手くいきません。どうやらLOCATEの動作があやしそうなのですが、BIGでLOCATEバグってるって話ありましたっけ? 現象はXSCREEN 5,4以上のサイズの時だけLOCATE指定からずれた位置にPRINTされるというものです。BIGのバグのような気がしてるんだけどいまいち自分のプログラムにも自信がなくて。

キー載せときます。 公開キー：4DN5R3XD ファイル：EXFILES また、他の画面サイズ判定方法とかありましたら、教えていただけると幸いです。