タッチ操作で選んだスプライトに切り替える処理をした後、スプライトの大きさを変更して移動させようとしましたが、大きさは正しく変化したものの移動が上手くいっていません…orz！ IF 変数==SPの番号 THEN SPOFS～という形式にしていますが、タッチ操作+SPCHR 変数,SPの番号で切り替えた場合には、変数==SPの番号という条件式ではダメなのでしょうか？ それとも、別の理由で正しく移動が行われない状態になっているのでしょうか？ エラーは発生していないので、命令の入力法を間違えているというわけではなく、正しい移動の処理が行われないだけです！他のパーツは正しく移動しているのに、条件式を使っているパーツだけが移動していないのは、何故でしょうか？

SPHOMEで起点が違ってるとか 拡大率に合わせて移動量を変化していないとかはどうでしょうか？

「変数」と「SPの番号」が、「SPの定義番号」なのか「SPの管理番号」か文面からよく分かりませんでしたが、全く動かないということでしたら、 　IF 変数==SPの番号 THEN SPOFS 管理番号･･･ で、「変数==SPの番号」になっているかと、SPOFSの管理番号が合っているかを確認してみてはどうでしょうか。 これらが、問題無い場合は、「動いているが動いていないように見える」Moh6ANさんのような原因をさぐる必要があります。

たとえば、 SPCHR 変数１,SPの番号 の「変数１」は、管理番号が入っている変数、「SPの番号」が定義番号で、 IF 変数２==SPの番号 THEN SPOFS 変数１･･･ の「変数２」は、管理番号で使っている定義番号を保存している変数だとすると、CPCHRで図柄を変更したとき、変数２に「SPSPの番号」を代入する処理がないと、「変数２==SPの番号」が「偽（0）」になって、SPOFSは実行されません。（分かっているとは思いますが、「思い込み」の確認です。）

いくつか追加情報をお伝えします！ まず、SPHOMEは左上が原点になっていて、それは関係無いと思われます。 次に、SPの定義番号と管理番号と変数に代入している番号は全て同じですので、番号が違うということもありません。 タッチ操作した結果、SPCHR 変数,SP番号で切り替えているので、条件式を変数==SP番号にすれば良いと考えたのですが、それではダメなのでしょうか？ そして、SPOFSで指定した座標も間違っていないはずです。 もしかしたら、条件式の処理が多くなっていることが原因になるということはありますでしょうか？

SPCHRによる定義番号変更は、プチコン内部で管理しているメモリ内容を変更するだけなので、ユーザが定義した変数に影響を及ぼしません。 もし、変数が管理番号で、図柄を変更しても管理番号を変更しないときは、 IF SPCHR(変数)==SP番号 THEN ・・・ 図柄を変更したときに管理番号も変更するときは、管理番号の変数の内容を明示して変更する必要があります。

というか、後者の場合、ＳＰＣＨＲでは無く、変数にＳＰ番号を新しいものを代入すればいいのではないでしょうか。

細切れですみません。 後者の場合、前のSPが見えなくなるようにする、移動かSPHIDEもお忘れなく。

あっ！やっぱり、SPCHRによる影響だったのですか？何となくそうかなぁ…とは思っていたのですが、変数に代入されたSP番号が入れ替わっているから大丈夫なのか？とも考えていました。 後者の場合、SPの変更に関わる処理が大変だと考えたため、SPCHRによる変更を選んだのですが、その場合はSPCHR(変数)という書き方にする必要があったのですね♪

便利な関数があったのでＳＰＣＨＲ（変数）と言う書き方をしましたが、１つ注意することがあります。 ・管理番号と定義番号との対応が取れていない場合、０を返すようになっています。（個人的には－１の方がありがたかったです。） なお、後者には後者の、前者には前者の良い点があるので、nobuさんの好きな方法でやるのが良いと思います。

コータ【quota】さんに教えていただいたSPCHR(変数)という書き方にしてみたら、正しく移動して表示されるようになりました♪ まだ、いろいろなパターンを試してはいませんが、SPOFSの数値が間違っていない限りは大丈夫だと思います。 あとは、その完成した顔を１枚の画像としてセーブして、それをロードして利用できるようになれば完成となりますが、その仕組みを作るのは初めてなので、正しくできるかは不明です…(´・ω・`)。

ところで、GSAVEに関してなのですが、色変換フラグの説明を読んでも、どういうことなのか？よく分かりません…orz。 １が物理コードのまま…ということは、本来その画像は１の状態ってことですか？ そして、０が32bitの論理色に変換…とあるのですが、そうすると元の画像より綺麗になるのでしょうか？ 元のままで良いなら、１にしておけば無難となるのですかね？

透明フラグとＲＧＢの色データの並べ方が変わるだけなので、画像の品質が変わることはありません。 １のときは、Ａ(1)Ｒ(5)Ｇ(5)Ｂ(5)［()内はビット数］の並び ０のよきは、Ａ(8)Ｒ(8)Ｇ(8)Ｂ(8)［()内はビット数］の並び になりますが、下位ビットの余ったところは、Ａは１、ＲＧＢは０で埋められるようです。

画像の品質が変わらないというのは朗報ですが、それでは０にすることのメリットは何でしょうか？ そして、基本的には１にしておけば良いですか？

どちらを選ぶかは、nobuさんが、どんな使い方をしたいかによります。 私は、１を使うことが多いですが、０を使うと、RGB命令・RGB関数で扱うのと同じ形式になります。

上とは別の質問になるのですけど、GSAVEというのはGRP0に現在表示されている画面の保存にはならないのですか？（並べたSPは、GRP4だから別の画面になるってことですか？） 先にGCOPYをしてからGSAVEをすれば、GRP0に表示されている画像を保存することができますか？ 保存したいのは並べ替えたSPなので、GRP4を指定すれば良いのでしょうか？しかし、画像を保存したら元の画像に上書きされたりしませんか？保存するのは配列だから、元の画像には影響ないということでしょうか？

１．GSAVEしても元の画像に影響しません。配列に読み込むだけです。 ２．GSAVEで転送元ページを省略したときは、GPAGEの第２引き数「操作（描画）ページ」で指定されたグラフィックページから読み出します。 ３．GSAVEで転送ページを指定すれば、GCOPYしなくても配列に保存することが出来ます。もちろん、GCOPYするやり方でもできます。

GSAVEだけによる方法とGCOPYも使う方法の両方を試してみましたが、どちらも上手くいきませんでした…(>_<)。 私が保存したいのはSPOFSで移動させたSPの集合体なので、GRP4を指定したのでは元のSP画像になってしまうし、何も指定しないと背景の画像になってしまいます！ SPCHRの考え方と同じで、SPOFSによる移動が表示上のものだけだとすると、そういう画像のコピーや保存は不可能ということですか？ プレイ画面のスクリーンショットのように、表示された画像をそのまま保存する方法は無いのでしょうか？

ＳＰやＢＧは、表示中のグラフィックページに書き込んでいるわけではないので、表示イメージを保存するには、一工夫必要になります。 １つのやりかたとしては、表示中のグラフィックページを使っていないグラフィックページにGCOPYして、スプライトの元絵やＢＧの元絵をGCOPYし、そのグラフィックページを保存することが考えられます。工夫してやってみてください。

そうですか…。どうやら、その方法だと苦労する割に完成する画像が一つだけで、たくさんのパターンを保存するのには向かないですね…。 もっと簡単に画像の保存ができるのなら、実装してみたい機能だったのですが、考えていたような画像の保存はできないので、画像の利用は別の方法を使うことにします！そちらのほうが楽に編集できるので、その方法より適切となります。 今回教わったGCOPYやGSAVEは、別の機会に使うことにします！ありがとうございました♪