DISPLAY 0/1の謎仕様に踏み込んでしまいました。 DISPLAY 0/1で別に設定できるものと共通の設定になるもの。何がどうなってるのか、これこそリファレンスやガイドブックとかに載せてもらわないと全てを把握する(試行する)のはすごく大変だと思うのですが、ちゃんと把握されてる方いらっしゃいますかね？ ちょっと調べたところ、別で設定できるのはGPAGE/SPPAGE/BGPAGE/GCOLOR/COLOR/BACKCOLORくらいだったかな。SPSETとBGSCREENはどう考えれば良いんだろう？とにかくようわからん^^; なんか、こう考えればスッキリ明確、な説明して頂ける方いらっしゃいましたら非常に助かるのですが。それともやはり命令1つ1つ確認しなきゃならないもんかな。 ＃スクショ貼るために3DSから投稿 ＃してるけど、慣れてないから大変。

上画面の青いのと同じプログラム結果の下画面。

別で設定できるもの、VISIBLEとLOCATEもあったか。ん?まてよ?ってことは画面関係ほぼ別で設定できるってことか?ナニで悩んでたんだっけ?^^;

殆ど別で設定できると思いますよー(・u・) 共通なのはFONTDEFとかSPDEFとかXSCREENくらい？ SPやBGは、上下画面それぞれ0からですー。例えばXSCREEN 2,384,3なら、上画面がSP0〜383,BG0〜2、下画面がSP0〜127,BG0、って感じになると思いますー。

やっぱりそっかぁ～。別で設定できるもの何だろう?って考え始めたのが失敗だったか(>_<)共通のものから考えればよかった^^; SPやBGSCREENはDISPLAY 0/1両方とも0番からってのはちゃんと分かってなかったなぁ(今回試してたくせに^^;)。今までは何となく番号被らないようにしてたような気がするけど意味なかったというか、SP使える数減っちゃうじゃんか。 同じ番号だとすごく紛らわしいなぁ。デバッグも大変そう。変数とかで工夫して気を付けるしかないか。

CALL SPRITE(BGもかな)の 反応も別々だったり

それはまだ私が使いどころを分かっていないSPFUNCとかのやつか。 DISPLAY 0のSP0番用のSPFUNC 0,"FUNC_DSP0" と、 DISPLAY 1のSP0番用のSPFUNC 0,"FUNC_DSP1" とかって使い分けなきゃならないのかな。やっぱり紛らわしい^^;

SPFUNCは、SP達に「各々指示された処理をしなさい」って言うと皆違うラベルや命令に飛んで勝手に処理してくれる、っていう機能ですー。 なので、最初に「君はこの処理ね」って指示を出すのですけど、別にその指示は上下画面全く関係なく自由に決められます( ´ u ` ) その後「各々処理しなさい」って言うための指示がCALL SPRITEで、そっちが上下画面別、って言うことだと思いますー。なので、上下画面どちらもの場合、 DISPLAY 0:CALL SPRITE DISPLAY 1:CALL SPRITE となるのだと思います。ていうか別なの初めて知った…(・д・)

詳しい説明ありがとうございます(^o^) SPFUNCとCALLは、薄ぼんやりとSPANIMとSPSTARTみたいな感じかなぁと思ってますが、やっぱり実際に使ってみないことには理解できたことにはならないかなぁなんて考えてます。 まぁ、そのうち使いたい機会やって来るでしょう^^;

SPANIMは一度指示するとあとはずっと動き続けますし細かい指示は出せませんが、SPFUNCは事前設定なのでその場では一切動きません。CALL SPRITEをした時だけ一回動きます(・8・) イメージ的にSPFUNC 0,"@FUNC"は、 (DIM FN$[512]があるとして) FN$[0]="@FUNC" こんな感じ。CALL SPRITEは、 FOR I=0TO 511 IF FN$[I]!=""THEN GOSUB FN$[I] NEXT こんな感じですー。(この時システム変数CALLIDXにIの値が入るので、どのSPから呼ばれたかがわかる、みたいな仕組みです。) 便利なので機会がありましたらぜひー( ´ u ` )

SPANIMには *1フレーム後からアニメが開始する。 *数百個のSPを毎フレーム移動させたりする 重いプログラムだとアニメが遅れる。 って欠点があるから、 僕は殆どSPFUNC使うなー

＃せっかくなので聞いちゃおう。試すの飽きたし。 CALL SPRITEで一斉に呼び出すってことだけど、CALL SPRITEの命令自体が終了するのは、呼び出した全てのサブルーチンとかが終了した時点で終了するのかな?それともサブルーチンの終了を待たずに直ぐ終了するのかな?(後者だと面白いな)

一斉に呼び出すとは言っても処理順がぐじゃっとなることはなくて、SP番号の小さい方から、処理始まり→終わり、次のSPの処理始まり→終わり、って感じですー。それが全SP分回りきったらCALL SPRITEが終わって次の処理に移ります。 使い方というか結果としてはホントに一個前のコメントで書いたようなことと変わらないと思いますー(・u・)

やっぱりそうなのね。ということはCALL SPRITEで呼び出されるいくつかのサブルーチンの1つが無限ループだったらそれ以上の処理に進まなくなるのか(無限ループは大袈裟だけど、いくつかのサブルーチンでVSYNC使ってたら、その時間が積み重なってっちゃうんだな)。 私はSPANIM(とFADEにもちょっと)にはロマンがあると思ってます^^; ちょっと前までリファレンスやヘルプ見てもさっぱり分からなくて、「説明全然足りてねぇ～。こんなんで分かるか～。もうSPANIMぜってぇ使ってやんねぇ。SPCHRで地道にやるからいいもんねっ」って思ってたんだけど、分かって使ってみると便利だったので今は解禁?して使ってます^^; SPANIMは実行してもアニメの終了を待たずに次の処理に進むのがロマンなんです(SPFUNCとどっちが良いかってことじゃなくて、そもそも用途が違ってくるなと思いました)。

ゲームの場合、基本的にVSYNCはループ毎に1回書くだけで、あとは一切使いません。例外的にRPG的メッセージ処理や演出でWAITやVSYNCを使う場合などもありますけど。 どの命令も使い方次第ですので、SPANIMもSPFUNCもFADEもSPCHRも全部使いますよー(・u・) なんならSPFUNCで設定したループでSPANIMを使うことも多いですし。 唯一SPVARだけは配列より遅いので殆ど使いませんけど…(ﾉ´∀｀*)

VSYNCの例が乱暴すぎましたね。言いたかったのは、一斉に呼び出されたサブルーチンの処理時間は積み重なる、です。例えばSP0番～500番までをイッキにCALL SPRITEしても、501回サブルーチン実行してるうちに処理時間1fps超えちゃって処理落ちとかも考えられるから気を付けないとなぁ、って感じです。 私のロマンの正体は、並列処理(マルチタスクとも言うか)です。SPANIMは単純なことしかできないけどそれでも一応並列処理と言えるので、そこに未知の可能性があるかも?とか妄想しちゃいます^^; 今のところは、なんか重い処理する直前にSPSTARTしてクルクル(ファイルロードとかで見かけるやつ)表示させるくらいでしか活用できてなんですけどね。

ハードの処理速度が変わらなかったら、並列処理しても処理落ちする負荷そのものは変わらないのかと思ってましたー。 プチコンで高速化のためにSPFUNCやSPANIMを使った、って話は聞かないんですけど、どうなのでしょうねー。可能性あるのかなぁ(・u・)

あー、SPANIMだから処理落ちしないだろう、ってことを言いたかった訳じゃないです。だにえるさんのおっしゃるように、たくさんSPANIMさせれば遅くなるようですし。 ただ、SPANIMはアニメ終了を待たずに命令自体の実行が直ぐ終わるのであれば、例えばループ中でSPANIM使ってても、ループ全体の処理時間には影響を与えない(あんまり遅くならない)のかなぁと思ったりするんだけど、どうなんだろう?ループ中でSPANIMたくさん使うと、SPANIMで実行されたアニメは遅くなるかもしれないけど、ループ1回の処理時間は遅くならないとか。それとも全体的に負荷が上がってやっぱり遅くなるとか。う～ん、検証してみないと分かんないですね^^; SPANIMのアニメがプログラム終了しても動き続けるのを利用して面白いことできないかなぁと妄想中。