HEEもHEAも略称としてはわかりにくいと思う…

僕もサンプルは読みづらい（分かりづらい）に一票。 それに長いプログラムになるほど理解には時間がかかりますしね。 とりあえず昔僕が投稿したサンプルでよければ、以下のようなものがあるので試してみてください。プログラムは１画面内なので打ち込みやすいと思います。というか、始めはなるべく自分で打ち込んだ方がいいと思うので公開キーなどはありません。 追加質問などもあれば受けつけますしコツコツと頑張りましょう！ 日付：2014/12/5 & 2014/12/9 初心者がよくトライするキャラクター移動のサンプルです。 左右に動いてAでジャンプ、Bダッシュのおまけつき。（※アニメーションはSPANIMを使っています） 12/9 https://miiverse.nintendo.net/posts/AYIHAAAEAADaVHhje1QgdA

命令に関しては覚えるという意識はしないで、とにかく人のプログラムを見てでもいいので自分で打ち込むことです。よく使う命令は何度も打ち込むことになるので自然と覚えられると思います。 あとはいきなり大きいプログラムを組もうとしないで、わからない事は聞きながらでいいので、とにかく小さなプログラムから始めてみるのがいいと思います。 僕も記憶力は良い方じゃないので単純に覚えるというのは苦手です。ただプログラムの場合は、色々と組み合わさってルール化してくるので、慣れてくればある程度はいけますし、調べながらでもじゅうぶんできます。（そして調べているうちに覚えていくこともあります） と言うことで、あとは諦めずに地味にコツコツやることだと思います。

BGはたくさん表示出来るけどブロック単位なので柔軟に配置させたり個別に動かすのが苦手。SPは柔軟に動かせるけど数に制限がある、と言うことで臨機応変に扱えるように両方に用意されているんだと思います。 ちなみにSPやBGの定義番号は文字コードと一致するように配置されているので、ASC命令で簡単に対応する文字の定義番号を求める事が出来ますよ。 例：?ASC("0")なら48でSP定義番号（BGキャラ番号）の0の絵と同じ。

ほとんどの人がちゃんと解説しているので、そういうことなんですよね。 質問前でも PRINT BIN$(-6) を表示してみれば、なんとなく納得できたかも？

処理と変数名から推測するに、最大８体の敵キャラが出てくるゲームなので、とりあえずその８体用に用意した配列変数３つを初期値で初期化している。みたいな感じだと思います。

まず何故２になると思うのか、その根拠を書いてから聞いた方がいいかもですよ。

説明は皆さんが書いてあるので僕は補足だけ。 IFで論理演算のつもりでANDを使っている人も居るような気がしますが、ビット演算と論理演算の結果は同じではありません。 正確な記述をすれば大抵問題ないですが、そうじゃない場合はかつの意味ではANDより&&を使った方が安全（安心）かもですね。 （BUTTONの時によくでるANDはビット演算の場合が多いので注意）

あきとさんはボタン命令の種類で処理するやり方だったので僕の方は変数などで処理するやり方をひとつ書いておきます。 このようにIFの時は対応する定義番号だけ変数にいれて、あとの方で変化があった時だけSPANIMするようにすれば何度も実行されないのでアニメーション出来ます。 変化の際は一旦全て止めるために現在の定義番号をそのまま再定義する（SPCHR）方法でSPANIMの効果を打ち消しています。 こうすることで対応外のボタン（離したときなども）にはSPANIMしませんがアニメーションは止めることが出来ます。

こういう機能は地味に便利ですよね〜。 ちなみに一つだけ気になるのは裏技（バグ技）なのでバージョンアップなどで使えなくならないか、みたいなところが心配ですね。 まあ今まで残してあると言うことは暗黙の裏技仕様として残してもらえるのかなという気もしてますが、それだけちょっと気になる感じでした。

速度調整の事を考えるとVSYNCを入れたときのスピードが基準だと思ってください。それでSTICK命令は最大±１の値しか返さないので、その値をそのまま計算するのだと移動量が少ない＝遅い、のでMiliniumさんの教えてくれたように、その値に一定量の数値をかけることでスピードアップさせます。

１　向きに関する変数を用意して、ボタン入力に合わせてその変数も変化させる。 ２　向きの変更を検知したらキャラクタの絵を変更する。 が基本かなぁ。で、絵を変えるだけなら変数を用意しなくてもIFの中でやってしまっても問題ないですが、スプライトをアニメーションしたい場合は１のように向きを変数に入れておいた方がいいです。 またアニメーションしたい場合はSPANIMを使う方法もあります。この場合、向きの変更を検知したら、その向きのアニメーションを開始するようなイメージです。注意点はSPANIMは何度も呼び出すとアニメーションが頭出しされて動いてない感じになるので、向きが変化した直後のみSPANIMさせることです。 あとはSPANIMのアニメーションがある場合は、向きの変化もそうですがボタンが全て離された（止まった）時は、アニメーションを止める処理も必要になります。

ビットは二進数での１桁（０か１）です。 ２ビットなら２桁、３ビットなら３桁になって、それはデータ容量とも言えますね。 （まとめてみた） ということで詳しく知りたい場合は二進数を調べるといいですよ。

ST35-SM35Fの存在を知らなかったので作るのも面倒だしそこまでする気はあまりなかったので音声転送に興味なかったけど、ズバリのケーブル（半差し不要）があるならちょっと興味が出てきてたりもする…

シンブルなタイトルながら、プチコンでC言語でプログラムが組めるのか聞いているのか、プチコンユーザーがC言語でプログラム出来るのか聞いているのかがわかりにくいという罠だ…

サイドビューで左右とかだけなら単純にX座標の比較で右か左か判定出来ますけど全方位になるとみむ*mimさんの回答な感じになりますね。

マップツール上でおかしいのか、プログラムで読み込んだあとのマップがおかしいのかでも変わってくるので正確な情報が欲しいです。 あとベース25×15の縦2、横2では正常なのだとするとマップサイズによるバグがある可能性があるんだけど、どちらにしても何処で何が出来なくなるのかを知りたいですー。

シフト演算子は、ビットをシフト（ずらす）演算子だから二進数を理解してないとイマイチピンとこないんじゃないかなって思いますね。 関数と言うよりは、演算子だからその名の通り＋やーなど演算子の仲間じゃないかなって思います。

何が出来なくなる感じですか？ 25×15の縦１，横１でも出来なきゃおかしいので具体的な事を教えてくれれば調査したいと思います。

バグと裏技は紙一重…