著作権フリーといっても「どのような使い方をしてもOK」というわけではないので単に画像だけでは判断は難しいですね。 「その配布サイトの条件にしたがって使用してください。」としか言えません。 あとプチコン3号の場合は公開キーを発行したら二次利用OKになってしまいますから公開キーの発行をする場合だと自分が撮影した写真以外ではかなり厳しいと思います。 また、それに加えてMiiverseの規約もあります。分からないことは規約を読んで自分で問題ないと思える写真を投稿すればよいかと思います。（規約を読んでも判断が難しいものは投稿しなければ良い） もちろん個人での判断でOKと感じても客観的に見たらそうではないという場合は削除されてしまう恐れがありますが。

MIKIさんへ 服の丈が短いのもそれと同じ理由です。 服やスカートが破れないのは私の良心です。m○hさんならば同じ趣旨の絵でも間違いなく破れてしまいMiiverseでは投稿できないような絵にしてしまうと思います。 靴に関してはサイズが合わなかったら伸びることはないので恐らく大きくなった後で合うサイズのものに履き替えたのではないかと思われます。

これはプチコン3号のRND関数は引数も戻り値も整数型として処理されるためです。（小数値を引数に設定しても自動的に切り捨てられる） プチコン3号の整数型で扱える範囲は-2147483648から2147483647ですが負数はOut of rangeとして処理されているため引数は実質0～2147483647となります。 すると必然的に戻り値は0～2147483646となります。プチコン3号のRND関数では2147483647という整数型の上限値は発生しないのです。 あと単なる整数値ではなく整数型になっているという点においても注意すべきです。 DEFを使った自作命令でTEST RND(400),RND(240)みたいに引数にRND関数を使うとその引数に使った変数は整数型変数となるため変数の使い回しをする際には問題が発生する可能性があります。

MIKIさんへ 「アニメ塗り」のことでしょう。 アニメ塗りとはくっきりとした線画を用意してそれにべた塗りで色を塗っていく塗り技法のことです。 私が書いたアニメ塗り講座を参考にどうぞ。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0f2ugs1cw

MIKIさんの u16*(1/(1<<n)) = u16 / (1<<n) = u16 / 2^n = c においてu16 / (1<<n)とu16 / (1<<n)はプチコン3号では同値とは言えません。 後者は強制的に整数化されるのに対して前者は実数で求まります。 mohさんがシフト演算処理で悩んでいるとは思いにくいのですが分からないのは具体的にどの部分ですか？

簡易地球儀は画面に表示される地球儀において各ピクセルが世界地図においての緯度や経度を求めるという処理を行っています。 計算アルゴリズムはともかくとしてテクスチャをを貼り付ける場合は変形を行うというよりも画面表示のピクセルがテクスチャ画像のどの部分を示すかを求めるというのがポピュラーなやり方ではないかと思います。 テクスチャは矩形でならなければならないということはなく計算がしやすいようにテクスチャそのものを変形しておくというのも1つのやり方ではとしてはありだと思いますよ。

この世界地図のGRPは左右は繋がっていますが、上下が繋がってないため上下回転をさせるようにするには「繋がるような計算処理」をする必要があります。 現状ではプチコンBIGでは1秒間に42万ピクセル分くらいのテクスチャ演算処理を行っていますが上下が繋がるようにするとかなり落ちると思います。 しかし、うまくARYOPが使えれば速度低下分がカバーできるかもしれません。 ARYOPを使用するならばGPSETの処理をGLOADで行えばリアルタイム処理としては最速レベルになると思います。 予めすべての方向の回転データを用意しておくならば横256通り、縦256通りならば合わせて65536通りになるためメモリ面ではかなり厳しいでしょうね。SDカードからのロードだとロード速度が追いつかないと思います。

単純に考えると1.3倍くらい速くなりそうですが、重いのは円内のピクセルかどうかの判定ではなく描画そのものなのでピクセル単位の描画処理そのものを軽くしない限りは高速化は難しいと思います。

最初に計算をすべて済ませておくというのは高速化テクニックの1つなのでずるくはないと思いますよ。 メモリがやたら多いプチコンBIGだと十分に「あり」な方法でしょう。 私が作った簡易地球儀は「リアルタイムで1ドットずつ計算して高速化」というだけにすぎないです。

念のため書いておきますが IF B==#L AND B==#R THEN ～ IF B==#L && B==#R THEN ～ においてB==#Lという条件とB==#Rという条件の両方を満たす場合というのは存在しません。 つまり、B==#L AND B==#RもB==#L && B==#Rも値が0であるためTHEN以下を実行しないということです。

リンク先の内容を理解すればLとRを同時に押しているかどうかは(B AND #L)!=0と(B AND #R)!=0という2つの条件を満たしているかどうかで判断ではなくIF (B AND 768)==768 THEN ～で判断（768という数字は#Lと#Rの合計値）で判断が可能なことをも分かると思います。

ここまでのことが何のことかさっぱり分からないというのであれば複数の条件式を満たしているかを判断する場合にはB==#Lのよう比較演算子を必ずつけるようにすれANDと&&の違いを意識する必要はほとんど無くなります。 では、IF B AND #L THEN ～　とはどういうことなのかというとIF (B AND #L)!=0 THEN ～から!=0を省略したものと考えるとわかりやすいです。 このANDの計算の仕組みを理解するには2進数の知識が必要になりますが、2進数を知らなくても下記のトピックスで詳しく説明しているように「値を取り出すもの」と考えると分かると思います。 https://miiverse.nintendo.net/posts/AYMHAAACAAADVHjrpjduHA

IF B==#L AND B==#R THEN ～ IF B==#L && B==#R THEN ～ このIF文はどちらもB==#Lという条件とB==#Rという条件の両方を満たした場合にTHEN以下を実行します。 比較演算子を使用した条件式（論理式）は上記のように1という値になりますが、「1 AND 1」も「1 && 1」も1という値になりこれは0以外の値であるためTHEN以下が実行されます。 つまり、ANDも&&も+や-のように計算をする記号に過ぎないということです。

IFというのはtrueかfalseだけで判断されています。 これはプチコン3号の場合は値が「0以外」か「0」となります。 あとB==16などの比較演算子（「＝＝」や「＞」など）を使った論理式というのは条件が成立した時に値が1、不成立の時は値が0となります。 つまり、IF B==#L THEN ～はBの値が#L(=256)の場合はB==#Lの値が1（true）となるためTHEN以下が実行されるわけです。 要するに「0以外」か「0」の状態にできれば良いわけです。

「瀕死状態の時にピンチになりやすい」「勝てそうな相手を攻撃する」というのはリアルさがあって良いですが、ゲームとしてプレイしていて楽しいかというのとリアルさがあるのは別問題なのが難しいですね。 リアル感を重視したら瀕死の時にHPフルの時と同じように行動できる方がおかしいですからね。それを言ったら重い装備をしたら素早さが下がらないとおかしいとかたくさんの問題が出てくるし、そういうリアルさを追求すればするほどゲームがシビアになってくるため楽しみにくくなりそうです。 その辺の線引きは作り手の判断次第なので「自分がやっていて楽しいもの」をぜひ作ってください。

三平方の定理を使って塗りつぶし円を描画するCIRCLEFILL命令を作りました。 CIRCLEFILL 中心のX座標 , 中心のY座標 , 半径 , 縦横比 , 色コード と記述します。 縦横比に1を指定した時は円ですが、1以外を指定した時には楕円となります。 1～8行はベンチマーク風にランダムに塗りつぶし円を描画するプログラムです。 プチコンBIGならば1秒間に1万回以上描画が可能です。 シンプルながらそこそこ速いアルゴリズムです。（最速アルゴリズムだとプログラムもそれなりに長くなるし複雑になる）

あとQSP等の文字数制限プログラムを作りたい場合は*や+の方が&&や||よりも短縮できる場面が多いため活用していますね。 そういう意図がなく普通に「かつ」「または」として動作するプログラムを記述するだけであれば自分が使いやすいものを使うと良いです。 プログラムは思った通りに動けばすべてそれが正解なので「○○を使ったらダメ」というものはありません。（「可読性を上げるならばこちらの記述方法が良い」とかいうものならありだけど）

私も参加したかったのですが、このトピックスに気が付いた時にはすでにたんじぇさんの72文字という大記録があったためこれを超えようと試行錯誤したのですが無理だったのであきらめました。 ネタ系もすでに主なものが出そろっていたので二番煎じ、三番煎じ的なものを投稿しても仕方がないですし。

ツララさんへ 「－」を使えばXOR的な使い方もできます。 *、-、+を駆使すれば複雑な条件も簡単に記述できるため私は昔からポケコンでゲームを作る際にはよく使っています。（簡単に記述できるため高速化できる場合もある） 同じものを&&や||といった論理演算子を使って記述するのはかなり大変です。

要するに「0以外」か「0」の状態にできれば良いので「AND」「&&」「*」のどれでも複数条件を満たした場合の判断は可能となります。（「OR」「||」「+」も同様） ただし、&&以外のものは比較演算子を使わないと「0以外」か「0」の状態にはできないためANDを使って複数条件のすべてを満たす処理を記述したい場合はIF A>1 AND B==2 THEN BEEPという感じに比較演算子を必ず記述しておけば問題ありません。 ヘルプの実行例もこの形になっているため&&とANDは同様に「かつ」として使えるように記述しているわけです。