反射は、大きさをとりあえず無視すれば、鏡で反射する光みたいな話。 とりあえず垂直な壁で考えます。 図の左下からやってきた玉は、壁が無ければそのまま真っ直ぐ進みます。 ところが壁があれはそこで鏡のように反射して、左上方向へと向きを変える。 反射による減衰がなければ、図のように反射点から上は二等辺三角形になる。 壁が無かった場合の到達点と、反射した場合の到達点の y 座標は同じ。 x 座標は壁を中心に、同じ距離だけ壁から離れている。 だから、壁が無かった場合の到達点座標を求め、x成分についてのみ壁からの変位を引いてやればいい。 反射により減衰する場合、反射角度は変わらず、単に到達距離が短くなる。 反射点から見て、減衰しない場合の到達点を (dx,dy) とすれば、減衰する場合は係数 0.8 を掛けて (0.8dx, 0.8dy) とすればいい。

ベクトルって矢印のことで、よく絵とかで「物がこっちに進む」のを表すのに物に矢印を付けて描くよね。あれがまあ速度ベクトル。 平面上で動くならx成分とy成分で表せる。 斜め60度に速度2m/sで移動している場合、そのx成分は 2*cos(rad(60))=1m/s, y成分は2*sin(rad(60))=√3m/s となります。 このx成分とy成分を(x,y)と表記するとそれがベクトル。 ちなみにキャラ座標も(px,py)で表したりしますよね。あれも「位置ベクトル」という名が付いています。 内積は単純に成分同士を掛けて足せばいいだけ。 (x1,y1) と (x2,y2) の内積 = x1*x2 + y1*y2 ベクトルの定数倍: c*(x1,y1)=(c*x1,c*y1) ベクトル同士の加算: (x1,y1)+(x2,y2)=(x1+x2,y1+y2)

みむさんが言うのは 「スプライト自身が、自分の位置や速度を知ってる」 ってことね。 他の質問であった spfunc と組み合わせると、とってもらくちん。 あと重要な点として、倍精度浮動小数点数だってことがあります。 「自分の位置? spofs out x,y で分かるじゃん?」 と思うでしょ? ところがどっこい spofs の座標は整数で丸められてしまうので、整数未満の座標が保持できない。 ので、「1フレームごとに 0.3 ドット進む」ような処理をしたいときに便利。

音楽つくろうぜのことかな?? 6 つくらい前の投稿に、作者(ナツキさん)自ら公開キーを晒してますよ。 MML作成支援ツール 音楽つくろうぜ！ Ver 0.53 【K25YE3DJ】

アッチェレランドとリタルダンドね。 確かに欲しいですね～～

input 代わり(確定ボタンを押すまで返って来ない)仕様なら、それで文章入力できるわね。 他のタスクもこなしつつ、キー入力も受け付けたいとなると、わりと面倒。

>ライセンス >GPLv3 マジか・・・!?!?

> IF A>=1 THEN PRINT"Aは1以上 > PRINT"Aは1以上"*!!Aと出来るのです。 後者は短くていいんだけど、残念ながら前者よりかなり遅い。 基本的に文字列の足し算掛け算は遅いと思っていい。 ∵結果の文字列を納めるメモリを確保し、そこにコピーする必要があるから 前者は固定文字列を print 命令に渡すだけなので、メモリ確保だのコピーだのは発生しない(ハズ) ながーーい文字列を while 1: s$=s$+t$: wend 的な方法で作るのは大変遅くなります。 同じ理由で、配列を push push で増やすのも遅いです。 また同じ理由で(prgdel -1 した後) prgset でどんどん追加してくのもものすごく遅くなる。ただこれの遅さは異常なほどなので、それ以外の理由もあるかも。

smile basic は「予約語」以外の命令は変数として使える。 予約語とは制御構文(if/goto/繰り返しなど)とか print/input/linput など。to step は fot 文の一部だけどなぜか予約語になってない。 for to=to to step step step: next とか書ける。 構文的に変数と解釈できるなら変数にとして解釈されるのね。 エディタのシンタックスハイライトは厳密に処理系と同じ構文解析字句解析してるわけじゃないので、エディタでの見た目は、実際に処理系によって解釈される構造とは異なります。

標準フォントの大文字と小文字を入れ替えます。 大文字って読みにくいので・・・ 内容は 26x2 行の fontdef 命令。 使い方: acls の後に exec "prg3:chcase.prg" を実行するようなコードにしておきます。 例 acls: exec "prg3:chcase.prg"

使用後

使用前

ここでは「チャンネル」だけが MML 特有の概念ですね。 これは合唱で言えば高音部とか低音部のパートのこと。 一つのチャンネルでは一度に一つの音しか出せない。和音はむり。 人の歌なら一つのチャネルが一つのパートに対応する。 三重唱なら三つのパートをそれぞれ一つずつチャンネルに割り当ててメロディーを記述します。 一方で、ピアノのドミソの和音を出そうと思ったら、三つのチャンネルを使って、ドとミとソを同時に鳴らす必要があります。 和音が出せる楽器は、複数のチャンネルに割り当てる必要があります。 和音とか音符の種類とか全部ミバで調べるのは非効率だから「楽典」とかで検索するか、図書館に行って調べてね。

えっ 記憶違いとかよくある話だし、そんな気にすることないし、実際私も間違ったことよく書くし。 「作るな」的な話に関しては、真摯にプチコン作品を作っている方々に対して失礼だと思ったのでそう書いたけど、当然それに反論あってもいい。 私の書き方がキツイとは再三指摘されているところで、反省はしていますが、改善には結びついていない現状です。 別にアマツナさんの人格否定しようとか攻撃しようという意図はないので、その点ご了解頂ければ幸いです。

倍精度浮動小数点数(double)入力の double 出力です。 一つの複素数を二つ double で表します。 複素数 Z[0] は x[0]=Z[0].re x[1]=Z[0].im で表し、 Z[1] は x[2],x[3], Z[n] は x[2n],x[2n+1] 入力も出力も複素数になります。

key=e5k45ehv file=w 大浦fftのサンプルです。 追加購入の fft とは呼び出し規約が違うので注意。

アマツナさん> 努力を、ドットペイントを、無駄にして足蹴にしてふみにじるような、そんなソフトであってはならないと思います。 アマツナさん> 認めてもらいたいのはわかりますがちょっとストップ、ですよすごいみなさん。 本気で言ってるのかな?? うわは～～～ そのプロとやらに対しても失礼だし、そのアマの皆さんに対しても失礼ですね。

アマツナさん> プチコンの出来のすごい作品だって、一般商品を越えるような作品は売り上げに影響でちゃうのでダメっていってませんでしたっけ。うろ覚えですが、すいません、小林社長のお知らせだったかな。 小林社長が「すごいの作ってくれ」というのは見たが、「すごいのダメ」なんてのは見たこと無いですね。 https://twitter.com/notohoho/status/720971707326930947 記憶違いでは? 他には 「好きな要望上げろ、あとはこっちで交渉する」 https://miiverse.nintendo.net/replies/AYMHAAACAAADVHkBMe-vjQ とかですね。 具体的にダメな例も挙げています。 https://miiverse.nintendo.net/posts/AYMHAAACAAAYUKlz7Z6FfA

とはいえ、プチコンと大喜利とは切っても切れない関係。 大喜利のないプチコンなんて、骨粗鬆症のカラスみたいなもの。 例えば 「こんなプチコンは嫌だ」 とかなら違反にならないし(実際過去にありました) 「while 文が fot 文に一言」 「誰にも言えない acls の苦悩とは?」 「プチコン 4 号が空前の大ヒット! その理由とは?」 プチコンのスプライトを二つ並べて「ボケて」 などなど要はプチコンがらみのネタならいけると思います。

ミバって任天堂という営利企業が運営している sns なのでね。 基本赤字になったら打ち切りになるわけです。 株主総会とかで、株主から 「ミバって利益を生み出しているの? お荷物なんじゃないの?」 とかツッコミが入るわけです。 そこでミバ運営チームは、ちゃんと根拠のある数字を出して、 「これこれこういうしだいで、ソフト・ハードの売り上げに貢献しています」 と示さなければならない。 そんなミバが、ソフトと関係ない雑談で溢れかえってたらどうなるかというと、株主から 「全く売り上げに貢献してそうにないけど?」 と反論されて、さっくり消滅するわけです。 今後もミバを利用したいならば、運営の頭痛のタネになるようなことはしないのがいいでしょう。