プチコン3号には「かつ」「または」を示す論理演算子である「&&」と「||」が用意されているためそれを使うのがベターですが、比較演算子を省略せずに記述すれば「AND」「OR」を「かつ」「または」として使用することは間違いであるとは私は思いません。

昔はパソコン自体が高価だったし、基本的にパソコンを買えばBASICが付属していた（多くの機種ではROMに入っていた）ためBASICが広く使われました。 パソコンの価格は80年代初頭（81～83年くらい）だと安い機種で10万円を切る程度でしたがモニタは別売り（ファミコンのようにTV接続可能な機種はあった）だし、FDD（フロッピー）は高級品だったので廉価機種には搭載されなかったためカセットテープへの保存が主流でした。 10万円でさえ厳しいならばポケコンという選択肢がありました。これならば安い機種だと1万円程度だったし単体で使えるため私も様々な機種を買いました。とはいえ安い機種だとメモリが1KBくらいしかありませんでした。（プチコン3号だと1画面プログラムを作るくらいの感じ）

IF 0<=H && H<60 THEN ならばIF !FLOOR(H/60)THEN に置き換えることができます。 HSVをRGBに変換するための判定ならばあらかじめ60で割って整数化したものを別の変数に入れておけばその変数の値が0の場合、1の場合、中略、5の場合の6通りの場合分けをするだけ済みます。 ただし、この場合はあらかじめHの値を0以上360未満にしておく必要があります。 Hの値がこの範囲外の時はどのようにするかで処理方法が変わりますがH=420をH=60とするならばH=((H MOD 360)+360)MOD 360とすれば良いです。（MOD 360を2回使っているのは負数の場合の例外処理のため） 整数化には様々な方法があるし、0から360の範囲に制限するのも様々な方法があるのでお好きなやり方でいいと思います。

初見では宝石を集めるラミアだと思っていたのにれいさんのせいでう○こにしか見えなくなってしまいました。

15パズルのお手本になるような細部まで親切に作られた作品ですね。 スプライトで作られているのでこれを「き○子」のようなアニメーションパズルに改造するのも容易にできますね。（アニメーションデータを作るのが面倒だけど） pinfuさんへ ライン＆ペイントによる1枚絵の表示は昔の8bit全盛時はデータ圧縮の方法としてポピュラーなテクニックでした。 プチコンのように無圧縮で1枚絵を使うなんて無謀だしJPEGやGIFのような画像圧縮は当時のマシンでは重すぎて実用ではなかったです。（16bit機であるPC-98ではMAG形式などの様々な独自の圧縮形式の画像が使われました） あとBASICで作られたアドベンチャーゲームではPAINTが遅く目に見える速度で少しずつ描画されていくのも興奮しました（笑）

みき★さんへ 私が調べた限りだとVSYNC終了時には画面更新は終了しているみたいですね。（ver.3.0.0では違っている） あとぷちぷちさんが言われている1/60秒単位での動作というのは入出力系の関数はすべて値がVSYNCのタイミングで値が更新がされているということです。 BUTTONだけではなくSTICK、TOUCH、ACCEL、GYROなどがすべて当てはまる（MIC命令は例外）ので60fps以外で動作しているゲームは正常動作できない場合があります。 でんぺんさんへ メインループにおいてVSYNC 1とWAIT 1はほぼ同じ動作になりますが、それは60fpsで処理落ちなく動作している場合に限られます。 わずかでも処理落ちしている場合はWAIT 1はそこからさらに1フレームのウェイトが入り、VSYNC 1だとすでに前回から1フレーム経過しているためウェイトは入りません。

パラシュートのリストはこちらです。OSPが十分に作れるサイズだと思います。

うえこうさんへ パラシュートのスプライトを作ったのでよかったら使ってみてください

すみません、私の勘違いです。 「楕円にならない」というのは左右の視差を考慮してどのように見えるべきかをプチコンのプログラムで再現した時のものでした。 一点透視（というか透視投影）ならばれいさんが言うように楕円で合ってますね。 なぜ球を出したかというと立方体の奥行きが不自然にならないようにするためには球を描いた時に円ではなく明らかに楕円に見えるレベルの範囲（画角）にならなければ良いためです。 個人の感覚に依存するため自然か不自然かの明確な境目はないですが、私のサイトの講座で書いているように個人的には画角45度くらい（標準レンズ）くらいを基準に考えています。

これは「球」は画面の中心にない限り歪んだ円形（ただし、画角や描画位置によって異なるため見た目の奥行きが長くなるような立方体に内接する球だと明らかに歪んで見える）に投影されるというだけの話なので平面に描かれた「円」であればどのような画角であろうとどのような位置であろうと楕円になります。

れいさんへ 「本来ならば円形に描かれる」というのは「ぱっと見た目で正円といって問題ないレベルの歪んだ円（「楕円」とも異なる）で描かれる」という意味で書きました。 画角が45度以下ならば周辺部に描いたものであってもほとんど正円と見た目が変わらないです。

明らかに左右よりも奥行きが長くても描いた本人が「立方体」と言えば立方体になるのが一点透視なのです。 ただし、他のオブジェクトも描く場合にはその立方体と合ったものにする必要があります。 本来ならばどこから見ても円形に描かれるはずの球もこのような明らかに奥行きが長い立方体に合わせて描くと円形にならなくなってしまいます。

一点透視図法については私のサイトでも解説を書いていますが、実は簡単に見えて難しいため正しく理解できている人は少ないです。 というのも、この描画しているのが立方体であるならばこの立方体の奥行きの長さはどれだけ長くても短くても一点透視としては間違ってないからです。（この場合だと奥行きが1ドットでも100ドットでも立方体となる）

上達のためにはちゃんと考えて作ることと数をこなすことが重要だと思います。 そういう意味では大きなプログラムを無理に作るよりもいろいろなタイプの小さいプログラムをたくさん作る方が効率が良いと思います。 あとは自分の力だけでは限界があるので他人が作ったプログラムを解析したりアルゴリズムなどが書かれた本を読んで勉強するのがベターだと思います。（あえて車輪の再発明をするのもありだけど時間的な効率は悪い）

こうやまさんへ iPadより面積は少し小さいですが2画面で両面タッチ可能といえば東芝から発売されたノートPC「libretto W100」がありますね。プチコンエミュを作れば実現は可能です。

動作方向が45度単位の方向ではない場合や移動量が0か1かではない場合だとスライドパッドを使うしかないですが位置的にスライドパッドの方が使いやすかったり斜め入力がしやすいというメリットもあるためスライドパッドでBUTTON相当の動作をする関数を作る（十字ボタンの方が使いやすいという人もいるためそれを考慮する）のが個人的には操作性の面でベターだと思います。 ちなみにプチコンmkIIはDSiウェアであり3DSで動作時にはスライドパッドは十字ボタン相当で動作していましたが、私は十字ボタンではなくスライドパッドをメインに使っていました。 斜め入力をされたら困るゲームの場合は十字ボタンの方が良いでしょう。

昨晩の線香花火は思った以上に好評だったので公開キーを取得しました。【 NKX5BXS3 】です。 まげさんへ 「バチバチ」という動作が線香花火のメインですが、その前後があってこその線香花火だと私は思います。 脳内でプログラムを書いた時にはこれで線香花火に見えるかが心配でしたが、概ね納得できるレベルに仕上がったと思います。 うえこうさんへ 入力ありがとうございます。

17行なので入力は楽だと思います。 公開キーはすでに10個使っているため希望者がいれば何とかします。

次の休日に作ろうと思っていた線香花火があっさりできたので公開します

整数型は「実数型より少し速くてメモリ消費が小さいけど整数しか入れることができず、±21億までくらいの数しか扱えない」、実数型は「整数型より少し遅くてメモリ消費は2倍だけど小数が扱える上に10の308乗くらいまでの数を扱える」という感じの大ざっぱな認識でいいと思いますよ。 必要になったときにもっと詳しく勉強すればいいと思います。