夏休み子ども科学電話相談でしょ? 初日から田中修先生出演てことで、いまからwktkしてます!! うまく録音できるか不安・・

お邪魔します。昔作った正円描くゲーム(QSP)です。 https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTpoKSK1Q 正円前提なので、応用は効きません。 なぞった点を gspoit して、お手本の特定の色かどうか判定するのが簡単かもですね。 ただそれだと手本の線が細いと得点できないので、手本画像を思いっきりぼかしたような画像を別に用意し、当たり判定はそちらの画像を対象にすればいいでしょう。 画像というより画素ごとの得点を入れた二次元配列というイメージ。 あくまで点での判定になるので、点と点の間をどのように移動したかという判定は入りません。 ただし線を描くアルゴリズムを使えば、移動経路上の各点についても判定可能。

おお、検証ありがとうございます。 やはり二度評価すると遅くなりますね。 この修正前のやつってとても不思議な感じがして、 いわば「inc v[e]」を内部的には「v[e]=v[e]+1」として処理してるってことなんですよね。 それって、例えばプリプロセッサを使うなら簡単に実装できるけど、コンパイラレベルでやろうと思うと、わざわざそんな事するより、inc 命令を真っ当に実装した方がよほど簡単だと思うんですよね。 どんな風にコンパイルしてる(してた)のかとても気になります。

知恵袋って 「ソースは、ネットで見た」 そのまんまだから・・・

> 今確認したけど push は実用的な速度を維持できるみたいですね。 更に定量的に確認。 option defint var n=1<<19,v[0],w[n],u,i,t0 t0=millisec: for i=1 to n: push v,i: next: ? (millisec-t0)/1000 t0=millisec: for i=1 to n: w[u]=i: u=u+1: next: ? (millisec-t0)/1000 結果 5.965 3.714 push は後者より 1.6 倍遅い。 後者が激遅キングの配列を使ってることを考えると、push の遅さも大概ですね!!

その通り!! inc は +1 より遅いんだけど、配列は最強の遅さなので v[0]=v[0]+1 vs inc v[0] では 前者が配列を二回評価するため、 一度しか評価しない後者よりも遅くなります。 inc が引数を二回評価してた過去のバージョンでは inc の方がおそくなってたのではないかな?

音楽プレイヤーで、音にあわせて山が出たりへこんだりするするグラフがあるでしょう? あれが音の周波数成分です。(左が低い音、右が高い音) 低音をブーストしたければ、音を fft して、低周波成分の大きさを増やしてやって、ifft して音に戻してやればいいわけです。 高周波領域も大きくすれば立派なドンシャリの出来上がり!! 画像も二次元の波と考えることができて、それに対して二次元の fft/ifft というのが定義できます。 画像に対して高い周波数を取り除くと、「ぼかし」になる。 低い周波数を取り除くと、輪郭抽出になる。

> フーリエ変換は、OWR+OWIをあーだこーだした結果を、IWR+IWIとして返す、 合ってます! ただし O と I が逆。O は output (出力) で、I は input(入力)の頭文字です。 フーリエ変換した結果の OWR+OWI をフーリエ逆変換すると 元の IWR+IWI に戻るってとこもポイント。 数学的に正確に理解するのは大学行ってからで十分で、今はただの道具として使えればいいでしょう。 Hanzoさんの説明でいいけど、余弦波が実数成分ですね。 参考: オイラーの公式(これは絶対覚えるべし(丸暗記でも役に立つ)) e^(iθ)=cosθ+i*sinθ 余弦とか名づけられて dis られてるけど、どっちかというと cos の方が主役です。 90度ずれてるのは「直交してる」ってことで、これも重要なキーワード。

これいいですね!! ループでいいから傾けた方に無限に動くようにしてもらえたらもっと嬉しい! Cumos ってご存知です? 立方体の万華鏡。 進学校だと 7 時間やった上に土曜日も授業とかやるみたいですよ。 大変だと思うけど、今この3年間でその後の人生の大部分(40～60年)が決まってしまうわけよ。実感ないと思うけど、今ががんばりどきなのよ。

アルゴリズム、わかりやすいのはソートですね。 単純比較、バブル、クイックソート、バケツソート、スパゲッティーソート、ボゴソートなどなど。それぞれ長所短所があります。

やまなさん、b タイプ了解です。 まげさんの作品は 8pixel にグリッドするようですが、絵の場合は特に 8 の倍数とか関係ないですよね?? ファイル名 + 座標指定でロード了解です。 >ビューアはコメントもつけられたら便利 見てるときにコメント追加ですか。 なるほど!! そういう発想はありませんでした。 >まんがというか絵本というか、そういうのを容量をあまり気にせず簡単に作れたら やまなさんの作品を見たいですね。別に私のツール使う使わない関係なく。 あのネコミミキャラかわいいです。 まさか小学生だったとは!!?!

ニャッキじゃないかなあ??

今確認したけど push は実用的な速度を維持できるみたいですね。 > push/pop/shift/unshift など配列長を変える命令も遅いから使わない。 これ撤回します。申し訳ない。

文字列の連結 s$="" while 1 for i=0 to 999 s$=s$+"." next ? "."; wend これ実行すればどんどん遅くなるのが実感できるでしょう。 prgset も同様です。 文字列は適当な単位(改行までとか)で区切って、文字列配列にどんどんつめて行くのがいいです。その時も push じゃなくて、上の技法使うんですよ。

ピープホール(のぞき穴)ってことで、局所的な最適化です。4倍を<<2で書き換えるとかはこの類。 うえこうさん、ごめん、減らす命令は大丈夫かもしれません(未確認)。 push の代わりに、一度に 1024 個とか追加して、足りなくなったらまた一気に増やす。 毎回毎回一つずつ増やすのが最悪のパターンです。 var 関数とか、実行時に文字列からシンボルテーブル引くわけだからますます遅くなります(普通の変数はコンパイル時にシンボルテーブルを引く)。goto などのラベルに文字列変数使うのも同様に遅くなるはず。

二行目は、 コンパイル時: 変数 i の暗黙の宣言 実行時: i に 0 を代入 という意味があります。 二行目がなければ3行目が暗黙の宣言になります。

参考になるか分かりませんが、3ds で鳴らした音を pc のオシロでみての観測結果が 私の 2016/1/3 日記 https://miiverse.nintendo.net/posts/AYIHAAAEAABEVRTuiaiXBw の 2016/5/26 のコメ 3 つにあります。

アルゴリズムレベルで変えるのが一番効果があって、 二番目は実装方法の工夫 (不変式をループの外に出すなど) 最後にピープホール最適化(ぐぐれ) 配列はホント邪悪 いい加減慣れたけど、こないだ改めてビックリしたのは (1<<n)-1 より mask[n] の方が遅いってこと!! どんだけ・・・ 除算より乗算のが遅いので a 倍する代わりに aの逆数で割った方が速い。 文字列の連結は遅いので使わない push/pop/shift/unshift など配列長を変える命令も遅いから使わない。

メモリリークがあったらしく、プチコン再起動したら BG も圧縮できた。 ついでに lzss でもやってみた。 標準 BG 圧縮 | サイズ | GRP比 | 圧縮 | 伸張 lzss | 108984 | 20.8% | 54.36s | 5.22s pic改| 95812 | 18.3% | 6.32s | 3.52s 標準 SP 圧縮 | サイズ | GRP比 | 圧縮 | 伸張 lzss | 92060 | 17.6% | 90.63s | 5.14s pic改| 77800 | 7.4% | 6.23s | 3.24s

あ、念のために書いとくと プチコンでいう「二次利用」に対して、なにかしら一定の制限を設けたいってのは分かります。 その根拠として「二次利用を認めると、技術力(芸術力)がある作者がプチコンで公開しにくい」というのを持ち出すのには全く賛同できません。 >商用ベースに乗ってしまうと、コピー品などの問題が出てくるので、その場合は、オリジナルの作者である事を主張して欲しいと言うことです。 もしこれがホントなら、最初から公開キーの規約に書いとくべきで、それをしないのはスマブのダブルスタンダードですね。