2進数がわかるのがベストなんですが、説明してる時間がないので別の考え方だけ。 ANDはその部分だけ取り出す、みたいに考えるといいかもです。つまり、みんなの例ではそのボタンの部分だけ取り出して判定しているので、他のボタンがどうなっていても大丈夫な感じです。 普通に==で判定しちゃうと他のボタンによって値が変わることが影響して判定できないので、この部分は大きなメリットになってるかんじですね。

頑張りましょう

おめでとうございます！ ちなみにこの斜めに関しては８〜１１行目をちょっと変えるだけでも対応出来たりします。キーワードはANDです！ もしくはせっかく斜めを独自に判定しているなら、本来移動距離としては斜めはもうちょっと遅くないといけないというのがあるんで、斜めの時は１を足すのではなく０．７１ぐらいを足すようにすると近い速度になると思います。

基本的には処理速度に3倍近い差があると聞いたことがあります。使える命令的な差は無かったはず。あ、あとNewは始めから右スティックがついているのが違いますね。 ただ僕は普通の3DSですが楽しめてはいるので、それほど気にしなくても大丈夫ですよ。まあNewの方が早くて嬉しいとは思いますが、僕は買い換え時の楽しみに取っておきます(^^;

VisualBasicなどのプログラムの基本がわかっているなら、とりあえずプチコンの説明書と命令表を見てみるのがいいと思います。 説明書は3DSのHOMEボタンを押した時に表示されるものです。ネット（スマイルブームのサイト）にもあります。命令表はスマイルブームのサイトにあるやつが見やすいと思います。 まずは一通り軽く目を通してみるといいと思います。

レイヤー書き出しをするならあきとさんの記事を参考にするといいですね。 マップデータをそのまま使うのだとしたら、僕の過去記事を探せばやり方が出てくるので参考にしてみてください。

細かい動作原理的な事は他の人に任せるとして、僕も使い分けとしては、VSYNCはタイミングをとるため＝基本メインループなどの間に入れるもの、WAITはその場でその時間動作を止めたい時に使う、みたいな感じでいいと思いますね。 VSYNCはタイミングを取る関係上必ずウエイトが入るとは限らないので、ボタン入力更新のためなどで必ずウエイトが入ってくれた方が都合がいい場合はループの中でもWAITを使うというケースもあると思います。

プログラムを書いていて似たような記述（コピペ含む）がたくさん出てきたらGOSUBやユーザー定義命令や関数を覚えるチャンスです！

その魔道書（ガイドブック）はLV3以上から使えるようになるので、LV3までは自力で頑張ってください！

HSPは昔少しだけやったことがありますが、もう覚えてません(^^; スレ違いなので詳しくは書きませんが、質問のように毎回ロードして表示するのは明らかに無駄なので、ロードを少なくするためにbuffer命令を使います。プチコンでいうと表示されていないけど画像が保存されている場所みたいな感じです。 プチコンではその見えない画像からスプライトを定義したりBGとして表示されたりしますが、HSPにはそういう機能は無い（はず）なので、自分でbufferで見えない画像を作ったら、そこからコピーして描画したりしてマップのようなものを表示したりする感じになるんだと思います。 ということで必要性がわからないと言ってましたが、とても大事な機能だと思いますよ〜。 あとはちゃんとHSPの掲示板などで質問したりネットで情報を集めた方がいいと思いますよ！

BGGET絡みのものがBG当たり判定なので、その当たりの投稿が参考になるんじゃないかと思います。 あとはまあ僕が過去にいくつか投稿したものもあるんで僕の過去の投稿を探してもらえれば参考になるものがあるとは思います。たぶん、 日付：2014/12/11 第２回、解説つきサンプル講座。 サイドビューの画面によるジャンプとBGとの当たり判定のサンプルです。 日付：2014/12/12 第３回、解説付きサンプル講座。BGスクロールのサンプルになっています。 この辺りが参考になると思います。

まず普通の当たり判定（マップの見えない壁とかじゃなくて）は出来るんですか？ 普通の当たり判定の例は他の人も出してますよ。見えない壁に関してはプログラムというよりは絵の工夫ですね。

sayさん観察眼が鋭い！　てか僕はさらっと見落とした(^^; 185行目、たぶんGOTOの間違えなんでしょうね〜。スタックオーバーフローの理由はsayさんのいうとおりです。RETURNしてないのに何度もGOSUBを呼び出すことでオーバーフローが発生した感じです。 （GOSUBはRETURNで戻る命令なので呼び出される度に戻る位置を内部的に記録していますが、それがRETURNされないまま繰り返し呼び出される事で内部的な記録だけが積み重なってオーバーする感じ。RETURNされるとその部分の記録は不要になるのでオーバーしなくなるのです）

さすがにプチコンとはあまり関係ないと思うので、HSPの掲示板とかを見つけて質問した方がいいと思いますよ〜…。 まあプチコンとHSP両方やっている人が答えてくれる可能性があるにはありますが、他のHSP情報を調べた方が手っ取り早きがする…

マップがBGを使っているのだとしたら、見えない壁は絵の部分もなにもないものを用意して（ただし移動出来る0番などとは別にしておく）それとの当たり判定をとるのが楽じゃないかなって思います。 実際当たり判定はプログラマの設計次第でもあるんで、BGとは別に当たり判定用のデータを別途用意すればBG表示とは関係なしに自由に当たり判定をつける事も出来るし、そういうやり方もありだと思います。（ただデータを作るのが面倒だったり容量が増えたりはするけど…）

他の方も言っていたり以前にも要望に挙げたかもしれまえんが、念のためもう一度…。 ファイルメニューで並びを選択できるようにして欲しい。以前と同じ新しい順や今回のアルファベット順、他にも作者順とか色々あると便利だと思います。 下画面を使っているときにINKEY$を使いたくてもキーボードが表示されないので一時的にキーボードが表示される（切り替え？）機能が欲しいです。 スマイルボタンなどから他プロジェクトのプログラムを実行したときにカレントはそのままなのでそのプロジェクトに入っている画像などは参照できずにエラーになってしまいます。 ランチャーみたいな機能を作った時に困るので他プロジェクトのプログラム実行の際にそのプロジェクトにカレントを切り替えるオプションのようなものがあればいいなと思いました。 以上ですが、よろしくお願いします。

区切りのつもりなら:じゃないと駄目ですね〜

このどの部分の意味ですか？

とりあえず個人的には上記で説明したように反転はSPDEFで反転用のキャラを定義番号３〜５に割り当てておきますね。 例えば0番目のキャラの場合、アトリビュートに横反転を加えて原点はデフォルトと同じ（０）にするとしたら、 SPDEF 3,248,416,60,96,0,0,#SPREVH みたいになると思います。そのようにして割り当てれば上記のSPANIMの方法でこの反転キャラを指定すれば逆に動かすためのアニメーションが作れるはずです。 まずはここまで。ではでは。

それぞれそのボタンを押した時や離された時にSPANIMを止めたり切り替えたりするプログラムが必要になりますね。 反転はSPDEFでアトリビュートも利用して反転用のキャラも他の番号に登録しておくと使い勝手がいいです。 ただちょっとすいません。しばらく私用で投稿することが出来なくなるので、具体的な答えは他の人任せか、もし後でまだこの投稿が残っていたら回答します。 頑張ってください！