＃忘れた頃にアップデート 実装してみると直したいところ出てくるもんですね。 　公開キー：NKF3A3YD 　ファイル：SUFBLR02_S1 更新内容： ・FILLタイプの関数は、ぼかした配列を返すだけにしました(描画は行わない)。 ・下記関数を追加しました。 　DIFF_ARY　2つの配列の違いを返す 　DIFF_SIZE　DIFF_ARYのサイズを返す 追加したDIFF～関数は、ぼかしPAINTに使いました。あと実装してみて気付きましたが、きちんとOut of memory対策するなら、DEF中のローカル配列はグローバルで持っといた方が良さそうですね。 DIFF～は賢いUNDOに利用できるかも。 ＃そう言えば、なぞかけっぱなしでしたね^^; ＃　そのこころとは、 ＃　ふぃるたぁが活躍するでしょう。 ＃お粗末(^^ゞ

私はプチコンのシフト演算が算術シフト?なるもの、っていうのを知らなかっただけで、2進数での計算は一応分かってるつもりです(^o^) 近頃は2進数で計算してたものをARYOPでどう実現するかで悩むことが多い(^^ゞ

CUI、逆に相性良いと考えることもできるかも。何故ならグラフィックリソース消費しなくて済むから。見た目かっこよく見せるのは難しそうだけど。

otta777さんの小ずるい方法面白いと思いました。そういう発想嫌いじゃないです(^o^) MIKIさん関数ありがとうございます。上手い方法ですね。 特に困ってるってことではなかったのですが、覚えとかないと後々謎バグ埋め込みそうで気を付けないとですね。

ぼかしも実装してみた。 ぼかしペン、ぼかしライン、ぼかしFILL、ぼかしPAINTが可能。 ぼかしPAINTのために、PAINT自体の機能に境界色指定を追加。 ぼかし自体はガウシアンで3×3～15×15まで。 3×3程度なら速度ほとんど気にならないけど、ぼかし強くするとかなり遅い。用意してたけど今まで出番のなかったクルクルアニメ(セーブとかで見かけるような)が大活躍です(喜ぶことではない^^;)。 とりあえず実装しただけで、Out of memory対策ちゃんとしてないんだよなぁ。DEF中のローカル配列はグローバルにする必要ありそうだけど、根本的にメモリ足りてるのかが怪しい。現状でも広範囲一気にぼかそうとすると「ピッ！」って落ちちゃうし^^; UNDO回数は減らしたくないし、広範囲ぼかしは分割して一度に使用する配列小さくしてみるか。

RGB(255,0,0,0)>>24 って255にならないんですね。 こういうもんだったっけ？(今更感^^;)

経験浅でまだあんまり気にしてなかったのですが、ランチャーとかに配慮するなら、ゲームでも無限ループしっぱなしじゃなくて、ちゃんと終了(startボタン長押しじゃなくて)できた方が親切だったかと、今更ながら思いました。 あとは、終了時に大きい配列はクリアしておくとか。 ファイル名やプロジェクト名については、キー公開時に一緒に示すのと、バージョンアップが見込まれてるならバージョン番号とかをファイル名やプロジェクト名に含めておいた方が親切かな、と思うくらいです。 ＃う～ん、普通^^;今の私に言えるのはこれくらい。

BIGにできて3号にできないことあります。 だにえるさんのおっしゃるように、BIGの方が処理速いので、複雑な処理のゲームだと3号では遅すぎて遊べないとか、画面の表示能力もBIGの方が高いので、XSCREEN 5とか6使うと3号にそのモードは無いので動かないとか。 他には複数のコントローラー使うとか。 3号にできてBIGにできないこともあります。 3号では3DS同士のローカル通信が4台までできるので、それぞれのプレイヤーが自分の画面だけを見れなきゃ成立しないようなゲーム(例えばトランプや麻雀など)を作ることができます。

無限ループというタイトルだと WHILE 1やREPEAT UNTIL 0 のように、条件部分が定数で、抜けるのはBREAK というのを連想しました。 条件部分が比較演算式とかなら、無限ループという感じではなく、ただのループかな。 ちょくちょく使う便利だと思うループは REPEAT VSYNC UNTIL BUTTON()

BIG専用と割り切って作れば、結構なレベルのもの出来そうだと思ってるんですが、つい3号のユーザー数の方が多いもんだから互換性保ちたくなっちゃうんですよね(^^ゞ スト2くらいのグラフィックなら難しくなさそうだけど、複雑で素早いコマンド入力の取得ってプチコンでは難しくなかったっけ? BUTTON関数って確かVSYNC 1空けないとちゃんと取得出来なかったと思うんだけど、それでボタン入力解像度足りるのかなぁって。 1/60秒、足りるか^^;

ソフトエッジの消しゴム改良できた(^o^) 下絵不透明と重なるエッジ部分だけを不透明で残しとけば良かっただけだった。 さあこれでやっと本命のぼかしペンに取り掛かるとするか。

ソフトエッジペン、なかなか手強かったがなんとか出来たようだ(と言っていいのだろうか)。 単純にペンの色透明にしたら消しゴムになるだろうと思ってたけど、ソフトエッジの場合、エッジ部分が色混ぜられて不透明になるので、そのままだと消しゴムみたいにならなくて。 結局タッチ中の座標全部覚えといて、タッチ離れたら覚えといた座標全てに対して透明色塗る(エッジは残して)ってしてるんだけど、重たい。気になりにくいタイミングではあるんだけど。 お絵描きツール作ってる方でソフトエッジ消しゴム実装してる場合、どうやってるんだろう?とても気になる。 画面はBACKCOLOR緑に透明ソフトエッジペンで字を書いた様子。

BACKCOLOR黒にするとこんな感じ。

ソフトエッジのペンが途切れる問題、未だ解決せず。手強いなぁ。 ペン先の処理が重いと途切れないんだけど、ちょっと処理軽くすると途切れちゃうんだよなぁ。う～ん、さっぱり分からん。

プチコンに潜んでるバグのせいなのか、WiiU自体の問題なのか、はたまたスピリチュアル的なものなのか^^; 定かではありませんね。 そういえば前に、宇宙線の影響でメモリの内容が壊れることがある、って言うメーカーの言い訳聞かされたことがあったっけ。真偽はよく分からなかったけど、そんな言い訳思い付くなんて、ってちょっと感心した覚えがある。

何よりも怖い夏の出来事。 ＃私はまだそういうの喰らったことないなぁ。 ＃自分のミスでやらかしたことは何度もあるけど。

その方法(複写、消す)でも少し大きく表示させることはできますが、それでももうちょっと大きく見せたいなぁなんて思うときは時々ありますね。 WIDTH 16にしてDirectモードにコピペしたりすることもあるけど、それだと文字1色になっちゃってあんまり見やすくないなぁ、って思ったり。

ありゃ、勘違いしてたようで、失礼しました。 プログラムスロットと実行時に使われるメモリ共通だと思い込んでました。ちゃんと分かれてる見たいですね。 ＃何かでFREEMEM増えるの見た気がしたんだけど ＃スマイルボタンがらみだったかな。

NEWしたらFREEMEM増えたので、ソースコードがスロットに存在してる時点で、そのサイズ分メモリ消費されてるんだろうなぁと思ってました。 プログラムにも依るだろうけど、よっぽどメモリいっぱいいっぱい使っていない限り、コメントでメモリ圧迫されるとかは気にしなくても大丈夫だと思います。

>立て続けに削除されてますけど。 一応、あの1件だけです。念のため^^; ＃初めてだったので少し驚いた。 ＃禁断の「AIで片っ端から作曲」ってのが ＃マズかったんだな(違う違う)。 プチコンに関係ないと思われなくて、誰かに不快と思われなくて、通報されなければ、まず削除されることはないと思います。多分。