副作用のある関数の問題は、関数型プログラミングやラムダ式関連でちょっとまえから話題に上がるようになったけど、実はダイクストラの昔からある話。 ALGOL型のサブルーチン=関数だけではこれがうまく解決できなくて、泥臭いグローバル変数つかうのが問題になってた。 構造体、さらにオブジェクト指向を使うと状態の情報やコンテキストといった物を引数に渡せるので副作用を無くすのが簡単になったんだけど、 それはまた別のお話。

これは点数もスプライトもいじるからたくさんプチコンを変化させる。副作用がある。(狙った通りに動いていても副作用という) これは関数だけでは作りづらい。引数が多くなる。かといってグローバル変数使っちゃうと関数の利点はかなり削れる。 さらに分割したら少しよくなる。 敵と弾が衝突したか判定する処理、 点数を増やす処理、 敵を消す処理、 にわけて、それらを呼ぶ処理をつくる。 そうすると、それぞれのサブルーチンは関数で綺麗にかけるようになるけど、 それらを呼ぶルーチンの引数はやっぱり爆発しちゃうし、そこは再利用しづらい。 これはGOSUB使うのがよいパターンになる。

副作用っていうのは… 関数を呼ぶ前後で、何かが変わること。 例えば、POWという関数がある。これは冪乗を求める関数だけど、呼んでも戻り値を入れる変数以外なにも変わらない。 これは副作用が無いという。数学の関数に近い。こういう命令だけじゃ(普通は)プログラムを作れない。 対してSPCLRという命令がある。これはスプライトの使用を止める命令で、呼んだ後は該当スプライトは無くなる。 関数というよりプチコンに対する「命令」で、こういうのは「作用」がある。 サブルーチンを自分で作るときは上の二つを組み合わせる。全部副作用無しなら簡単でわかりやすくてDEFに最適。とても再利用しやすい。 ところが一部に「作用」がある命令が含まれるととたんに微妙になる。例えば弾が敵に当たったら点数を増やして敵を消すという処理は何回も実行するから分離して関数にしたとする。続く。

またアバター変わってる…

柔軟っていうだけだと中身ないので、俺の指針的なの書いとく。 副作用の有無 引数の個数 UIの有無 規模 この4つが判断するポイント。 副作用がないものや、ただ命令をラップしただけなら圧倒的にDEF。 副作用があっても限定的で、引数が少ないならDEF。 副作用があって、規模が大きくて、引数が多くて、UIがあるならGOSUB。 あてはまらない場合は分割の仕方がおかしい可能性高い。 参考に。

そりゃ将来の話するならCやC++、Javaを勉強するのが一番いいって話になるに決まってる。なら最初からそれやりゃいいだろ。プチコンでなく。 むしろ、こういったメジャー言語で「関数」しかないから プチコンでGOSUB使えるのはいい経験だと思うね。 DEF＝スコープのある関数はALGOL由来で、アルゴリズム研究から生まれた。抽象化を重要視する思想。サブルーチンを「関数」と解釈したのもこれで、だから「再帰呼び出し」もALGOLから。 GOSUBはFORTRAN由来で「必要があったから」作られた。BASICは引数なしだけど。より現実的というか、泥臭いというか。そういう思想。 引数の存在やその個数、変数や関数のスコープの有無やその範囲、そういった「サブルーチン呼び出し」の仕様は言語によって違う。それぞれ特徴があり、得手不得手がある。 柔軟に使うのが一番重要。

流れに逆らうようだけれども。 俺はGOSUBもたくさん使うし、みんなもGOSUBたくさん使ったらいいと思ってる。 DEFを使わないほうがいい用途はたくさんある。 歴史や思想を説明するのは長くて大変なんだけど。 GOSUBは「大きな処理から同じ処理を纏める」という発想から作られたもの。 DEF(関数)は「小さな処理をたくさん集めて徐々に大きな処理を作る」という発想でできてる。 トップダウンとボトムアップの違いというか。 だから構造的には、DEFは小さな部品を作るときは美味しくて、大きい処理はGOSUBがおいしい。 なんだけど、処理速度的にはGOSUBのほうがDEFより早くて、頻繁に呼ばれるものをDEFで作るとまずい。 参照とかないので配列や文字列を扱うときDEFではわかりづらい時もある。 なので、あんまDEF教を信仰するのはオススメしない。 その都度適切なものを考えたほうがいい。

MPSENDで文字列を送れるので、 SPでもBGでもなんでも、文字列化すれば送れる。 一度にたくさん送るとエラーになるんで、細切れにしたり通信が終わるまで待つような仕組みが必要だけど。

タッチした位置と時間以外に何が欲しいの？ ジェスチャとか？

friendlyfireがおおくてきつかった。 敵の真ん中に補給基地とか、 ひどいTーT

じゃあイチゴから少しでるほうがバクか… 15万点くらい。

画面のしたにワープするのは仕様なのかバグなのかバグだったけど仕様ということで押しきることにしたのか。

ｸﾏﾐﾐ…

やわらかい は難しいよね。 ちゃんと計算しようと思ったらスパコン要る。そういうのは昔から創意工夫で乗り切ってきた。 動画や絵を用意しておくのがまぁ一般的。 昔よくあったのが文章で表現するやつ。フェードアウトして文字だけで、とか。 「前提を覆す」って大技もある。やわらかいが難しい＝硬ければ難しくない。 機械を撫でよう。 この車かっけー！ナデナデ。この冷蔵庫素敵！ナデナデ。 飛び出せ！家電の森 みたいな。 電子レンジ！君に決めた！ いけ、１０万ボルト！みたいな。 あれ、ごめん俺疲れてるみたい。

vsyncやwaitは1/60から結構ずれてるので、長い間待つ必要があるときは要注意。 これらは垂直同期を待つ関数で一定時間をまつ関数じゃない。 時刻を正確に知るにはTIME。

なんかの歌詞かとおもった。

あー それは気付いてはいけないプチコンコミュの三大タブーの一つ。 その謎を知ろうとしてウッディー氏やとりゅふ氏は逝ってしまった。 知らない方が幸せなこともある。 SHUHEI氏も気づかなかったことにしていつものようにプチコンコミュを楽しむんだ。 それでも気になる、真実を知りたいと言うのなら、この赤い薬を飲むんだ。 プチコンコミュの真実を覗かせてやろう。 っていうゲーム思い付いた

なんでも簡単にできるように見えるんだよね 俺も心の中では世界を変えるゲームが完成してる

ブロックはブロックされた人の投稿が見えなくなる機能であって、ブロックした人の投稿はブロックされた人には見えてる って誰か教えてやってくれw 怖いとか苦手とか見えてるからw あ、ついでに数当てゲームも楽しかったと伝えてくれると助かる。 傷つきやすいようなんで優しく頼む

音声認識で調べて。 説明も実装もけっこう大変で、ここに書くのはかなりつらい。 流れだけ書くと フーリエ変換して第一、第二フォルマントの周波数比から母音判定。 全スペクトルとその時間変化から子音候補検索して前後の文脈から文字列推定。 そんな感じになるんでいろいろ知識要る。 母音まではなんとかなったんだけど子音がまだうまくいかない。