新作「鉄壁(TEPPEKI)」です。キーJRN3N2NV 見た目ブロック崩しですが、ブロックは「1/64の確率」で壊れます。思った以上に鬼畜です。 このゲームを「New3DSで」テストプレイして頂ける方を募集しています。というのもWAITやVSYNCだと遅くて面白くないのでFOR～NEXTでウェイトを計ってます。当方3DSLLで作ってますので。 他にいい方法があれば教えていただきたいです。

NEW3DSLLからプチコンをやっています！

ボールが速すぎてとても追い付けません…これがまさに“鬼畜ゲー”だと思います… @NEW3DSLLからプチコンをやっている人

ありがとうございます。やはり速かった、と。 54行目がウェイトの値ですので書いてある数字の3倍くらいにしてみてはいかがでしょうか。

試してないので出来るかわからないんですが、MAINCNTが１増えるまでにループした回数を計測して、そのループ回数によってFORのウエイト回数を調節するようなプログラムを書けばVSYNCに頼らずVSYNC以上の速度をある程度調節ってできないですかね？ まあでも3DSとNEWの違いだけなら両方でちょうど良い数字を見つけて埋め込むだけでも問題ないのかな…

なるほど。MAINCNTを使う方法は頭にありませんでした。ありがとうございます。

うーん・・・MAINCNTを組み込んでみましたが、1/60秒で1カウントですのでVSYNCと変わらなかったです。ありがとうございます。 そして、そのMAINCNTを利用して「3DSかNew3DSかの自動判別」を疑似的に行ってみました。 それに伴い公開キーがNKAKN5RYへと変更(アップロードの上限に達している為)しました。これはまた新規投稿でもお知らせします。

あ。ちょっと僕の意図がちゃんと伝わってなかったかも…。 MAINCNTは1/60秒で1カウントなんです。 なので、それとは別に、自分でもメインループの回数をカウンターでカウントしておいて、MAINCNTが1増えたタイミングで、そのカウンタがいくつになってるか調べてみる感じです。 それでカウントが予定より多かったら、その分多くのループを回っていると言うことになるので、自分のウエイト用のFORループのカウント回数を増やしてメインループの時間が間隔が長くなるように少しずつ調整していくという感じで…。ってイメージ伝わりましたかね？ まあ自動判別が出来てその切り替えで問題なさそうなら大げさな感じもあったので、とりあえず考えてみたってだけの話でしたが〜…。

なるほど。ちなみに私の方法は MC=MAINCNT:FOR I=0 TO 14999:NEXT IF MAINCNT-MC>8 THEN 「3DSである」 こんな感じで(実際計ったら10と返ってきましたので)。

ふむふむなるほど〜。 NEW 3DSではいくつの数字が返ってくるのか気になりますね〜。というかその割合でウエイトの回数を調整出来るのかな？ 3DSで10でNEW 3DSで5だったらウエイトの回数を倍にする、みたいな？

旧3DSとNew3DSは処理によって変わりますが概ね3～4倍の速度差があります。 したがって、MAINCNTでNew3DSか否かを判別する関数をプチコン3号が発売された日に私も作りました。これによってNew3DSで動作時には旧3DSと差別化は可能ですが、60fpsを超える速度で動かすのは表示更新が1秒間に60回なので意味はないですね。

>でんぺんさん　New3DSでは試していません(報告が欲しいくらいです)のでだいたい3倍と踏んでます。私もNew3DS買おうかなホントに。 >おちゃめさん　報告ありがとうございます。3倍だいたい当たってたのに驚いてます。処理速度を抑える為のウェイトですので表示の限界に挑戦する気は無いですね。

すみません、質問です(・ω・)／ 落とせなかったのでゲームは見れてないのですが、ゲーム速度をCPUにウェイトをかける事で実現したのはどうしてでしょうか？ 普通にボールの速度を変数で持っておいて、その変数の値で制御する、という方法しか私は考えが浮かばなかったもので……。

バージョン変わったのでプログラムを一旦消しました(容量上限に達しているので)。新しいバージョンはNKAKN5RYになります。 ボールは(3DSを普通に持った状態から)横方向に1又は-1、縦方向にSINで求めた値(-1～0～1の間)で制御しています。 その為ノーウェイトだと速すぎてゲームにならないのと、WAITやVSYNCですと1/60秒で刻むので遅いんですよ。中間を取ってFOR-NEXTでウェイトをかけました。

VSYNC 1であっても1フレームの間に4回処理すれば240fps相当での動作になるのでFOR～NEXTでウェイトを入れなくても問題はないですよ。

なるほど。その発想は出てこなかったです。

出来ました。この54行目と59行目をこう変えてVSYNC 1までに@BALを何回かループさせたらいい具合になりました。多謝。

>ミケランジェロさん ありがとうございます！(^O^) 落とせました。あと、修正版の投稿は公開キーの最初の2文字が間違っておりましたので、訂正コメントを入れた方が良いかもしれません。 球のスピードは係数を変数で持って調整するイメージでしたので、処理負荷の高低で調整しているメリットが分からなかったのです。 が、自分でやってみて理由が分かりました。 一回の計算で2ドット以上進むと、そのままではブロックとの跳ね返りの処理が上手くいかなくなるのですね(^^; 正攻法で対処するなら多分めり込みを戻す計算を追加する感じになると思われますが、シンプルに対応するならおちゃめさんも書かれてる、1ドットずつの計算を繰り返す方法が良さそうですね。 あ、4面までは行けました(・ω・)v

どうもです。今のバージョン(VSYNCの前に複数回@BALを入れる)が問題無ければ明日にでもアップし直そうかと考えてます。 ブロックの跳ね返り処理は「周り4ドットの色を見てどこからぶつかってるのか判断」していますので1ドットづつでないと動かせないという問題があります。思ったよりも難しい問題ですので。 あと4面は「この野郎」と言いたくなる構成にしています。上手く間に入り込んでしまえばいいのですが条件が中々揃いませんので。