Archiverse Internet Archive
投稿のみ 投稿と返信
前のページ(最近)
147 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67154
次のページ(過去)
返信[2]
親投稿
おちゃめ ochame_nako
目は各自の個性がもっとも反映されやすい部分なので自分が思ったように描くのが一番です。 しかし、先人が培ってきたデフォルメというのもそれなりにちゃんとした理由があり、それを理解しておくというのも重要なことです。この辺は「プログラミングは自由」といっても先人が残してきたアルゴリズムを理解してプログラミングを行うというのと何ら変わりはありません。 ちなみに添付の画像は私が以前作った「プチコン3号お絵かき入門」で書いたものです。 さらに詳しくはWeb上にある初心者向けのデジタル絵講座を参照してください。
2そうだね
プレイ済み
返信[19]
親投稿
おちゃめ ochame_nako
ちなみに60fpsで動作しているプログラムのメインループに入れる場合はWAIT 1とVSYNC 1ではほぼ同じ動作となります。 「ほぼ」というからには全く同じということはなく異なる部分もあるわけですが、ループ内で初回に実行されるVSYNCはスキップされる可能性があるのに対してWAITは初回時でもスキップされないためです。普通のゲームならば最初の1フレーム目の動作を見分けることは困難であるためどちらを使ってもかまいません。 とはいえ、「メインループ」であれば「待ちすぎたら困る処理」であるので「ほぼ同じ」ということを理解して意図的にWAITを入れる場合を除きVSYNCの方がベターです。
2そうだね
プレイ済み
返信[18]
親投稿
おちゃめ ochame_nako
WAITは確実に待つため例えば30fpsで動作するゲームに処理時間を一定に保つためWAIT 2を入れるとWAITだけで2フレームとなるため30fpsでの動作保証はできなくなります。 その点、VSYNC 2は前回のVSYNCから2フレーム経過するまで待つため(処理落ちしている場合を除き)30fpsが保証されます。
2そうだね
プレイ済み
返信[17]
親投稿
おちゃめ ochame_nako
VSYNCとWAITの使い分けはプチコン3号の前のプチコンmkIIから使っている人でも出来てない人が多いのですが、実際はすごくシンプルで「待たないと困る処理はWAIT」「待ちすぎると困る処理はVSYNC」を入れると簡単に使い分けができます。 今回のようなボタン入力処理の場合は一定時間待つことで改善が可能ですが、VSYNCでは「指定時間待つ」ということが保証されない(ねこはちさんもかかれているように前回のVSYNCからの経過時間となるため)ということで確実に待って欲しい処理にはWAITがベターということなのです。
3そうだね
プレイ済み
返信[8]
親投稿
おちゃめ ochame_nako
しんしんさんへ プチコン3号で変数として使用できない予約語は以下のものです。 IF THEN ELSE ENDIF GOTO GOSUB RETURN ON FOR NEXT WHILE WEND REPEAT UNTIL BREAK CONTINUE DEF END VAR DIM AND OR XOR NOT DATA READ RESTORE PRINT INPUT LINPUT CALL TRUE FALSE SWAP OUT COMMON USE EXEC この中に含まれてないTOは変数として使用可能となっています。
2そうだね
プレイ済み
返信[7]
親投稿
おちゃめ ochame_nako
単に「プログラムを短くしたい」のであれば変換テーブルを用意するのが最も簡単です。 変換テーブルの作り方はいくつもありますが、DATAの形で記述していくのがポピュラーですね。 もちろん、子音+母音に分けて処理するという方法でも全く問題ありません。こちらの方がさらに短縮が可能だと思います。
2そうだね
プレイ済み
返信[15]
親投稿
おちゃめ ochame_nako
きゃっきゃさんへ 残念ながらプチコンBIGにはネット対戦のための機能は備わっていません。とはいえ、Miiverseやチャット、twitter等のテキスト投稿が可能なWebサービスを使えばアクション系のリアルタイムな対戦ではなくオセロみたいなテーブルゲームであれば「すごく面倒なネット対戦」は可能です。 要するに現状の盤面の状況や自分の手札(トランプゲーム等の場合)を暗号化してそれを文字列で表現して投稿します。 相手はその文字列を入力して復号化して自分のプチコンBIGで相手の状況を再現というものです。 オセロのような完全情報ゲームであればこの方法で問題はないですが、トランプゲームのようなものはプログラムを一旦停止させて変数の中身を見てしまうと相手の手札がバレバレになるのがネックですね。
1そうだね
プレイ済み
返信[13]
親投稿
おちゃめ ochame_nako
きゃっきゃさんへ ありがとうございます。 プログラムそのものはシンプルなものですが、テクスチャのお陰でかなり映えるものになったと思います。 プチコンmkIIでは簡易地球儀はデフォ設定(R=64)で0.4fpsしか出ませんでした。 「R=64の地球儀をなめらか(30fps以上)に回転させる」というのがプチコンBIGでようやく実現可能になったわけであり、実際に実行してみれば旧3DS(2DS)のプチコン3号(2fps)、New3DSのプチコン3号(9fps)、プチコンBIG(33fps)の差は一目瞭然で「現時点でプチコンBIGの性能を最も体感できるプログラム」になっていると思います。
0そうだね
プレイ済み
返信[12]
親投稿
おちゃめ ochame_nako
(続き) とはいえ、このジオメトリ演算はARYOP命令を使うことで高速化が可能です。 プチコンBIGには高度サウンドユニット相当の命令が標準搭載されているのでARYOP命令を使うというのもありですが、ARYOP命令を使っても最低でも1ループ当たり1回の配列読み出しは必要になるためこのプログラムから大きな高速化(ARYOP命令を使うだけで数倍になるような高速化)は難しいと思います。 興味があればこのプログラムからどれだけ高速化が可能かに挑戦しても良いかもしれませんね。 うまくいけば2倍くらいの高速化も可能かもしれません。 プチコン3号版はQSPに収めるためそこまでの高速化はできませんでしたが、このBIG対応版は基本的にプチコン3号版と同一のアルゴリズムであるため高速化の余地は残されています。
0そうだね
プレイ済み
返信[11]
親投稿
おちゃめ ochame_nako
(続き) というわけでこのプログラムにもまだ高速化の余地が残されているのですが、このプログラムの最大の特徴はループ1回あたり配列の読み出しが1回のみということです。配列はプチコン3号やBIGにおいて非常に大きなボトルネックになっていてこれを減らせることがこのプログラムの最大の特色となっています。 回転だからといって普通に回転行列を使ってしまうと配列を使った演算を多数行う必要がありそれが低速化へと繋がります。 普通に計算すると12844回のループ回数が必要ということは12844頂点の3Dモデルの回転と同じだけの演算量となります。これは立方体を1606個回転させるのと同じだけの演算量になるため実際にプログラムを作らなくても非常に重い処理であることが簡単に分かることでしょう。 (下記に続く)
0そうだね
プレイ済み
返信[10]
親投稿
おちゃめ ochame_nako
はるさんへ 高速化というとループ回数を減らしたり演算ステップ数を減らすというのが重要となります。 ループ回数においてはこのプログラムではR=64の時に12844回となっていてこれは512x512のテクスチャを元に素直に変換した場合の262144回と比べると20分の1以下のループ回数になっているもののこれは上下をまとめて演算を行うことで半分に減らすことができます。 とはいえ、ループ回数が半分になっても演算ステップ数がそれほど変わらないので速度は思ったほど向上はしません。 演算ステップ数は「このプログラムが最小」と言いたいところですが、実はループの内側にあるU/2/PI()というのはループ内で変化しない値であるため例えばこれをN=U/2/PI()と置き換えてループ外に出してやるといとも簡単に1割程度の高速化が可能なのです。 (下記に続く)
1そうだね
プレイ済み
返信[2]
親投稿
おちゃめ ochame_nako
真上からの見下ろし型のレースゲームを作ろうとしているのですね。 縦横スクロールタイプか回転タイプかで作り方が多少変わってきますが必要なのは自車の移動(三角関数を使用)、BGとの当たり判定、周回判定、敵車の思考ルーチンです。 まず最初はシンプルにするためコースを自車が移動するだけのプログラムを作ってみると良いでしょう。(この時点では道路以外の場所も自由に走れる状態) 次に当たり判定を作り、そして周回判定を作り、それから敵車の思考ルーチンを作ると作りやすいと思います。 敵の思考ルーチンはできなくてもタイムアタック専用として機能しますが、それ以外は作れないとレースゲームとしては機能しにくいため頑張って作ってみてください。
3そうだね
プレイ済み
返信[7]
親投稿
おちゃめ ochame_nako
あとこのプログラムはGRPのサイズが1つあたり512KB(524316バイト)になってないのを不思議に思うかもしれません。 GRP:WORLD_MAPは126133バイト、GRP:KIRBYの方は2428バイトです。 これはGRPをプチコンBIGで一旦保存しているためです。 どうやらBIGではGRPに圧縮保存機能が加わってみたいで色数が多いWORLD_MAPの方は4分の1程度ですが、KIRBYの方は200分の1以下のサイズまで小さくなっています。 今後のバージョンアップでプチコン3号にもこの機能が加わるかもしれません。
1そうだね
プレイ済み
返信[6]
親投稿
おちゃめ ochame_nako
実はこのプログラムはテクスチャサイズは自由に変えることができます。 デフォルトでは上記のように512x512のテクスチャになっていますが、変数U(横方向のサイズ)、V(縦方向のサイズ)の設定値を変えることで様々な大きさのテクスチャに対応できます。 U=320、V=240に設定して読み込むファイル名を"KIRBY"に変更するとこんな表示になりピンクの球体をぐりぐり回転が可能になります。 地球儀だけではなく球体に自由なテクスチャを貼り付けて回転できるプログラムなのでいろいろなテクスチャ画像を作りスライドパッドで回転させて楽しんでください。
1そうだね
プレイ済み
返信[5]
親投稿
おちゃめ ochame_nako
このプログラムの原理は非常に単純で球体にテクスチャを貼り付けてそれを平行投影表示しているだけです。要するに1ドット単位で見え方を三角関数を使って計算しているとわけです。ただし、独自のアルゴリズムによってQSPで可能な範囲内でほぼ限界まで高速化しています。 大したことはやってないのですが、言葉で説明すると長くなるため割愛します。興味がある方で、このプログラムで分からない部分があれば言ってください。 また、左右方向のみではなく任意方向に回転させることは可能ですが、処理が遅くなるしリストも長くなるためこのプログラムでは左右回転のみの対応となっています。 陰影処理や3D立体視に対応することも容易に可能なので興味ある方は各自で改造してみてください。
0そうだね
プレイ済み
返信[4]
親投稿
おちゃめ ochame_nako
なお、このプログラムはそのまま無改造プチコンBIG上でも動作します。 さすがにプチコンBIGは高速でありデフォサイズだと30fps以上で動作し、負荷が4倍になるR=128とかでも約8fpsのそこそこスムーズな回転が可能です。 そのためプチコンBIG専用の高解像度対応版もこちらに用意しました。 https://miiverse.nintendo.net/posts/AYMHAAADAAB2V0feIfhp2Q この地球儀のテクスチャサイズは512x512なので表示サイズを大きくするとさらに見た目がキレイになります。 さすがのプチコンBIGでもR=192とかだと4fpsくらいに落ちてしまいますが。
1そうだね
プレイ済み
プレイ日記
おちゃめ ochame_nako
スライドパッドでぐりぐり回転できる地球儀プログラム「簡易地球儀 for BIG」です。
21そうだね
プレイ済み
返信[3]
親投稿
おちゃめ ochame_nako
表示サイズを大きくすればするほど処理は遅くなります。 ちなみにNew 3DSで動作時にはデフォルトの64ドットのサイズで9fps程度でそこそこスムーズに回転できます。 旧3DSや2DSならば2fps程度なので重いですが、R=32にすれば8fpsくらいになります。 これは以前私がプチコンmkIIで作ったプログラムの移植ですが、デフォサイズではmkIIでは0.4fps程度でした。(旧3DSでもmkIIの5倍速い!)
0そうだね
プレイ済み
返信[2]
親投稿
おちゃめ ochame_nako
回転速度はスライドパットで微調整できます。(左右回転のみに対応) デフォルトでは半径64ドット(R=64)の地球儀ですが、起動時に押している(正確には起動してから30フレーム以内に押している)ボタンによってサイズを任意に変えることができます。 Aボタンならば半径16ドット、Bボタンならば半径32ドット、Yボタンならば半径128ドットになります。
0そうだね
プレイ済み
返信[1]
親投稿
おちゃめ ochame_nako
これがプログラムリストです。公開キーは【 7XN4X3K4 】です。 フォルダにはテクスチャ用のGRPも同梱しています。(ピンクの例の奴は私の手書き、世界地図の方はパブリックドメインです)
2そうだね
プレイ済み