私はお絵描きも結局ドット絵のように描きたくなっちゃって(細かいところ拡大してプチプチ)、大きい絵を描くのが苦手です(嫌いって訳じゃない)。

RINGCOPY使えば意外と簡単にできそうですね(^o^) やってみて下さい！(やってやってぇ～)

そうですよね。初心者にとって難しい内容だとしても、示されてないよりは示した方がマシ、というより示されてないとダメだと思います。行き詰まっても情報なくて困るのは初心者の方が多い(熟練者は自分で色々試して解決できたり)と思うので、これちょっと初心者には難しいから省略して伝えよう、とかは要らぬ気遣いだと思います。そして初心者はいつまでも初心者じゃない。意外とすぐ初心者じゃなくなるもんです。世間に溢れる「初心者向け～」なんかは初心者というより初見で終わりの情報で、もっと詳しい情報がそれに埋もれて中々見つからないのがイライラする。そもそも初心者向けってなんだ?面倒くさいこと省くための言い訳か?なら初心者向けって言葉使うべきじゃない。万人向けを目指すべきだ～。 って突っ走り過ぎました(^^ゞ そういえば、配列って実数型より整数型の方が速いみたいですね(今更感)。

配列直接シフトにする前に、R,G,BそれぞれGSAVE/GLOADしてたから、COPYに較べると若干遅い感じだったかなぁ(いろんなバリエーション試しすぎて定かじゃない^^;)。 でもGRP使えればいろんな処理楽チンにできそうですね(座標があーだからいくつずらしてごにょごにょ、とか考えるの疲れる)。

ふっふっふっ。それ私も思い付いてました。不透明度捨ててたから丸見えにはなりませんでした(っていうか何も見えない)けど。あとGSAVE/GLOAD3回ずつが意外と遅かったです。 ＃っていうかmoh6anさんそれやりたくなくて ＃一生懸命COPY使ってたのかと思ってましたよ

ナツキさんのおんつくでは、1小節単位での表示、入力になっていて、その小節の長さ分ぴったりに音符や休符を埋めないと、次の小節の入力に行けない感じだったと思います。 小節の区切りの検出は、頭から音長カウントしてくしか方法浮かばないです^^; でも検出してくれて、MML出力時に小節の区切りにスペース入れれたりすると嬉しいかな。

本当に簡単な記述になるか、作ってみました。 キー：WE2EAD ファイル：RING_SFT 左スティックでスクロール、Xボタンで終了です。 ミソは、2次元配列なら1ドットずらしても行末が次の行の行頭に行かず、その行の行頭に来るのと、コピー先オフセットにマイナス値を指定できるところです。これによりかなり記述を簡単にできました。 とは言っても、縦シフトは意地でRINGCOPY使ってやったのでちょっと強引です。あと3号では試せてないので速度どうなのか。速いと思うんだけど。 それと気になったのは、MIKIさんのおっしゃってた、COPYでコピー先/元同じだとバグってるっていうの、BIGだと大丈夫っぽいんですよねぇ。コピー先/元の配列内の領域かぶってても問題ないようだし。これはもうちょっと調べてみます。 ＃なんか脱線してきたかな?ぼかしでは結局 ＃RINGCOPY使う必要なかったし^^;

＃なんか朝に勘違いに気付く^^; やっぱりCOPYでの画像配列シフトそれなりに面倒だったんですね。ぼかしでばかり考えてたから、1ドットずらして前の行末のドットが行頭にずれて来てても、端っこ切っちゃってたから簡単だと勘違いしてました。 なので、やっぱりRINGCOPY有効かもしれません。単純に同じドット数ずらしてコピーするだけの処理ならRINGCOPYの方が遅いかもしれませんが、ずれて行頭に来たドットを何とかするために複雑な処理が必要になるなら、RINGCOPYではその複雑な処理が要らない分、結果速くなるかもしれません。 縦シフト1次元、横シフト2次元で処理できれば、RINGCOPYだとすごく簡単な記述になります(^o^)

実際のBGM聴いてないんでアレなんですが、音楽の著作権OK/NGの判断って結構難しいと思ってます。 世の中似たよう曲たくさんありますし。 実際問題訴えられたら(て負けたら)NGみたいな。 かといって一か八か似た曲発表して賭けに出るなんてのはリスク高いというか、ハイリスクノーリターン。 私はそんななんやかんや煩わしいのでもっぱら著作権切れの古い曲使うことにしてます。自分で作曲するにしても、偶然既にある曲と似ていたら、とか思うと怖い(以前に作曲できないけど)。

Kには数値が入ってるはずだから、IF文のところK==0とかにしなきゃならないかな。 "でくくると文字列です。

報告 画像配列シフトにRINGCOPY使ってみましたが、BIGではCOPYより遅かったです。処理考えればCOPYの方が単純そうだから、当然と言えば当然の結果なのかな。まぁ使用ケースによって変わってくるかもしれないし、3号では違うかもしれないし、参考程度に。 ぼかし関数は、整えたら研究会の方で紹介させて頂こうと思ってます。 ＃3号の高度サウンドユニット持ってないことが ＃歯痒くなってきた^^; ＃戦略に乗るのはシャクだが買っちまうか。

配列直接シフトにしたらまたまた結構速くなりました。公開したものに較べると2倍近く速くなったんじゃないかな(ふぅ、私にはここら辺りが限界かなぁ)。 しかし作ってはみたものの、実装どうしようかなぁ。とりあえず欲しかったのはぼかしペンみたいな機能だったんだけど、それはまたアルゴリズムちょっと変わってくるなぁ。 ぼかしGPSET、ぼかしGLINE、ぼかしGFILL、ぼかしGPAINT(が一番難しい) 野望は広がる(SBGEDにそこまで必要か?って気もするけど^^;)。

BIQUAD良さそうですね。ちょっとBIGで試してみました。 ＃速度は計ってないけど、多分速いんだろうなぁ。 DEF ARY_SUM(A) VAR T=LEN(A) DIM FP[13],O[T] FP[0]=1:FP[3]=-1 BIQUAD O,A,FP RETURN O[T-1] END

私はもちろん画像まるっとUNDOですとも(^^ゞ 差分管理もちょっと検討してみたんですけど、挫折しちゃいました。っていうか、検討過程でBIGのFREEMEMあんまりあてにできないことが分かっちゃって(>_<) 何故か起動直後だけ大きい配列定義がOut of memoryになっちゃう現象にも悩まされました。Directモードとかでじわじわ配列大きくして定義していくと使える配列大きくなっていくという。。。

紙の原画があるのなら、お絵かきツールを起動したGamePadの上に原画を置いて、タッチペンでなぞれば良いのだ(^o^)。色塗るのとか色々大変だけど:-p

実はBIGのSBGED(純正のね)では差分だけのUNDOを行ってたようで、果てしなく戻れる感じでした。 ただGPAINTのUNDOが絶望的にバグってたために残念なものになってました。 あとUNDOバッファ長可変だったのに空きメモリチェックしてなかったからOut of memoryの恐怖もあったかな。 志は良かったと思うんだけど非常に惜しいです。

今朝気付いたんだけど私勘違いしてました。 画像配列横シフト全然面倒じゃなかったですね。 縦シフトもそんなに面倒じゃないし。 何故か1ビットだけずらしたら画像ななめに傾いちゃうんじゃないかと思い込んでました^^; なので無理にRINGCOPY使うこともないかも。

＃深夜のワルノリでワル妄想。 ＃信じちゃダメ。絶対^^; 配列が遅いのは、高度サウンドユニットを売り付けるための戦略。そしてこの高度サウンドユニットの存在により、将来的にも配列が速く改善される見込みは薄いと思われる。 なぜなら配列速くしちゃってユーザー関数でも高度サウンドユニット相当のことが可能になっちゃうと、高度サウンドユニット買ったユーザーから「金返せ～」とかのクレームが沸き起こり、対応が大変になるから。 詰みました。投了:-p ＃ほんとに信じちゃダメだからね^^;

私は初代ディスクシステム(と、たまに甥に付き合わされてNintendoLandの)しかやったことありませんが、あの雰囲気は好きでした(^o^) 因みにメトロイドは敵のくらげみたいなやつの名前で、主人公の名前はサムスでしたね(メイドサムス?^^;)。 初代で丸まり爆弾を連射スティック使ってどんどん上昇する技を発見した時、友達と大はしゃぎしたのを思い出します。 制作者の想定していない(であろう)攻略を発見した時のワクワク感はたまらないものがありますね(^^ゞ 昔のゲームにはそういうの良くあったと思うけど、最近のゲームではしっかり作り込まれているせいか、あまりお目にかからないのがちょっと寂しい。

＃私の憶測による勝手な理由付け。 ＃適当なこと書きますのでどうか信用なさらずに^^; 一般にゲーム機のCPUというのはパソコンのに比べると遅い。但しゲーム機では画像処理は大事な機能なのでCPUとは別にそこそこ性能の良い画像処理専用のもの(GPUっていうのかな)が積んである。 配列なんかはCPUで扱うから速くないが、画像処理に関係するものは速い。この画像処理に関係するものには、今時のゲーム機では当たり前になっている3次元空間を表現するための、実数計算を扱う機能も含まれていて、なので三角関数とかは速い。 除算が乗算より速いのは、3DSのCPUに使われているARMコア自体に除算機能が備わっていて除算が得意(もしかしたら逆に不得意だったかも^^;)。 とか思っていて、なら遅くてもしょうがないかぁ、と納得することにしています(^o^) ＃にしてもやっぱり配列は遅いか^^;