＃1個足りなくない?:-p 配列確かに遅いと思うけど、何かプログラム作る前から気にしてもしょうがないと思いますよ。 ちょうど良いかどうかなんて作る前から分からないし、遅いからって配列使わなきゃどうにもできないこともあるだろうし。 何か作ってて遅いなぁと実感してからう～んどうしようかと色々考えた方が幸せだと思います(^o^) ＃まだ起きていない先の心配をしても意味がない ＃とか誰か言ってなかったっけ?

あと、RGB分離を先に済ましておく方法試してみたら結構効果ありました(^o^)。 ただ画像シフトはまだGLOAD/GSAVEのままなので、配列を直接シフトする方法これから試そうと思ってます(ついでにRINGCOPYも)。

今日ちょっと1次元係数のままの方法挑戦してたんですけど、なかなか上手い方法思い付かなかったんですよねぇ^^; 1次元ならx方向に係数かけた後、更にy方向に係数かければ、掛け算はx+y回だけで良いけど、色成分はx*y個分必要なのでx*y回足し算が必要。 それを単純に別々にARYOPしちゃうと#AOPMUL x+y回　＋　#AOPADD x*y回　なので 足し算と掛け算を一緒に行うことにして#AOPMAD x+y回　＋　#AOPADD x*y-(x+y)回 というのを考えてたんだけど、後者の切り分け?方法が思い付かなくて。 あと、上手いこと#AOPMAD使えたとしても、1次元と2次元でARYOPの回数は結局変わらない気がしてて(2次元だと全部(x*y回)#AOPMADなのが1次元だとx*y-(x+y)回だけ#AOPADDに置き換えられるからちょっとは軽くなるかもしれないけど)。

そっか、RGB分離のためのARYOPの回数自体を減らすためのアイデアだったんですね(今更理解^^;)。 RINGCOPY、2次元配列での動作よく分からなかったので試してみたら、横シフトになりました(^o^) 但しコピー先、コピー元は別配列じゃないとダメみたい。 DIM G%[H,W],O%[H,W] GSAVE 0,0,W,H,G%,0 RINGCOPY O%,1,G% ＃O%には1ドット右にズレた画像が入る。 コピー先コピー元同じにできたらもっと便利だったんですけどねぇ。

画像配列を横にズラすのに役立つかもしれない小技。 GSAVE -1,0,W,H,G%,0 ってすると、左端の画像データは0としてG%に格納されるみたい。

やっとできたガウシアンぼかし関数。 画面端だとか透明色とかの対処、私なりに考えて作ったつもりだけど果たして良いのかどうか。。。 そして1次元ガウス係数を1次元のまま使う方法は保留中。確かに係数の掛け算の回数は減らせるけど、結局2次元テーブル数分ARYOPで足さなきゃならなくて、あんまり変わらないかなぁと。 因みに63×63で試したら4分強かかった。あとフルスクリーン(1024×1024)も結構遅かった(7×7で1分くらいだったかな)。 公開キー：4DY31EX3 実行ファイル：GAUSS_S1

まぁ、端っこなんで、そんなに気にならないとは思うんですけどね。 端っこ処理、やれるだけやってみて遅かったら見送り、ってことにしようかな。

RINGCOPY使ってる訳じゃないのね。 てか、RINGCOPYだと縦方向にシフトする(スクロールする)のは簡単だけど、横方向が面倒か。 てか、RINGCOPYに限らず画像配列横にシフトすること自体面倒だということに気付いてきた今日この頃。

そういえば、ボカす時平均取ってくるピクセルが端っこ(-1とか512以上)の場合どうするのが良いのだろうか。今はとりあえずはみ出す直前のピクセルと同じ色ってことにしてやろうとしてるけど、結構面倒くさくてそこまでしなくても良いかなぁとか思ったり。 あと透明色は一旦BACKCOLORと同じ色の不透明ということにして、ボカす画像を退避、不透明BACKCOLORで塗りつぶした後、退避画像をロードしてからボカし、とかやろうとしてるけど、それも良い方法なのかどうか自信なし^^;

BIGだと、 SPDEFの個数は0～4095の4096個、 スプライトに使える画像の座標範囲はX,Y=0～1023,0～1023です。 512ってのは3号の場合ですね。

Hanzoさん> できました！ ゆっきさん> 2の累乗は出てこなかったような？．．． そしてC言語じゃなくて（じゃないほうがむしろ）良いです(^o^) InDoorさん> 二項定理ってのまでは辿り着いたんですけど、それを利用した式の解き方ばかり説明したサイトばかりで。「5C2=4だから云々」の4をどうやって求めるんじゃ～って^^; あと、nCr=n!/r!(n-r)!って式にも惑わされました。InDoorさんの式で納得です。 コメント頂いたみなさんどうもありがとうございました。とても助かりました。

＃煮詰まってしまって(>_<) パスカルの三角形 1 1 1 1 2 1 1 3 3 1 1 4 6 4 1 1 5 10 10 5 1 1 6 15 20 15 6 1 (とりあえず7段まで) これを、いちいち前の段から足し算して計算するんじゃなくて、例えば7段ならその7からシンプルに計算したいのですが、良い方法ないですかね? 5を渡したら1,4,6,4,1の配列を返してくれる関数のようなイメージ。 参考: i;c;main(a){for(;a=c?a*c/(i-c):(c=++i)<21;printf(--c?"%d ":"1\n",a));} ネットで見つけた20段までを表示するCのプログラム。これがそのシンプルな計算してるような気がするんだけど、C言語忘れちゃった^^;

1次元ガウス関数→パスカルの三角形→二項定理、と迷走してしまいました(>_<) 1次元ガウス関数の重みの配列、分子はパスカルの三角形から、分母は16の「広げる範囲のピクセル幅」乗(範囲3×3なら16の1乗、5×5なら16の2乗)で計算できればスッキリするかなぁと(なるべく整数値で持っといて、最後に分母で割れば誤差抑えられるとか)思ったんだけど、肝心の分子のパスカルの三角形のところが良い方法思い付かなくてハマり中。 例えば範囲5×5の5から、1,4,6,4,1をさらっと求められれば良いのだけれど。 ＃すごく単純な気がする。けど思い付かん。

海外ではこのネジ穴使うスタンド発売されてるみたい。あとストラップ?付けて首から掛けて画板見たいにして使えるやつとか(駅弁スタイル)。 WiiU買った頃は、そのうちスタンドみたいなのNintendoから発売されるんだろうなぁと思ってたけど、結局(国内では)出ませんでしたね。 ＃宴会場でよく見かけるカラオケの機械のような ＃使い方できるんじゃないかなぁと思ったり ＃したけど、わざわざな感じもするし^^;

1次元での仕組み、やっと分かった(多分)。 色混ぜ範囲が3×3の場合、2次元のままだと3×3=9回計算しなきゃならないところ、1次元だと3+3=6回の計算で済むという訳ですね。 色混ぜ範囲広い程効果が大きいし、これは良いですね(^o^) 因みにσ(ｼｸﾞﾏ)の値ですが、もし適当な値決め打ちしているようであれば、色混ぜ範囲のサイズによって計算する方法もあるみたいですよ。 σ=0.215*((SIZE-1)/2-1)+0.81 ＃SIZEは3×3なら3 0.215とかの数値はサイトによって若干違ってたりします^^;

最近首というか背中というか(巨人の弱点のちょっと下あたり)、とにかく物凄く痛くて、プチコンしてる体勢が良くないんだなぁと思って、GamePadをカメラの三脚に乗せてみた。 TV付けると部屋暑いんで、この頃はGamePad+USBキーボードだけでプログラミングしてたんだけど、首を急角度で下に向け続けるのが良くなかったんだと思う。かといって寝転びながらやろうとしても、腕がすぐ疲れちゃうし。 イスに座ってもGamePad目線の高さくらいになったので、首が大分楽に(^o^) そしてこの体勢でのお絵かきは、何か雰囲気が出る(描きやすいって訳じゃないけど^^;)。 GamePad裏の謎のネジ穴がそのまま三脚のネジに入る訳では無いので注意。

私が見たサイトでは、ガウシアンの色混ぜ具合の係数は、計算済み(なのかザックリか)の値を予め配列に入れてました。 3×3なら 1/16,2/16,1/16 2/16,4/16,2/16 1/16,2/16,1/16 式がよく分からなかったので、これをそのまま使ってます。但し、色混ぜ範囲を広くしようとするとやっぱり計算した方が良いのかもしれませんね(そのサイトには3×3と5×5の配列しか載ってなかったので、今のところ私にはそれ以上のボカしができない^^;)。

私もマネしてガウシアン中です(^o^) それにしても11×11は凄すぎ(ヘンなドライバー1本しか持ってないプロゴルファーの弟のセリフが聞こえて来そうです)。 私はとりあえずアルゴリズム再現したっていうレベルで、1ピクセルずつの処理だから激重でした(無駄にARYOP使って更に重いという...)。 たばすこさんのお絵かきツール完成するの楽しみにしてます(パクる気満々(^^ゞ)。

そうなんですよねぇ。3号コミュの方がにぎやかでうらやましいんですよね。 3号に比べて単純にユーザー数少ないんでしょうね。WiiU自体が既に希少なゲーム機になりつつあるようだし。 でもBIGは3号の3倍の値段だから、1人で3人分なのだ(なんのこっちゃ?!)